1.
Black Ops Of TCP/IP 2011<br />Dan Kaminsky, Chief Scientist, DKH<br />

2.
Intro<br />I’m Dan Kaminsky<br />I write code<br />Not here to fix authentication<br />Working on that<br />Not here to make DNSSEC scale<br />Working on that too<br />

3.
What I’m here for<br />Return to form<br />As a community, we’ve sort of stopped looking at network security<br />Mapping networks<br />Evading firewalls<br />Subverting design assumptions<br />This is probably the right thing – looking at attacks:<br />Acquire Beachhead<br />SQLi the web front end<br />PDF the client backend<br />Lilypad<br />Use acquired credentials to break everything else<br />Netsec is only so relevant in such an environment<br />

4.
So?<br />We’re going to look into it anyway. Maybe we’ll find something interesting.<br />

5.
BitCoin<br />“BitCoin turns nerd forums into libertarian forums”<br />It’s infected everything else in nerddom, why not this talk?<br />What is it?<br />Attempt at making a digital currency with no central bank<br />A system with economic properties I don’t know anything about<br />An overlay network upon the Internet that people think has certain properties<br />

6.
BitCoin In A Nutshell<br />Built on doing three things<br />TRANSFER: “I Alice, give Bob 2.1 BTC”<br />Alice signs the declaration to Bob’s public key<br />GOSSIP: “Heh everyone! Did you hear that Alice gave Bob 2.1 BTC?”<br />Alice sends that declaration into a peer to peer network that gossips the change<br />APPEND: “Everyone, the official registry of transactions should now include Alice paying Bob, Charlie paying David, and so on.”<br />This is gossiped too<br />Requires solving a problem so hard, it takes the world 10 minutes for someone to do it<br />If it takes less than 10 minutes, it’s not hard enough<br />Crypto lets you make things hard enough<br />Solving the problem gives you 50 BTC (today) to Transfer<br />

7.
The Truth Of Bitcoin<br />…this is not my BitCoin talk <br />Go to dankaminsky.com for a more detailed deck<br />BitCoin is actually really impressive<br />Entire classes of bugs are just missing<br />The first five times you think you understand it, you don’t<br />BitCoin has fixed almost all flaws that aren’t forced by the design<br />

8.
The Main Flaws (there are a few more)<br />Does not scale<br />Totally not anonymous<br />

9.
Scalability (from BitCoin’s Own Wiki)<br />Bandwidth<br />“Let's assume an average rate of 2000tps, so just VISA…. Shifting 60 gigabytes of data in, say, 60 seconds means an average rate of 1 gigabyte per second, or 8 gigabits per second.”<br />CPU<br /> ”A network node capable of keeping up with VISA would need roughly 50 cores + whatever is used for mining (done by separate machines/GPUs).”<br />Storage<br />“ A 3 terabyte hard disk costs less than $200 today and will be cheaper still in future, so you'd need one such disk for every 21 days of operation (at 1gb per block).”<br />

10.
OK, so you end up with supernodes and normal nodes<br />What are the characteristics of supernodes?<br />They’re banks<br />“Welcome to the new boss, who looks suspiciously like the old boss”<br />I’m not saying banks are bad or anything<br />The “peer to peer” model of BitCoin eventually goes away; as soon as the thing gets big, the entire thing switches to a banking model<br />With all the elements of banking people think BitCoin is immune to, without necessarily the properties people like<br />However, until then…<br />

11.
An Interesting Question<br />Travis Goodspeed: “Heh Dan, any chance BitCoin can be used as a samizdat service?”<br />Samizdat (Russian: самиздат; Russian pronunciation: [səmᵻˈzdat]) was a key form of dissidentactivity across the Soviet bloc in which individuals reproduced censored publications by hand and passed the documents from reader to reader.<br />An old challenge<br />The Internet is usually about sending data, ephemerally<br />Can we use it to store data, indefinitely?<br />Well, if BitCoin is eventually going to require a 3TB HD every 21 days…and is going to need to keep that data forever…<br />

