Month: May 2009

Messing with WEP – Part II

This is where it gets fun. In this part, we’ll set our wireless interface to monitor mode, and we’ll start sniffing some packets and dumping the captures into a file for further analysis.

To start, we have to list the available wireless interfaces to the system. Hopefully your card is compatible and has a driver already loaded. Let’s fire up Konsole (a terminal application), which is the third icon from the bottom-left, and we’ll type:

iwconfig
picture-21

This will throw us back the list of wireless interfaces. iwconfig is similar to ifconfig, and easy to remember because of the single letter change.
Once we determined that our wireless card is there, and what it’s name is, we’ll set it into monitor mode by running:

airmon-ng start wlan0

Obviously, replace wlan0 for whatever your interface name is.
After we set the card in monitor mode, we’ll be given an alternate interface name usually in the form of mon[x]. We’ll be using that interface to sniff packets.
Next, let’s do a short site survey to see what’s really around us. We’ll run airodump-ng to do this as follows:

airodump-ng mon0

picture-4

This will give us the list of AP’s and stations close to us, and if your card supports it, a signal strength and receive quality indicator. It’s best that your receive quality is close to 100, as this will help when injecting packets later on…
If you see, the Channel keeps varying, this is because we’re surveying the entire spectrum for available networks. Once we find the one we’d like to peek into, it’s very important to lock the card in that channel so we can listen to the maximum number of packets.
Let’s lock the card into channel 1 so we can hear that AP better… we do that by using iwconfig again:

iwconfig wlan0 channel 1

And then let’s see the results:

airodump-ng –channel 1 mon0

Hopefully now there will be beacons more often (which are useless, but good indicator that we have signal, the faster they flow the better).
We’ll set the proper airodump-ng parameters so we lock to a specific Channel, specific AP (or BSSID), and we write the captured IV’s into a file that we can use…

airodump-ng –ivs –write /root/capture –bssid 00:12:17:05:92:5D –channel 1 mon0

By doing this, we’ll start listening to ALL network traffic going and coming out of that specific AP. If the network is pretty active, we should see the “#Data” counter go up, which is exactly what we want. The more “Data” the faster we can get that WEP key.
Just to give you an idea, it’s very unlikely you’ll get far with anything less than 50000 IV’s (“Data”). This is why on the next section I’ll go over how to inject packets to generate fake traffic and get that Data counter up to something usable in minutes.

Messing with WEP – Part I

It’s been long known that WEP is a very insecure wireless encryption protocol, and this is due to weak Initialization Vectors (IV) being used within. See, the engineers that designed the WEP protocol attempted to create a stronger encryption by adding a 24 bit IV to the cypher key that changes constantly, thus “eliminates” the repeated encryption of data with the same key over an over. The problem is, these IV’s are too short, and are periodically reused… which means that if we can sniff enough data over the air, and get the AP to reuse IV’s eventually, we can figure out the key.

In this tutorial I plan to do exactly that, grabbing the WEP key of my own “public” wireless network, which I made “1234512345”. Simple.

First, we’ll start by grabbing a copy of BackTrack. BackTrack is a live Linux distro that has a (pretty big) collection of little tools that aid security professionals in penetration testing. Of course, put in the wrong hands, this distro can do some serious damage. Fortunately, we won’t be doing any of that here.

You can grab the distribution by going to http://www.remote-exploit.org/backtrack_download.html and downloading the ISO. I’ve been using the BackTrack 4 Beta lately, so i’ll be showing that one around.

Once you got the ISO cooked and ready to go, reboot your PC and watch that kernel uncompress… sweet… after a while you’ll be presented with this:

Login

We’re going to login as root with password toor. After we’re in, we’ll type in startx to start X and KDE so we can get some GUI and multitask on command windows easily. After the GUI is loaded, you’ll see KDE which looks like this:

KDE

And that’ll be all for today. I’ll continue the guide later so we can put your wireless card to better use.

Zimbra and Funambol integration

So, since I recently wiped my ESXi box and installed CentOS 5.3 on it instead, I went with Zimbra for my e-mail solution, with LDAP authentication, and I have to say so far it works amazing… but e-mail push is a feature i’ll be missing on my phone…

I found the solution to be something called Funambol. It is similar to what BES is for Exchange or Notes. It provides a sync interface for end devices into Zimbra, or Exchange, or others. I’ve been spending the weekend configuring Funambol and Zimbra to see each other, and my phone to sync with it.

Here’s the guide i’ve been following: http://wiki.zimbra.com/index.php?title=Open_Source_Mobile_Calendar_and_Contact_Synchronization