There are a lot of people already blogging about their perspectives of Shmoocon this year so go check them out if you're interested. I wanted to dump some thoughts for posterity.

Shmoocon rocked. I haven't really heard any perspectives that would disagree. Most of the people that went, knew what to expect and I think it lived up to those expectations.

Shmoo VS Defcon

Every year 9000 hackers - er I mean security professionals - turn out for Defcon. The culture ranges from script kiddies to 1337 h@x0rz and from overpaid business men to Feds. It's all over the board. Usually once you get there, the crowd partitions off into separate factions. Skiddies look for things to hack (see steal), 1337's start working on the challenges, business men keep track of their receipts, and Feds quietly hover in a cloud of self-content. Good times are had by all that know how to have good times and the technical information in the talks is very informative.

In contrast, Shmoocon had a gathering of 1300+ people with less skiddies and Feds, and more of the in between. There were a lot of black shirts and alot of business casual. The aren't as many talks as Defcon but there seems to be more of an open community. In my opinion it seems friendlier.

What seemed to be the best part was the smaller amount of people in a smaller area which made it more likely for the same people to be in the same place over and over. Same thing with the parties. Smaller parties, same people attending. But anyone that can throw a party in a church is pretty awesome in my book

Lessons Learned

1. Script the registration to get lower costs - it's very unlikely that someone clicking register now over and over again can beat a multi-threaded instance of curl.
2. Play the contests - there are a lot of cool contests and games that not a lot of people play. If you're good at that stuff, you're likely to place somewhere
3. Don't make fun of the Steel Workers Union's Mullets - learned the hard way (sorry Sysmin)

Yesterday I passed my Certified Ethical Hacker test making me a CEH. I really don't put much personal information in this blog but since I wish I'd found more information about the possibility of self studying for the CEH before I took the exam, I'm going to write this entry in the hopes that someone else will find it before they take their's.

CEH's Perception

The Certified Ethical Hacker certification came around years ago but I first heard about it at Defcon 15. You can go look at what the CEH is and read why you need to get it but I'm more interested in writing about how I personally have seen it perceived.

One of the Goons at Defcon was making fun of the certification saying that he was going to start his own test to be a CEH - Certified Ethical Harpoonist and that the CEH cert was less than desirable. He used more colorful adjectives. Goons are at least two steps up from the "Humans" at Defcon so their opinion has some sway (especially among n3wbs and scene whores) no matter how beer fueled it is.

None of the people that I know or are friends with have the CEH cert and I've never really had a conversation with anyone saying how they're going to work towards it. Most look at the CISSP to be a manager or some of the SANS certs if you want to actually know how to hack. The best example of how CEH is not widely known or desired was I told a techie friend that I'd passed my CEH exam and his response was, "Congratulations. What's that?"

Why get the CEH?

So if it's been planted in my mind that the CEH is really not that big of deal and most people don't even know what the CEH is, why even go for it right? More than anything else it added a structure to the security projects I had been working on. Up til now, I was working on 15 different projects using all kinds of different technology from encryption games and anonymity utilities to programming projects and improving my soldering skills. I found the CEH study guide and looking through the table of contents, it seemed like something that could teach me new skills to wrap into my projects. So it just really put everything I had been studying into a specific achievable goal.

I would say to anyone expecting the CEH cert to open doors or make it easier for you to get a job, don't waste your time. In my opinion, CEH is the A+ of security.

Is Self Study an Option?

The short answer is a big maybe.

I'm lucky enough to work for a company that pays for my training. That being said, I really didn't want to take a week of to do the CEH training course knowing that the CEH really wouldn't do much for anyone. Since I'm on sabbatical for a few months, what better time to study towards something like this.

I bought the CEH review guide which in one of the first paragraphs of the books states something to the affect of

"This book does not contain all the information you need to pass the test."

Ok, I understand. I'll look at the information it's talking about and apply some real world examples. The review guide was missing a LOT of information. In fact, if I had no previous experience in security and was starting from scratch, the review guide wouldn't have even touched upon half of the subjects in the test.

I know what you're going to say, it's called a _REVIEW_ guide but in fact, there is no official book of information for the CEH which means that the only book to study from is this review guide. Maybe this is normal but for all the other certifications I have, there's always been a gigantic book that you studied from. So it was like having the cliff notes instead of the original novel and then trying to pass a 150 question exam. It wasn't like that, it WAS that.

The alternative to the review guide is that you hook up with the EC Council training and they tell you the secret subjects that you should study for in one of their week long training classes. Lets just say that thanks to the openness of the Internet, I was able to track down some more information to study.

