1.
Yeah, I agree.  The dontstealmywifi is mitm.  I guess your attacker has a 50% chance of tapping into the new AP.  Maybe put the new AP closer to the outside of the premises.

2.
I watched one of the videos, but it uses Auditor which I don't have, so I did this instead:

Backtrack 2 Live->Ran Kismet.  Channel locked to my AP's channel (no encryption on the AP).

On another laptop I logged into yahoo mail, went to the inbox and checked my mail.

Went back to the Kismet machine, copied the .dump file to USB
Rebooted the Kismet machine to Windows, ran dontstealmysecrets
In the program, converted the .dump file to .pcap
Opened the .pcap file

My email account appeared.  I double clicked on it and it opened my account.  Everything is there and I can send a new message.  I then right clicked and went "explore" and all my previously received email messages had been downloaded and were stored as .html.  I did a search from within the program for my kids' names and other personal information and it all came up.

I then changed my IP address (not the NAT address, the IP address provided to the router) and double clicked on the email account again without reloading, and it still went into my account.

I then did the whole process from the beginning, this time logging out of yahoo before loading a newly converted .pcap file, and it still worked.

I then did it on one machine, capturing wired traffic with wireshark only.  Opened the wireshark .pcap file without converting it and the email account appeared, and did the same thing as above.

I then took the .pcap file and loaded it while connected to another ISP, and there it did not work.

3.
I showed this to my boss he said he'd have to "think about it."  He should know what is going on here.  We have clients that have these kinds of accounts. 

4.
If I am getting this right, this means that someone can capture wireless at any open access location (say a convention center) and gain complete control over numerous email accounts, just by capturing packets.  Their only restriction is that they have to connect to the same AP (or provider) to gain access.  This is not something that I have ever seen before.

Hell i'm just happy I created a thread that is actually getting some interest.  Normally I'm the one in the background just reading.   Feels good to give back to the group.   

OK, I've got dontstealmywifi installed and ran it while logging into my yahoo and gmail accounts. Here's what I've got so far:

1) It doesn't recognize my gmail account at all. It logs my access to gmail pages, but doesn't give me any account information.

2) It isn't obtaining any password information. When double-clicking on my yahoo account that it lists, it immediately sends a GET request to /ym/ShowFolder and requests to view my Inbox; it appears to be using the same cookie that I was issued when I first logged in (I didn't look too close though, I'll have to verify this later).

3) When it IDs an account (such as my yahoo account), it starts downloading all messages. Because of this, I'm now locked out of my yahoo account temporarily, so I will have to wait a while to continue testing this.

4) After I logged out of yahoo, it still said it was downloading messages. I'm not sure if it was or not, because it doesn't give any real details, but I have a couple theories on this: yahoo mail is receiving so many requests with the current session cookie (because the program is downloading all of my mail) that it ignores/overlooks the logout and the session remains valid OR yahoo mail simply does not properly destroy session data server-side, so anyone using the session cookie can still gain access to the account after you logout. I'm leaning towards the former.

Once I can log into my Yahoo account again, I'm going to run some more tests...I'll post up anything interesting.

Agreed Kev, anything in plain text is fair game for anyone who happens to be listening in! SSH tunnels all the way!

