 Abaddon is going to be talking about Airject 2, which is a very exciting thing that he's been working very hard on for all of us. We're all very excited about that. And then at the end, we're going to have an opportunity to be able to talk about, answer your questions, talk about things in the wireless security field, doesn't have to be just things that are in the panel. Okay, it's really quiet. And feedbacky. Okay, Kiznet 3 is out. Lots of new toys in it. It's been about six months since the last release. This one should be more stable. Just cover the main new things that are out in it. The channel hopper is now part of it. I got a lot of questions about people who had to start it separately who didn't. So that's taken care of. Packet handling is a little more secure. It spawns off multiple processes to handle each capture source. Does IPC back to the... Some of the big things in it. There's some stateful packet inspection now. It'll detect... Yes, thank you. Probe not joined. It will detect things based on behavior instead of single packet signatures. So things like NetSummler will get detected with how they behave, looking for networks and never participating in them. Remember, it's not going to be the same thing. It's not going to be the same thing. It's not going to be the same thing. Remote Sniffer drones. You can now run a capture source on a cheap throwaway PC, send the packets over a wired network and analyze them with one Kismet server. It works in OSX now. There's new alert systems and there's more drivers. I see we have OSX fans. There's some more detailed things here. With the Kismet drones, you can cover the entire floor of a building or an entire building. Send all the packets over the wired network, log them all in one place, pipe them all to snort in one place. Basically, if you're too cheap to buy his company's product... It's a good thing for... It's not so much the oriented towards war driving, but it's good for IDS. The new alert system, previously all the alerts came in pretty much unmanaged. You can now do burst alerts, rate limiting. Eventually, we'll have plugins. I've been saying that for a year. It'll happen when it happens. I mentioned the stateful packet alert stuff already and the named pipe output allows you to use a named pipe file, which IDSes like snort can then open and do live layer 3 IDS of the packet stream. If you put the web keys into Kismet, it will de-wep the packets for snort, which is fairly important if you're doing IDS. That actually looks pretty much the same as it did before. We weren't going to do this with a live capture stream, but we ended up having to. It should be interesting. Can we dim the lights? No? Okay. Actually, it really looks pretty much the same as the previous versions. People can go through the screens themselves, so we'll move on to people with more interesting tools now. I'm the schedule Nazi. Okay. As long as I've known Mike Kershaw, he's never taken enough credit for Kismet. It's a great product. It's a great tool that he can get a lot of money for. Mike Kershaw. Thanks. Okay. I'm going to be spending a couple minutes talking about weakness in the LEAP challenge response mechanism. Okay. What is LEAP? Well, LEAP is Cisco Market Share. What's the deal? So, LEAP is Cisco's plan on controlling the 802.11 airspace. Now, we've got different EAP types available to us for 802.11 X authentication on wireless networks like PEEP, TTLS, EAP TLS, but none of those three make Cisco as much money as LEAP does. So, what's the deal with LEAP? It's the lightweight extensible authentication protocol. It's also known as Cisco EAP. It's easy to install and configure, easy to support with a unified supplicant, and it must be secure, right? Well, the thing about LEAP is Cisco has been lately pushing this big program called Cisco CCX. I don't know what the acronym stands for, somebody else does. But what Cisco is doing is they're licensing the LEAP software to other manufacturers. So, you don't have to buy Cisco cards, Cisco Wi-Fi cards to be able to use LEAP on your network. Now, you can buy a Linksys card, a D-Link card, a 3Com card, whatever, and it comes bundled with the drivers to be able to do LEAP. The part that Cisco makes money on is when you buy APs. So, if you want to do Cisco LEAP, you can only use Cisco APs because that's intellectual property of Cisco, right? So, the LEAP specification is only open to business partners of Cisco. Like I said, the client is licensed to a bunch of other manufacturers, and what happens is these manufacturers license the client and now use the consumer to say, oh good, this extra thing is available. Now, it's much easier for me to secure my wireless network with Cisco LEAP because I don't have to go through the trouble of setting up an 802.0.1x server. I don't need to buy still-belted radius or any of that kind of stuff. I don't have to worry about distributing client software to all my clients. They already come with these drivers that I'm getting with these cards. So, Cisco is making it very attractive, but when you use LEAP, you're locked into always using Cisco APs, and that's where the cash cow comes in. Okay, so, information here, just for my own disclaimer purposes, is derived from packet captures of LEAP transactions, specifically through counting bits with ethereal, and from this one post that's on the internet, I believe this slide's on the Defcon CD, so if it's not, you can email me and I'll get your copy of it. Okay, Mike? So, what does LEAP do? Well, it makes the world a lot safer for everybody. So, LEAP actually uses a modified MSChap V2 challenge response authentication mechanism to make sure that you are who you say you are when you join a LEAP network. It uses mutual authentication to mitigate man-in-the-middle attacks, so you're not only authenticated to the AP, but the AP authenticates itself to you. It uses short-lived web keys to encrypt data, and it prevents the usage of weak IVs from the access point, so this mitigates a lot, not all, of the effectiveness of tools like AirSnort and WebCrack and BSD AirTools. It does reduce the probability of IV collisions due to a randomized selection process, so when it doesn't use a sequential initialization vector counter, it actually uses a randomized value. Mike? Okay. So, the weakness that I'm going to be talking about is actually in the MSChap V2 authentication challenge response. So, what sucks about MSChap V2? There's no salt stored in NT hashes, so the NT hash is basically just an MD4 checksum of the file of the user's password, 16 bytes in length. That's it. No salt, so it's vulnerable to dictionary attacks. Dictionary attacks, however, can be very time-consuming, and I know all the attendants here with ADD just wouldn't have the time to be able to wait for that. Okay. It actually uses a weak DESKEY selection for the challenge response mechanism, and that weak DESKEY selection lets us discover the last two bytes of the user's NT hash. The user names are set in clear text, unlike TTLS and PEEP, which encrypt user names and passwords, so that's not immediately obvious, and with all these flaws, we can actually deduce user names and authentication passwords just by looking at the leap challenge response mechanism. Okay. So the leap station challenge response mechanism works like this. The AP issues an 8-byte challenge to the station. The station then accepts that 8-byte challenge and they take their NT hash. They split that NT hash into three 7-byte values to seed DESK with. Each key is used to seed DESK to encrypt the 8-byte output, the 8-byte challenge, which generates 8 bytes of output. The three times that happens generates a 24-byte response that is sent back to the access point. The access point then does the same process for the challenge response and makes sure that they match. That's how that authenticates the user. The DESKEY selection actually works like this. It has to split the 16-byte value, the 16-byte NT hash, into three 7-byte DESKIs. DESKEY 1 are NT hash bytes 1 through 7. Key 2 are NT hash bytes 8 through 14. And the DESKEY 3, remember it's only 16 bytes in the NT hash. We use 7, 7, 14. That leaves us two bytes left. So in MSChap v2, they actually use five null characters for that third DESK seed. Okay. And after the AP receives that response to the challenge, it issues a success or failure message. Right? Okay. So the problem here is that the response leaks two bytes of the user's hash, the last two bytes of the user's NT hash. The third DESKEY is weak. Because we're only using two unique bytes in that DESKEY, it only leaves us two to the power of eight possible permutations to be able to guess that third DESKEY value. Because we know the last five bytes are always null. So, and on a measly Pentium 2, 233, I can calculate two to the power of eight DES challenge, DES encryption mechanisms, and two to the power of 16. Two to the 16. Wow. Sorry. Two to the power of 16, not two to the power of eight. I was smoking crack when I wrote this, and I just messed it all up. Sorry about that. So we're able to recover, the bottom line here is that we're able to recover the last two bytes of the user's NT hash. Why is this important? Because if we have a big pre-computed database of all the users and all the, all potential passwords and NT hashes, we can significantly reduce the amount of search space we have to do on that by a factor of two to the power of 16. So in a simple example I put up here is, imagine grep ending by one, ending by two, matching to the end of the file of an NT hash dictionary, and that generates a list of possible passwords that we can use. So the bottom line here is it significantly reduces our search space in that big dictionary file to be able to find the user's password. And in my experience from about 2.5 million passwords in a test dictionary that I was working with, usually leaves about 30 guesses that I have to make. Okay. So what's our attack? Our attack is to take a large password list and pre-calculate the MD4 hashes for each entry in that list. So we take a big dictionary list. Myself, I took a 300 megabyte dictionary list, and then I added 0, 1, 0, 2, 0, 3, 0, 4 to the end of every, to the end of every password. And then I started changing O's to 0's and I's to 1's, and I ended up with a really huge dictionary file when I was all done with it. I then passed that file through a tool that generates an indexed binary file for efficient lookups of the user's password, the clear text password, or the potential password, the dictionary word, and the 16 byte NT hash. So what I do then is once I get the challenge response mechanism from a Cisco leap connection, I calculate the last two bytes with a third DESCII weakness that I just talked about. I only look at those entries, and then I use each password to try to encrypt the challenge text that I got from the access point. I only have to do it about 30 times or so, like I said, in 2.5 million passwords, or 2.5 million dictionary words, and I can do that in about 10 seconds. So the matching entry, so when I match the NT hash, I've got the associated clear text password with it. Now I know the username and the password of the leap authenticated user. Okay, so that's great when it's all in theory and everything, but where's the wares? Well, here they are. So it's a tool I'm calling a sleep improved, because the first version really sucked. So a sleep, I thought, was appropriate for Cisco, like a sleep behind the wheel when they decided that MSChat v2 was a good idea to do challenge response authentication. So gen keys. Gen keys is the program that takes a huge dictionary list and then generates an MD4 hash of each word that it has in the dictionary list and writes it to a binary indexed file. On my Pentium 3, I was doing about 65,000 words a second, except when I was running Kismet, then it was about 40,000 words a second. So MD4 hashes are made to be fast and efficient. So with the appropriate amount of disk space, you could, in one instance, you only have to do it once, generate a very, very large indexed file to be able to use for potential matches to a user's password. So the sleep tool. The sleep tool does a couple of things. It reads from either a PCAP stored file or from a live network interface in RFMON mode and it watches for the leap challenge response mechanism. It calculates the last two bytes of the NT hash and searches the gen keys output file for matches and then it reports the user's password. Okay. So that was pretty much v1 of a sleep. So I thought, well, I should probably add some features because I'm sick and tired of waiting for you to authenticate to their leap networks. So what I added was a search mode and the search mode actually does channel hopping to go between all the channels that are available on your card and then look for any data traffic on every channel. It has an active mode. So the active mode identifies active stations on the network. So if it sees a data packet, 2DS, to the distribution system on the network, it identifies that as an active node on the network. It injects a sleep tool, injects a spoofed, de-authenticate, leap logoff, a leap logoff frame followed by a de-authenticate frame to that station on behalf of the access point. So the station receiving that packet says, oh, the access points tell me to log off. That's perfectly legitimate. They might be low on resources or they might be low balancing or whatever. I'm going to re-authenticate now. That forces them to re-authenticate so it makes significantly less waiting for me to make that happen. Thank you. And a feature I just added was to maintain a binary AVL tree to maintain all the stations that I've seen in the network. So I only have to attack each station once. I don't have to blindly keep attacking stations that I've already found their passwords. Another feature is that it saves a leap exchange into a pcap file. So I only need three frames. I need the challenge, I need the response, and I need the success or failure message. The sleep tool is smart enough only to give me to only try to crack passwords when it's a successful authentication. We don't want fat finger passwords because that just wastes our battery time. But the feature of the WTAP file is this. I've got an IPack running familiar. The tool compiles on ARM. I can run that tool and it will be in active mode and it will just dump all those challenge response packets to a different file. I can take that challenge response file to a big system like a spark system, a sun system with a huge amount of disk and a huge dictionary password, and I can just go to town on that system. So it works out very well. Okay, a little demonstration. I do not have a Cisco access point. So the GenKeys program just takes an input file and an output file. So for this particular case, I've got this big dictionary file of one password per line. These are really probable user passwords. It's just sorted. So I already ran that through the GenKeys program so you guys wouldn't have to see that. But the GenKeys output file just reports this data. So if I want to run a sleep, I just say run a sleep. I'm going to identify what the NT hash file is. Thanks, man. So I'm just going to do a very basic test. We don't have a live LEAP network here for me to test, but I'm just going to pass the LEAP-F for the GenKeys binary output file and stored pcap file I have on the system here. And so immediately it finds the username information and it calculates it has a challenge in response. And in less than a second, I calculated the hash byte. The last two values are the hash bytes. And there you go. It reports the NT hash and the user's password at the end of the file. How about that, huh? And of course, my favorite username, Tim's mom. Who also has the user password, password. Okay. Can we get the lights back on? Okay. A couple of last points. Cisco, as of 20 minutes ago, released a peace heart advisory on this weakness. So that's up on the website. Thank you very much to my friend John Stewart for taking care of that for us. So I'm working with Cisco on a little bit of ethical disclosure kind of stuff, but surely thereafter this tool will be made available. And if you just watch the bug track mailing list, I'm sure you'll catch up on the post. So I've got a couple of minutes, I think, for any questions. It was that good. Everybody understands everything about MSchevvy 2, and that's awesome. Okay, so the question is, if I pick a binary password, you're not going to be able to crack it, right? Or a difficult password, a recommended, good, strong password, right? And the answer is... Sorry? Okay, yeah, not password, right? Okay. Well, and the answer is no. The tool is only going to be able to find passwords that have matching passwords in your dictionary file. It is still a dictionary tag. It's just much more improved because of the weakness in the third-desk key value there. There are potential improvements to this. How many people saw the slash dot article or read the paper on the LASIK MSchev v1 challenge where they used binary hash tables to do fast and efficient password lookups? The speed time trade-off paper? Okay, that would be good. Your users use stupid passwords. This is not a valid scenario in that they used a good password because I've yet to see it. Your users are dumb and you know this. That's why you don't get people your shadow file. People couldn't correct that if it was a perfect password. This is the same thing. I was actually discussing this very issue with somebody from Cisco a couple of days ago, and I asked, are there any password auditing features in Cisco Secure ACS where you can expire invalid passwords or passwords that are weak and can be cracked? The answer was, well, no, that's an interesting feature, though. But an excellent question. Anything else? Sir. Will I be released in the dictionary? The big dick. Sure. If I can put it up on Sourceforge and I have to pay for the bandwidth, yeah, sure. But, you know, you want to use a password dictionary that is appropriate for you. I did include a couple of parole scripts in here that'll run through your dictionary file and make it freaking huge. So just with all the common permutations of, I know, I'll make my, you know, password with an E, with a 3 instead because nobody will ever guess that. So just some stupid shit like that. Yeah, right. So the comment was, you could use a two-line dictionary password with password and Cisco in there, just like Cisco routers are. So an excellent piece of recommendation. Okay, the question is, does PEEP use MSChap V2? And the answer is yes, it does. But PEEP uses a TLS tunnel to encrypt MSChap V2 so it is not vulnerable to this kind of attack. We'll see how it's vulnerable in a little while. Thank you, everybody. It's my pleasure to introduce Anton Rager, who's going to be spending some time talking about his new attack tool. Anton? My name is Anton Rager, and go ahead and jump to the next slide. I want to talk a little bit about injection attacks on WEP. Most people, when you think about WEP, you're thinking about how do you break the keys. Most of the tools that are out there, people are trying to run air snored or WEP crack or other sorts of tools like D-WEP crack that are actually iterating through weak initialization vectors to try to derive the actual key so that then you can associate and log on to the AP and actually be a valid user. But that takes a lot of time, and it takes quite a bit of data to be able to collect enough data to be able to break the keys. It turns out that it's much easier to come up with ways that I can just inject traffic into your network. And so I can craft arbitrary packets, inject it into your network, and I'm not really worried about knowing your encryption key. I'm just utilizing the fact that WEP is RC4, and it's easy to derive some of the keystream from each of the packets and then just replay that same keystream, X-Waring it against different data. So here's kind of the run down of an attack, like an injection attack. We need to know a keystream for a specific initialization vector. There's two ways that are already publicly known. One way is very difficult to actually pull off relying on DHCP discovery frames, and it turns out it's very specific to Windows in a way that Windows sends out a DHCP discovery. You have a lot of known plaintext. Known plaintext gives you the actual keystream for that IV, because you can just X-word against the ciphertext, and now you have the keystream that you can re-encrypt with your own data. Shared key authentication. Last year, this gentleman here came up with this attack, which is shared key authentication has a tremendous amount of plaintext that's known. It's actually how the authentication process works. Which is cleartext, and the client turns around and sends an encrypted response of the exact same cleartext encrypted. So now you have the cleartext and the ciphertext, and you X-word the two and you get the keystream. It's really smart of them. Not only is it a really bad authentication mechanism, it gives you material you can now use to re-inject into that network using the same IV over and over. There's another one that I will just cover real briefly that I'm still in the process of working on and finishing up, and that has to do with IV collisions of mixed protocols. So, specifically, and I'll talk a little bit more about it, but if you have an IV collision that involves an arc frame and an IP frame, if you lay the two out next to each other, it turns out they reveal pieces of each other that you can then use to come up with known plaintext. That's something that occurs more often than, say, looking for weak IVs. It's much more likely to occur than waiting for 7 million IVs to go by. So after you have that, you now create your own frame, your own IP packet and you put whatever text you want to in it and re-exward against the key stream and then you send it back to the access point for the IV that you captured that maybe was with the shared key authentication and the AP will accept it, or a node will accept it as a valid web frame as long as you calculate the ICV and it looks like a valid frame. What you have is you have a transmit-only attack channel because you really can't read what your responses are. You can inject all day long, but you don't know exactly what's coming back. You can summarize it maybe, but you don't actually always know. Go ahead, Josh. So there you go. I'm not sure I can really completely summarize it there, but basically replaying traffic that you know to get other IVs that have the same initial payload, I think is what we said. So go ahead and jump to the next slide. And this is just kind of a visual on the IV collisions between two different types of protocols, specifically ARP and IP. It's kind of a high-level summary, but it turns out that the IP addresses in the known plain text the known plain text within ARP frame, such as you know what the source MAC is, and you know your ARP header information, like protocol size, things like that, that's all known plain text. And it reveals things that you don't know or that maybe you do know in the IP frame, and it turns out that two of the things that it initially reveals are two bytes of your source IP. And generally, if both of those happen to be sourced from the same network leaving to the access point to go to another network, then now you can begin to plug some of this in. So go ahead and mic, mic. Shiny object. All right, that's good, that's good. So now you can take that same value you already revealed, and you can plug that value into your requesting IP, because we're on the same network, and say it's 10 dot, 10 dot, 10 dot something, you reveal the first two source IP bytes in the IP frame, and you can now take those values, plug them into your unknown piece of the ARP frame, and reveal additional bytes within the IP frame. Anyway, you basically unravel the two frames with each other, and it becomes a little more difficult to go out further, but it is possible in some situations to be able to reveal enough of a key stream using this method that you can actually insert arbitrary TCP, UDP, and ICMP frames into the network. You have enough continuous key stream that you can now XOR any frame that you want to that's within reasonable size. And one of the things that makes that happen is it turns out that a lot of Ethernet drivers, or Ethernet cards, I'm not real sure exactly which is doing this, zero pad, the trailers that they have, like for a an ARP it's not a trailer. What's it called when it's still an Ethernet? What's that? No? The trailer? Okay. So you end up with a trailer field, a lot of times a zero pad, you can generally determine whether or not it's going to be zero pad or not by a specific MAC address for a vendor that tends to be tied to a vendor. And baseline information you can now reveal an awful lot more of the frame, and you have the potential to completely unravel this key stream that you can then replay the network. There's some things you have to brute force, but it's a fairly quick fairly quick brute force process, and you've got some ways that you can validate it. So I'm not going to go into a lot more detail on it, but that's just kind of a high level of visual of how the two frames lay out, summarized. So let's jump to the next slide. So if I can inject traffic into your network, what does this mean? Well, if I can inject arbitrary traffic into somebody's network and they have a firewall and they have access and I have a box that's sitting on the internet that I also own, then I can monitor what I'm injecting. And so immediately, by using that and taking advantage of the fact that they probably have some sort of connectivity to the internet through a firewall, I can start mapping out what the firewall rule set may look like. So I can inject TCP frames, UDP frames, ICMP frames, different ports, things like that and try to figure out what's the firewall rule set. Well, this is also kind of useful to figure out what the firewall is going to allow me to do a little bit later. So I can now begin to spoof some frames to make it appear that I'm trying to ping somebody valid on the inside of the network and have the responses to that ping go to this host that I own that's on the internet. Same thing with port scanning. This requires a few more tricks in the firewall. I have to start poking state tables in the NAT state engine to be able to get like the ICMP unreachable protocol and port unreachable messages to come back through and actually get through the firewall. The interesting thing about UDP port scans is that once I do, just like traditional UDP port scanning, if I don't get an ICMP port unreachable message, then that means there's probably something there. That also means that there is a hole that's created in that firewall now. Let's say that I port scan for SNMP and I didn't get a response saying that the port is unreachable and I know that the firewall will pass SNMP because I've kind of already played with that earlier and so I don't get that response within a specific time interval. I now have a hole that's poked into firewall and I can do an SNMP get from the outside, from this box that I own on the internet, come straight back in through the firewall, have a direct connection to this host that the firewall thinks that the host created itself, although I actually spoofed the traffic and injected it in. TCP port scanning is also possible. The one roadblock with TCP scanning is that you really can't take it to the next step like you came with UDP as easily, but you can get RSTs through the firewall and so you can know whether or not a service is listening. I think it's possible to extend it into poking a big hole through the firewall so that after you do a port scan on TellNet you can actually get the TellNet banner from your external host, but it's going to take a little bit more work. Let's jump to the next slide and go ahead and hit the spacebar one more time. This is just kind of laying out what I was talking about. We've got a host that's attacking an 802.11 network and some internal target. They happen to be connected to the internet and there's another host that I own that's on the internet. So I've got two hosts, the yellow ones I own, the red ones what I'm attacking, and I don't have their web keys or anything. I'm just using these injection attacks to try to figure out what's running on this host. So I can inject traffic into the host spoofing the actual source address, the source address of an internet host and this target, go ahead and hit space and we'll then respond back to my internet host. So you're tricking the target into forwarding your traffic back out the firewall. Now there's more tricks to it than the simplistic view in that I have to send some traffic first spoofing that it looks like the target source address to my internet host to create some state tables in the firewall then it will allow me to spoof that, you know, this internet host is trying to talk to this target and it'll respond over the internet. Go ahead and hit the next slide. The cool thing is you can put all this on one host and so if I have a CDMA modem or if I have a CDPD modem and an 802.11 card I can be sitting in a parking lot and have an internet connection that's potentially un-matted that I can get to and an 802.11 network that I can inject into go ahead and hit the spacebar a couple of times. Same idea I inject and the responses come back through the internet to my other interface and so if you can imagine scan-ran or maybe even in-map that's broken into two separate interfaces and you're injecting on 802.11 that you really can't monitor the responses and your monitoring responses over CDMA, that's kind of the concept. Go ahead and jump to the next slide. So I have a little bit of a proof of concept tool here that's called WEP-Wedgie and WEP-Wedgie takes advantage of this. Currently, although it says that it's supposed to deal with the R5EV collisions I am still working on that part of the code. There's like a very alpha code that's going to be posted here in a few minutes after I get done with this and it does the keystream determination via the pre-shared key authentication so if somebody is using pre-shared key authentication it derives the keystream that you need which is a fairly significantly sized keystream. You can craft some really big packets. And then using AirJack does some injection attacks. You can use CDMA or CDPD for the secondary interface Currently it's doing all the injection stuff and I don't actually have it to where it's doing the more the port scanning in correlation on what ports are open and what ports aren't open but it is doing the injection and it's doing it based on the shared key authentication. So the next version will actually be doing the correlation in the back end to do the UDP-TCP port scanning as well as PING scanning and the firewall rule mapping. Right now it's a bit of a manual process so you need to run P-dump and look at it and see what the responses are or run it through your own Perl script to try to do something interesting with it. I think I got a quick demo as long as nobody crashes me in the process and if they crash me I think I get to hit Mike. You know the cool thing, well you're talking about the ID collision attacks if the same ID you can XOR between the two frames the LLCs are going to be different XORs and the XORs are going to be the same encrypted they would be a P-run encrypted and so you can just see what the delta should be for an arc versus an IP and you automatically know I got a match and then you can start playing around to see which one's the arc and which one's the IP and then go through the unroll and hopefully nobody will crash me and hopefully my system will run and hopefully my code will run but I get to hit Mike because he's the only one who really could do that. That's the serial port all the time. So I'm going to have to learn how to use these damn computers. There's a reason why we did the largest in the world. Did we bend a pin? Antony. Great man. Well, not token ring. I'm just going to run my house on it. So what we have here is this program has two different components to it currently. The first component is actually what captures the PRGA screen and it's very simply called PRGA snark and it uses air jack and basically you could do this with the cathode well and it just monitors for authentication sequences so you can see a lot of people out here that are doing open authentication. I pretty much ignore anything that's just open authentication and the system does. Please stop. So Can I hit it now? Oh, I see. Somebody turn the light on just for a second. Thank you. Do you want to get that hooked up and let the other guys do it at the end? I can demo it in a little while. I'll play around with it. We're running short on time so Anton's going to do his demonstration of the wedgie tool at the end of the session so please stick around if you want to see that. Anton Rieger, thank you. Alright, is anybody still sober? No. No, okay. Well, we've got a couple more presenters. I'm very pleased to introduce a colleague who's going to be speaking about some attacks, some weaknesses of web vulnerabilities. Take it away. So let me switch over to this. It's kind of hard to see, but can everybody see that? No? Not really? What's that? Okay. So basically I'm just going to talk about some web stuff because you've seen Kismet. I'm a de-stumbler so if you really want something better than de-stumbler use Kismet, okay? I've heard that 3.0 does. It runs on open. Well then you'll have to put up with de-stumbler if you're running for BSD, okay? Oh, first of all how many people here use BSD? Because okay, okay, not bad. I have at least some people going for me here. Yeah, so I'm Hikari, David Holton, whatever. I run the BSDR Tools project and I've released a white paper called Practical Exploitation of RC4 Weaknesses and Web Environments and it basically just outlines some optimizations to RC4 cracking and stuff and that's mainly what I'm going to be talking about today. Let's skip this. Basically past, present, and future. This is stuff that everybody knows. I'm just going to review this in case anybody knows about web cracking and stuff like that. Basically web stands for wired equivalent privacy and it uses RC4 and this is a bunch of copied slides from an old presentation so it says 40-bit and 104-bit, but as you know there's also the 256-bit which is actually 128-bit and stuff like that. But basically the other stuff uses 24-bit IVs and I believe that the new stuff uses 128-bit IVs. Well, if anybody wants to correct me you can correct me later, but that's all that I know. As far as 40-bit 40-bit if you use the key generator with your Linksys access point or whatever, Tim Nution pointed out a couple years ago that you can easily crack it and roughly about what, like 15 seconds or so 20 seconds really depends. It's really fast. You only have to crack 21-bits. Properly generated 40-bit requires about 50 days or one day or on the fly. And 104-bit still takes a little while to crack. The way that we usually get around this is the FMS attack or the PRGA attacks that Anton mentioned earlier. And with de-webcrack it usually requires about half a million to two million packets to crack web. I understand that Aerosnort says that it takes about five to six million and I'm not sure does anybody here work on Aerosnort with Shmoo or anything like that? Okay, well I'll have to talk to them later about it because I've never run it. Either way, I've heard from a lot of people that it's a lot faster and requires a lot less packets and it works with 40-bit and 104-bit with FMS attack. Basically it essentially reduces the key space, so most of the time you still have to brute force through a lot of different keys, but it reduces it dramatically by just capturing half a million to two million packets so you can crack it in under a minute or so. Yeah, so Tim Neuscham pointed out the 21-bit attack and that's included in de-webcrack. You can run it on a captured log file. All you need is two packets and you can crack it in 20 seconds or so. With 40-bit and 104-bit you can brute force it, as I said. It also takes word files for 40-bit and 104-bit and so you can do the same attacks that he pointed out where you have a big-ass word file and it of course does FMS attack and includes all the optimizations that I outlined in the white paper. So, basically it officially uses all the weak IVs and well, almost all of them and does it fairly fast. If anybody can think of any way to do it faster, I'd like to talk to you. And yeah, just I've implemented some faster searching and stuff like that, but that's enough with de-webcrack. Right now in the present these are some things that I've developed about a year ago and it's just been kind of like in CVS and stuff, just kind of hanging out there. And basically I developed a really simple pack and creation and injection library for 802.11, which is very similar to lib.radiate, but it requires a lot less modification using your own driver and stuff like that. And it's a really simple library. I mean, last DEF CON I coded it like during DEF CON for about 30 hours or so. And it's just a really simple interface and includes various patches to OpenBSD kernel so you can inject packets fairly easily. With de-inject, I basically took this library and just made a command line based so if you want to send out a probe response, a beacon packet, whatever you can just run a simple command with a set of options and inject them. And so it allows you to prove different things. And I've also had this available for anybody that wants to use it. You can do fake AP in about like four lines of shell code. There's lots of stuff you can easily do with this. And I basically with injection, the stuff that I have is really rudimentary and it has lots and lots of cons. Basically it's not reliable. It requires the right card that supports Mode 5 and all that kind of stuff. And it really sucks. It really does suck. So hopefully some people will be releasing what's that? Hopefully people will be releasing stuff a lot better than this in the near future. Hint, hint, hint. And then hopefully other people will be releasing stuff that's pretty nasty. Oh, okay. Oh, cool. Oh, okay. Nice. And so yeah, one thing that I kind of came up with a while ago was traffic generation. Basically for cracking web faster you can do simple stuff like determine if packets are small tcp packets and stuff like that by just looking at their sizes. Arps have pretty much a fixed size depending on the operating system as well as like tcp sins, acts rsts, fins, whatever. And so basically the attack is really simple. You just look for these packets and if you see one you re-inject it onto the network because web is totally vulnerable to replay attacks and that sort of thing. So this is basically how it works. The node sends like an ARP request across the wireless network that's encrypted and hits the access point or another host or whatever. And the attacker sees this ARP request and determines that it's probably an ARP request based on the length. Just grabs it, re-injects it, the access point or other host sees another ARP request and of course it sends an ARP response back for the previous one and the one that you injected and the 10,000 more that you injected that second. And so you can just crank through IVs really fast and achieve your half million to two million packets fairly fast which would be a lot better if we have a really good driver for injection. With tcp you actually get a couple packets back and it's all technicalities but basically it's a really simple attack for just generating traffic and cracking web faster. As a result, it takes me about an hour to generate enough weak IVs to crack web with one ARP or one tcp packet or whatever but if we had a better driver it could be done a lot faster. And it really varies with hardware that filters weak IVs as far as web cracking and stuff like that. So it really depends on how good their weak IV filter is. Yes, about three or four more slides. So future stuff that I believe we're going to be seeing is A&G stuff. It would be nice to have a monitor mode driver for that. Is there one? Analyzing web 2, the 256 bit web stuff. Getting into some frequency hopping stuff and just the layer one stuff like the nice driver for injecting stuff. And these are just different links to Doc Bowden projects myself. But here's a zero day so if anybody wants to grab the beta release then you can grab it from here or just email me or something like that. But that's pretty much it. So. Thanks Akari. I think it's really important to point out too. It's immediately obvious to us up here but maybe not to everybody else. The attacks Akari is talking about and the attacks Anton are talking about is a lot of web. Not just static web. I never changed my web key. But the tumbling web, peep, TTLS, those attacks don't lie on web. So these attacks also apply to those protocols as well. You doing that Mike? I should point out that we have some swag to hand out too. So stick around. We'll be throwing that at the audience in a little while. There's some. Use the mic Akari. Yeah there's quite a lot of them out nowadays and there's some that do the and there's some that don't. What's that? I've seen a couple that just bypassed the baseline attack and so they'd still be vulnerable to the numerous IVs that also the ones that people forgot to implement when they were doing their web cracking applications. Yeah. Well we got to get on. Let me do stand up. Okay my laptop is sucking. So it's just us lied. So I'll wing it. I'm a baton. Yeah, you may remember me from such things as I'm taking down the network last year at Def Con. And the whole man in the middle stuff that Cisco was trying to mitigate would leave. That was me and Mr. Robert Baird out there. Yeah. Okay so the other work I do most of you probably haven't heard about because it's mostly a bunch of drivers for guys like these. I was the one who was hinting at the whole time there. I'm working on air jack 1 and all it does is injection stuff. A lot of people have used host AP to do that. The problem with host AP is it's not meant to do that, it's meant to be an access point. And so you have a huge limitation. Air jack was specifically meant to inject traffic. That was air jack 1. Air jack 2 I got a lot of complaints for a lot of things. One, it required a prism 2 card. Nobody has prism 2 cards. I only ran on linux. It didn't support station mode or access point mode or anything like that. So I started work on air jack 2 which should be something of a release. This weekendish if you want to run it have a journaling file system. Okay. Stable. The new air jack 2 is actually got three layers. It's got an OS independent layer and that's why it's going to be running on right now. The code is for linux that's doing anything useful. Like I told you, I have about a thousand lines so far of the PSD code because and then it's going to be going to OSX and then I've decided I'm going to put it on Windows eventually. I'm not giving you a date. I made it for Windows because I wanted to learn the Windows driver programming. But basically the reason why you care about this is because their tools will now work on all your other platforms. I also put in a bus independent layer so you can use USB cards with it and card bus cards with it which is why I'm able to do the tool of an A and G stuff with it now. You can also use PCI or Compact Flash or PCMCA. Additionally, it has three abstraction layers. The third one is for the chipsets which should work on most cards. There's two particular chipsets. I'm not going to be able to write drivers on because of NDAs with my work but I'm not going to get into it. I've got two people that I'm going to beat until they write it. You'll have it for all of them. Right now it's coming up with the Prism 2 and it'll do the Hermes chipset as well. It's a Lucent card. Maybe it'll have the USB stuff for the working. Sometime, hopefully by the end of August I'll have it working on NetBSD and then hopefully OpenBSD and FreeBSD after that. And OSX if I can borrow a friend's laptop. But like I said, pretty much... Chicks dig Airjack. That's what the slide said. It also repeated that scene horse dig Airjack and also that Tim's mother digs Airjack. So that was all on the slide. It's not quite as funny when I'm when I'm reading it. But... All right. Okay. So there's one other thing that Anton left off that I'm going to be really vague about because it's funny. There is a much, much dramatically better way to get to the key streams. And someone's done it. Taki is not released yet. It might be in the future. That's dramatically better. But... Does anybody have any questions? Right now we should be supporting station mode and ad hoc mode. I'll have the AP mode stuff in there so you don't need to switch drivers between there. Oh, yeah. It's 802.11ninja.net. 802 is a subdomain. I'm clever. 11ninja.net. That slash Airjack. That's where all the Airjack stuff is. 10ninja.net or go to the website and we've got a mailing list going. Three of them if you're interested in it. But... I don't really have to terribly much more to say about that. We have questions about, well, anything really. I mean, we have time for everybody. But specifically the moment about the drivers and how we can do it. It's mostly meant so that you can do injection stuff, which will be one-up source drivers to use all the other features, like, you know, connect to an access point normally. It'll do that. And it should do that for BSD as well. That one. Sorry. It doesn't now. But it's pretty easy to do it. You fill in, like, 20 stubbed functions and poof, it works on that card. Because it's got a lot of abstraction in there. Anybody? Anybody? Questions for them? Sure. Oh, sorry. He asked if I'm still going to be supporting this stuff even though they're not doing their wireless anymore. Yes. Yes, it is. Yeah. It should work. I have to beat somebody into doing the the internet and the atheros because I have NDAs. But the card bus stuff for that should work. Anyone? He asked, what are my thoughts on ATO2 and WPA? I can answer that first and I'm sure some of these people are going to want to get on that. Thank you, Keith and Mick. Let's try. But I don't really have much faith in it. ATO2 and WPA is a little better. But I'd really want to see the problem with ATO2 and WPA is you're not going to be able to put it on the old cards. It simply doesn't have the horsepower to handle AES. The newer ones are running on a much, much faster Mac processor so they can do it. And so hopefully we'll see once everybody's using ATO2 and ARG or hopefully just G, we'll be able to have the horsepower to do that. But until then it's mostly a problem with horsepower on the access points because you can do it on the host CPU. But as far as WPA goes, I don't have much faith. Those hashing functions that it's based on are really, really weak. And it's still RC4. Yeah. It is exactly WAP. So most are giving out swag. People with good questions. Someone's got a good question. So whoever just asked that question, come pick swag. And somebody else with a good question. Yeah, are you in the back? Not Jim. Yeah. Just email Tim's mom at ATO2.11ninja.net. That's a pop account. Yeah. Yes. I did see that. Part of their problem was that they were... I'm sorry. I was bitching at you. Now, he asked if I'd seen anything to implement anything with the Nokia's. They put out a paper about problems with tunneled authentication protocols that tunneled through TLS. And if I'd tried to implement anything with that, my understanding with that, which is not too terribly extensive. I read it, but I sort of skim past it, is that they were relying on a weakness in the client. And I didn't see an actual specific mention of the weakness. They're right in that it's one-way authentication in the same way. They're really only authenticating this over to do the TLS. But I didn't really see the actual weakness in the client that was specifically mentioned. They were talking about it's a bad, best practice, which is true, I agree. But it's a lot better than, say, LEAP. Yeah, yeah, go. In our tunnels for weak authentication passwords inside a tunnel, the problem is that the client doesn't know whether or not it's talking through a critical tunnel or not through any of the tunnels. It's possible in some client communications to fool the client into thinking that a secure tunnel exists when it actually does not and then derive the credentials. But in practice, I don't think anybody's seen one. But that's a good question. Also, something else to point out is that a lot of those authentication things that are using EAP use static broadcast keys. These are keys where they send traffic to broadcast, which makes them very, very, very vulnerable to the stuff that Ikari and Anton were talking about, because you can send it to a broadcast address. Even if you need a Unicast IP, you can put that right on a friend that has a broadcast Mac. I've seen symbols have been compliant for a long time. They do make APs. They make APs and have made APs for a long time, but they're not really the kind that you buy someplace. You get them for warehouse and point of sale. But they've had WPA for a long time. Cisco does it right now. If you get their latest stuff, I'm pretty sure. The new iOS and the 1200 series will do it. I couldn't even really tell you. But the 1200 series has a little power PC and it's pretty powerful. Intermec. Intermec. Intermec might be. Is it it? Yes? Well, he has what's the best hope for getting into 2.11 security running, is what you said? Right? Everybody start yelling at actually both of you two. Let me tell you a few more. The major problem with that is IEEE isn't listening to people really. They did try with the WPA stuff. They really did try. They also did a pretty decent job on the 8 or 12 of an eye, but it's just not there, I guess. Yeah. Don't pull yourself into thinking that your IP second limitations are secure for wireless networks. Frankly, I have yet to see an IP second that's not the kind of problems we're talking about. But my two problems, you're still a little to all kinds of analysis attacks. Well, if you're not using strong authentication, strong authentication read as PKI, if you're not using strong authentication with it, you're wasting your time. I demonstrated that at Black Hat last year with Rob. How many people have passed all the clients that are involved in that? Yeah. What is a little bit of it? I would have to say that the one thing that makes peep good is that Cisco says so. Which is not really a good reason. But that's what Cisco will tell you. I can't really say which one's necessarily better. They both have their problems. I would lean towards the one that's a little more open. But If you have a lot more flexibility with the football calls and how you can use it, you can still get the same level of security in that TLS call that T-plus. Shrug. Yeah. MSChap V2 doesn't give me a warm, fuzzy feeling. My immediate thoughts with the Leap stuff was Cisco and MS meaning Microsoft in MSChap. Cisco and Microsoft the dynamic duo out to secure your network. And who doesn't trust that? He asked if we run wireless networks in our houses and how would we secure them if we did. I can answer that one right now. I run one at my house. It's pretty open. The SSID is free porn. And the way that I handle security is that I don't use it for things that I don't want people seeing or getting on. And it's not connected to the rest of the network. It basically is there so people can get on the internet and what do they do on the internet but free porn. You have to ask these guys. I run one in my house. In my apartment. That's basically a Faraday cage. You're lucky if you can see it from my front yard. We have big antennas outside of our place but we don't run wireless. I'm fucking paranoid. I use Kismet drone sensors outside my house to monitor the network and do some custom real-time reporting stuff to find out what's going on. But basically, you know, if you want to drive over my house and sit in front, knock on the door and say hello for Christ's sake. I'll sit in my parking lot. Hold on. Get some swag. He's talking, he has to, if I've ever seen anybody he's talking about exploiting the Michael Countermeasures problem. The Michael Countermeasures problem. Michael, incidentally, is the message integrity check that they have on T-CIP. Michael is a very well, bad hash function. They had reasons and not completely bad. The guys were given sort of an impossible task. They had to make a good hash function that could run on a CPU that can't do anything. And it had to run really fast. So that's why it was bad. But it's so bad in fact that if they get too bad, badly authenticated, it has a good CRC so they know it encrypted properly but it has a bad make hash on it. Then if they get two of those within a minute, I believe, then it disconnects you. Was in a second, is it? Okay, well, one of those two and it disconnects you. Problem with that is I haven't actually tried this specifically to know for sure that it works. But there was some talk a long time ago about the, you could do bit flipping inside the RC4 because it's still an RC4 system. And get the CRC to come out valid. Now I can't do bit flipping to get the mit come out valid but I don't need to. If I get two to come out invalid but the encryption was good, you're off the network. I haven't seen it in the wild. Have you ever seen it in the wild? I haven't seen much WPA in the wild. Expect to see it in the wild when there's a lot of WPA out there. And it's a really bad DOS attack. So for people who don't know, the counter measure is two with big packets. Yeah, it kicks you off. Yeah. Don't be standards compliant, please. Yeah. So we already have enough insecure protocols so one more won't hurt. I think it's really in large part up to the people in this room and the guys you know, in my opinion. Because you guys, two groups, you guys are the ones who are going to be bitching to fix it and you guys are the ones who are going to be breaking it and making other people bitch to fix it. If enough people are concerned about it, yes. But in my personal experience people don't want security. They want a rubber stamp that says they should cure. So to that end, if it becomes a demand, they absolutely are going to have to. And 8219 and some higher end hardware, the new 821G stuff will do it. But as it is right now, I don't really see them fixing it because it's not a high priority of them. There will be standardization if somebody else has to do it, I'm sure. I would say problems. The WPA stuff was not done by IEEE. It was done by the Wifi group, was it not? No, it was done by both. Yeah, I know it was based on 8219, which is high-tribal-E. I don't know who you've been talking to, but I didn't do it. Well, hold on. Anybody new? Hold on a second. You? He asked if SSL based security is better than IPsec bumping out of the layer. There's a viable solution. In some cases, the problem with that is, well, a problem with that is it's only authenticating the server using, you know, SSL stuff generally, which means you have a signed certificate from the server. So it's one way authenticated. The other major problem is that your users are very stupid and will click yes. It's all just techno jargon. What do you mean it's not signed by them? I just want my yahoo. You were asked how effective it is to disable SSID broadcasting. That's sort of, in my opinion, a confused question. Ask him. Let's discuss what you mean by effective. If you mean by making people accidentally connect to you? Yes. Yes, it's effective. The SSID was never intended to be a secure part of the protocol. So you can turn it off in the beacons, but as soon as someone connects and the access point says you're allowed to connect, there's the SSID. It pulls it out automatically. Anything else could, I just automate it. Go to 802.11ninja.net slash airjack. There's still one tool that's still in there. It's the SSID jack, which I wrote so people would stop thinking that was a security measure. It kicks somebody off using airjack. Thereby forcing them to reconnect, and I see the SSID. It's not a password. It's range generally is not nearly as long, and that's one good thing from that perspective, but some perspectives that's bad. The increased web links doesn't impress me. Web is dead. Web is totally broken. It's starting to smell. You can make a bajillion bit key. I don't care. Web is done. But as far as I do use A, I use G, but primarily I mostly use B, or G because it's backwards compatible. It's the major deal. Because he wants to get free porn on my network. From where for over six months we've contacted every person we knew at all these companies, talked about your firmware sucks, and it's easily exploitable, and there are a lot of bugs that we didn't talk about today, but they don't want to hear it from security industry, and it's just that we're nice guys, so we don't just go for the road track. I have talked to some of them through my work. If it were just me, they would never listen to me. Only through my work. Without much gain from it, you got me confused with somebody else who cracks it. So I think this question is something in the effect of what are we going to do when self-employed companies come out using SIM authentication, is it? Uh-huh. Okay. I see. He said a lot, so that's it for me, but he's saying about the SIM, I don't really, you talk to this man. I don't really mean to, he's talking about using SIM cards, some cellular companies using SIM cards to authenticate 8 or 211 new devices, and whether or not this is a good idea or a single point of failure, I think it's probably a really bad idea, just because they shouldn't wrap up. We still have three things to give away. Let's do three more. Three questions. Does everybody know what's up here? Oh, really? Somebody takes swag first off, and then... This is a cellular modem, so you can hack people from anywhere. Not like you can't do it already with wireless, but... What? This book? Yes. If we didn't off you swag, please come up and get it. If we didn't off you swag, and you can beat them up here? Come and get it. Oh, man. Use strong authentication. Strong means PKI, keep your known host file never, never, never just click yes. Strong authentication, it can be done right. You have a whole can of worms, though, because I'm on your physical network. If I can't get in through your SSH, I now have physical access to your machine, and I can just try and hack you dead on, and then steal your SSH key, so... Do we have time? Or do you want to wrap it up? Or do you have time for the demo? Does he have time for his demo? I think Anton wants to stick around. If anybody wants to stick around, he's going to... He got to go and demo it. Oh, baddened. Thank you very much. We know everybody wants to go out and get blitzed. The show doesn't start until 11 o'clock tomorrow, but Anton's going to spend some time doing his demonstration for WebWedgie, and then we'll take some more questions until we need to go drinking. So if you want to stick around for questions after the demo, if you want to stick around for questions after the demo, please do, don't feel bad about leaving to go get a hammered. Thank you.