Black Ops of TCP/IP 2011 (Black Hat USA 2011)

Black Ops Of TCP/IP 2011Dan Kaminsky, Chief Scientist, DKH

IntroI’m Dan KaminskyI write codeNot here to fix authenticationWorking on thatNot here to make DNSSEC scaleWorking on that too

What I’m here forReturn to formAs a community, we’ve sort of stopped looking at network securityMapping networksEvading firewallsSubverting design assumptionsThis is probably the right thing – looking at attacks:Acquire BeachheadSQLi the web front endPDF the client backendLilypadUse acquired credentials to break everything elseNetsec is only so relevant in such an environment

So?We’re going to look into it anyway. Maybe we’ll find something interesting.

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

BitCoin In A NutshellBuilt on doing three thingsTRANSFER: “I Alice, give Bob 2.1 BTC”Alice signs the declaration to Bob’s public keyGOSSIP: “Heh everyone! Did you hear that Alice gave Bob 2.1 BTC?”Alice sends that declaration into a peer to peer network that gossips the changeAPPEND: “Everyone, the official registry of transactions should now include Alice paying Bob, Charlie paying David, and so on.”This is gossiped tooRequires solving a problem so hard, it takes the world 10 minutes for someone to do itIf it takes less than 10 minutes, it’s not hard enoughCrypto lets you make things hard enoughSolving the problem gives you 50 BTC (today) to Transfer

The Truth Of Bitcoin…this is not my BitCoin talk Go to dankaminsky.com for a more detailed deckBitCoin is actually really impressiveEntire classes of bugs are just missingThe first five times you think you understand it, you don’tBitCoin has fixed almost all flaws that aren’t forced by the design

The Main Flaws (there are a few more)Does not scaleTotally not anonymous

Scalability (from BitCoin’s Own Wiki)Bandwidth“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.”CPU ”A network node capable of keeping up with VISA would need roughly 50 cores + whatever is used for mining (done by separate machines/GPUs).”Storage“ 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).”

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

An Interesting QuestionTravis Goodspeed: “Heh Dan, any chance BitCoin can be used as a samizdat service?”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.An old challengeThe Internet is usually about sending data, ephemerallyCan we use it to store data, indefinitely?Well, if BitCoin is eventually going to require a 3TB HD every 21 days…and is going to need to keep that data forever…

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

…and just because it would have made Len laugh

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

Side EffectThis does cost BTCAbout 1.0BTC in totalThere’s minimums to transferring moneyThis does destroy the moneyThe network thinks somewhere, there must be a public key with a hash of “Len was our friend.”I am OK with this.It is the cyber equivalent of pouring one out for your homies.

Can we get higher bandwidth?BitCoin lets you send money to a public key directly, rather than its hash10x increase from 20 bytes to 200 bytesThis is not a bugBitCoin allows for extra data in a signature

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

Illicit Signature ExpansionSignatures can’t cover themselvesChicken and EggSo signatures also don’t cover the presence or absence of additional data within themselvesBlock appending does cover additional dataBut there is time between when transactions are first created and emitted, and when they’re included in a block appendSo it turns out anyone can add additional data to an otherwise valid transaction

Limited UsefulnessIf you’re just some random relay, gossiping the information, you have to compete with the real versionTransaction fees limit you to about 1KB of embed per 0.01 BTC (14 cents)This does not apply to you if you generate the signature with extra data, because then you can pay feesThis 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 carryStill better than 20 bytes per 0.01 BTC Yes, Travis, bitcoinfs is totally possible

What about Anonymity? Looking at blockexplorer.comTransaction Sources: These are all the same IDTransaction Dst’s:One of these IDs is (likely) all of the IDs on the left

Problem: Linking pseudonyms isn’t enoughReid/Harrigan get luckyOne BitCoin source publishes the IPs it gives money toAnother user posted to a forum seeking donations to a linked IDThey’re linking pseudonyms within BC, but they’re not linking to IP via out of band processesThe published audit trail is noisy and deniable“Naturally, much of this analysis is circumstantial. We cannot say for certain whether or not these ﬂows imply a shared agency in both incidents. There is always the possibility of drawing false inferences.”Is there another source of data?

P2P!There are two sources of transaction information in BitCoinThe “blocks” that have been set in stoneThe “loose transactions” waiting to be merged into blocksThese (effectively) always refer to a single identityBoth are “gossiped” around the networkBig relay race; Alice tells Bob and Charlie, Bob tells David and Eric, Charlie tells Frank and Gary

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