As far as the program in question is concerned, it's a nice simplified interface for capturing email sessions for certain online accounts (like I said, it didn't seem to recognize gmail, so I don't know what sites/account types are supported) and for spidering a user's Inbox (as stated above though, this will lock out their account, so it's not perfect), but it doesn't seem to do anything that couldn't be done with a shell/perl script.

Basically it just captures the session cookie and uses that to hijack a user's session. The reason you can still log in after the user logs out of the account is that the session cookie is only deleted from the client's browser...it is not deleted from the server however. I verified this by logging in, copying the cookie data, logging out, then requesting the Inbox page using wget which I supplied with the cookie header. Yahoo happily spit back my Inbox.

So, while this app doesn't do anything ground breaking, it seems that Yahoo doesn't destroy session data on the server when you log out of your account, which is quite interesting. There also seems to be a couple of URLs that can be used to redirect users arbitrary sites/pages...could be useful for XSS/CSRF attacks.

That certainly is something...I don't know if it's a good something, but it's something!

I'm not aware of any other programs designed specifically to do this either t0lomp, I was just saying that this program doesn't do anything magical that couldn't be done with tpdump/grep/wget. Not saying it isn't useful as you pointed out, but again, this program doesn't do anything you couldn't do with most default Linux installations - it just makes it much, much easier.

Also, I'm still able to access my account using the cookie issued from yesterday. I've logged out, cleared my cache, and rebooted, still works. Interestingly, I mentioned this issue to one of my friends who does security work and he said he'd heard about it before from somewhere, so Yahoo's failure to properly destroy sessions isn't entirely new apparently.

Good find d1spat3r, thanks for your help in figuring out how this works t0lomp, and if I ever decide to use Windows again I just might find myself using this.

Hey t0lomp,

Well, if you don't mind doing some copy/pasting by hand, the easiest way to do this would be to use ethereal to capture session cookies and then request pages by hand using wget. But that's kind of a pain. If you wanted to automate it, here's how it might work on Linux:

1) Fake WAP

Linux allows you to place your wireless card in master mode (i.e., turn it into an AP), and enabling IP forwarding will allow it to forward requests between the wireless interface and the ethernet card (which should be able to access the Internet obviously):
   
   iwconfig eth0 mode master essid "My Fake AP"
   ifconfig eth0 192.168.1.1
   echo 1 > /proc/sys/net/ipv4/ip_forward

A better way IMHO would be to spoof DHCP replies and tell client machines that your computer is their gateway/DNS server. It's harder to track, and you can write some fun NAT rules to redirect connections to your own servers.

2) Downloading all emails

You can use tcpdump/tethereal to capture data and grep for people accessing their Yahoo/Hotmail/whatever email accounts, then extract their cookies from the data (regular expressions would be useful here) and pass those cookies to wget which can recursively download pages on their Inbox page.

Examples of some Perl scripts I've written in the past to perform similar data capture/extraction using tethereal can be found here (http://packetstormsecurity.org/wireless/wlan_webauth.txt) and here (http://www.craigheffner.com/security/aim-jack.zip); there are probably better examples out there though . A quick and dirty tutorial on using wget to perform recursive downloads can be found here (http://linuxreviews.org/quicktips/wget/).

3) Providing access to the account

I've actually written a Perl HTTP proxy (http://www.craigheffner.com/security/httprox.txt) that allows you to specify a random header, which is perfect for this. Put the cookie header into a file, connect to the email account via the proxy, and you're in like a dirty shirt. It's nothing fancy and some of the code was swiped from other Perl scripts floating around the Internet - it just forwards requests through wget, then sends the response back to the browser.

Well, that's kind of like saying you might as well leave the keys in the ignition because someone could steal your car by hotwiring it. There's nothing wrong with SSL, and in fact if the webmail sites used SSL throughout the entire session, this wouldn't be an issue. Honestly I can't believe that Yahoo doesn't properly destroy server-side session data, that seems like a no-brainer to me. But regardless, remember there still are restrictions to session hijacking even in a case such as this because most sessions will be tied to a specific IP or IP range. If you capture a Yahoo mail cookie at a WiFi hotspot, you can't go home and use it like you could if you had the actual user name and password.

"Unlike T-mobile, or other more established services, FON (http://www.fon.com) opens up its users to identify theft, and in a particuarly nasty way. For example, dontstealmywifi and dontstealmysecrets (http://www.dontsteal.net) allow a Windows user to download every mail message of any FON user, and lets anyone send and receive new email from their account, even if authentication occurs over SSL. This can be done by the person who owns the FON router, or anyone else. How long will it be before someone posts such messages and attribues them to the FON insecurity? How many users would be comfortable with it then? Which ISP employee (anonymously, of course) will be delegated this task?"

http://wiki.fonboard.nl/index.php/FON_router_security