12.
Len.<br />Our community recently lost one of its shining lights<br />If one executes:<br />strings --bytes=20 ~/.bitcoin/blk0001.dat <br />Strings extracts human readable text from any blob of data<br />Usually used to find hardcoded interesting stuff in executables, like default passwords<br />The block database of all transactions ever pushed into BitCoin, run through a filter that extracts all human readable text from the (presently) 450MB file…<br />

13.
BitLen<br />

14.
…and just because it would have made Len laugh<br />

15.
How This Works<br />In BitCoin, Alice gives money to Bob by issuing a sort of challenge<br />“Whoever can sign a message with the public key that hashes to the following bytes, may claim this money.”<br />Well, bytes are bytes<br />Instead of pushing the hash of a public key (20 bytes), we push 20 characters of a testimonial<br />

16.
Side Effect<br />This does cost BTC<br />About 1.0BTC in total<br />There’s minimums to transferring money<br />This does destroy the money<br />The network thinks somewhere, there must be a public key with a hash of “Len was our friend.”<br />I am OK with this.<br />It is the cyber equivalent of pouring one out for your homies.<br />

17.
Can we get higher bandwidth?<br />BitCoin lets you send money to a public key directly, rather than its hash<br />10x increase from 20 bytes to 200 bytes<br />This is not a bug<br />BitCoin allows for extra data in a signature<br />

18.
Signature Expansion<br />BitCoin works with small programs<br />The program from the receiver is: “Put this signature and public key on a stack”<br />The program from the sender is: “Take the signature and public key off the stack and make sure they’re good.”<br />The receiver can put extra stuff on the stack, and yes, it still works just fine<br />This is in fact a bug that is visible purely from being pedantic about the English Language<br />

19.
Illicit Signature Expansion<br />Signatures can’t cover themselves<br />Chicken and Egg<br />So signatures also don’t cover the presence or absence of additional data within themselves<br />Block appending does cover additional data<br />But there is time between when transactions are first created and emitted, and when they’re included in a block append<br />So it turns out anyone can add additional data to an otherwise valid transaction<br />

20.
Limited Usefulness<br />If you’re just some random relay, gossiping the information, you have to compete with the real version<br />Transaction fees limit you to about 1KB of embed per 0.01 BTC (14 cents)<br />This does not apply to you if you generate the signature with extra data, because then you can pay fees<br />This does not apply to you if you calculate the block – you can include as much as you want, up to present 2MB limit, and force everyone else to carry<br />Still better than 20 bytes per 0.01 BTC <br />Yes, Travis, bitcoinfs is totally possible<br />

21.
What about Anonymity? Looking at blockexplorer.com<br />Transaction Sources: These are all the same ID<br />Transaction Dst’s:One of these IDs is (likely) all of the IDs on the left<br />

22.
Graphs (from Reid/Harrigan)<br />

23.
Problem: Linking pseudonyms isn’t enough<br />Reid/Harrigan get lucky<br />One BitCoin source publishes the IPs it gives money to<br />Another user posted to a forum seeking donations to a linked ID<br />They’re linking pseudonyms within BC, but they’re not linking to IP via out of band processes<br />The published audit trail is noisy and deniable<br />“Naturally, much of this analysis is circumstantial. We cannot say for certain whether or not these flows imply a shared agency in both incidents. There is always the possibility of drawing false inferences.”<br />Is there another source of data?<br />

24.
P2P!<br />There are two sources of transaction information in BitCoin<br />The “blocks” that have been set in stone<br />The “loose transactions” waiting to be merged into blocks<br />These (effectively) always refer to a single identity<br />Both are “gossiped” around the network<br />Big relay race; Alice tells Bob and Charlie, Bob tells David and Eric, Charlie tells Frank and Gary<br />