Discovering NodesJust scan the Internet on 8333/TCPJoin the IRC channels!#bitcoin, #bitcoin00 to #bitcoin99 on LFNETBitBotRecursively ask every node about every other node it knows about“get_addr” messageCan start from hardcoded seeds

Statement From Gavin Andreson, lead dev on BitCoinBitcoin 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.

What about Tor?Tor indeed obfuscates IPs derived from outbound connectionsIt does nothing if you’re still listening on 8333/tcp and somebody sweeps the net for youBug filed in BitCoin to shut off listener when operating through Tor

What about unreachable nodes?Most are behind NAT, and only connect via outbound linksThe active inbound set is only 3000-8000 nodesSo, you just create 3000-8000 nodes and you’re half the gossip networkProbably only need a few hundred, since each node will collect ~7 peers and you only need one

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

How UPNP is supposed to workInternal hosts send a multicast message out via SSDP (Simple Service Discovery Protocol)1900/UDP M-SEARCH MulticastInternal UPNP nodes – media players, routers, etc – respond w/ endpoints that can be twiddled via web services requests1900/UDP NOTIFY UnicastResponses are sometimes just flooded out, in the absence of M-SEARCHSSDP NOTIFY messages are supposed to contain a randomized URL for UPNP messages to go to

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

Stats (and yes, Scanrand’s coming back)

More StatsNot all listeners on 2869 are fully openWould require fixed UPNP endpoints, instead of the randomized ones Microsoft usesMany verified listeners thoughHundreds of thousands to millionsEntire countries have standardized NATs that are vulnerable

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

What about outside the consumer space?Corporate environmentsLess about BitCoin and UPNPMore about web services and ACLsAre there ways past corporate ACLs?Access Control Lists“Access to this IP is constrained to the following range”

Ye Olde TrickIP SpoofingJust pretend to be a source IP vaguely near the target, and you’ll probably pass ACLs“But BCP’s!”Real world, IP spoofing is not hard, as long as you’re not virtualizedIP spoofing – the one thing the cloud isn’t very good for

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

Understanding The Limits Of IP SpoofingMost modern protocols run over TCP, a reliable communication protocol1) Alice sends Bob a SYN, containing a random sequence number2) Bob replies with a SYN|ACK, containing both Alice’s sequence number, and his own sequence number3) Alice replies to Bob with an ACK, containing both sequence numbersData can be sent nowSequence numbers become a sort of “password” for all future trafficIf Alice spoofs her IP, she doesn’t see Bob’s sequence number, so she can’t complete step 3

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

ExampleRFC1948F(srcip, dstip, srcport, dstport,secret)+timeF==MD5F(1.2.3.4,2.3.4.5,50000,80,”abcd”)==12341234time==1111seq==12341234+1111==12342345F(1.2.3.4,2.3.4.6,50000,80,”abcd”)==89991121time==2000seq==89991121+2000==89992121F(1.2.3.4,2.3.4.5,50000,80,”abcd”)==12341234time==5000seq==12341234+5000==12346234

A Problem: MemoryWhat if somebody just floods us with connection attempts?They don’t have to remember all of our “passwords”They don’t even need to use their own IP addressesWe need to remember all of theirsThis is a SYN flood, and it’s old as dirt

Solution: SYN CookiesSpecified (if not invented) by Dan Bernstein in 1999Finally on by default in Linux in 2008The “password” turns into a challenge“If you can send this back to me, I’ll accept your data”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 metadata5 bits is exposed to everyone publicly, 3 bits don’t matter, so there’s 24 bits of security

AlasAverage of 8 million packets to bypass SYN cookiesMay be less, due to fudge factorsOf course DJB knew this “No matter what function is used, the attacker will succeed in a connection forgery after millions of random ACK packets.”But it’s a different reality than 1999Sending 8M packets is easy now, we has the bandwidthForged connections have arbitrary sourcesThey get through your ACLsThey can contain arbitrary Web Services payloadsDefinitely REST, maybe SOAP

Are you safe if you disable SYN cookies?Well, not on LinuxLinux is RFC 1948 compliant for the lower 24 bitsUses MD4, but stillUpper 8 bits?Counter, starting at 0, increments every five minutesSequentialShared between inbound and outbound connectionsSo, you send a query from your actual IP once or twice to find the offset, and blindly spoof a SYN and a payload-containing ACKAfter 8M tries, you win

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

