Back Track Linux. If you haven't heard of it, you can call it the most talked about linux live distribution for penetration testing. It's a mixture of older distributions Whax which had a lot of penetration testing tools and auditing which was focused on forensics. Back Track just gives it all to you and more. Here's their site: http://www.remote-exploit.org/backtrack.html

This post is for first things first. How to run it from more places than just a CD. Specifically a USB pen [no pun intended, or is it?] drive.

Install to a USB pen drive

This is really easy.

1. Download BackTrack Linux Link
2. If you're running Windows, burn the iso to disc and boot your computer into backtrack
3. Run this command which will mount the iso you downloaded mount -o loop -t iso9660 WhereEverYouPutTheBTIso.iso /mnt/iso
4. Copy the /boot and /BT folders to your pen drive
5. run "sync" to make sure files are where they're supposed to be
6. then run a handy script called "bootinst.sh" from the /boot folder thats on the USB drive/span>. If you do it from anywhere else you'll be at risk of overwriting the MBR on an important device.
7. You'll get something like this -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Welcome to Slax boot installer -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This installer will setup disk /dev/sdb1 to boot only Slax. Warning! Master boot record (MBR) of /dev/sdb will be overwritten. If you use /dev/sdb to boot any existing operating system, it will not work anymore. Only Slax will boot from this device. Be careful! Press any key to continue, or Ctrl+C to abort...
8. You're done!?

That's all that I needed to do on my Lenovo T43 but I know from experience this will not always work. On my system, I needed to go into the BIOS and add the USB HD as a boot option but that was it.

External Links

http://backtrack.offensive-security.com/index.php?title=Howto:USB_Stick - a web pages that goes into how to install to USB from Windows, Linux, and OSX.

http://www.remote-exploit.org/backtrack.html -BackTrack website.

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