25.
Subverting the Relay Race<br />An attacker can just connect to every node in the public cloud at once<br />“But that could take 50,000 connections!”<br />Yeah, we can do that in Python now. Kernels don’t suck anymore (well as much).<br />When you’re connected to every node, the first node to inform you of a transaction is the source of it<br />“Done relay it because done done it”<br />More or less true, and absolutely over time<br />(Bonus: You can accelerate your own transactions, by relaying them to everyone yourself)<br />BlitCoin – accelerated probing of BitCoin<br />

26.
Discovering Nodes<br />Just scan the Internet on 8333/TCP<br />Join the IRC channels!<br />#bitcoin, #bitcoin00 to #bitcoin99 on LFNET<br />BitBot<br />Recursively ask every node about every other node it knows about<br />“get_addr” message<br />Can start from hardcoded seeds<br />

27.
Statement From Gavin Andreson, lead dev on BitCoin<br />Bitcoin transactions are more private than credit card or PayPal transactions, but are less private than physical-world cash transactions. Unless you are very careful in the way you use Bitcoin (and you have the technical know-how to use it with other anonymizing technologies like Tor or i2p), you should assume that a persistent, motivated attacker will be able to associate your IP address with yourbitcoin transactions.<br />

28.
What about Tor?<br />Tor indeed obfuscates IPs derived from outbound connections<br />It does nothing if you’re still listening on 8333/tcp and somebody sweeps the net for you<br />Bug filed in BitCoin to shut off listener when operating through Tor<br />

29.
What about unreachable nodes?<br />Most are behind NAT, and only connect via outbound links<br />The active inbound set is only 3000-8000 nodes<br />So, you just create 3000-8000 nodes and you’re half the gossip network<br />Probably only need a few hundred, since each node will collect ~7 peers and you only need one<br />

30.
Just how unreachable are they?<br />Many users are behind wireless routers<br />Routers implement NAT – outbound is easy, inbound is hard<br />“Poor Man’s Firewall”<br />Don’t mock it, it was more effective than real firewalling when it came out<br />Most home routers implement UPNP – Universal Plug And Play<br />UPNP allows nodes inside your network to ask the router to open up ports from the Internet<br />BitCoin now supports doing this by default<br />…but even if it didn’t…<br />

31.
How UPNP is supposed to work<br />Internal hosts send a multicast message out via SSDP (Simple Service Discovery Protocol)<br />1900/UDP M-SEARCH Multicast<br />Internal UPNP nodes – media players, routers, etc – respond w/ endpoints that can be twiddled via web services requests<br />1900/UDP NOTIFY Unicast<br />Responses are sometimes just flooded out, in the absence of M-SEARCH<br />SSDP NOTIFY messages are supposed to contain a randomized URL for UPNP messages to go to<br />

32.
Question<br />UPNP is supposed to only work on internal interfaces<br />“Hello Router, please let the outside world in.”<br />It would be tragic if routers listened to UPNP on external interface as well..<br />“Hello Router, please let the outside world (read: me) in”<br />

33.
Stats (and yes, Scanrand’s coming back)<br />

34.
More Stats<br />Not all listeners on 2869 are fully open<br />Would require fixed UPNP endpoints, instead of the randomized ones Microsoft uses<br />Many verified listeners though<br />Hundreds of thousands to millions<br />Entire countries have standardized NATs that are vulnerable<br />

35.
Your Princess Is In Another Castle<br />Turns out there’s a speaker talking at DEFCON about just this very subject!<br />I’m a little more careful about independent rediscoveries now <br />Daniel Garcia found that there were open UPNP endpoints on the net last year<br />Track 3, Friday, 17:00<br />ArmijnHemelalso did some great work<br />upnp-hacks.org<br />Also noted that sometimes UPNP was exposed to outside world, back in ~2007<br />Still true, unfixed<br />

36.
What about outside the consumer space?<br />Corporate environments<br />Less about BitCoin and UPNP<br />More about web services and ACLs<br />Are there ways past corporate ACLs?<br />Access Control Lists<br />“Access to this IP is constrained to the following range”<br />