Beyond RST: Injection?RST handlers (usually) only check SEQ# (32 bits)ACK handlers however check both SEQ# and ACK# (64 bits)64 – (16 bits from Alice window) – (16 bits from server window) = 32 bits2B packets for 50%32 bits – (5 bits from Alice window scaling) – (5 bits from Bob window scaling) = 22 bits1M packets for 50%Uh oh22 bits – (8 bits from Alice predictable high bits) – (8 bits from Bob predictable high bits) = 6 bits16 packets for 50% 

Difficulty: PortsLinux randomizes the source port of a new connection by defaultYou don’t worry about this when you’re doing an ACL bypass, because you control the source port and the dest portYou do have to worry about this when injecting into other sessions though 6 bits (from large windows and high bit disclosure) + 13 bits (port leakage) = 19 bits250K packets for 50% injection even with port randomizationNote that sometimes a TCP client sets its source port (DNS, BGP)

StatusThis is very old code in LinuxPredates the check in history of LinusTorvaldsThey’re figuring out the right fix that won’t cause even more problemsThere are many potential wrong fixes that are even worse

A DigressionRFC1948 is an interesting constructionSequential and ordered with the keyRandom and unpredictable withoutCan participate with either:Aprivate component (the secret, mixed in with the 4-tuple), able to generate all possible sequence numbersA public component (a sample sequence number), transmitted over the network, successfully received and retransmittedPublic/private cryptography with nothing but a password?Clearly this is impossibleOnly possible here because of intersection of network security and crypto

To be clearPasswords are a bad ideaThey’re constantly being lost and forgotten and stolenThey are responsible for 50% of compromisesThey increasingly look like l33tspeak, and this is not helpingBut, supposing we ignore all that…and assuming that we’re stuck with them…

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

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

So…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:Stores nothing but a normal public keyDeploys nothing but a standard challenge to make sure the client has the matching private key, derived unilaterally from a password?In other words…Can we construct a keypair out of a password?

A Foreboding QuestionWhat vulnerability impacted all asymmetric cryptosystems, be they RSA, DSA, or ECC?

…ok…DebianSpecifically, a change to the way Debian calculated random numbers in OpenSSLIt always calculated the same numbers All asymmetric cryptosystems use entropy as follows:Collect: Grab random bitsPermute: Alter those bits until they meet certain requirements. Then emit a public/private keypairPredictable entropy == Predictable keypairs, no matter the algorithm

Uh OhWhat if we turned the Debian bug…into a feature?Cryptography is all about constructionsWe have hash functions, stream ciphers, block ciphers, all of which can be constructed from eachotherNote too this is often a bad ideaWe know how to take a password and construct an everlasting stream of psuedorandom numbers from it“Predictable Entropy”We can even do so in a way that is Hard, in both CPU time and Memoryscrypt

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

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

ssh-keygen using Phidelius# 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# 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

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

What Phidelius Gives YouGeneric, multi-application support for predictably generating keypairs from passwordsssh-keygen for SSH keysopenssl for certificatesPhreebird for DNSSEC keysAllows message signing, message encryption, client certificate authentication, etc. with nothing but a passwordSolves the “log in with a password, without the system learning your password” problem thoroughly, without you having to store anything anywhereWith BitCoin, you could literally give money to the bearer of a word, or a photo.

No pain server sideAll time/memory hard requirements are limited to the client – the server just implements completely standard crypto

Primary Issues With PhideliusThe obvious onesIt uses passwordsPasswords tend to be low entropyThe not obvious onesIt’s fragileAn 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?”As an implicit scheme, it depends on assumptions that happen to be encoded into a particular version of a particular key generatorIt’s hard to saltAll users of the common password “password” have the same public/private keypair!

Salting with PhideliusBasic idea is that the private key is computed not just from the password, but from the public key as wellThe public key is then the carrier of the saltWorks for protocols like SSL, fails for protocols like PGPAlso a good channel of parameters, like “scrypt doesn’t need to use 256MB of RAM”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

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

The TopologyLink 1Google.comLink 2ISPClientHome RouterMicrosoft.comYahoo.comLink 3

Understanding the Target1) “Magic box” is deployed within ISP network, in front of all links2) Box matches packets to policies, and applies different rules to different packetsCan be stateless – “Do I like this packet?”Can be stateful – “This packet is part of a flow. Do I like this flow?”3) Policies can be anything and can do anythingLimit maximum bandwidthIncrease minimum latencyAlter content

The Problem With SubtletySay bing.com is 50ms slower than google.comIs this because of the ISP?Or is this because google.com has better hosting?There are many reasons why bing.com might be slower than google.com, granting plausible deniability

