Black Ops of TCP/IP 2011
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 122 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/40551 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 1992 / 122
3
5
10
11
12
22
23
24
30
31
32
38
43
46
47
49
51
54
56
59
60
62
71
73
76
84
85
88
92
93
96
97
98
104
106
109
112
113
115
119
00:00
AuthenticationScale (map)CodeIntegrated development environmentComputer networkInformation securityProbability density functionInternet forumDigital signalPhysical systemOverlay-NetzInternetworkingHeat transferWindows RegistryDatabase transactionInclusion mapSign (mathematics)Peer-to-peerHypothesisEntire functionSocial classWikiScalabilityBefehlsprozessorData storage deviceBand matrixBit rateAverageMiniDiscMilitary operationBlock (periodic table)Vertex (graph theory)Characteristic polynomialInheritance (object-oriented programming)Data modelBoss CorporationElement (mathematics)Execution unitString (computer science)DatabaseDigital filterPasswordDefault (computer science)Hash functionMessage passingSoftware bugScalabilityComputer networkFitness functionCryptographyMessage passingScaling (geometry)BefehlsprozessorMultiplication signWikiData storage deviceLine (geometry)Closed setEndliche ModelltheorieLengthHard disk driveFlash memoryCategory of beingSoftware engineeringNumbering schemePoint (geometry)Overlay-NetzSoftwareDebuggerDirect numerical simulationHacker (term)Database transactionCentralizer and normalizerInternetworkingQuicksortComputational fluid dynamicsType colorSoftware testingGotcha <Informatik>CodeRow (database)Logistic distributionPhysical systemProbability density functionFirewall (computing)Game theoryDisk read-and-write headMappingInformation securityOperator (mathematics)Public-key cryptographyDirected graphVideo gameIntegrated development environmentWeb 2.0Client (computing)Service (economics)Virtual machine2 (number)FamilyString (computer science)InformationCore dumpWeb pageGoodness of fitBlock (periodic table)Data miningWordDivisorSequelSmoothingDatabaseDistribution (mathematics)Heat transferSlide ruleComputer animationLecture/Conference
08:44
Total S.A.Computer networkHash functionCybersexBand matrixElectronic signatureComputer programStack (abstract data type)Formal languageThermal expansionDatabase transactionBlock (periodic table)Revision controlInformationRandom numberLimit (category theory)Source codeGraph (mathematics)Link (knot theory)TrailInternet forumLinker (computing)Musical ensembleProcess (computing)Mathematical analysisInferenceIdentity managementPoint cloudKernel (computing)Vertex (graph theory)InternetworkingLattice (order)Message passingStatement (computer science)PlastikkarteIntegral domainAddress spaceOperations researchWireless LANRouter (computing)ImplementationFirewall (computing)Default (computer science)Interface (computing)TrailService (economics)InternetworkingSet (mathematics)Firewall (computing)PermanentMereologySource codeAuthorizationComputer networkIntrusion detection systemMultiplication signData storage deviceInformationCountingDatabase transactionLimit (category theory)Band matrixConnected spaceGodRow (database)Block (periodic table)Coma BerenicesEquivalence relationCybersexHash functionInheritance (object-oriented programming)VideoconferencingTheoryPerspective (visual)Computer fileCommunications protocolRouter (computing)Key (cryptography)PseudonymizationMusical ensemblePhysical systemRight angleInternet forumQuicksortProcess (computing)Graph (mathematics)OvalElectronic signatureContent (media)Software bugStack (abstract data type)Game controllerCodeFingerprintMetropolitan area networkMessage passingRandomizationComputer programmingMaxima and minimaComputational fluid dynamicsMathematicsPublic-key cryptographyDemo (music)WebsiteIP addressLevel (video gaming)Constraint (mathematics)Information securityFormal language2 (number)File systemObject-oriented programmingCovering spaceSign (mathematics)Streaming mediaGoodness of fit
17:14
StatisticsEntire functionIndependence (probability theory)TrailSpacetimeIntegrated development environmentElectronic mailing listZugriffskontrolleRange (statistics)Service (economics)Source codeReal numberPoint cloudDirect numerical simulationUDP <Protokoll>Query languageComputer networkDependent and independent variablesServer (computing)Limit (category theory)TelecommunicationCommunications protocolSequenceNumberPasswordRandom numberRead-only memoryAddress spaceHTTP cookieBernstein polynomialHash functionTupleDefault (computer science)Information securityFaktorenanalyseFunction (mathematics)Band matrixUsabilityComputer wormWindowScaling (geometry)AverageInjektivitätClient (computing)Control flowProxy serverRandomizationCodeTorvalds, LinusCryptographyEuclidean vectorPhysical systemDatabaseRevision controlEquivalence relationNormal (geometry)Matching (graph theory)Standard deviationVorwärtsfehlerkorrekturCryptosystemRSA (algorithm)Entropie <Informationstheorie>AlgorithmPermutationStreaming mediaBlock (periodic table)NP-hardBefehlsprozessoroutputRootUniverse (mathematics)Process (computing)Message passingEncryptionGeneric programmingMultiplicationPublic key certificateAuthenticationDigital photographyKey (cryptography)Numbering schemeParameter (computer programming)Instance (computer science)Prime idealCharge carrierProof theoryNetwork topologyRule of inferenceInternet service providerLink (knot theory)Maxima and minimaContent (media)GoogolDatabase normalizationSoftware testingConfiguration spaceLatent heatVirtuelles privates NetzwerkComputer networkService-oriented architectureInternetworkingDataflowSample (statistics)Characteristic polynomialStrategy gameSummierbarkeitQuicksortRouter (computing)Stack (abstract data type)Network socketFirewall (computing)Perfect groupEmulatorCausalityMaxima and minimaPasswordService-oriented architectureServer (computing)Hacker (term)Multiplication signCodeBitIdentifiabilityMoving averageSource codeFirewall (computing)Speech synthesisMereologyNumberIn-System-ProgrammierungModemForm (programming)CASE <Informatik>Client (computing)RandomizationDifferent (Kate Ryan album)Set (mathematics)Connected spaceGame controllerAsymmetryMathematicsSoftware bugWeb pageCommunications protocolData conversionPhysical lawRange (statistics)InternetworkingCuboidWindowOnline helpDataflowGodLink (knot theory)Direction (geometry)Normal (geometry)Strategy gameInformation securityLoginHTTP cookieWordDigital photographyElectronic mailing listKey (cryptography)HookingDenial-of-service attackInstance (computer science)Game theoryCartesian coordinate systemLimit (category theory)FreewareSequenceArithmetic meanCryptographyBasis <Mathematik>1 (number)Computer clusterPhysical systemAuthorizationConsistencyComputer networkIdentity managementRouter (computing)GoogolPublic key certificateNP-hardSemiconductor memoryInheritance (object-oriented programming)Characteristic polynomialMessage passingSoftware testingSampling (statistics)Rule of inferenceVulnerability (computing)Dependent and independent variablesPredictabilityEncryptionReal numberTrailProof theoryCore dumpResultantExploit (computer security)Point (geometry)Moment (mathematics)Domain nameData storage deviceWeb 2.0Proxy serverGoodness of fitIP addressLevel (video gaming)Type theoryOffice suiteOpen setFunctional (mathematics)Universe (mathematics)Direct numerical simulationInformationRandom number generationNumbering schemeBlogEuklidischer RaumPublic-key cryptographyFunction (mathematics)RoutingConnectivity (graph theory)outputIntegrated development environmentRevision controlEquivalence relationValidity (statistics)Type colorPoint cloudDifferential (mechanical device)Block (periodic table)Constructor (object-oriented programming)Hash functionAlgorithmEntropie <Informationstheorie>Web applicationStreaming mediaBefehlsprozessorCross-site scriptingPseudozufallszahlenStream cipherScaling (geometry)Web serviceDefault (computer science)CryptosystemFilm editingRight angleData Encryption StandardContent (media)DatabaseSineBand matrixFingerprintComa BerenicesAddress spaceStructural loadSpacetimeSummierbarkeitWebsiteLatent heatUniform resource locatorKnotAmsterdam Ordnance DatumAuthenticationSign (mathematics)AirfoilInjektivitätNetwork topologyAutomatic differentiationStandard deviationComputer animation
Transcript: English(auto-generated)
00:00
So hello, everyone. It is great to be here at DEF CON 19. Thank you all for being here. If you don't know me, hi, I'm Dan Kaminsky and I write code. I am not here to fix authentication or regale you with stories of DNS or DNSSEC. These are still things
00:24
I'm working on, but not today. Today is a return to form. As a community, we have sort of ‑‑ was anyone here out of curiosity at my talk in 2002 about black ops TCPIP? Anyone? Awesome. This is a sequel to that talk. Got it? First impression ever.
00:57
Let's see. How about this? Is this good? Logistics. How about this? Does this work?
01:14
Awesome. Thank you, guys. All right. So we sort of stopped looking at network security, you know, mapping networks, evading firewalls, subverting design assumptions. You know,
01:23
the various arts of messing with packets have kind of been abandoned and that's sort of a good thing. You know, when you actually look at how systems are broken into, it's the same game every time. Sequel inject the web front end or PDF the client back end. Take whatever credentials are on the box and move on with your life.
01:41
It's not hard. Making hacking look difficult is just something we do so we look awesome to the other people. So NetSec is only so relevant in such an environment. You know what? I do not care. This is what I liked doing back in the day and we're going to play with the packets. So what are we going to
02:01
start messing with here? We're going to start messing with, of all things, Bitcoin. Why not? It infects everything else. It should hit my talk, too. You know, what is Bitcoin? Well, it's an attempt at making a digital currency with no central bank. Yeah, yeah, yeah. It's a system with economic properties I don't know anything about. I'm not an economist. But to be fair,
02:23
neither are most economists. So it sort of works out. It's an overlay network upon the Internet. It's like an Internet on an Internet that people think has certain properties. Now that, that is a toy to play with. So Bitcoin is
02:41
built on doing three things. Transferring money. I, Alice, give Bob 2.1 Bitcoins. That's done with public key cryptography. You sign the message. Then there's gossip. Hey, everybody, did you hear that Alice gave Bob 2.1 Bitcoins? Alice goes ahead and gossips that out and it just spreads
03:01
throughout the network like wildfire. Look at this great new news. And then there's a pending. Once about every ten minutes, someone on the network does enough computation to say, aha, the official record of all transactions ever should include that Alice paid Bob and Bob paid Charlie and Charlie paid David. And, you know, it's a lot of cryptographic work. How do you know if you've
03:24
done enough work? Well, if the network generates answers any faster than ten minutes, you make the problem harder and harder and harder until it takes once every ten minutes. It's really quite elegant. And it's, you know, if it goes too fast, it self-corrects. So talking about Bitcoin, this is not my Bitcoin
03:44
talk. Go to dancominski.com if you want to see some slides on that. The good news is that Bitcoin is really impressive. Anyone who's all dismissive of it and they're just like, oh, it's got all these bugs? No. They're just like missing. Like the first five times you think you understand Bitcoin, you're not even close. I'm on
04:03
major bug nine on Bitcoin that I was absolutely sure was going to work. Now, now they like, like the line of code that would have made that bug work is just not there. It's the mark of a pen tester is upon this software. Bitcoin is
04:23
fixed almost all the flaws that aren't forced by the design. However, there are flaws forced by the design. It totally does not scale and it is absolutely not anonymous. What do I mean? If you go to the scalability page on the Bitcoin wiki, you will see the funniest document in the history of software engineering. Let me give you some quotes. I
04:42
don't even need to talk about how Bitcoin doesn't scale because they say it. They're like, yeah, for bandwidth, eventually we're going to require every machine to exchange a megabyte a second. What? CPU, you'll have to have 50 CPU cores just to participate.
05:00
And storage, well, you might need a three terabyte hard drive every 21 days but it's cool because they're like only 200 bucks and that's pretty affordable. This is their own page. I'm not making this up. So, you know, you end up with like super nodes that do special stuff and everyone else who trusts them. We have another word for
05:21
this. They're called banks. I'm not saying banks are bad. I'm just saying all of these economic properties of Bitcoin that everyone likes today are going to be gone tomorrow. Now, I'm not saying those are the properties of a Ponzi scheme. I'm just, you know,
05:42
until we get to this point that Bitcoin completely has to shift over to the banking model, who here knows a very interesting character by the name of Travis Goodspeed? You don't even know how ridiculous this guy is. But he asked me a great question. He
06:01
said, damn, could we use Bitcoin as a Sama's dot service as a way to store information and distribute it? You know, three terabytes is an awful lot of data. There's an old challenge. I haven't thought of it in years. And it's, well, the Internet is about sending data from point A to point B, at which point it just
06:23
magically disappears. What if we could get away where it didn't magically disappear? Or in fact, it stuck around forever? Well, the reason you need a three terabyte hard drive in Bitcoin is because basically all the transactions have to live forever somewhere. So if it's going to live forever, what could we do with this?
06:44
Who here knows Len Sassman? Len was one of our brightest lights in our community. There's a command that one can run on Bitcoin today and on Bitcoin forever on
07:00
any node running Bitcoin. Strings bytes equals 20 dot Bitcoin slash block 0001 dot dat. Strings will go ahead and extract human readable text from any blob of data. We usually use it to find hard coded passwords inside of statically linked executables. Well, if we run this on the block database of all transactions ever moved through Bitcoin on any machine in the world
07:25
participating, you know what you get? Well, Len was our friend and
07:40
was a brilliant mind, a kind soul and a devious schemer, his husband to Meredith. He was brother to Calvin, who is here at his first DEFCON ever. Son to Jim and Dana Hartorn, co-author of mine and of many others,
08:01
co-founder at Schmoo and so much more. We dedicate this very silly hack to Len, who would have found it absolutely hilarious. And just to increase the amusement factor, and Len would have loved this, Bitcoin is now dependent until the end of time on Len.
08:22
Bitcoin is also dependent until the end of time on the head of the Federal Reserve, Ben Bernanke. So how did we do this? In Bitcoin, Alice gives money to Bob by issuing a sort of challenge.
08:42
Whoever can sign a message with the public key that hashes to the following bytes, that has the following fingerprint, may claim this money. Well, bytes are bytes. Instead of pushing the hash of a public key, we pushed 20 characters of a testimonial 78 times. There are consequences to this. It does
09:02
cost money. It costs about a Bitcoin. There are minimums to transferring money. This does destroy the money forever. The Bitcoin network is thoroughly convinced that somewhere, somehow there must be a public key with the hash that Len was our friend. I am totally cool with that.
09:24
This is the cyber equivalent to pouring one out for your homies. So, coming at higher bandwidth. Bitcoin does let you send money
09:42
to a public key directly rather than its hash. So that gives you like a 10x increase in bandwidth. But that's not good enough. Bitcoin allows for extra data in a signature. A really beautiful style, too. You see, Bitcoin works with small programs. The program from the receiver
10:02
says, please put this signature and public key on a stack. Pile of data. And the program from the sender is, hey, take the signature and public key off the stack and make sure they're good. If you look at this just from a language perspective, Meredith's research is all about language theoretic security.
10:21
What if there is extra data that the receiver puts on? You know, I don't know, some video file or something. I don't know why someone crazy would do that. Well, the sender just says, take the signature and public key off the stack. Doesn't say anything about making sure there's not more data.
10:43
So this just works fine. Now what's funny, this bug shows up all the time in signature checking systems. It's not just the sender of money who can add the extra content. See, a signature can't cover itself. When you sign a document, you don't sign the signature because the signature is not there yet. It's a chicken
11:03
and egg problem. So you're signing everything but the signature and the extra crap that's been thrown in with the signature. Now, in Bitcoin, eventually the extra crap does become part of the permanent set of data, the so-called block. But there is time between when the transaction is sent and
11:23
when that thing happens every ten minutes to merge stuff in. And in that time, it's not just the sender of the money who can add extra data. It's like anyone can add extra data because it's unsigned. Oops. So this is
11:43
Bitcoin does charge you money or Bitcoins per kilobyte of your message. So the random relay can't add all that much. So this limit doesn't count if you're the one adding the extra data because you can just pay the fee. It's about 14 cents per kilobyte to put something on a huge
12:03
multi-million dollar Bitcoin thing. Also does not count if you generate the block. So if you're the guy who does the work every ten minutes, you can go ahead and make everyone in the world store two megabytes of data, no problem. So I, Amy and Travis are talking. Yes, we can totally do the Bitcoin file system.
12:25
And what about anonymity? Let's look at blockexplorer.com. This is the big site that tells you what's going on in Bitcoin. When we say anonymity, look, you have a bunch of sources of money and a bunch of destinations. All these sources are the same guy. Also, you get obvious pseudonym linking in Bitcoin.
12:45
One of these two destinations is all the guys on the left. That's your sort of change when you've paid too much and you need some money back. And you can build these great graphs. I was going to show you some of mine, but Reed and Harrigan actually did a much better job in that recent Bitcoin is not anonymous paper. So they got their pretty pictures. Now the problem is,
13:04
is that they got lucky, right? Like, the way they got to IP addresses is some jackass shows up on a forum and is like, hi, I'm Bob Jones and my Bitcoin ID is this. Yes, that will, in fact, de-anonymize you, idiot.
13:21
Another user, another system, when it gives Bitcoin, it tells the IP of who it gave it to. So they're getting de-anonymization, they're getting pseudonym linking, those IDs linked to each other within Bitcoin. But if you want IP addresses, that's out of band. This audit trail is noisy and deniable. And, you know, the authors of this paper know it.
13:42
Is there another source of data? Well, there are two sources of transaction information in Bitcoin. There's the blocks that contain the historical record. There's also the loose transactions that are getting gossiped all over the place. So it's a relay race. Alice tells Bob and Charlie, Bob tells David and Eric, Charlie tells Frank and Gary.
14:01
So what you do is you just connect to all the Bitcoin nodes in the world. You can say, oh my God, that'd be like 50,000 connections. Yeah, computers are powerful now, it turns out. So when you connect to every node in the world, the first node to inform you of a transaction is the source.
14:21
He don't relay it because he done done it. So I wrote some code, which I can't demo for time constraints, called Blitcoin. Does anyone here get that joke, by the way? It does accelerated probing of Bitcoin. So how do you find out who to probe? Well, you can just scan the entire internet on 8333 TCP.
14:43
You can join the IRC channels. Bitcoin runs like a botnet command and control. So you just have this thing called Bitbot. It connects to all the IRC channels, watches a live stream of everyone who's connecting. Or you can just add, ask every node, hey, what are the nodes do you know about? And they'll tell you. They'll give you a map of the network within 30 seconds.
15:04
Now, the Bitcoin devs want to be very clear. They know Bitcoin is not anonymous and they wanted me to spread this out. This is just not a feature they're working on. So don't think it's not intentional. What about Tor? Well, Tor is interesting.
15:22
Tor will go ahead and hide the IP address for all your outbound connections when the Bitcoin node talks to the rest of the world. But what if the rest of the world is scanning every IP address on the internet looking for who's listening for Bitcoin? Tor doesn't do anything about that. So there's actually a bug file now in Bitcoin to say when running through Tor, how about we not listen for incoming connections?
15:43
What about unreachable nodes? Well, most are just behind NAT and you can't connect to them. They can only connect out. We already have sort of a super node situation. There's only about 3,000 to 8,000 Bitcoin nodes. Maybe, you know, 10% to 20% of the nodes in the world that you can go ahead and just arbitrarily connect to.
16:03
And that's awesome because now I create another couple hundred incoming only Bitcoin nodes and the other 50,000 depend on me. So they come to me and they make a direct connection and now, again, the first people who connect to me and tell me of a transaction, I know who they are.
16:20
So probably only need about a few hundred. Let's talk about unreachable. Many users are behind wireless routers, you know, these little Wi-Fi devices from Linksys, like poor man's firewalls. Now there's a protocol that most of these devices accept called UPnP and it allows nodes inside your network to say, hey, can you let the outside world in?
16:44
And there's a protocol that allows you to discover that you can ask for inbound connections. I have to sort of speed through this a little. Well, UPnP opens up firewall holes from the inside to the outside. Man, it'd really be bad if that service wasn't just available on the internal network.
17:05
If like people on the internet could just say, hey, firewall, can you not be a firewall? God damn it. Hundreds of thousands to millions of these things are out there.
17:23
Now, of what I just showed you, they're not all fully open. The Microsoft code is great. It actually requires this random identifier that you have to be on the internal network to discover. But every other vendor is just like, well, you know, we have this code and it's the most, some of the most widely deployed
17:42
code in the world and you can reach it from the internet from everywhere, but our budget for this device is like four dollars. Maybe we aren't number one on the security. So I don't need to go into this because there's another speaker who found this first. So I just got to refer to him.
18:01
Daniel Garcia, he's speaking on track three today at five o'clock. He found that there were open UPnP nodes on the net last year. So now we're starting to collaborate to figure out what the exact number is. Another guy, Dutch, Armaan Hemel, I think I pronounced his name right. He's doing some great work too. He's at UPnP hacks.org.
18:23
The one thing to realize, this was found in 2007 and it's still broken. So, yeah, things, oh, by the way, the other nice thing about home routers, it's not like they patch. Yeah, it's like a worst case scenario. So what about outside the consumer space?
18:42
Corporate environments. So less about Bitcoin and UPnP and more about web services and ACLs and access controllers. He says, oh, you want to access this resource? You better be coming from this IP address. So of course we lie through our teeth.
19:00
You know what's called IP spoofing. You just pretend to be some IP that the system trusts. You might say, but, but, but I thought networks block spoofing. It's like, yeah, they block spoofing from, like, your cable modem. I'm on the core of the internet. It does not give a crap what IP address, like, lame. The one thing that does care about IP spoofing, though, I have finally found something that the cloud does not do well.
19:25
If you are running in a virtual node and you want to spoof packets, good luck. You can't do it. The hypervisor will stop you. You'd have to, I don't know, like, have a hypervisor exploit. No one has those. So is IP spoofing still effective to do interesting things?
19:44
Well, there's a DNS trick that I've been sitting on for a couple of years. You know, in DNS, you go to a server. You say, hey, go look up this domain. The server goes and runs around the internet and looks up the domain. So you say, oh, hey, go look up a domain I control, and I'm, you know, this random IP.
20:02
You're not going to get the reply with the answer, but that server has to go run around the internet to go satisfy the request. And it'll run around to you. So you now see, oh, okay, my spoof type request spawns another request that comes back to me through another channel. Now, this only works for obscure applications like DNS and UDP.
20:24
Certainly nothing built on TCP, right? Well, limits of IP spoofing. Most modern protocols run over TCP. It's a reliable communication protocol. And TCP has sequence numbers. They're kind of like passwords that are exchanged at the beginning of a session to make sure that each side is really able to hear the other side.
20:45
And it's rather effective, and it means when you don't get the reply because you spoofed your address, you're not able to get to the point at TCP where data is really going to be exchanged. Now, sequence numbers didn't used to be random, which meant people could just guess them out of thin air.
21:03
Okay, so let's go ahead and make them random. Well, you can't just go ahead and make them random. See, the problem is that sequence numbers did not start out as passwords. They started out as markers where inside a session, here's a bunch of bytes. Are they on page one or are they on page 100 or are they on page 500?
21:22
You've got to know where to put the words. So, the deal is, let's save a connection from 24123 on port 50000 and 4221 on port 53. You've got to make sure if there are two connections and all that stuff is recycled, that random packets from the old session don't show up in the new session.
21:43
It'd be like you're reading a book and suddenly a page from some other book shows up. It'd be rather confusing. So, the game is to have, you know, random sequence numbers unless the idea is the same and then we go sequential. And that's done with a hashing function where you hash all the data with the secret, you get some absolute number and you add time.
22:04
So, if you have a slight difference in, you know, 2345, 2346, the numbers become much different, but if it's absolutely identical, it becomes sequential with time. Now, there's a problem. What if someone just floods us with connection requests?
22:21
They don't have to remember all the passwords. They just need to like flood us with requests and we need to remember their passwords. So, we run out of resources. This is a SYN flood. It's older than dirt. So, the solution is, came from Dan Bernstein. It's called SYN cookies and basically what is sent out to the requester is a challenge. If you can read this challenge, if you can respond, all right, I'll go ahead and I'll store some memory.
22:45
And there's 24 bits of security there. So, okay, 24 bits, that's, you know, 2 to the 24 is 16 million. It takes about 8 million packets to go ahead if SYN cookies are enabled and guess what the cookie would be.
23:01
And it might actually be a little less. So, DGB knew this, right? It's like no matter what you do, the attacker will succeed in a connection forgery after millions of random ACK packets. Well, there's something that's changed in 1999 to 2011. Networks are really fast. Sending 8 million packets is not that big a deal.
23:20
When you have a spoofed acknowledgement, you can also throw a bunch of data in there. You can throw like a web services payload. So, if you have like a web, like an Apache server, and it's behind an access control list that says only connections from IP I trust, every 8 million packets, he's going to get a fake packet from an IP it trusts.
23:43
And it's going to be received and get to do whatever it wants. Not so good. Now, what about on Linux? What do we do on Linux? Well, so, Linux has SYN cookies on by default. But even if you disable it, what do the actual sequence numbers look like? Are they RFC 1948?
24:03
Are they randomized unless you have the same source port, desk port, source IP, desk port, desk IP? Totally randomized. Well, okay, not totally. Three-fourths of it's all randomized. The lower 24 bits are pretty strong. The upper 8 bits, no, no, that's just like sequential. Just keeps incrementing one every five minutes.
24:26
And it gives that number to everyone. So, you can go ahead, find out the offset being your real IP and then you know every sequence number that everyone else is going to use. And after 8 million tries, you win. So, this lets you go ahead and there are some old attacks on reset hacking.
24:46
So, you'd shut down a session without actually knowing the codes before or the sequence numbers. Before, it would take, you know, 128 packets to kill a session in the worst case. Now, it's a one-packet kill.
25:02
The other problem is that you might have a live session between two hosts. I have to skip through this quickly. I'm so sorry. You might have a live session between two hosts. And there's 64 bits of security between them. Two to the 64 is an ungodly number of packets. But, there's windowing which says kind of like a range of where the password can be. So, that cuts off 16 bits in each direction.
25:27
So, now we're down to two to the 32. 4 billion packets, oh man, that's a lot. Now, we cut off another 5 bits because the windows might be really big through something called window scaling. Oh, okay, now you're down from 32 bits to 22 bits. So, now it's a million packets to go ahead and inject into a session.
25:45
By injecting into a session, let me translate this into the world's most difficult cross-site scripting attack. Now, because the 8 bits are known in each direction, we have a problem because we take 22, minus 8,
26:01
minus 8, 6 bits, it takes 16 packets to have a 50% chance of the world's greatest cross-site script. Crap. Now, it does get a little harder because there's port randomization, but, you know, the port randomization adds at most 13 bits, so it's still only 250,000 packets.
26:23
That may not even happen with port randomization if you have a client that's forcibly setting its ports, which actually happens with DNS and BGP. So, status, this is some very old code in Linux. It actually predates Linus Torvald's check-in history into the Linux source tree.
26:41
So, like, this bug's been there since, like, the late 90s. They're figuring out right now the right fix that won't cause even more problems. There's a ton of fixes you could do that would make just things even worse. So, digression. Let me check my time here, make sure I'm not going to go over. Alright. RFC 1948 is an interesting construction. It is sequential and ordered if you have secrets, and it is random and unpredictable without.
27:09
It's actually kind of a public and private system. There's the private component, the sequence number is mixed with, like, a secret, and you can generate all possible secrets with that thing, so it's like a private key.
27:20
Then there's, like, a public component. I give you one of the generated values, and if you can see it on the network, you can communicate for that one session as that one IP using that one set of connection identifiers, which are ports. So, wow, that's like public-private cryptography, without nothing but a password.
27:43
Clearly this is impossible. It's only possible here, because we're at the intersection of network security and cryptography. You guys know what public-private cryptography is? Just as a quick example, a photo of my face can be a public key, and my actual face is a private key.
28:03
It's very easy for people to identify me from a photo. It's very hard for them to, you know, mash their face into, you know, being my face. So it's all about asymmetry. Now I want to be clear here. What I'm about to tell you is a terrible idea.
28:21
However, nowhere does it say on the DEFCON sign-up form that everything you say must be a good idea. In fact, not usually the case. But passwords are a bad idea. They're constantly being lost and forgotten and stolen. They're responsible for 50% of compromises. They increasingly look like LeetSpeak. Not helping. But let's ignore all that for a moment. Assume we're stuck with them.
28:44
How do we use a password to log into a system without that system learning our password? Well, people say, oh, you know, you idiots, you should be hashing the data in your database. That's nice. The web app is still receiving the password in plain text. The attacker just modifies the web app to send the plain text to them.
29:03
So it doesn't help. Next thing, we challenge you to mix your password with this particular hash. And then we'll never have to send the plain text password on the wire. This is a thing called digest or NTLM. The problem is, if you're hashing the plain text password with some random value, they gotta do that too.
29:27
They gotta store the plain text password or some password equivalent version. There are things where you say, we require knowledge of the password to complete this complicated asymmetric crypto magic foo.
29:43
SPEAK does this and SRP does this. It requires the client and server to run some really obscure code and good luck getting that code deployed. What are we gonna do? Is it possible, not advisable, but is it possible to build a system where the client only remembers a password,
30:02
but the server stores nothing but a straight up public key and deploys no other magic code except the standard challenge to make sure the client has the matching private key derived unilaterally from the password. In other words, can we construct a cryptographic key pair using nothing but a password?
30:22
So here's a question and if you can answer it, we're gonna go get a drink after. What vulnerability impacted all asymmetric crypto systems, be they RSA, DSA or ECC? Anyone? There you go. We'll grab some tequila.
30:42
So check it out. Debbie and Bug had, was basically a situation where every time the cryptographic key generator went to get random numbers, got the same random numbers. So all cryptographic, all asymmetric crypto systems use entropy as follows.
31:01
They grab random bits and they permute them until those bits are roughly a private key they can get a public key from. Predictable entropy means predictable key pairs no matter what the algorithm is. So what if we said it wasn't a bug? What if we turned the Debbie and Bug into a feature?
31:21
Cryptography is all about constructions. We have hash functions that make fingerprints of data. We have stream functions that stream ciphers that give us a stream of data. We have block ciphers that take data and a key and mix them all together. You can actually turn any of those into any of the others.
31:40
Well, we also know how to take a password and construct an everlasting stream of pseudo random number generators from, random numbers from it. This is predictable entropy. We can even make this stream of predictable entropy in such a way that is both time hard, meaning it takes a whole bunch of CPU to find out what the stream should be from the password,
32:05
and memory hard, which means it takes a whole bunch of memory that, I don't know, a GPU really can't do on a per block basis. So, you know, screw you, LCOMSoft. So this is a great algorithm called S-Crypt that does this.
32:21
So, what if you make the output of a password seeded PRNG, the input to an asymmetric key generator, you end up with 2,048 bit RSA keys that have a trap door in the form of a human memorable password. This is not theoretical.
32:41
I actually went ahead and wrote this. And the way it's written is just awful, terrible idea. God, I love it. So check it out. In normal key generation, if I run SSHKeyGen three times, I'm going to get three different keys.
33:00
But now we're going to run a little piece of code that I call Fidelius. And Fidelius is saying, you know, LD freedom of Fidelius.so, password of high grandma. My grandmother comes to my black hat talk every year. It's great, she brings cookies. And if you look, I run this twice with the high grandma password and I get ADOD52 and once again ADOD52.
33:26
So how's this happening? See, here's what the deal is with Fidelius. Harry Potter, properly understood, is a story about the epic consequences of losing one's password.
33:44
Fidelius is how passwords fail in the Harry Potter universe. And if you don't get the reference, go find, I don't know, Dumbledore. What Fidelius does is it hooks dev random and it hooks devu random and it hooks OpenSSL's random functions.
34:01
What do I mean by hooking? I mean that the applications try to go get random numbers and my code steps in and goes, have I got some random numbers for you? So, this just works, like unmodified code.
34:21
SSH KeyGen will suddenly develop standardized keys. OpenSSL for certificates will generate the same certificate every time. You can get a certificate authority to sign a password. Freebird will even generate consistent DNS set keys. So you get, you know, message signing, message encryption, client certificate authentication,
34:43
nothing but a password. It solves the login with a password without the system learning your problem thoroughly, without you having to install anything anywhere. In fact, the server has no idea there's a trapdoor and can never find out. So it's, I wouldn't say non-consensual.
35:02
It's more backwards compatible. With Bitcoin, you literally could send money to like a word or even a photograph because you can actually say, my private key is, you know, a picture of a pony. You can do that. We have the technology.
35:25
So there's no paying server-side, all-time memory hard requirements are limited to the client. There are a couple of issues that are totally real. The obvious ones, passwords suck. The non-obvious ones, it is fragile. It is dependent on the peculiar way that SSH KeyGen 5.3 P1 turns random numbers
35:46
into a final key. That's what you get for being an implicit scheme that, you know, tries to make function hookings useful. It's also hard to salt. What does that mean? That means everyone who uses the common password, password
36:00
is going to generate the same certificate every time. So that kind of, that's kind of a problem. Now you can fix that, but not implicitly, not for free. You basically have to have a situation where a randomized salt, a thing that says five different instances of the password, password are going to get five different certificates.
36:24
The public side needs to contain the random information. So instead of just, I have this password, I generate this private key, it's I have this password and a particular instance of a public key, I can now generate this private key.
36:41
It can do that, but it takes some custom magic. Back to TCP IP. I want to get to the last thing in this talk, the thing that, God, I missed packets. What can we do with networks? That's how I started coming to DEFCON.
37:02
That's what I haven't played with in a while. Let me tell you something you can do if you're willing to play some games with packets. Who here knows about net neutrality? Once upon a time, the only people messing with my traffic were, I don't know, you guys.
37:20
Now it's my ISP. Really? I don't have a worry about when my ISP is obviously messing with me. First of all, I can just tunnel around it using DNS. Secondly, I can know to tunnel around it, or I can complain to my congressman. What I'm worried about are when the biases are subtle,
37:44
when I can't necessarily prove that they're there. What I'm here to tell you is that there has been a change in technology, and I'm going to describe it to you, and we are going to always be able to know if an ISP is manipulating your traffic. So if bias networks are affecting you, this is the proof that's going to be able to be shown up in a court of law.
38:05
And if you happen to be working for an ISP doing this stuff, I'm just saying, if you don't want it on the front page of a newspaper in two weeks, you might want to stop doing it now. I don't want to embarrass everyone.
38:20
I would love it if I didn't find any violations in net neutrality, because then there would be no violations. So let's look at the topology, how we're going to do this, because I'm making some big claims here. Extraordinary claims require extraordinary evidence. A standard topology in the real world, you have some client, goes through a home router which has 83 million bugs,
38:41
goes to an ISP. The ISP has various links to the internet, level three and whatnot, link one, link two, link three, and then you have Google and Microsoft and Yahoo that are linked through those links. So the fear is, and it's a reasonable fear because they're all over Washington saying it's going to be great when we can do this, there's a magic box deployed within the ISP network in front of all the links.
39:04
The box matches packets to policies, applies different rules to different packets, it can be stateless. Do I not like this packet? Or it can be stateful. This packet rolls with a bad crew of packets. It's part of a flow.
39:20
Do I not like the flow? And the policies can be anything and they can do anything. Limit maximum bandwidth, increase minimum latency, alter content, they can do everything. But sometimes you don't know if they're doing it or not. Let's say Bing.com was 50 milliseconds slower than Google.com.
39:43
Is this because of the ISP or is this because Google.com has better hosting? There's a lot of different servers, there's a lot of different routers and the problem is you can't tell if Bing is slow because of the ISP or because of all the routers and servers.
40:02
There are many reasons why Bing may be slower than Google and that means there's plausible deniability. We've got to go deal with that. Deal with that with normalization. Whether the tester is accessing Bing.com or Google.com, the network path should be identical
40:22
or at least the path should be uncorrelated with the particular identity being run over it. That way any changes would be the result not of the path but of policy at the collection point which is the ISP.
40:40
So simple normalization, HTTP. Let's say all we're looking at is websites. There are absolutely policies out there today that say if you see an HTTP connection and there's a host that says Bing.com, go mess with it. Slow it down by 50 milliseconds, why don't you? This is super easy to detect.
41:00
Just put up a server at some IP address somewhere that will be, I don't know, like a proxy or something. It'll respond for all web requests no matter if it's for Bing or Google or whatnot. Now we have a consistent server with a consistent path back to the client. If packets from the proxy,
41:21
oh wait a second, you don't have to write any code because it's just a proxy server. It's just squid. If traffic from the same squid server is faster when it seems to come from Google than when it seems to come from Bing, you have just discovered a biased network. Very simple.
41:41
There's a problem. Very protocol dependent. Works wonderful for HTTP. Do you guys know the internet is bigger than the web? The problem is all of these other protocols, BitTorrent, require a lot of work to implement or emulate.
42:01
And I'm a lazy guy. The other problem is that proxy servers have some IP. You know what that IP is? Not Bing's. Not Google's. And the ISP can just look in DNS to find out which IPs are actually associated with Google and Bing.
42:22
So you can have the greatest test server in the world. The policy is only applied against genuine Bing or Google servers. You're blind. So we gotta do something about that. We gotta spoof the whole internet.
42:41
Okay. So I've written some code. It's a neutrality router. It's called Neuter. Neuter is the network normalization engine. It's very easy to explain. Who here has ever run a VPN? All right, so here's the deal. You got a VPN. You're sitting in some Starbucks, but where you really want your networking to be from
43:02
is, I don't know, the home office or the home or somewhere in EC2. Anywhere where wherever you're at can't see what you're doing and there's all this access stuff. You just wanna operate from the other network. So in a VPN, traffic is pushed from a client to a broker.
43:22
An IP address at the broker or VPN concentrator, it goes ahead and talks to Bing. It goes ahead and talks to Google. And they respond back to the broker. Hey, now the broker's got all the packets. It's all the same source. So you have a normalized server
43:41
and then when it sends traffic back to the client, it always comes from the broker. So you got a normalized path. It happens to be because it's encrypted that the ISP doesn't see anything and so no policies are applied. Well, that's a bug and we're gonna fix that with Neuter. See, with Neuter, when the server talks to the client,
44:01
okay, we're just gonna go ahead and send that in the clear. In fact, we're gonna spoof the IP addresses of the real Google or the real Bing. So it looks like Google and Bing are talking straight to the client. Why do you do that? We want the ISP to see the returned traffic. We want the ISP to apply the policies that they only would normally do for Google and Bing
44:22
and we want them to mess with us too. Why? Because then we bust their policies. And it works. Someone in this room thinks,
44:41
oh man, I can detect the crap out of that. I am gonna mess with Kaminsky's stuff. I already got like the blog post half written. Oh, oh, but the rabbit hole goes so deep. See, the policy engine in this scenario doesn't see traffic from the client to server. That's encrypted VPN style. What if the policy engine only worked?
45:03
It saw all the traffic from the client to server and all the traffic from server to client and otherwise it didn't go anything. Guess what, dude? You do that. So here's what we're gonna do. In normal neuter, we're gonna spoof the traffic
45:20
from the server to the client. But in roto neuter, it's doing it the other way around. In packet sample A, the client's gonna talk to the real Google. No magic whatsoever. It's just gonna go talk to it. Real routes, but full bidirectional flow, trigger whatever policy is there.
45:41
And then apparently the policy engine doesn't like half flows. Well, guess what we're gonna do? We're gonna go give it a half flow. We're gonna take the client to server traffic and we're gonna route that thing encrypted right around the ISP's policy engine. And then the first thing that's gonna happen at the broker, the broker's gonna send that traffic straight to Google
46:00
as if it had the IP address of the client. Google's happy. It sees requests from a client, a response to the client. It's only the ISP that suddenly's got a half flow and you get differential behavior between full flow and half flow. And I've still got you busted. So, guess what? It's a catch-22.
46:20
The ISP applies policies to half flows. Neuter sees it because the normalized server gets a difference in performance. If it only applies policies to full flows, when I create a half flow to the real Google, suddenly it has different performance characteristics. Either way, neuter wins. This is the endgame.
46:42
Biased policies might as well be transparent because I'm gonna find it. Now, I think I might go over by two, but no more than two.
47:02
Suppose you really want the ISP to see bidirectional traffic. You don't want this, you know, weird catch-22 I just said. Well, you'd wanna do this because it's definitely going to trigger all the policies. Also, if you've got an inconvenient NAT in the way, then that really needs to see client-to-server traffic to open up return connectivity.
47:23
It might be inconvenient to get around a NAT. Now, the disadvantage is if an ISP is seeing client-to-server traffic, if a NAT router is seeing client-to-server traffic, the server sees the client-to-server traffic too and it might reply, interfere, complain, etc.
47:41
So, what are the tricks we can do now? Well, we can play with TCP checks. The client can tunnel valid traffic to the broker and can also send packets with invalid checksums to the server. So, it'll get past the NAT and it'll get past the ISP and it'll arrive at the server. Servers like this thing is corrupt. I'm going to ignore it.
48:01
That actually kind of works. The problem is the policy engine might actually do TCP checksum validation and the NAT might go ahead and fix the sums. There's been a problem with that. But we got another catch-22 because we get differential behavior when the policy engine sees packets with bad checksums. So, once again, it's like,
48:20
oh, I see a full flow but it's got to have checksums. I'm going to change policy. Gotcha. So, you know, that's nice. Strategy two of three is low TTL. When you send traffic on a network, this is from my 2002 talk, you can control how far it goes. So, you can say, I want this traffic to get past my NAT
48:42
and I want this traffic to get past my ISP, but not so much with getting to the real server. Could you like stop along the way? You can do that. We have the technique. So, the advantage, it's legitimate traffic. The disadvantage, the policy can locate low TTL and alter behavior.
49:01
That's great actually in the catch-22 because now not only do we identify the policy engine, but we know which hop it's at. Nice. But okay, let's talk about utter, utter packet trickery. The silence place.
49:20
You see, normally, according to the TCP specification, if you ever get a TCP packet that doesn't look right, you are supposed to either acknowledge it or send a reset to stop that guy from talking to you. So, you're always supposed to reply. Well, the thing is, there's a lot of servers out there that have the right stack,
49:41
but they got firewalls in front of them. The firewall is like I see something that looks even remotely bad. I'm gonna hide in a little corner and not say anything. I have use for this behavior. So, what I'm gonna do is I'm gonna have the real client do a three-way handshake with the server. So, it's gonna go and have a real session
50:01
and then that's gonna see it, the ISP's gonna see it, and even Google's gonna see it. And you know what Google's gonna see next? The broker's gonna send a reset and it's gonna shut that thing down hard at the server side. Client's still open. Client's expecting server to say something any minute now. Server doesn't want anything to do with client now.
50:21
So, now the broker shows up and says, hey, server, why don't you set up a connection with me? So, broker sets up a connection with the server, gets it all nice and good, and then the broker just goes ahead and splices his connection into the connection that has been originally set up at the client. And now, client sends server traffic,
50:41
server ignores it, broker spoofs the server back to the client, client accepts it, packets go out, packets go in, you can't explain it.
51:00
So, bit of warning, if you are passively monitoring network traffic, these techniques kinda sorta allow any one side of the conversation to impersonate traffic from anybody. You can detect it, if someone tells you to detect it, telling you to detect it, where neuter is now and emulates half flows,
51:21
it's super fast, it supports anything that runs over IP. If you wanna know whether a network prefers Xbox 360 traffic to PlayStation 3 traffic, this will tell you at a court of law. So, I gotta end this. Here's the summary. Networks are neat. Bitcoin isn't anonymous.
51:41
UPnP sometimes exposes itself to the outside world. Atlas can be bypassed using interesting sequence number tricks. Passwords can be used to seed asymmetric crypto, even though they shouldn't. And subtle net neutrality hacks are doomed, transparency or bust. Thank you to an N2K of 3Crowd and Docs of Lion Labs
52:01
for the crazy things they're letting me do on their network. And I'm looking for some help release engineering cause we gotta get this code out and about. Thank you so much.