Subjects not covered

I looked up as much information as I could and I talked to people in some forums and IRC channels that I frequent and they all basically said the same thing. "Nothing really surprising. Few gotcha questions. Pretty straight forward." And in response to did you self-study - "No." In fact out of the 5 or 6 people I directly talked to that had passed the CEH, they all shelled out the more than $1000 for the week training and then took the test.

The biggest item that I didn't study for was programming. They don't expect you to write any exploits or anything like that but you need to be able to debug C to point out locations for buffer overflows. I don't know C or C++ but can hack my way through so it was a stretch and not in any thing that I was studying. Luckily there were only two of these questions.

Conclusion

My major conclusion is the test material is really good for security professionals but if you're going to be able to pass the exam with the review guide, you are probably already in the security industry and this test will do nothing for you. If not, you'll end up spending the same amount of money re-taking the test that you would have if you did the week long training. The reason that I was successful was because of all the extra study materials I found and generally because I am a geek.

Nathan Evans did the last talk on the first night of Defcon called De-TOR-iorate Anonymity. It had a lot of people sweating on the Tor mailing list and even generated a huge debate about whether Tor should even be attempted to be used on a multi-purpose system versus a dedicated machine or virtual machine like JanusVM or AnonymOS. The information was pretty thick to process at the time, but a few minutes later, it finally sunk in. Here's how it works.

Overview of Tor

A quick review of how Tor works. Tor is a anonymity tool that creates a circuit of proxy servers to relay connections through. For instance, in the figure below we see Alice trying to connect to Bob. Alice sends traffic to node 1, node 1 relays that traffic to node 5, node 5 relays that traffic to node 8 and node 8 finally sends the request to Bob. If Bob replies, the data travels back the direction that it came. Simple enough?

Overview of Attack

Nathan's attack would fall under the "partitioning" label as the goal of the attack is to partition the Tor network smaller and smaller until it can find the entry node the user is coming from. Because this attack assumes you have control of the exit node, obtaining the entry node confirms the second node used as a relay thus showing every node in a user's circuit. This makes Tor as anonymous as a single proxy.

Circular Circuits

Nathan found that an attacker can create looped circuits. That is Node 1 relays to Node 2 and then relays to Node 3 but at Node 3 an EXTEND command is issued so the circuit length is increased infinitely. This causes the queue of traffic waiting to be relayed to fill up and the latency to increase by a large amount.

Why it works

Doing a DoS attack and measuring the latency is not new. It was actually talked about at last year's Defcon. The difference with this attack is the attacker actually creates circular circuits so nodes are actually looping traffic back to the beginning instead of relaying properly.

This is why the attack worked:

• Tor is hard coded to only uses 3 nodes in a circuit(debatable whether or not to change)
• Tor does not provide padding to keep latency at the same rate (and never will)
• Tor allows for infinite circuit lengths (to be fixed in proposal 110)

The Attack

To attack the network, he used the following environment

1. a "Bad Exit Node" owned by the attacker
2. Tor client used to generate circular circuits (Defined as "DoS Client")
3. Web server to act as the destination and to keep track of latency (Defined as "DoS Server")
4. Normal user that is using the Bad Exit Node ("Alice")

The attack is done by a denial-of-service attack on many nodes using circular circuits discussed above. If the user's latency stays low during a circular circuit creation, then the attacker knows that the entry node is NOT one of the DoS'd relays and tries different nodes. In this case, latency is measured by injecting a javascript command to ping a web server collecting stats. The process of generating circular circuits and recording the results is repeated until the user's latency increases substantially at which time the attacker knows that the entry node is one of the three nodes used in the last DoS attack.

Example

In this figure, you can see that Alice is trying to connect to Bob via nodes 1, 5, and the Bad Exit Node that is owned by the attacker. During this time the attacker is creating circular circuits between 1, 2, and 3 which generate large amounts of traffic causing a slow down.

The Fix

Tor has been been updated at least 3 times since writing this blog. Among many other bug fixes and feature additions are the changes related to Proposal 110. This is the proposal to change Tor to handle circular circuits. The proposal splits up relay requests into "Relay" and "Relay_Early." Relay requests do not have the ability to issue the EXTEND command that is used to generate the circular circuits and Relay_Early can as these would be the beginning of the circuits.

The 0.2.0.30 version also makes an addition to block "risky" extend cells.