37.
Ye Olde Trick<br />IP Spoofing<br />Just pretend to be a source IP vaguely near the target, and you’ll probably pass ACLs<br />“But BCP’s!”<br />Real world, IP spoofing is not hard, as long as you’re not virtualized<br />IP spoofing – the one thing the cloud isn’t very good for<br />

38.
Is IP Spoofing Still Effective?<br />Sure! Let me just pull this DNS trick out of the archive…<br />Generate a query for “$RANDOM.attacker-domain.com”<br />Send query to all IPs on a network, from various IPs that network might trust<br />x.1.1.1 -> x.1.100.8<br />x.1.100.1 -> x.1.100.8<br />Response will go back to IP you don’t control – but first, the server will try to resolve $RANDOM.attacker-domain.com – from you!<br />(Yes, this was another way to exploit that bug.)<br />Granted, this only works for an obscure application like DNS and UDP…certainly nothing built on TCP <br />

39.
Understanding The Limits Of IP Spoofing<br />Most modern protocols run over TCP, a reliable communication protocol<br />1) Alice sends Bob a SYN, containing a random sequence number<br />2) Bob replies with a SYN|ACK, containing both Alice’s sequence number, and his own sequence number<br />3) Alice replies to Bob with an ACK, containing both sequence numbers<br />Data can be sent now<br />Sequence numbers become a sort of “password” for all future traffic<br />If Alice spoofs her IP, she doesn’t see Bob’s sequence number, so she can’t complete step 3<br />

40.
Sequence Numbers Didn’t Used To Be Random<br />Obviously if you can guess a sequence number, you can blindly inject into sessions<br />So, make them random?<br />Problem: Connections are identified by source port, dest port, source IP, and dest IP<br />24.1.2.3:50000 -> 4.2.2.1:53<br />Sometimes, ports are recycled from one connection to the next<br />What if a packet arrives from an old connection? It could look like it belongs in the new one!<br />Fix this by having random sequence numbers, unless id is the same, then we go sequential in time to maximize distance<br />

41.
Example<br />RFC1948<br />F(srcip, dstip, srcport, dstport,secret)+time<br />F==MD5<br />F(1.2.3.4,2.3.4.5,50000,80,”abcd”)==12341234time==1111seq==12341234+1111==12342345<br />F(1.2.3.4,2.3.4.6,50000,80,”abcd”)==89991121time==2000seq==89991121+2000==89992121<br />F(1.2.3.4,2.3.4.5,50000,80,”abcd”)==12341234time==5000seq==12341234+5000==12346234<br />

42.
A Problem: Memory<br />What if somebody just floods us with connection attempts?<br />They don’t have to remember all of our “passwords”<br />They don’t even need to use their own IP addresses<br />We need to remember all of theirs<br />This is a SYN flood, and it’s old as dirt<br />

43.
Solution: SYN Cookies<br />Specified (if not invented) by Dan Bernstein in 1999<br />Finally on by default in Linux in 2008<br />The “password” turns into a challenge<br />“If you can send this back to me, I’ll accept your data”<br />Uses 3/4ths of the sequence number (24 bits) to store the hash of a secret and the four tuple, 5 bits for time, three bits for connection metadata<br />5 bits is exposed to everyone publicly, 3 bits don’t matter, so there’s 24 bits of security<br />

44.
Alas<br />Average of 8 million packets to bypass SYN cookies<br />May be less, due to fudge factors<br />Of course DJB knew this <br />“No matter what function is used, the attacker will succeed in a connection forgery after millions of random ACK packets.”<br />But it’s a different reality than 1999<br />Sending 8M packets is easy now, we has the bandwidth<br />Forged connections have arbitrary sources<br />They get through your ACLs<br />They can contain arbitrary Web Services payloads<br />Definitely REST, maybe SOAP<br />