Requirement: NormalizationWhether the tester is accessing bing.com or google.com, the network path should be identical (or at least uncorrelated)We call this normalizationThat way, any changes would be the result not of path, but of policy (presumably, and ultimately detectably, at the ISP)

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

The Problem1) This is very protocol dependentHTTP can be made to do this at low workOther protocols require lots of work to implement/emulate2) The policy can always be specific to IP addressesSniff DNS to learn which IPs to coverDoesn’t matter how many hundreds of test servers you have, if policies are only applied to genuine bing.com or google.com servers

The Solution: N00terN00ter: The Network Normalization EngineStart with a VPNTraffic is pushed from the Client to a BrokerAn IP associated with the Broker contacts Servers, who reply to the BrokerThe Broker sends traffic back to the ClientNormally, the ISP sees nothing because traffic between Client and Broker is encryptedNow, instead of encrypting traffic from Broker to Client, send it back to the clientUnencryptedSpoofed, as if there was no Broker

SPOOFING ALL THE INTERNETWe want the ISP to see our return trafficWe’re trying to trigger the response, that would normally be reserved for Bing/Google, for our normalized test serverPolicy engine can’t tell, because we’re impersonating the real entitiesTraffic took the same pathTraffic came from the same sourceWhy else would we see different Quality of Service?

What About Forward Flow?The policy engine in this scenario doesn’t see traffic from Client to ServerThat’s encrypted, VPN styleWhat if it just didn’t trigger the filtering policy if it didn’t see both sides of the conversation?

ENTER ROTO N00TERNormal N00ter: Spoof the server to the clientRotoNooter: Spoof the client to the serverSample A: Client talks directly to the real GoogleISP sees SYNSample B: Client talks to real Google by way of Broker, who spoofs the Client. Google replies directly.ISP does not see SYNBoth samples have the same path!If they have different performance characteristics, it must be because of the segment of the network that no longer sees client traffic – the ISP!

Catch-22If ISP applies policy to half-flows, N00ter can differentiate the performance of the spoofed half flow of Google, versus the spoofed half flow from BingIf 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 GoogleEither way, N00ter WinsThis is the endgame. Biased policies might as well be transparent, because they’re not going to be deniable.

Retaining Full FlowsSuppose you really want the ISP to see bidirectional trafficAdvantage: Triggers all policies. Also, opens up listeners for NATs, that might be inconvenient to get aroundDisadvantage: If the ISP sees Client->Server traffic, then the Server sees Client->Server trafficIt may reply, interfere, complain, etc.

Strategy 1: Bad TCP ChecksumClient can tunnel valid traffic to Broker, and push packets with invalid TCP checksums to ServerAdvantage: Invalid TCP checksums are ignored. Server won’t interfere. NAT almost certainly won’t check sums; Policy engine might notDisadvantage: Policy engine could. NAT might fix sums.Catch-22 with checksumsIf 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

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

Strategy 3: The Silent SpliceWhen a TCP stack receives a message not associated with an active socket, it’s supposed to RSTBut many servers have firewalls that silently ignore unassociated messagesFor Security!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 ServerPackets from Client to Server will be ignored by serverPackets from Server to Client are actually spoofed by BrokerPolicy Engine sees client talking to server. Policy Engine sees server talking to client. You can’t explain that.100% Perfect Bidirectional Flow

A Bit Of WarningIf 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 anyoneParticularly if the server ignores unassociated trafficKeep complete traffic logs!Validate checksumsCheck TTLs

Where N00ter Is NowEmulates half flows at presentVery very fast (written to the old LibPaketto code!)Supports anything that runs over IPIf you want to know whether a network prefers XBOX360 traffic to Playstation 3 traffic, this’ll tell you.N00ter is extremely neutral – It Just WorksAgain, it’s just a VPN that exposes Server->Client traffic in the hopes it’ll get filtered 

SummaryNetworks are neatBitCoin isn’t anonymousUPNP sometimes exposes itself to the outside worldACLs can be bypassed using some interesting sequence number tricks and large number of packetsPasswords can be used to seed asymmetric crypto, though they probably shouldn’tSubtle net neutrality hacks are doomed. Transparency or bust.Research hosting thanks to N2K of 3Crowd and Doxx of LyonLabsAnyone want to do some release engineering for me? 

Black Ops of TCP/IP 2011 (Black Hat USA 2011)

More Related Content

What's hot (20)

Similar to Black Ops of TCP/IP 2011 (Black Hat USA 2011) (20)

More from Dan Kaminsky (20)

Recently uploaded (20)

Black Ops of TCP/IP 2011 (Black Hat USA 2011)