Relays now reject risky extend cells: if the extend cell includes a digest of all zeroes, or asks to extend back to the relay that sent the extend cell, tear down the circuit. Ideas suggested by rovv.

The fix is not complete. They are still implementing parts of proposal 110. They have to maintain backwards compatibility in case a version 1 circuit is created.

External Links

http://www.torproject.org - Tor Project Website
https://www.torproject.org/svn/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt - Details of the proposal for the fix
http://archives.seul.org/or/talk/Aug-2008/msg00148.html - just for accuracy's sake, Roger Dingledine's follow up to my explanation on the or-talk list
http://web.cs.du.edu/~natevans/ - Nathan Evan's website. Nothing there really
https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-evans-grothoff.pdf - Original powerpoint presentation called De-Tor-iorate Anonymity
https://www.torproject.org/svn/trunk/ChangeLog - the always updating changelog of Tor

Last year was my first year at Defcon so I was sucking up as much information as possible but generally I just went to the talks and then back to the room to play with the things that I had learned.  I didn't get into the social scene very much.

This year I still attended a ton of the talks but instead of taking time to go back to the room and play, my friends and I made more of an effort to get into the Defcon social scene.

Overall Experience

Just like last year I had a blast but I think even more this year because of some of the people we met. I've seen some posts complaining about the situation at Defcon about how it was too crowded and they missed some talks because of this. It sounds to me like a lot of people have gone to things like Microsoft Events where you stand around some muffins and coffee and then sit through 2 hours of talks.Defcon hacks the conservative convention idea and takes into account the amount of hackers that have ADD.They offer 5 tracks of talks at the same time, lock picking training, wireless village, general hang outs, and more. Then when the talks are all done, there are parties all over the city. It's not cup of coffee, stand in line, polite conversation kind of gathering but rather a red bull and vodka, bum rush, punch in the face cluster of people from all over world meeting to show solidarity in the hacker community. At least that's the my ideal perspective of what Defcon should be, it may be growing in a different direction.

List of talks I attended:

• Welcome by DT & Making the DEFCON 16 Badge with Joe "Kingpin" Grand
• Clinton Wong - Web Privacy & Flash Local Shared Objects.
• Roger Dingledine -Security and anonymity vulnerabilities in Tor: past, present, and future
• Robert Ricks -New Tool for SQL Injection with DNS Exfiltration.
• Magnus Bråding -Generic, Decentralized, Unstoppable Anonymity: The Phantom Protocol.
• Eric Schmiedl -Advanced Physical Attacks: Going Beyond Social Engineering and Dumpster Diving Or, Techniques of Industrial Espionage
• Fyodor -NMAP-Scanning the Internet.
• Matt Yoder-Death Envelope: Medieval Solution to a 21st Century Problem.
• John Fitzpatrick -Virtually Hacking.
• Nathan Evans -De-TOR-iorate Anonymity
• Movie Night With DT: Premiere of "Hackers Are People Too
• Cameron Hotchkies-Under the iHood.
• Jay Beale-Owning the Users with Agent in the Middle.
• Luciano Bello & Maximiliano Bertacchini-Predictable RNG in the Vulnerable Debian OpenSSL Package, the What and the How.
• Panel: All your Sploits (and Servers) are belong to us.
• Mike Perry-365-Day:Active https cookie hijacking.
• Tony Howlett-The death of Cash: The Loss of anonymity & other danger of the cash free society.
• Ryan Trost-Evade IDS/IPS Systems using Geospatial Threat Detection.
• Rick Hill-War Ballooning-Kismet Wireless "Eye in the Sky"
• Jay Beale-They're Hacking Our Clients! Introducing Free Client-side Intrustion Prevention.
• DAVIX Visualization Workshop
• Stealing the Internet

Tor

I've been following Tor for a while now so it was interesting to go to the two Tor specific talks – both about vulnerabilities in Tor. Roger Dingledine presented a general overview of past, present, and future vulnerabilities in the Tor network and Nathan Evans went over a specific vulnerability which allowed an attacker to find out all nodes in a circuit. Both talks were interesting and I'm going to go into much more detail in future blog entries.

Sidejacking Redux

Last year, the concept of sidejacking was in its infancy. Sidejacking or session hijacking is when an attacker uses a man in the middle to steal the current session of something a user is accessing. For instance, with this attack, an attacker could steal the cookies used to authenticate a person's gmail account which would grant the attacker access to Gmail and all other Google services for the amount of time that session was valid. This year Jay Beale of the company Intel Guardians released a tool called “The Middler” which automates this process and Mike Perry of Riverbed and the Tor Project pointed out a flaw in the way that some companies have tried to protect users from this exploit.