45.
Are you safe if you disable SYN cookies?<br />Well, not on Linux<br />Linux is RFC 1948 compliant for the lower 24 bits<br />Uses MD4, but still<br />Upper 8 bits?<br />Counter, starting at 0, increments every five minutes<br />Sequential<br />Shared between inbound and outbound connections<br />So, you send a query from your actual IP once or twice to find the offset, and blindly spoof a SYN and a payload-containing ACK<br />After 8M tries, you win<br />

46.
Impact on RST attacks<br />Tony Watson, “Slipping In The Window”<br />Noticed that only one 32 bit “password” was required for Resets (RSTs)<br />Noticed that the “password” only had to be in the “window” of valid data that could sequentially be sent<br />Window describes how many bytes a sender is allowed to transmit without a receiver acknowledging<br />Noticed that the “window” wasn’t even limited to 16 bits; was being expanded 5-8 bits more from “Window Scaling”<br />32-16-8 = 8 bits = 128 packets to kill a session on average<br />New possibility: 32 - 16 – 8 – 8 = 0 bits = 1 packet will always work (assuming full sized window)<br />

47.
Beyond RST: Injection?<br />RST handlers (usually) only check SEQ# (32 bits)<br />ACK handlers however check both SEQ# and ACK# (64 bits)<br />64 – (16 bits from Alice window) – (16 bits from server window) = 32 bits<br />2B packets for 50%<br />32 bits – (5 bits from Alice window scaling) – (5 bits from Bob window scaling) = 22 bits<br />1M packets for 50%<br />Uh oh<br />22 bits – (8 bits from Alice predictable high bits) – (8 bits from Bob predictable high bits) = 6 bits<br />16 packets for 50% <br />

48.
Difficulty: Ports<br />Linux randomizes the source port of a new connection by default<br />You don’t worry about this when you’re doing an ACL bypass, because you control the source port and the dest port<br />You do have to worry about this when injecting into other sessions though<br /> 6 bits (from large windows and high bit disclosure) + 13 bits (port leakage) = 19 bits<br />250K packets for 50% injection even with port randomization<br />Note that sometimes a TCP client sets its source port (DNS, BGP)<br />

49.
Status<br />This is very old code in Linux<br />Predates the check in history of LinusTorvalds<br />They’re figuring out the right fix that won’t cause even more problems<br />There are many potential wrong fixes that are even worse<br />

50.
A Digression<br />RFC1948 is an interesting construction<br />Sequential and ordered with the key<br />Random and unpredictable without<br />Can participate with either:<br />Aprivate component (the secret, mixed in with the 4-tuple), able to generate all possible sequence numbers<br />A public component (a sample sequence number), transmitted over the network, successfully received and retransmitted<br />Public/private cryptography with nothing but a password?<br />Clearly this is impossible<br />Only possible here because of intersection of network security and crypto<br />

51.
To be clear<br />Passwords are a bad idea<br />They’re constantly being lost and forgotten and stolen<br />They are responsible for 50% of compromises<br />They increasingly look like l33tspeak, and this is not helping<br />But, supposing we ignore all that…and assuming that we’re stuck with them…<br />

52.
An Old Challenge [0]<br />How do we use a password to log into a system without that system learning our password?<br />“We hash it!”<br />You’re still giving the server your plaintext password, it just isn’t storing it<br />If salt (random but public prefix) is omitted, attacker can precalculate hash->password database, notice when two users use the same one<br />

53.
An Old Challenge [1]<br /><ul><li>“We challenge you to hash against it properly”</li></ul>“Send me the password hashed against $RANDOM”<br />Digest/NTLM are more advanced versions<br />Requires server to store plaintext password or password equivalent<br />“We require knowledge of password to go from keypair to shared session secret”<br />SPEKE/SRP<br />Requires both client and server to run fairly obscure code – good luck getting either deployed<br />

54.
So…<br />Is it possible (NOT ADVISABLE, OBVIOUSLY THIS IS A BAD IDEA) to build a system where the client only remembers a password, but the server:<br />Stores nothing but a normal public key<br />Deploys nothing but a standard challenge to make sure the client has the matching private key, derived unilaterally from a password?<br />In other words…<br />Can we construct a keypair out of a password?<br />

