After I rooted my HTC Incredible I started doing searches in the market for interesting things. I found some neat wireless utilities, I found a file manager that lets you browse SMB fileshares on the lan (NEAT.), I found a packetsniffer, and some more interesting tools.

The light came on over my head when I realized “Wait, a packet sniffer AND a wireless access point? .. can .. I sniff.. the wifi with this?!”. As it turns out the answer is yes – it takes some fenagling, and if you do it in the wrong order one application stomps the other (I’ve already written the author of the packet capture application about this but have not gotten a response yet).

Here is a quick walkthrough on how to turn an HTC Incredible into a rogue wireless access point:

1. Root the phone. This can be done by visiting http://unrevoked.com/recovery/, downloading the app, and running it.
2. Once the phone is rooted, go to the market, and install the wifi tether application: Be aware though, that with the HTC incredible there are additional steps to get this application to work (see their wiki page: http://code.google.com/p/android-wifi-tether/)

   

3. Install the packet capture application. This also will need additional steps after the installation. (http://sites.google.com/site/androidarts/packet-sniffer)
4. Once you have the packet sniffer installed, configure it to log to a file instead of a sql database. I wasn’t able to find the actual database this thing logs to, but the text file appears right at the root of the sdcard. It looks just like the ‘live’ output though, which I don’t think is a proper format. It doesn’t log raw traffic at all.
5. Don’t start the sniffer or wifi tether yet – they must be configured beforehand.
6. Go back to wifi-tether and configure the SSID. Name it something which will attract people in search of free wifi. Linksys. Dlink. Netgear. 2WIRE858. The SSID of a target network, perhaps. Again, do not turn on tethering here yet.
7. Open up the packet sniffer again, and go to the ‘wifi capture’ section, then enable the capture, and if you’d like, enable logging packets to the screen.
8. Hit the phones ‘home’ button to exit without stopping the packet capture tool, and re-open the wifi tethering tool. Once in the tethering tool, enable tethering.
9. Hit home again, and go re open the packet capture tool. If anybody connects, wifi tether will tell you in the status bar at the top of the display, and you will start seeing arp traffic and dhcp traffic scroll in the live feed window as you would with any other packet sniffer.
   

There are several caveats to this though:

1. This tool appears to not capture raw packets. You can do this from a terminal using TCPdump if you feel so inclined – the packet capture tool installation instructions have you install a new version of tcpdump. You should be able to use this to capture raw traffic and not just clear text
2. Packet capture has to be running before wifi tether – if you try to do it the other way around wifi tether will hang and you’ll have to kill it.
3. This will also capture all the traffic from your phone to the internet, so if you’re trying to do a bunch of stuff on your phone while running a rogue access point, it will  muddy your results.

This has been a fairly simple howto – you creative types will easily be able to find more interesting things to do with this.

My wishlist after figuring this out? – An app that acts like airodump – I want to see clients probing for networks so that I can “give them what they want”. I also want this packet capture tool to log raw data, not just plaintext stuff.  Now that this is possible, I wish for tools like drifnet, dsniff, and others of that sort to become available on the android platform. The objective here would be to use this during a pen test as a tool to capture data, then bring it back to the labs for analysis.

Before we begin, however, I want to re-emphasize that it is VERY EASY to protect yourself against this sort of attack. Facebook supports HTTPS, so when you browse facebook (or twitter for that matter) or if you have it bookmarked – please make sure you’re using HTTPS:// rather than HTTP:// in the URL at the very least, if not using a VPN solution for further encryption. Also, if the ‘victim’ logs out of facebook, the attackers session becomes invalid – so it’s a good practice to actually log out of facebook and log back in again rather than using the ‘remember me’ checkbox.

Facebook like many sites operates using authentication cookies. Their auth cookies contain a variety of information, but for our purposes this is irrelevant. Here is a sanitized cookie for reference:

Cookie: datr=1276721606-b7f94f977295759399293c5b0767618dc02111ede159a827030fc; lsd=Xesut; lxe=greg.evans%40****************; c_user=100001230367821; lo=wl9fcGXMhPfoT4bAhKFP3Q; lxs=1; sct=1276721745; xs=a615cfe596448194d6e2a8d062a90e4e

You can see the ‘lxe’ field is the login. We haven’t done any further research into what the various other fields mean, but using facebook without any kind of security you’re both leaking the email address used for your login and the session cookie.

First thing you’ll want to do is fire up your favorite packet capture application. For this example we’ve used Wireshark:

Next, set the filter in the top left to ” http.cookie contains “datr” “. This should show you only packets captured which contain the cookie we’re looking for. You can see that in this screenshot we’ve already captured a cookie.

Once you’ve found a suitable cookie, you can copy it into the buffer by right clicking on the cookie line, and clicking Copy -> Bytes (Printable Text Only)

Next you’ll want to open up firefox. You’ll need both greasemonkey and the cookieinjector script.

Simply browse to facebook – make sure you are not logged in:

Hit ALT-C to bring up the cookie injector dialog box:

Then paste in the cookie!

Hit refresh and – VIOLA! you’re now logged in as your victim! Now this doesn’t give you access to their credentials, this is about the equivalent to walking up to their workstation while they’re away from their desk and using facebook.

Neat huh? Pretty easy too. I smiled big when we demo’ed the attack in our lab – its old, sure, but being successful is always a good feeling!

P.S: This isnt REALLY Gregory Evans account. We setup this account because .. well.. the name was available! We thought it was in good taste as the No #1 hacker’s twitter feed got hacked the other day, his site is riddled with XSS exploits, and his book is copypasta from a variety of certification exam prep books. Thanks to Nick and mckt for the work and tootilage, respectively. No noobs were harmed in the making of this film.

With the information that I know now (12:40am, 12/18):

The host which contained the landing page was hosted with bluehost. This tells us a few things

• They didn’t have the infrastructure to do packet captures, or credential theft. Bluehost does shared hosting.
• Any attempt to do so would have thrown TONS of SSL errors, and very likely DDoS’ed the server hosting the landing page. (Twitter had HUNDREDS of servers, these guys had 1.). All of your twitter apps would have thrown errors, or flat out stopped working.
• Twitters security infrastructure was left untouched, and was not a target of the attack.

I’ve been watching twitter scroll with sensationalism and panic, people yelling “OH GOD TWITTER GOT HACKED EVERYONE CHANGE YOUR PASSWORDS NOW”.

Please – don’t do that.

Its going to make everyones job harder who have to work on this situation, it incites panic and causes people to prematurely flip out and do things they probably shouldn’t do.

I’ve had to deal with this in the past – people throwing their arms in the air and screaming about passwords being compromised when they in fact weren’t. It did not end well.

Please – think before you hit send.