Since last year, services like Gmail have offered SSL encryption to protect from this attack but they didn't force users to use SSL which lead to Mike Perry's talk. He pointed out an attack on a Gmail  where even though the user was using an SSL connection, the cookie could be transmitted in clear text allowing a session hijack. This was done by doing a MITM attack, using a tool to check which online service the user was using, inject a piece of html that pointed to the non-SSL encrypted version of that online service and then perform a session hijack after reading in the credentials. He even pointed out a simple fix that he has told Gmail and Yahoo about where you can set a bit in the cookie to only transmit in SSL.

War-Ballooning

One of the most fun talks that I attended was Rick Hill's War-Ballooning demonstration. They were planning on doing a live demo from the roof of the Riveria but at the last minute, some authorities decided to stop them. War-Ballooning was a development of last years idea of War-Rocketing which shot a rocket in the air and then searched for wireless signals while it parachuted to the ground. This year they took a professional balloon that was used by photographers for shooting aerial shots, attached a cooler filled with various wireless gear, and configured a orbital webcam that controlled which direction the yagi antenna was pointing. So they gave a video of the demonstration which was recorded the day before in a park five miles out of town. For added drama, they used Kismet's feature to read wireless networks out loud as it found them. They had the balloon up for ten minutes and found over 300 wireless signals as it broadcast a 7 mile radius. 30% of those were unsecured.

Hackers Are People Too - Ashley Schwartau

And how could I forget to add something about my acting debut in the documentary Hackers Are People Too which was premiered at Defcon XVI. Well ok, maybe I was on the screen for less than 2 seconds and I wasn't quoted as saying anything but hey, to be in a hacker documentary was really cool. Ashley even recognized me when I came up to her vendor booth. But enough of my vanity, the documentary was so cool and people really should pick it up to show to their friends and family and get the scarey idea of what hackers are out of their heads.

External Links

http://www.hackersarepeopletoo.com - link to the Hackers Are People Too official website (BUY BUY BUY!!!)
http://fscked.org/ - Mike Perry's website
http://www.defcon.org-Defcon
http://www.intelguardians.com/ - Intel Guardians will soon be releasing "The Middler"
s

I arrived Thursday morning to Las Vegas in an attempt to do some of the pre-Defcon social events this year. We posted our room availability on the Defcon forums and picked up two roomates to help with the costs; Riot and Matt.

I reserved the "deluxe" room at the Riveria which although being nicer, doesn't have any more space than the non-deluxe. It does look much more romantic but filling it with 4 guys takes care of that feeling pretty quickly.

Badges this year include an IR port, an SD slot, and supposedly a way to shut off all TV's in a certain radius, and a transmit mode that may allow you to talk to other badges as you walk around the floor.

Ethical Hackers

Ethical Hackers was doing a get together at Hofbrauhaus, a German brew house at 8:00pm. Dan who runs the site was putting it all together and had a $500 tab for us to use. The whole event was a lot of fun and had a lot of interesting people. Timmy of Red Rock Security, Brian of Cisco, Ed of Intel Guardians, David an extreme baby sitter, Collin of Training Camp, Mike the Military Vet, Naps, and a bunch of others of whom I may have forgotten their names. Check out ChicagoCon for anyone that will be in the area. Sounds like a very worthwhile event. I think the whole get together was a success.

EFF Summit

We also grabbed a few of the guys to make it back to the EFF Summit at the top of the Monaco tower back at the Riveria. Donations were $40 to get in and included a one year membership. Once the sound system was working at around 10:30 or 11:00, some of the EFF guys went up to talk about some of the cases that were won and some of good things that the EFF does. I think it was kind of preaching to the choir but the event went pretty well.

External Links

http://www.ethicalhackers.net
Red Rock Security
ChicagoCon
Intel Guardians

Coming back from Defcon, one subject I'm now very well versed in is Tor and other anonymity networks. After sitting through what my friend called the “ten hours of tor,” I learned a lot about the inner workings and the future of what Tor has planned.

What is tor