55.
A Foreboding Question<br />What vulnerability impacted all asymmetric cryptosystems, be they RSA, DSA, or ECC?<br />

56.
…ok…<br />Debian<br />Specifically, a change to the way Debian calculated random numbers in OpenSSL<br />It always calculated the same numbers <br />All asymmetric cryptosystems use entropy as follows:<br />Collect: Grab random bits<br />Permute: Alter those bits until they meet certain requirements. Then emit a public/private keypair<br />Predictable entropy == Predictable keypairs, no matter the algorithm<br />

57.
Uh Oh<br />What if we turned the Debian bug…into a feature?<br />Cryptography is all about constructions<br />We have hash functions, stream ciphers, block ciphers, all of which can be constructed from eachother<br />Note too this is often a bad idea<br />We know how to take a password and construct an everlasting stream of psuedorandom numbers from it<br />“Predictable Entropy”<br />We can even do so in a way that is Hard, in both CPU time and Memory<br />scrypt<br />

58.
A TRULY TERRIFYING AND UGLY AND BAD AND AWESOME IDEA<br />What if you make the output of a password-seeded PRNG, the input to an asymmetric key generator?<br />You’d end up with 2048 bit RSA keypairs, with a “trapdoor” in the form of a password<br />This isn’t theoretical<br />

59.
Normal ssh-keygen<br /># ssh-keygen -f $RANDOM -N "" | grep -i root70:94:3d:4f:c8:c1:1a:a3:88:9a:77:d7:cf:9e:44:2a root<br /># ssh-keygen -f $RANDOM -N "" | grep -i root69:3e:11:4e:a5:5f:09:12:ac:e2:94:21:c4:3b:40:09 root<br /># ssh-keygen -f $RANDOM -N "" | grep -i rootd6:7c:3a:c2:d5:ec:84:88:9d:da:81:2b:6f:9a:c3:9b root<br />

60.
ssh-keygen using Phidelius<br /># LD_PRELOAD=./phidelius.so PH_PASS="hi grandma" ssh-keygen -f $RANDOM -N ""| grep -i rootad:0d:52:2a:72:be:77:e4:b5:ca:83:bb:4f:49:ce:d2 root<br /># LD_PRELOAD=./phidelius.so PH_PASS="hi grandma" ssh-keygen -f $RANDOM -N "" | grep -i rootad:0d:52:2a:72:be:77:e4:b5:ca:83:bb:4f:49:ce:d2 root<br />

61.
Enter Phidelius<br />Harry Potter, properly understood, is a story about the epic consequences of losing one’s password.<br />Fidelius is how passwords fail in the HP universe, so…<br />Phidelius hooks /dev/random, /dev/urandom, OpenSSL’s Random functions, and a few other tidbits to provide predictable entropy where it isn’t expected<br />Uses a modified version of scrypt to require ~1 second processing time, and about 256MB of RAM, per crack attempt<br />No GPU fun for you<br />Can be seeded with a file as well<br />

62.
What Phidelius Gives You<br />Generic, multi-application support for predictably generating keypairs from passwords<br />ssh-keygen for SSH keys<br />openssl for certificates<br />Phreebird for DNSSEC keys<br />Allows message signing, message encryption, client certificate authentication, etc. with nothing but a password<br />Solves the “log in with a password, without the system learning your password” problem thoroughly, without you having to store anything anywhere<br />With BitCoin, you could literally give money to the bearer of a word, or a photo.<br />

63.
No pain server side<br />All time/memory hard requirements are limited to the client – the server just implements completely standard crypto<br />

64.
Primary Issues With Phidelius<br />The obvious ones<br />It uses passwords<br />Passwords tend to be low entropy<br />The not obvious ones<br />It’s fragile<br />An explicit scheme to use a password to seed an RSA key, for instance, fixes parameters like “How sure do we need to be that this number is prime?”<br />As an implicit scheme, it depends on assumptions that happen to be encoded into a particular version of a particular key generator<br />It’s hard to salt<br />All users of the common password “password” have the same public/private keypair!<br />

