 I give you Dan Kaminsky and the black ops of TCP IP 2011 take it away Dan Hey, so who here is excited to hear about DNS? I was gonna say me neither Yeah, I've been spending the last couple of months dealing with sopa you know what I'm not gonna talk about now Sopa cuz damn it. No, you can go. He doesn't like other people talk about that Tomorrow, there's a really important talk. Let's think it is by a Peter Eckersley from the EFF He's talking about a proposal called us, huh? Thursday, excuse me Talking about sovereign keys. It's some DNS sex stuff He's wrong But he's wrong in really important and intelligent ways I I'm just gonna tell you straight out It's probably one of the more important talks that's been here. So I recommend everyone actually goes This is not one of the most important talks here. This is one of the least important parts here You know I talked about some of this stuff before but if you're in the room and you're here You probably haven't heard it. So it's new to you I'm just here to talk about some toys some things. I've been playing with some things that turned out to be Kind of interesting and amusing It's sort of a a return to form, you know as a community We've stopped really looking at network security, you know mapping networks evading firewalls of verting design assumptions You know, this is probably the right thing to do because the old net security tricks This is not how things get broken into I swear to God Hacking stuff is like comedy and you sell the same joke over and over again, right? It's like I got my beach head I did my stupid little sequel injection or you know, I popped some client always with Java because it's always freaking Java Now I'm in one box I just go ahead and take the rentals and go next to next to next and it's the same game Over and over maybe someday in my career. I'll get to break things in a new way So, you know network security is only so relevant in such an environment, but you know what it is Well, it's fun. So I'm gonna go ahead and look at that Awesome Let's talk about Bitcoin Bitcoin was a lot more exciting a little while ago It's gotten a little bit of attention recently because it turns out to be one of the most reliable least expensive ways To move money across international borders. This is not because Bitcoin is excellent. It's because everything else is now crap So, you know, the joke about Bitcoin is that it converts Nerd forums into libertarian forums. It's infected everything else in nerddoms. I might as well get into my research What is it? Kind of an attempt at making a digital currency with no central bank System with economic properties. I don't know anything about it. I'm not an economist, but to be fair neither are most economists No, really I'll see your propaganda and recognize it as such. No, Bitcoin is an overlay network It's an overlay network upon the internet that people think has certain properties and that's interesting because overlay networks are things I can speak about Bitcoin in a nutshell does three things and it kind of does them in a loop. First of all, it transfers money I Alice give Bob a 2.1 bitcoins So that means Alice is signing a declaration of some transfer with Alice's public key Then that information is spread all over the world in phase two, which is gossip. Hey everyone Did you hear that Alice gave Bob 2.1 bitcoins and that information is transferred around in this big peer-to-peer network as a emulated broadcast The internet does not really support broadcasting or multicasting because that would require routers to have good code and know Yeah, you know why we talked about the network being dumb because we saw what happened when it tried to be smart There's like five people in the room who really understand this is the most true thing they've heard all gone The third thing that Bitcoin does is it appends and this is complicated Everyone the official registry of transactions should now include Alice paying Bob and Bob paying David and Charlie paying David and so on Now this official log of Transaction this is gossip as well and what it does is it requires solving a problem now You might remember from school from classes, you know, you you might have math problems in the beginning They were really easy and later on they got more and more difficult. Well, it turns out with cryptography We can make problems arbitrarily easy or arbitrarily difficult so what Bitcoin does is it keeps making problems harder and harder and harder until it takes the entire world trying or at least the entire Population ten minutes of effort before someone actually comes up with an with an answer How do you know that you haven't made it hard enough? Well an answer comes too fast. You go. Oh, okay. I'll go make that harder This is a really interesting property It's kind of as if the more gold you mind the harder it became for gold to actually be found anywhere That's kind of cool And if when you go ahead and you actually are the one who wins this Cryptographic lottery lottery you get 50 bitcoins which then you return to the beginning and transfer it which gets gossiped Which then gets concluded in the next log. It's a you know, virtuous circle on the crazy thing is it actually kind of works It's not my Bitcoin talk. I got like a bigger one's on dank minceki.com What's interesting is that uh It is not a complete disaster. I Mean come on how used to it look look guys. This is a piece of software. It listens on the open Internet It's written in a non-memory safe language. And if you own it you get all the money They should have died immediately But what's really crazy is when you actually dive into the thing first of all ignore all the friggin specs and Documentation and again, that's the problem. Why? No, no, this is one of the few things if you don't read the code to Bitcoin You have no friggin clue how it works because they have not even bothered to update their their Specifications and ages on what's really cool And this is why a re-implementation of Bitcoin is actually a disaster because huge amounts of the security model are Represented with lines of code that are just missing Like you get to the point the bugs supposed to be there and it's just not there They didn't even put a comment in you're like But it was just me I'm like man am I losing it and then I go ahead and talk to a friend of mine He's like no no no my list of 15 bugs as opposed to have it didn't work either so like what you actually end up finding in Bitcoin auditing is like a They basically got all the bugs that were not totally fundamental to the design The main bugs of Bitcoin is that it does not scale at all and it is absolutely not anonymous Now what do I mean by not scaling the only me just go to their own wiki They're like well, you know do you assume visas rates you're gonna have to ship like 60 gigabytes of data in 60 seconds So just may not the move like a gigabyte of data every second to cross the entire Internet That's all CPU you're gonna have to have you know these pretty huge systems 50 cores plus whatever is needed for mining Storage, I love what they say about storage. They're like well, you know three terabyte hard drives aren't that expensive Have you seen what happened in Thailand You'll only have to buy a hard drive every 21 days Um So okay, so Bitcoin starts out small and it ends up with what are called supernotes Better work for supernotes or banks, you know welcome to the new boss looks suspiciously like the old boss I'm not saying banks are bad But like the peer-to-peer model of Bitcoin in the long run is not how the game works And as soon as it gets big the entire thing switches to a banking model This actually is not entirely true. I've had some talks with people The one exception is banks have magic integers that just say how much money they have well, you know that says one How about it said ten they can do that they can even do that with gold because no one actually moves gold around That's the big pain in the butt unless you're Hugo Chavez So you just have magic integers that say how much gold you have and so there's also magic integers There's no magic integers in Bitcoin like it doesn't matter who you are even in the super node bank environment Yeah, it's actually kind of true. You actually have to have you know The you have to have generated the keys yourself or the the bitcoins yourself And there's just no way to make more than 50 of them every 10 minutes. That's kind of cool You can't even do that with gold But you know until we get to the point where Bitcoin goes all bank. What can we look at it as? So Travis Goodspeed one of the more interesting characters in the scene comes up to me as a damn So any chance we use Bitcoin as a some is dot service? You want to know what some is dot is it's a way of you know Transferring information without and storing it without you know anyone knowing that you're doing is kind of like a under the surface kind of thing We've always had the ability on the internet to send data anywhere using various cute tricks But storage has been hard Yeah, you know, you can do the old ICMP moon bounce, you know, send a packet to someone they send it back to you after a few seconds Some of us would like to store data for longer than a few seconds That hasn't really been a thing the internet offers But what about this Bitcoin overlay network if Bitcoin is eventually gonna require a three terabyte hard drive every 21 days And it kind of has to keep that data around forever in order to function Um well Anyone here know Len sassman Used to speak here Incredibly smart cryptographer Len unfortunately passed away a few months ago If you go to the Bitcoin database and you run the strings command now All strings does is say this is a nice big file. You got here. Show me what text is inside If you run strings on the list of all transactions that have ever happened in Bitcoin You end up seeing Len was our friend a brilliant mind a kind soul and a devious schemer husband to Meredith brother to Calvin Son to Jim and Dana Hart's horn co-author and co-founder and shmoo and so much more We dedicate this silly hack to Len who would have found it absolutely hilarious And Just because you know one piece of ASCII art is not enough We also put in a ASCII art version of Ben Bernanke the head of the Federal Reserve Because now Bitcoin depends on Ben Bernanke and this can never go away by the way Like they got a cart this thing around like a luggage for the rest of Bitcoin's existence So this works and Bitcoin Alice gives money to Bob by issuing sort of a challenge Whoever can sign a message with the public key that hashes the following bytes may claim this money Well Bytes or bytes instead of pushing the hash of a public key, which is 20 bytes We push 20 ASCII characters of a testimonial Now this does cost Bitcoin it costs about 1.0 bitcoins in total There are minimums of transferring money What I did here was actually destroy that money The network thinks that somewhere somehow there must be a public key with a hash of Len was our friend. I Am okay with this. This is the equivalent of pouring one out for your homies Can we get higher bandwidth well Bitcoin does let you send money to a public key directly rather than its hash So we can go from 20 bytes to 200 bytes This is not a bug. This is just part of how Bitcoin works What might be a bug and they don't think so they're not gonna fix this Bitcoin allows for a signature the actual block that says hey Here's something that I've signed and allows there to be extra data They're above and beyond the signature that makes the information valid Now how does this work what works through the fact that in signatures in Bitcoin the way it actually says I've sent money You know I Alice send this money to Bob What actually is said is? He who runs this program and satisfies it They can go ahead and claim that money so Bitcoin even includes mobile software and still does not die overnight The way they fix this problem because they actually did die one day They basically said okay We have an entire system where you can send small programs around but we're only going to allow two programs Anything more you know anything that does not match our known trusted software does not get to play around So the program from the receiver is take this signature here and public key and put it on a stack and the program From the sender is take the signature and public key off the stack and make sure they're good Now the receiver can put extra stuff on the stack And it just works fine. I mean look one side wants a signature and public key The other side gets a signature in public key if there's extra. Well Bitcoin doesn't care So the thing is we can actually expand these signatures somewhat illicitly The reason you can do this is because you can't sign yourself. It's a chicken and egg problem, right? You've got a blob of data that's saying everything else is valid It can't say it itself is valid because it's itself. It's you know, you can't be self-referential so When you put extra data into the signature itself That doesn't matter the signatures only covering what came before not what comes after What is interesting though is That when you add data, so okay, I told you there are three parts of Bitcoin There's where you transfer information there's where you tell everyone about all the transfers that you heard about and then there's this third thing where you Say the official register of all transactions that have ever happened now in this third case where you have the list of all the Stuff that has happened and you're the guy who did all the hard work and did all the mining You're basically taking a collection of everyone else's transactions Smashing them together and then putting your stamp on it It turns out in that last phase you can throw a bunch of extra crapping Because everyone else's signatures only covers what comes before the signature You're going ahead and making things official You can actually throw extra stuff on and then make that extra stuff official too So turns out anyone can add additional data to another wide valid transaction It's not that useful It's not that valuable. This is the kind of bug you find in Bitcoin like this is exciting crap, right? Everyone else is playing with like I don't know you know buffer overflows and telnet D and that's exciting, right? This is like the extent you get in bitcoins like how I can crap a couple of extra bytes in The long and short of is yeah, you know, this is the best you get it does actually mean you can build a Bitcoin file system Travis, but You know if you really want to go ahead and have like a bunch of data that the world has to cart around forever Bitcoin will do it for you Let's talk about anonymity There's a site called block explorer calm the thing to realize about Bitcoin is there's no grant There's no magic person who holds the truth It's not like DNS where there's a single route and then things delegate down from there Instead it's like what we would have done pre DNS where everyone just passes around the truth This is a giant host file and then there's keys around to you know, try to make it somewhat Hard for people to make fake branches What you actually get is you get this public ledger there's a list of all transactions that have ever happened in the world That's why big that's what ultimately that big pile of data that bitcoins handing around so Bitcoin you'll have a bunch of sources that are giving money to a couple of destinations All these sources are the same person One of these sources is the people on the left So even though they all look like random values these random values. These are all the same guy on the left Then it includes one of the people on the right So Deanonymization on the first layer happens just because yeah You have multiple keys and multiple random identities But you can see they're like the same guy because they participated in the same transaction So when you draw these graphs these guys are Reed and Harrigan that are out in Dublin Really fun guys went out and met with them. They actually went ahead and monitored like Okay, we've got this thief. Everyone knows he's a thief Let's go ahead and link them to all those other identities and then they found that one of the identities the guy had actually posted on a forum Hey, you should all donate me money and you know, here's my IP address and information and all that So they managed to link him one of the identities was public and it infected the other 70 so This is kind of how normal Bitcoin deanonymization works It's super noisy and deniable and Reed and Harrigan admit it naturally much of this analysis is circumstantial We cannot say for sure whether these flows imply a shared agency in both instance There's always the possibility of drawing false inferences. Okay, is there another source of data? Well, there's the official record of all transactions that goes around the gossip network, but there's something else, too There's the gossips of things that are not official yet. There's just Alice paid Bob These are called loose transactions. These are basically gossiped around so the next ten minute interval can collect them They always refer to a single identity So it's a big relay race Alice tells Bob and Charlie about a transaction Bob tells David and Eric Charlie tells Frank and Gary The way you attack this is you just connect to every node in the world And then once you're connected to every node in the world You see who tells you about a transaction first and the first person who's in the relay race is not relaying it for someone else They knew about the transaction because they done the transaction. That's them So, you know people say to me but but you couldn't possibly connect to every node on the internet Which I say have you seen the size of distributed denial of service attacks? I can just go ahead and send packets to everyone And they'll go ahead and respond to me So that's what I went ahead and did funny thing by the way back in the day I do large-scale internet scans and I was like, oh, you know kernels they are so slow They have socket socket suck, you know Well, something happened and it was called the web and the web made Network stacks have to get really really fast so now you can go ahead and in Python connect to 30,000 hosts and It just works faster than if I went ahead and just generated the packets myself. So it's kind of cool So I wrote some code called slit coins and kind of a graphical Joke and it goes ahead and it connects to every node in the Bitcoin network And then once you do that whoever tells you about a transaction first is the actual source So how do you find out who to connect to well, you just scan the internet on 8333 TCP You can join IRC. Oh my god IRC never went away Is it a botnet command and control network or is it bitcoins network, I don't know they work just the same So I read some code in pearl called bitbot. I'm pretty sure pearl is a language optimized for writing IRC bots And So once you go on the third thing you can do is you can just ask Every node in the Bitcoin network to tell you about all the other nodes that it knows and there's an overlay network It will tell you believe me it will tell you in massive incredibly deep detail So going ahead and getting a view of the entire Bitcoin cloud is pretty trivial When you go ahead and you ask the Bitcoin devs they basically say yeah We don't even try to be anonymous anonymity is not a service we offer. Um, this is their position now their historical architecture Reaks of trying to do anonymity, but here's what happens in development sometimes you totally fail Sometimes you try to build a feature and at the end of the day you didn't get it It don't work and that's kind of what happened with Bitcoin They obviously tried to go ahead and make this thing anonymous But they ended up realizing they back themselves into a design corner actually turns out a lot of the Inefficiency of Bitcoin comes from this half-assed version of anonymity the implement They'd be a lot more efficient and frankly a lot more scalable if they got rid of it entirely So what about Tor well Tor obfuscates the IP addresses derived from outbound connections that it does But it does nothing if you're listening if you allow inbound connections people can go ahead and connect to you And then you'll go ahead and give them whatever you'll relay your transactions to them directly So I think we filed a bug in Bitcoin to go ahead and shut off the listener if the outbound was Tor But I don't know if that actually got merged in it might have What about unreachable nodes? Most nodes are behind that and only connect via outbound links The amount of Bitcoin the size of the Bitcoin node the size of the Bitcoin network six months ago Was something like 60 or 70,000 nodes, but only three to 8,000 of those nodes Allowed inbound connections. So if you just create three to 8,000 nodes yourself, or I don't like control some botnet somewhere You're half the gossip network Each node in Bitcoin will connect to seven nodes and for for gossiping You probably only need like a few hundred to be one of those seven that are in the first layer that each node goes ahead And makes their outbound connections to the other thing and this is where we get to stop talking about Bitcoin I know some of you are just excited about that Many users are behind wireless routers Routers implement net this is where outbound is easy, but inbound is a pain in the ass To poor man's firewall and don't mock it because it sure worked a hell of a lot better than the firewalls We actually did have in 2001 And some that we have in 2011 frankly Most home routers implement UP and P is called universal plug-and-play UP and P allows nodes inside your network to allow your router to Open up ports from the internet Bitcoin will actually by default now tell the router, please open up my UP and P ports But what if someone's running an old client that didn't actually go ahead and ask for you know the ports to open up? Well how UP and P is supposed to work is that internal hosts will send out a multi-cast message out by SSDP Multi-cast works fine on like a single network It's just when it tries to hop over like anything larger than one land that it becomes a disaster What's supposed to happen is that whoever on the land that actually does support? UP and P via this SSDP protocol Whoever it actually supports it is supposed to reply and the reply is supposed to contain some secret information Then that secret information is then unicasted towards a Towards the UP and P ports or UP and P service and Now you can go ahead and make requests So effectively it's a challenge the server wants to know the client can actually hear it That is actually on the land that it is actually local UP and P is supposed to only work on internal interfaces It'd be tragic if routers listen to the internet and said hey internet You want me to open up any ports? Yeah Turns out that a bunch of routers not only listen on both internal and external interfaces But they don't actually have the randomization so anyone can ask them to do anything. This sucks And by the way, this is not a thing that is like dotted around Entire countries have like a single ISP and that ISP is like a single wireless node That they give to all their customers and that wireless node Implements UP and P with no randomization and outbound listening. So yikes I want to be clear not everything on the internet listening on 2869 is fully open Everyone gives Microsoft crap, but all the Microsoft listeners are actually fine They went ahead and implemented Randomized end points. So yeah, you can talk to it over TCP But when you actually say hey you Open up some stuff because you don't have the secret that I would have given you over the land screw off right answer But a lot a huge number of nodes are hundreds of thousands to millions You can just hop on the land by asking their router on the external interface to Let you play I'm not the first to start playing with you PNP The turns out there's like a small research community that's been looking in this Go look up the work of a Daniel Garcia Armin Hemel upnp hacks org people have been poking at this for a couple of years now and Probably by the next Defconn will have some really concrete data and tools. There's some really nice tools out already You map that's Daniel Garcia's tool. It's beautiful Way nicer than the grab I was working on What about outside the consumer space, you know corporate environments are less about Bitcoin and UP and P more about web services and Accels access control lists Are there ways past corporate ACLs? Well, you know, basically what an access control list to says is if you want to go ahead and talk to this destination Your source must be this particular IP. It's completely stateless Now, of course, you can just go ahead and spoof your source IP, right? Just pretend to be some source IP vaguely near the target and you're almost certainly going to bypass the access control lists Now I tell this to networking guys and they're like, but Best practices BCPs, they say that you can't spoof your traffic and it's like, yeah I can't spoof my traffic from my little home cable modem provider from, you know, any real-world hosting spoofing works fine People like but ISP should implement and then you go to you say, hey, how good's your URPF? Implementation is anyone in this room actually worked with a thing called URPF anyone one person as Somewhat, I don't even know Raise your hand if you think it's a complete piece of crap Right there we go. I just got a thumbs up another guy URPF scales right to the point that it works for a single network and a single like a Cable modem or DSL URPF is supposed to automate a network knowing which networks It's supposed to be able to send traffic as and don't work. It really doesn't there's no way You can piss off a network engineer more than being a security guy saying your security technology doesn't work network guy Got in horrible fights that way. What can I say it doesn't work? So is IP spoofing still effective? Well, this is an old trick. I said I wasn't gonna talk about DNS But this is just fun, right? So what you do is you go ahead and you generate a query for some random domain Subdomain under a domain that you control you Crap requests for that randomized domain all over the internet from people's neighboring IPs Now what happens is this goes through the access control lists and it arrives at the name server name servers like oh look I've got a request now it won't send the reply back to you because you spoofed your source But you control the domain and so when this random name server that's you know, every network's got a name server When this random name server sees your request it has to forward the request Back to you So now you go ahead and you know, okay if I spoof traffic with this source IP to this network I actually do see a request so I know I can get in now. This only works for obscure application like DNS and UDP Certainly nothing like TCP right? All right, so I'm talking about some wonky stuff Most modern protocols run over TCP is a reliable communication protocol some of you in the room totally know about it Some of you don't so let's do some basic introductions Allison's Bob a sin contains a random sequence number Bob replies with a sin act containing both Alice's sequence number Proving that Bob could hear Alice and then his own sequence number Alice receives the sin act sends an act with basically Showing that she got Bob's number and that she's still Alice because she knows her number so the security model as what it is is that you know that You're a you know that you're speaking to someone who can actually hear you because they saw your sequence number You saw their sequence number So sequence numbers become kind of a form of a really crappy password They weren't intended to be this right they were just intended to make sure that They were just intended to make sure that you knew where in a byte stream You were and that the two sides had a similar idea of what was being sent But we we turned them into kind of randomized passwords Here's the problem Connections are identified by a combination of four values source port destination port source IP destination IP Sometimes Connections are recycled so you'll actually have this what's called for tuple used once over again So I just an example and this is a DNS request 24 dot 1 2 3 from a random source of 50,000 Talk to 4 2 2 1 on a totally non-random destination of 53 the Most dangerous thing that can happen to TCP is that packets from a new connection Look like they're packets from an old connection because everything built on top of TCP assumes reliability it assumes that Whatever it's handed Doesn't matter the noise doesn't matter corruption The other guy sent this there was no screw ups. There's no Error tolerance in anything depending on TCP if there's recycling of connections if there's recycling in these four tuples it is possible that Bites from old will appear in new and the way that is fixed The way you prevent that from happening is making sure that sequences are as far away from each other as possible So in other words, yeah, our four tuple might be the same But that old session is sending bite, you know one million and we're on bite like three billion So these are different sessions. I can drop the packets. No corruption occurs This is super easy when you have predictable sequence number generation You just always go ahead and make sure sequence numbers are constantly increasing from session to session session But if we're making them random because we want randomized passwords now we're screwed because here's the thing If you randomly select ranges, I'm getting a little wonky. Maybe you go over in time a bit, but check it out There sequence numbers are on a 32-bit range. This means there's four billion possible numbers however You know, you're sending data right got lots of data in flight You might have you know hundreds of thousands of bytes, which you know anywhere in there is valid You know You know Look at it like I've got a little window inside the new session a little window inside the old session It's not one bite. It's like a range of possibly hundreds of thousands You got to make sure like this range It's not overlap with that range because if they ever overlap it's the end of the world Or you get bad data from an old session in a new one So what they did is they said, okay? we'll make it so unless So We will be totally random on sequence numbers unless these four values are exactly the same If these four are the same and we have a chance of a collision now, we're not going to go random anymore We're going to go sequential Sequential from a random offset, but we're going to make sure that It's not like you know the random stuff could show up anywhere We're going to make sure like this session from over here is as far away from this session from over here So give me give me give you an example. This is what specified RC 1948 You have some function that takes source IP desk IP source port desk port and a secret and Then it adds time function in this case with MD5 So I have to source a one two three four to two three four five port of five fifty thousand to eighty secret of ABCD One two three four one two three four time equals one one one one sequence number is going to be one two three four two three four five I Go ahead and I change the destination IP just a little set that from five to six All the sudden I'm in a completely different portion of the sequence space move to eight nine nine nine two one two one go back to the original and That all goes away it is made guaranteed sequential so it's back to the original time problem What if someone just floods the game is making sure it's always increased the last thing it got more it could have gone Less it could have gone anywhere. You want to make it so it's monotonic in time. That's the technical term Now there's a problem and the problem is memory. What if someone just Floods us with connection attempts They don't need to remember all of our little passwords They don't even need to use their own IP addresses We need to remember all of the sequence numbers that they used This is what's called a sin flood and it's old as dirt So solution to preventing sin floods, you know with this, you know new security model where each connection has a password It's called sin cookies. It's specified if not invented by Dan Bernstein in 99 Finally on by default in Linux in 2008 by coincidence The password turns into a challenge if you can send this back to me. I will accept your data It uses three fours the sequence number 24 bits to store the hash of a secret and the four tuple and then five bits for time in three bits for some random connection metadata Like you know what how much how many bytes called the mss? How much data can I implement on this tcp session? Five bits are exposed publicly three of the bits don't matter. So there's 24 bits of security Well, two to the 24 is 16 million that means to bypass Sin cookies meaning you're just Gonna go ahead and say I don't know what my password is going to be But I'm just gonna try all of them trying all of them takes 8 million packets And it may actually be even less now Dan Bernstein knew this said no matter what functions use the attacker will succeed in a connection forgery After millions of random act packets What is changed from 1999 to 2011 is sending 8 million packets is not that big a deal Sending it we have the bandwidth so what this means is if you've got some web service that's behind a Access control list and says oh well. I only accept my web requests from like neighboring IPs People can just send 8 million and get through your crappy little 1999 firewall rule No problem So those spoof packets can go ahead and contain, you know arbitrary web services payloads and they'll work I think you actually need to send two packets You need to spoof a sin and then you need to spoof an act as if you saw what the other side had synact But yeah getting through a Firewall that is just looking your source IP you can go ahead and drop arbitrary web services payloads And you can know that a spoof will work because you can DNS to find out that that particular network Cares about your spoof source. So that's what I've been trying to explain if you were wondering where I was going with this So it gets worse Are you safe if you disable sin cookies? Well not on Linux Linux is RFC complete actually now it's safe. They went ahead and actually fixed all this code a few months ago Let me tell you that no one better in the world to report bugs to than Linus Torvalds You're like hey, dude. Yeah, I'm just giving you a heads up if I want to fix this in a few months It's like what do you mean few months? I want to fix this now Who the hell are you in security? Tell me I have to wait five months to fix my bug I want to fix that in five days like dude. Don't let me stop you. I was just giving you a heads up Turns out it took a while for them to actually fix it and that's fine because it was a complicated bug to fix So in the you know up until recently Linux went ahead and was compliant with RFC 1948 for the lower 24 bits of the sequence number the high 8 bits were sequential So I don't know how we didn't notice. I mean it really shows up in like a Raw packet dump, but it turns out in TCP dump it goes ahead in our yeah You know t-shark it would actually make all the sequence numbers relative. So it was hiding the fact that they were all the same So what this means is is that You go ahead From your own IP you send a couple of queries you find out what the high 8 bits are and now that you know The high bait 8 bits are you only have to brute force the lower 24 You spoof your sand you spoof your payload containing act after 8 million tries you win even with Sequence or sin cookies disabled There's some impact on some other attacks thing in 2005 Tony Watson wrote a really cool paper called slipping in the window He noticed that you know so when you're actually sending data in a session There's one set of rules, but it's a much more relaxed set of rules for Resets when you're actually trying to close one and what? Tony found is if you just got a reset in the window you could What's it called? Oh, you could shut down connections even without with much greater ease You so in a window you know TCP you're sending lots of bytes You're not just sending one byte at a time She might have say you know 64,000 bytes anywhere in that region is good if you got to shut down anywhere in there It would shut everything down. Well now the fact that in Linux the high 8 bits are remotely visible You have an even better view of where you should go ahead and send your resets because you're not guessing across 4 billion you're guessing a cross at best 16 million I think the math ended up working. Oh, the other thing is we've implemented something called window scaling So the original design of TCP it said well, you might have like 64 kilobytes that are I want to say this that have not been accepted yet that haven't been Acknowledged that's the word I'm looking for So we'll go ahead and send data even though you haven't acknowledged yet up to 65,000 bytes or 64,000 at which point Well, we'll stop until you say yeah, I got it Well, turns out we have these what are called long fat networks these long fat networks like satellite links and even just you know Really high bandwidth links You might actually have hundreds of hundreds of kilobytes maybe even megabytes that are just in space. They're just floating And so if you want to really use all the available bandwidth you have to allow more and more and more data to Be unacknowledged and so you get the window scaled past 64 kilobytes up to possibly megabytes. Well, since there's a bigger window You end up with we started out with 32 bits We subtracted 16 because of the window size. We subtracted eight because of the high the higher bits You end up in its average of like 128 bits 128 packets to kill a session now if you go ahead and make window scaling even bigger You can get to the point where like a single packet will kill an arbitrary connection without you having any visibility into the data on that session So that kind of sucks Is there a possibility of injection? Maybe the reset handlers only check one of the sequence numbers There are two in every packet. There's the one from Alice is the one from Bob Act handlers though go ahead and check both So we have 32 bits or 64 bits But now we go ahead and we shave off 16 from Alice's window and 16 from Bob's window So now we're down to 32 bits that still requires two billion packets for a 50% chance of injection Ah, but we have window scaling. Let's say we have five bits on each side So five bits from Alice's window scaling five bits from Bob's window scaling now We're down to 22 bits now We have one million packets for a 50% chance of injecting into a session blindly Um, ah now we have the predictable high bits too So we have eight bits from Alice's predictable high eight bits from Bob's predictable high six bits left That means 16 packets for a 50% chance of spoofing blindly into a session moral of the story Please now have firewalls more advanced than will we stop IP spoofing? So that's probably the most obscure thing that I'll talk about That's a lie There is some difficulty with ports Lennox has some stuff where it randomizes the source port of a new connection by default So you do get port ranges that you have to go ahead and brute force But at the worst case they end up increasing the amount that you have Oh, here's the nice thing firewalls will not only go ahead, you know be configured to Just block IP spoofing sometimes they'll take your nice port randomization and make your port sequential This was a huge problem with the DNS fix because we were randomizing our packets, but the firewalls were Resequentializing them So but even when that happens even if they're not doing that you get to you know 250,000 packets for spoof So this is old code actually predated Lennox's Linux Torvald access to a source tree. So it was there when it got into jit They did actually implement the fix and it's fine it raises it from like 24 bits of security to 31 bits of security and they fix a bunch of other stuff Kind of a digression You know RSE 1948 some interesting construction it involves Sequential and it means that to data is sequential and ordered with the key So if you know all the secrets everything's in nice order if you don't know the secrets as random and Unpredictable, so it's just kind of like public or public cryptography with nothing but a password I mean that's not supposed to be possible. I guess it's only here because we're at an intersection of network security and cryptography I had a bad idea. This is truly an awful idea Passwords are a bad idea they're constantly being lost and forgotten and stolen They're responsible for about 50% of compromises. They look like elite speak. What the hell are we doing here? I Suppose we ignore all that Suppose we assume we're stuck with passwords. What can we do? Just don't challenge How do we use a password to log into a system without that system learning our password? But we often say oh, you know passwords should be hashed You know anyone who builds a web app that doesn't hash passwords as an idiot by the way, is it over? Okay, if I go over about ten minutes I'm gonna go over ten minutes because I'm an asshole Come on up and tell me if I'm if I'm being a really bad person all all I won't do it I won't do it um You're a bad person time. How about five minutes? Okay, five minutes and then get as you five minutes for questions and insults All right, I've been explaining stuff. I've been going a little okay to check it out, right? look You can hash the password in your database all you want I still owned your web app, and I'm still watching plain text arrive into it Oh, no my ownership today has to continue for a few days, and I see all your active users guys There's you know There's all the challenge response stuff We challenge you to hash your data against this password properly So send me your password hashed against this random value This requires the server to store the plain text password Otherwise, it can't send you challenges because it doesn't know what to challenge you against Or me at worst that's do a plain text equivalent thing. So ntlm works The most advanced one is we require knowledge of the password to go from a key pair to a shared session secret This is how speak works is our SRP works It requires the client and server to run some fairly obscure code Good luck getting either deployed and still the bad guy can go ahead and break in and do their offline password computations That kind of stuff So here's an interesting thing Is it possible not good but possible to build a system where a client only remembers a password but the server stores nothing But a public key deploys nothing but a standard like SSL client authentication Mechanism to make sure the client has a matching private key which is derived Unilaterally from a password. Can we construct cryptographic key pairs out of passwords? Is that possible? I don't know. Let's see well You know what the one bug that all ace met your crypto systems that do key pairs and then the one bug they all had RSA DSA or ECC Well, remember the Debian bug Now that a random number generator and the random number generator was busted in all the ciphers fell over and died So all ace the met your crypto systems use entropy as follows You collect some random bits and then you permute those bits until they meet certain Requirements and then from those permutations you emit a public private key pair So predictable entropy equals predictable key pairs no matter what the algorithm happens to be So what if we turn the Debian bug into a feature? Oh? Hash functions stream suffers block ciphers all of them can construct into each other We know how to take passwords and construct an everlasting stream of pseudo random numbers from them And this is you know pseudo random entropy predictable entropy We can even do this in a way that is hard both in terms of CPU time and memory It's called s-crypt. So what if we do that? What if we have the input the output of a password seeded prng be the input to a asymmetric key generator? You end up with 2048 bit RSA key pairs that have a trapdoor in the form of a password This is not theoretical. This is actually implemented normal use of SSH key gen you go ahead and you generate It's three times you get three different keys Because you know a stage key gen is normally going ahead and going to dev random or dev you random Well, we're going to go ahead and hook those so we're going to go ahead and Have every time SSH key gen runs it gets the Entropy as generated from the phrase high grandma and now we see the actual same SSH key being generated I call it fidelius. This is a horribly obscure Harry Potter pun because Harry Potter properly understood is a story about the epic consequences of losing one's password So what fidelius does it hooks dev random dev you random open s cells randomized functions and a couple other things And it makes normally high quality entropy have a backdoor of a password. It works very nicely uses sCrypt to require one second per of Processing time per attempt to make brute forcing quite a bit more difficult. So no, you don't get to use GPUs What fidelius gives you is generic multi application support It turns out that apps that no need to know That they're even being made to generate things predictably servers that have certificates have no knowledge that the Private key can be reconstructed from a password You know one of the things from Bitcoin you can actually go ahead and have money sent to I don't know a Picture of your mom and you know picture of your mom turns out to be the key to you know claim your money. It's kind of cool Um There are some bugs, you know, not just the bugs of like it uses passwords in their bad But bugs like it's super fragile, you know the actual way entropy is used by SSH key gen is not specified or fixed So you have to keep using SSH key gen. It's also really hard to salt. There are some tricks, but uh Two uses of the same password are almost certainly going to lead to the same private key And that kind of is a bad architectural decision There are some tricks that you can do but telling bug me about them later So there's one last thing I want to end with it's kind of a TCP IP trick The actual part of it was invented here actually was invented like in the back over there But I finally got around up for a few years to implement it Anyone here worried about net neutrality So I am maybe you're not I'm not so much worried about networks that are outright blocking traffic I am working worried about networks that subtly slow things down What I want to say if you work for an ISP in the long run what I'm about to talk about means I Hope you like whatever you're doing being public because it's going to be If you're proud of it great if you're not you might want to stop Check this out Here's your standard network topology Some client desktop has a home router connects to an ISP the ISP's got a bunch of network links Those network links talk to Google or Microsoft or Yahoo or wherever Fear is this Some magic box has been deployed within the ISP network in front of all the links the box Packets to policies and applies different rules to different packets these policies can be stateless Do I like this packet or they can be stateful this packet is part of a flow? Do I like this flow now the policies can be anything and they can do anything they can limit bandwidth They can increase latency they can even alter content throw a few advertisements in there And the reason people are afraid of this is because ISPs are demanding the right to do this So it's not actually like subtle or anything How do we find this stuff? Well, like I said my fear is not that stuff is outright blocked because blocking is not subtle I'm worried about stuff like Bing is 50 milliseconds slower than Google It's totally deniable. I mean, you know Bing has a different servers than Google Bing has different networks than Google This might not be because the ISP is doing anything. This might just be because of the rest of the network So there's plausible deniability. How do we get rid of that? Well, what we need is normalization if I have some test system whether the tester is accessing Bing calm or Google calm The network path should be identical or at least uncorrelated with whoever is you know, this appears to be We call this uncorrelation Normalization that way any changes in behavior of quality of service or content are not because of the path taken But because of policy presumably at the ISP So the really basic way to normalize is just to ask random I you know some test server on the internet for the content from Google or the content from Bing You're talking to the same server over the same network paths. Just your host header happens to say Bing or Google Okay, you don't need to write any code for this just like deploy squid because that's what squid will do Now if you get different performance when you're emulating Bing versus when you're emulating Google You know that the problem is in the ISP and this will actually detect very nicely HTTP HTTP bias policy today. No work required The problem is that this is really protocol dependent HTTP can be made to do this in a low work effort But other protocols require lots of work to implement and emulate because HTTP really wanted to support caching Proxies that did interesting things whereas other protocols have no idea what's going on and the other problem is that Policies can be really specific to IP addresses you sniff DNS You figure out which IP addresses need to be slowed down because you don't like them and then you go ahead and you know It doesn't matter if you've got hundreds of test servers around the internet If policies are only applied to IP addresses that are genuinely Bing or genuinely Google So um, I have a solution It's called neuter. It's the network normalization engine and the best way I've found to explain neuter is this How many of you guys have ever used a VPN? All right, so VPNs make it look like you're on some other network, right? You got some client traffic is sent from the client to a broker or VPN concentrator as we call it the IP address Right now your IP is the brokers IP whatever it gives you so an IP associated with the broker contact servers Who apply to the broker the broker encrypts the traffic back to you so the ISP doesn't see anything, right? Like it's an encrypted stream to a VPN concentrator and the VPN concentrator replying back encrypted so You know None of the filters are triggered. Well, that's a problem. That means we don't actually see the behavior of the filter So here's what I'm thinking you do a VPN just as normal, but now When the broker communicates back to the client that traffic is not encrypted It's open in the clear in fact not only is it not encrypted It spoofs the source IP of the real Google of the real Yahoo of the real whoever you possibly want It's unencrypted. It's spoofed as if there was no broker. Why do you do this? You want the ISP to see your return traffic because we're trying to trigger the response We're trying to trigger the policy that would normally apply to just Bing or just Google We wanted to apply to our normalized test server the policy engine can't tell because we're impersonating the real entities The traffic took the same path it came from the same source. Why else would we be seeing different quality of service? Now of course anyone here is a network engineer knows the bug in all of this The bug is the policy engine in this scenario doesn't see the traffic from the client to the server That's encrypted like in a VPN What if the policy said aha I am sneaky I am not going to filter one-way return traffic because that guy's just trying to bust me This is a very very interesting idea. It's also a trap Totally gonna have on the five. It's great. Check it out. We did neuter now We're gonna come out something called roto neuter a normal neuter We were spoofing the server to the client in roto neuter We're gonna spoof the client to the server So we're gonna take two network samples in sample a we do nothing client talks to Google Real Google ISP sees the sin you get some performance characteristics in the second model and sample B Client talks to the real Google by way of the broker. So the ISP sees nothing Broker goes ahead and talks to Google and it spoof the client it tells Google Oh, yeah, you know that user that ISP just went ahead and sent you a sin. Why don't you send him a sin act? In fact, why don't you talk to him? So in this case the ISP does not see the sin Both samples have a real set of responses coming from Google But in only one of those situations is the ISP seeing the sin from the client So if there's different performance characteristics, that means that aha you just busted them You know having their policy engine be sneaky So it's a it's a damned if you do damned if you don't if the ISP applies policies to the half-flows neuter can Differentiate performance of the spoofed half-flow from Google from the spoof half-flow from Bing if the ISP Applies policy only to full flows though Roto neuter can differentiate the performance of the full flow to and from the real Google versus a half-flow from the real Google Either way, I'm going to win So bias policies might as well be transparent because they're certainly not going to be deniable in the long run Now let's talk about three tricks that get really fun We're taking full flows suppose you really do want the ISP to see full bidirectional traffic the advantage here is all the policies are triggered Also your gnats that might be around they're all opened up Nats really don't like it when there's unidirectional flows because it breaks their model of how networks function The problem is is if the ISP sees the real client to server traffic You know who else does is the real Google like you're trying to spoof something Google's like What is this weird-ass network session? I'm seeing and it goes ahead and it replies or no fears it complains It's a real problem So how do we deal with that? Well strategy one of three is we have a bad TCP checks on so client goes ahead and does all the normal Trafficking of data through a broker to the real Google and then Google replies But then client does something more which is actually sends a stream to Google But all the streams to Google have a bad TCP check some so the packet leaves the net and triggers the net rules And it leaves the policy engine and triggers the policy engine rules And then it gets all the way to Google and Google goes like this is an invalid traffic abort And so that works pretty well Now the policy engine might go ahead and detect things are wrong or not might go ahead and fix the checksums This doesn't necessarily work But you can catch 22 on this as well The next strategy is to use a low TTL. This has everything be valid But you know the packet only gets about you know five or six hops out of the ISP Middle of some sprint link, you know some data center somewhere just drops on the floor Policy here as well could detect low TTL and not trigger stuff. But again, you get to catch 22 of them The third one is the fun one. This is my favorite trick in a while When a TCP stack receives a message that is not actually associated with a real session It is supposed to send a reset supposed to be like this is broken I don't know what's going on abort that is what's supposed to happen But us security people said no firewalls if they get anything wrong, they should just drop it on the floor Perfect because that's what I want. I need Google to ignore some of my traffic So here's what I'm gonna do The client is gonna go ahead and complete a three-way session with the real Google and then the broker because it knows the sequence numbers It knows the passwords. It's gonna send a reset. It is gonna shut down that connection on the server client Now what happens is the client is doing all the normal stuff where it's proxying connections through a broker and whatnot But it's also sending real traffic to Google and Google is gonna ignore all that stuff because it's seeing all these packets on a session That thing already got reset. It ignores it. So, you know client sending packets to a server Server sending packets to a client. Everything looks perfect from a policy standpoint policy engine is triggered But it's not talking to Google and not gonna me I just hit my end of time Bug me for questions. These are the random toys. I've been playing with I really hope you enjoyed them Oh, Dan. Yeah, Dan you may you may have to buy a bunch of people some drinks Really? Yes, because the bet ah well the Viara IRC a group Thinks that or is thinks that you may have rediscovered something that they discovered in 2007 Your talk doesn't credit them for the Linux sequence number. I have no no I was certainly not intentional. Does anyone have the names of the people I may have screwed up crediting because I mean That's a really big deal. Yeah, they've got the links are all down here. So I will Apologize profusely in advance. It's I'm by everybody Jagermeister. I will buy drinks absolutely now Here's the thing they certainly didn't get it fixed But if if if I if I've accidentally Recapitulated some research. I apologize. I do everything in my power to find stuff And I'm happy to buy Jagermeister for all of you. So my apologies Thank you very much, Dan The puppies and flowers we waiting for you downstairs