Tor is a service that aims to allow a user's online activity to be anonymous and untraceable. It is a project that creates a network of servers to route traffic in a way to make it harder for attackers to find out where the traffic is going, or where it originated from. This is an example of what's called an onion routing network and in fact, it's the first and original one created. [If you're interested in other onion routing projects, check out JAP [http://anon.inf.tu-dresden.de/index_en.html].]

How does it work?

The Navy came up with the idea of “Onion Routing” but the EFF took the project over and this is currently how it works:

1. The Tor service is installed on the client
2. The client system is configured so that it uses the Tor service correctly and is sometimes used in conjunction with a program like Privoxy which is a web proxy server that further protects the end user
3. When the Tor service is started, it downloads a list of directory servers which keep track where valid nodes exist on the network
4. The user makes a remote request like accessing a website
5. The client establishes a circuit of nodes based on the kind of traffic you are generating [HTTP can connect to nodes that go up and down often while SSH would rather use a node that has been up for days] and it is used for the rest of the session.
6. While creating the circuit, the first node is remembered as the client's “guard node” and will be used for all future circuits relating to that type of traffic [HTTP vs SSH] while the “relay nodes”, the ones in between the guard nodes and the exit nodes, are chosen at random.
7. The traffic is then encrypted as many times as there are nodes in the circuit and forwarded over TLS/SSL
8. The first node, the guard node, removes a layer of encryption and forwards it to the next relay node in the circuit
9. This continues through the rest of the circuit until it reaches the last node, the “exit node” at which time the information is decrypted into the original data that was sent from the client.
10. The exit node forwards the information to the remote host that the client was trying to connect to and if a response from this host is required, the data travels through the same circuit backwards to the client.

When implemented correctly, the final result is that the client's traffic remains anonymous and untraceable. For the most part, that goal is successful except when you introduce adversaries to the network.

Current Challenges

The goal of anonymizing all traffic for all users at all times and doing so while relying on anonymous volunteers that have the ability to change the code is a daunting task to say the least. The main troubles the Tor developers are facing, stems from what Nick Mathewson and Roger Dingledine called “malicous nodes.” These are people that have set up Tor servers that are working “differently” than their designed purpose causing harm to the end user. In fact, Nick Mathewson and Mike Perry based some of their presentation on security challenges they are facing and how they are defending against them but although that was the most interesting part, I'm going to skip over them for now. If you'd like to see read through the presentation that Mike Perry published, you can head here: [link]

Legality of Tor:

I was explaining to a friend how Tor worked and he asked me, “Wouldn't it be possible for you to get in trouble if you were an exit node, and a Tor user was doing something illegal.” My immediate response was no you can't get in trouble because the nodes do not contain any data but then he also reminded me that to the ISP, it would look like it was coming to you. I didn't have a good response so I did some research. Here is Tor and the EFF's response to that issues:

Can EFF promise that I won't get in trouble for running a Tor server?

No. All new technologies create legal uncertainties, and Tor is no exception to the rule. Presently, no court has ever considered any case involving the Tor technology, and we therefore cannot guarantee that you will never face any legal liability as a result of running a Tor server. However, EFF believes so strongly that those running Tor servers shouldn't be liable for traffic that passes through the server that we're running our own Tor server.
[link]

There has been a case in Germany where Tor servers were confiscated during a child pornography crack down, but all the servers were returned within one days time. [link] As of today there still is no law in any country that states what legal protection or responsibility a person has involving running a Tor server but Kevin Bankston of the EFF has gone on to point out this:

Tor servers meet the definition of an Internet service provider, which means that operators are not required to know what data passed through the server... ...While it is possible for the operator of an exit node to see the data, it would likely increase their liability, because if the operator became aware of illegal activity, they would have to report it

What's planned for Tor

Roger Dingledine, Nick Mathewson, and Mike Perry outlined the future of Tor and some really cool things. Some, under request from Roger Dingledine I will not post because they are designed to circumvent firewalls and if they become publicized can be counter attacked. But one of the most interesting services that I've seen is having content hosted on the Tor network using what they called “hidden services.”

Hidden services

Tor has not only worked on forwarding information through the network and back out to the internet, but providing routing to endpoints that reside inside of the network. They call these hidden services and an example would be hosting a website. How it works is a web server connects to the Tor network and appears to users as a .onion pseudo-domain name. This is an exciting idea that is only released in the alpha stages but it looks to me to be in the same realm as the Freenet project.

Conclusions

Day 2 of Defcon was Tor day for me. There were a lot of interesting things going on that some of my friend went to but I was really interested in Tor and meeting the developers behind it. Tor is an awesome service and it's crazy to me to think about what they've created and how far they've come. I think they are facing only half the adversity they will be facing if they ever become more public. I can imagine laws being created to make using Tor illegal especially during the times we live in. I can especially envision the types of censorship that Roger Dingledine talked about but it's awesome that they are already taking preventative measures now.

External Links:

http://tor.eff.org – Tor main homepage

http://tor.eff.org/eff/tor-legal-faq.html.en – EFF's legal FAQ about Tor

http://anon.inf.tu-dresden.de/index_en.html – JAP: a German anonymity service kind of like Tor that is java based

http://www.securityfocus.com/news/11447/2 – article about an attacked on the Tor network

http://fscked.org/transient/SecuringTheTorNetwork.pdf - a temporary link to Mike Perry's presentation

http://yro.slashdot.org/yro/06/09/11/1050215.shtml - The slashdot article about the Tor servers being confiscated

Defcon started for me with a presentation from the Church of Wifi. This is the first time I've ever been exposed to the persons behind CoWF but they were very interesting to say the least.

There were a ton of projects that they went over like The Traveling Terabyte, portable file servers, rolling thunder a car mounted file server, a special CoWF linux distribution, and last and probably most importantly, the new WPA Rainbow Tables.

Rainbow Tables

For those of us that don't know, rainbow tables offer a time-memory trade off used to recover the plaintext password from a password hash generated by some kind of hash function. In normal terms, it saves you all the time to crack a password hash by having a list of all the hashes and then the password that they correlate to. But there is a challenge when making a rainbow table for WPA.

How WPA Hashes Work

WPA is the new security standard that currently does not have an easy way of attacking without a brute force method. The hashes are created by encrypting the password the users wants, and then by adding the ESSID of the wireless network as a salt to that hash. This salting process is repeated 1000's of times in what's call a Password-based Key Derivation Function (2). The specific purpose of the salt is to protect against rainbow tables and dictionary attacks. But that hasn't stopped CoWF.

WPA Rainbow Tables V1: CoWPAtty Lookup Tables

Last year, apparently, CoWF released the much praised WPA Rainbow Tables which were over 7GB in size. Perfect for a dual layer DVD. The problem was that because of how WPA works, and as explained above, the tables were not as easy to make as say a WEP rainbow table. This was due to the issue that if a wireless network chose the same password, they would not have the same hash value. So they needed to correlate the hash values to the password AND the SSID. So 7GB is really not very large when you think about how for every SSID, and for every dictionary work you would have a hash and the corresponding password. The first version was 172,000 words for the top 1000 SSID's.

WPA Rainbow Tables V2: Uber CoWPAtty Lookup Tables

This year they released the newest WPA rainbow tables. So what's different? Instead of the 172,000 word dictionary used before, they employed a trimmed version of 1,000,000 words. This list had contributions from the group and Kevin Mitnick. They harvested actual passwords from Google to compile the list of not just dictionary words but most common passwords used. From the 4 million real passwords found, 1 million words were put into the list. The result? An almost 40GB rainbow table of the most common SSID's with the most common passwords.

What's next for CoWPAtty?

So 40GB is big but they were actually thinking about using 2 million words. The reason they didn't was to support the idea that they could create a live distribution that would use a USB hard drive to boot up and automatically start the rainbow tables. That will be very interesting to see.

Render

Render, the self proclaimed “mouthpiece” of the CoWF, went on to discuss other interesting topics like how the new 802.11i specification includes a DoS condition built into the protocol, a call out for more cheap, open, bluetooth capturing tools, and a really simple but cool way to defend against wireless attacks.

Defending WEP and Talking to Eachother

One of the topic Renders talked about was how applications like aircrack-ptw enabled anyone out there to be able to crack WEP in a matter of minutes. He pointed out that aircrack, whichever version, does not verify the packets coming in. His point being that if an access point were to send fake packets to muck up the aircrack process, cracking would be much harder. So although this was interesting, two other groups had come up with the same idea already but they didn't know about each other.

His point more than showing a possible defense against wireless attacks, was that groups needed to communicate more. He talked about how we as a community need to share discoveries and information more openly.

Conclusions

Church of Wifi was a great way to start off Defcon for me. The packed room showed how everyone was interested in the subject and it was a cool way of learning about all the projects that the Church of Wifi had been working on throughout the year.

External Links

http://www.churchofwifi.org/ - Church of Wifi Website

http://en.wikipedia.org/wiki/PBKDF2 - a link to a deeper explaination of how WPA hashes their passwords

http://www.churchofwifi.org/FileLib_Index.asp?FID=30&LibName=Uber%20Wifi%20tables% - link to the SSID's and passwords used to create the CoWPAtty Uber Rainbow Tables