65.
Salting with Phidelius<br />Basic idea is that the private key is computed not just from the password, but from the public key as well<br />The public key is then the carrier of the salt<br />Works for protocols like SSL, fails for protocols like PGP<br />Also a good channel of parameters, like “scrypt doesn’t need to use 256MB of RAM”<br />Can be implemented with no magic code on server, but client needs magic code to embed metadata in public key, and to extract said magic during computation of private<br />

66.
But, to get back to TCP/IP…<br />Lets talk about one last thing we can do with networks.<br />We can find biased network policy, no matter how subtle<br />If biased networks are affecting you, this gives you proof.<br />If you are biasing your network, this is how proof will come.<br />

67.
The Topology<br />Link 1<br />Google.com<br />Link 2<br />ISP<br />Client<br />Home Router<br />Microsoft.com<br />Yahoo.com<br />Link 3<br />

68.
Understanding the Target<br />1) “Magic box” is deployed within ISP network, in front of all links<br />2) Box matches packets to policies, and applies different rules to different packets<br />Can be stateless – “Do I like this packet?”<br />Can be stateful – “This packet is part of a flow. Do I like this flow?”<br />3) Policies can be anything and can do anything<br />Limit maximum bandwidth<br />Increase minimum latency<br />Alter content<br />

69.
The Problem With Subtlety<br />Say bing.com is 50ms slower than google.com<br />Is this because of the ISP?<br />Or is this because google.com has better hosting?<br />There are many reasons why bing.com might be slower than google.com, granting plausible deniability<br />

70.
Requirement: Normalization<br />Whether the tester is accessing bing.com or google.com, the network path should be identical (or at least uncorrelated)<br />We call this normalization<br />That way, any changes would be the result not of path, but of policy (presumably, and ultimately detectably, at the ISP)<br />

71.
Simple Normalization: HTTP<br />Policy: “All flows associated with a HTTP request w/ Host: www.bing.com should be delayed by 50ms”<br />Detector: Configure a single server to accept HTTP requests for www.bing.com, www.google.com, etc.<br />Then set the client to use it as a proxy server<br />If traffic from the proxy server is faster for some names, than it is for others, you’ve just detected a HTTP-biased policy!<br />

72.
The Problem<br />1) This is very protocol dependent<br />HTTP can be made to do this at low work<br />Other protocols require lots of work to implement/emulate<br />2) The policy can always be specific to IP addresses<br />Sniff DNS to learn which IPs to cover<br />Doesn’t matter how many hundreds of test servers you have, if policies are only applied to genuine bing.com or google.com servers<br />

73.
The Solution: N00ter<br />N00ter: The Network Normalization Engine<br />Start with a VPN<br />Traffic is pushed from the Client to a Broker<br />An IP associated with the Broker contacts Servers, who reply to the Broker<br />The Broker sends traffic back to the Client<br />Normally, the ISP sees nothing because traffic between Client and Broker is encrypted<br />Now, instead of encrypting traffic from Broker to Client, send it back to the client<br />Unencrypted<br />Spoofed, as if there was no Broker<br />

74.
SPOOFING ALL THE INTERNET<br />We want the ISP to see our return traffic<br />We’re trying to trigger the response, that would normally be reserved for Bing/Google, for our normalized test server<br />Policy engine can’t tell, because we’re impersonating the real entities<br />Traffic took the same path<br />Traffic came from the same source<br />Why else would we see different Quality of Service?<br />

75.
What About Forward Flow?<br />The policy engine in this scenario doesn’t see traffic from Client to Server<br />That’s encrypted, VPN style<br />What if it just didn’t trigger the filtering policy if it didn’t see both sides of the conversation?<br />

76.
<br />

77.
ENTER ROTO N00TER<br />Normal N00ter: Spoof the server to the client<br />RotoNooter: Spoof the client to the server<br />Sample A: Client talks directly to the real Google<br />ISP sees SYN<br />Sample B: Client talks to real Google by way of Broker, who spoofs the Client. Google replies directly.<br />ISP does not see SYN<br />Both samples have the same path!<br />If they have different performance characteristics, it must be because of the segment of the network that no longer sees client traffic – the ISP!<br />

78.
Catch-22<br />If ISP applies policy to half-flows, N00ter can differentiate the performance of the spoofed half flow of Google, versus the spoofed half flow from Bing<br />If ISP applies policy only to full flows, RotoNooter can differentiate the performance of the full flow to and from the real Google, versus the half flow from the real Google<br />Either way, N00ter Wins<br />This is the endgame. Biased policies might as well be transparent, because they’re not going to be deniable.<br />

79.
Retaining Full Flows<br />Suppose you really want the ISP to see bidirectional traffic<br />Advantage: Triggers all policies. Also, opens up listeners for NATs, that might be inconvenient to get around<br />Disadvantage: If the ISP sees Client->Server traffic, then the Server sees Client->Server traffic<br />It may reply, interfere, complain, etc.<br />

80.
Strategy 1: Bad TCP Checksum<br />Client can tunnel valid traffic to Broker, and push packets with invalid TCP checksums to Server<br />Advantage: Invalid TCP checksums are ignored. Server won’t interfere. NAT almost certainly won’t check sums; Policy engine might not<br />Disadvantage: Policy engine could. NAT might fix sums.<br />Catch-22 with checksums<br />If policy is disabled when checksums are bad, policy can be proven by having Broker provide steady stream of good sums while ISP sees the bad ones<br />

81.
Strategy 2: Low TTL<br />Client can send traffic to Server with TTL that causes packets to be dropped in the middle of the Internet<br />Advantage: Legitimate traffic.<br />Disadvantage: Policy could note low TTL. Router may drop sessions from ICMP Time Exceeded messages. Sort of a router DoS.<br />Another Catch-22: Can probably even figure out which hop the policy engine lives at, by when precisely the flow policy shifts<br />

82.
Strategy 3: The Silent Splice<br />When a TCP stack receives a message not associated with an active socket, it’s supposed to RST<br />But many servers have firewalls that silently ignore unassociated messages<br />For Security!<br />We can have the Client complete a three way handshake with a server, snipe the connection with a RST from the Broker, and then splice a connection between Broker and Server, with what Client (and ISP) think is a connection between Client and Server<br />Packets from Client to Server will be ignored by server<br />Packets from Server to Client are actually spoofed by Broker<br />Policy Engine sees client talking to server. Policy Engine sees server talking to client. You can’t explain that.<br />100% Perfect Bidirectional Flow<br />

83.
A Bit Of Warning<br />If you’re passively monitoring network traffic, be aware that these techniques do mean a malicious client can make it look like they’re having a conversation with anyone<br />Particularly if the server ignores unassociated traffic<br />Keep complete traffic logs!<br />Validate checksums<br />Check TTLs<br />

84.
Where N00ter Is Now<br />Emulates half flows at present<br />Very very fast (written to the old LibPaketto code!)<br />Supports anything that runs over IP<br />If you want to know whether a network prefers XBOX360 traffic to Playstation 3 traffic, this’ll tell you.<br />N00ter is extremely neutral – It Just Works<br />Again, it’s just a VPN that exposes Server->Client traffic in the hopes it’ll get filtered <br />

85.
Summary<br />Networks are neat<br />BitCoin isn’t anonymous<br />UPNP sometimes exposes itself to the outside world<br />ACLs can be bypassed using some interesting sequence number tricks and large number of packets<br />Passwords can be used to seed asymmetric crypto, though they probably shouldn’t<br />Subtle net neutrality hacks are doomed. Transparency or bust.<br />Research hosting thanks to N2K of 3Crowd and Doxx of LyonLabs<br />Anyone want to do some release engineering for me? <br />