I don't understand why it's possible to play back captured wireless traffic and get access to any web mail account. There seems to be some kind of fundamental flaw at work here.
Printable View
I don't understand why it's possible to play back captured wireless traffic and get access to any web mail account. There seems to be some kind of fundamental flaw at work here.
The flaw is probably the users not changing default passwords, not using strong passwords and not using strong encryption.
Nihil, as usual, has hit this right on the head... the flaw is not necessarily in the technology... it is in the way people use the technology... Routers, by default ship without encryption enabled... and most people never bother to switch it on. So it is trivial for an unauthorized user to sniff the wireless traffic and capture all kinds of information.
well, aren't a lot of logins encrypted at the browser these days anyway?
I know for sure my i-banking login is sent encrypted, reasonably sure my yahoo account is although I haven't used it in ages and I don't care about my hotmail, its mostly spam.
Something a lot of people forget with wireless. Even IF they break the WEP/WPA or whatever you use, most sites use 128bit encryption anyway. So all really sensetive data ends up double encrypted.
If the web mail account uses HTTPS, you're safe.
Otherwise, you're probably at risk.
Open wifi networks are easy to intercept from some distance away - this makes them very risky. If you're using an open wifi network (for some reason) you should be mindful of this and not log on to any non-HTTPS site which requires a password etc.
Unfortunately some sites (possibly including AO) may use cookies to remember who you are - if you even *visit* such a site over HTTP on an open wifi connection, your account may be compromised.
Slarty
AO is not encrypted... this is something I have never understood... the password is sent in plaintext...
It's a playback of wireless traffic which provides access to any web mail account, and it appears to work even if the account password or hash is protected by SSL. I don't think it is an MITM attack since the traffic is pulled out of the air.
Seems like a fundamental flaw in web authentication. I can't see how this could be though. Very confused.
Either you are making unreasonable assumptions, or you will need to provide much more detail........... like how the hell do you know:
1. It is a playback of wireless traffic
2. It doesn't matter if you are encrypted
3. The traffic is pulled out of the air
Huh?
So far you have described nothing that couldn't be explained by a simple keylogger ;)
I guess because I saw it done.
What I saw was that the traffic was pulled out of the air using Kismet under the Backtrack Live CD booted on a laptop. The .dump file was saved to USB. The same laptop was then booted into Windows XP and a Windows program was run against the traffic, first to convert it from 802.11 to a .pcap file, and the same Windows program then provided full access to every account accessed via 802.11.
There was no keylogger involved. There was no access at all to the machines that originally accessed the accounts.
I am really now completely mystified by this whole thing. The password hashes under the accessed accounts are encrypted via SSL.
it sounds a lot like what they are doing here is replaying the traffic from a successful login like listening in to a spoken password. You hear it, you reproduce it. However given what I know of authentication protocols, surely the time stamp would be off. Also, good protocols have a random number and session ID assigned to them and those would be wrong indicating that it was a recording of a previous handshake not a new, live, one.
Where did you see this?
Are you talking about WEP as opposed to WPA or WPA2?
WEP is weak.......that has been known for a long time, please take look here:
http://www.openxtra.co.uk/articles/wep-weaknesses.php
It is a question of where in the communications chain the weakness exists?
Farmikol0t:
I don't think it is possible to gain access if the password hash is SSL encrypted.
Clearly you aren't talking about the encryption to the router, but rather the security mechanism for logging in as provided by the authenticating web server. This should hold up even if traffic is presented in the clear, or with WEP, over a LAN, etc.
If you could tell me what "Windows program" was used to analyze the traffic and log you into the authenticating system it would help a lot.
Obviously if the password is presented in the clear, as in the AO forum, it is trivial to authenticate.
If the password or hash is not presented in the clear, then for well-known web mail systems it would be a big deal (and I believe impossible) to authenticate if provided with the traffic only.
Have a nice day.
Coworker showed me.Quote:
Originally Posted by Aardpsymon
Neither. Talking about SSL encrypted hashes and authentication.Quote:
Originally Posted by nihil
That's what I thought also, but what I thought and what you have stated above are incorrect. Apparently it is possible to gain access by replaying traffic (wireless or wired), even when the password or hash is presented via SSL.Quote:
Originally Posted by marsbarz
what was the login for? as I say, replaying web traffic should throw off bad time stamps, session ids and probably other things I don't know about.
Web mail accounts where the password hash is encrypted via SSL.Quote:
Originally Posted by Aardpsymon
It's a lot more than showing what was re-played, rather full access to the account was provided.
Then the authentication on those webmail accounts is flawed. Badly flawed.
Replaying login traffic isn't a vulnerability that was created with wireless.
I tried the procedure myself (obviously with my own accounts) over the weekend and there is a serious problem, it's endemic, and not for just one provider. The problem is present even with very large web mail providers (the world's largest, in fact).Quote:
Originally Posted by Aardpsymon
Now more confused than before...
That is rather scary. Tie that in with the fake hotspots mentioned in that other thread and you have everything you need to compromise a LOT of email accounts in seconds.
Hmmmm,
OK, the first issue to my simple mind is "where is the interception taking place"? in other words just what is getting exploited or circumvented?
What and/or who is "leaking"?
Have cookies got anything to do with it?
Given the number of security "wannabes" out there I find it very strange that something so fundamental has gone unnoticed for so long :confused:
Does this only affect e-mail?
aha! that could be it, cookies. I suspect you have it there nihil. Its not redoing the authentication at all, its reading the saved cookie. No session ID/timestamp problems there, just reading the contents of the cookie which doesn't change.
Perhaps the moral here is to never remember logins on a wireless connection?
Agreed - it's full control over the account.Quote:
Originally Posted by Aardpsymon
Don't know but it works even on a logged-out account (i.e. any cookies presented would be expired so they shouldn't work).Quote:
Originally Posted by nihil
View of any existing mail message and the capability to send new mail on web mail accounts.Quote:
Originally Posted by nihil
As far as I can tell.Quote:
Originally Posted by nihil
Agreed.Quote:
Originally Posted by nihil
not mitm, not SSL problem, and not cookie replay......
so what is it then....not not not, but what? you are saying that you can walk into any coffee shop (unencrypted) and gain the ability to send and receive out of any web mail account....this is definitely someting new, if it's real.
"Program" name please?
I still suspect cookies............. if they hold the password (and some do) that would explain it all?
The session would be expired, but the password would be the same?
Farmik0lot said you could do it with many top mail providers. I am confused here, since most of these are professionals. If 'any' is included in this, that counts gmail. Do all of these mail servers use stale cookies?
Is it just me, or has he yet to explain how he is capturing the traffic. As in 2 wireless clients connected to the same unsecured AP and he is capturing the traffic from an unsecured wireless ap.
Perhaps the coworker was showing off and bogusly captured his OWN information?
You can't replay SSL traffic without the private keys involved. End of story.
MITM attacks are possible over wireless. If the web applications digital certificate was signed by a known CA, then the MITM would have caused the browser to prompt the user to verify the cert. If they accepted, game over: the traffic is clear to the attacker. This is because the attacker would have replaced the public key with their own.
Ask your friend how many wireless interfaces they have in that laptop. Or, ask them what they did. You know what they say about assumptions. :)
I cant really remember what they said about assumptions....
It was something on the line of "assume"
You make a/an "something" out of u and me.
an "ass" out of "u" and "me"
and I'm still with d34dl0k1 on this one. ANY half decent authentication system would drop replayed traffic AS replayed traffic, IE - out of date and not a current session. Its not as if the same thing wasn't possible on wired networks for years without switches.
Not sure, an expired cookie wouldn't work for top webmail providers, so it appears to be something else.Quote:
Originally Posted by nihil
Capturing traffic with Kismet. There is no AP in the laptop, just a wireless card not acting as an AP. The machine that logs to the account is connecting to the legitimate AP.Quote:
Originally Posted by net2infinity
No, because I tried it myself independently.Quote:
Originally Posted by ngboot
One wireless card, no AP. The authentication is SSL encrypted.Quote:
Originally Posted by d3dl0k1
Major webmail providers presumably have a half decent authentication system.Quote:
Originally Posted by Aardpsymon
Thanks for telling me to have a nice day. The reason that I posted the question in the first place is because I don't understand what is going on.Quote:
Originally Posted by marsbarz
what windows app is "replaying this", what webmail provider are you testign this on? I see three posibilites here.
1) someone is being hoxed, possaibly you, possibly us...give us some mroe details to rule out that option.
2) a provider is putting plain text passwords in their cookies (need the name of teh email provider, this is a serious problem and everyone needs to eb made aware)
3) someone's SSL is broken (if its an SSL session the timestammp would block everything, the encryption would keep the "replay" from giveing you usefull info)
4) Some one figured out how to crack SSL on the fly....this would be major...very very major, and should be impossable with current computers.
I am leaning towards option 1, the rest realy strech plauseibility and all of our info so far has been ver vauge.
Hmmmm,
1. Just look on our front page?...........left or right and look at the security news............there are a lot of people looking into all sorts of obscure security issues. relating to crap I haven't even heard of........ yet here we have "the great white whale" of all security issues............ and nobody has squeaked even once???????????????...............c'mon how real can that be?
2. We have allegations, but no details? HOW was this done?........... step by step, and with full details of the software used.
3. If I knew what was suggested was remotely possible, I think I would go to internet mail providers and collect a living for life............. or, at least a seven figure sum?
4. Name, the names, or STFU............ but,...... if you are wrong, they will sue your sorry butt to hell and back :D
5. Try demonstrating it to a major e-mail provider? at least you might get a beer, or a living forever.....
WHAT I AM SAYING SHOULD BE VERY CLEAR...........................give us the details or shut it.
Also, perhaps you have had the perscipacity to report this to the Federal Bureau of Investigation, the United States Secret Service, the Department of Homeland Security, and any others interested in the global terroristic opportunities that it would provide?
bballad.................. please remind me to get you a grammar and spellcheck for Christmas:p........... but I do agree, apart from that:D
READ the SSL RFC to see why this is just a wet dream.
sandcraft, I would not try to answer this technically. The original poster has apparently "seen a clever trick" and does not understand it............ neither can we, as we were not there and have not been given any details.
The original poster appears not to understand it either, but, as he will not provide the information, we cannot help him.
He claims to have done it himself, so perhaps he would pass the software and details on to us and we can give him an answer.
Otherwise.....................urban myth? .............. or some stupid schoolboy April 1st. joke;)
There are many problems with Farmikol0t's explanation, most of which is in the use of SSL to explain what is going on. Passwords aren't hashed with SSL, the entire socket is encrypted. Do you mean that MD5'ed passwords are being pulled off the line? None of the network traffic is even accessible without the private keys, replaying is impossible over SSL. If you are confused with your knowledge of hashing algoritms like MD5 and public key SSL, then we might be going somewhere. Because as it is right now, nothing adds up. :)
None of the above fits. I can duplicate it, so it isn’t #1. The provider’s authentication is over SSL, and the cert is valid, so it isn’t #2 or #3. It is not possible that it is #4.Quote:
Originally Posted by bballad
The procedure is provided below.Quote:
Originally Posted by nihil
Just looking for an explanation as to why it is possible to replay traffic and gain control over webmail accounts. Perhaps I have come to the wrong place.Quote:
Originally Posted by sandcraft
It doesn’t add up for me either, but it works, and this is the reason that I asked the question in the first place.Quote:
Originally Posted by d34dl0k1
The procedure is as follows. I have now done this several times. I have never done this with anyone’s wireless traffic other than my own.Quote:
Originally Posted by .
1. Get a backtrack live CD and burn it to .iso.
2. Boot the backtrack live CD on a computer with a Kismet compatible 802.11 card.
3. Run Kismet, capture traffic and let it continue to run.
4. Connect wirelessly on a separate computer and log to yahoo classic mail, yahoo beta mail, hotmail classic, or hotmail live lite, etc. (or all of them). Log out of them if you want.
5. Stop Kismet and copy the traffic (.dump file) to USB. You’ll have to specify the path of the Kismet .dump file when copying (i.e. where it says “*.dump” below).
mkdir /mnt/usb
mount -t vfat /dev/sda1 /mnt/usb
cp *.dump /mnt/usb
umount /mnt/usb
6. Boot to Windows XP Pro. Run the windows program.
In the program, convert the .dump file on the usb device to a .pcap file using Tools->Convert 802.11.
7. In the program, go to options and turn off mail downloading.
Go to File->Open and open the .pcap file.
8. Click OK and wait until the account names show at right. It may take a few minutes for the accounts to appear.
9. Double click on any account to enter the account, send and receive mail, or whatever.
10. You’ll have to be connected to a network that is on the same provider to do this. So if you capture traffic from your own SBC DSL line, you’d have to be connected to the SBC provider to replay the traffic. What this means is that if someone did this in a coffee shop, they’d have to connect to the coffee shop wireless AP to replay the traffic and gain access to the accounts.
11. The wireless traffic has to be unencrypted (i.e. in the clear, or with the WEP key, or with the WPA key from a rainbow table).
12. This also appears to work for wired traffic, not just wireless. The only difference in procedure is that you do not have to convert the .dump file to a .pcap file.
I still have no idea how this is done or why this works. As far as I can tell, there is a problem. Perhaps this is wrong.
If there is someone out there who can tell me what exactly is going on, and why this procedure works, how it works, and whether this is a well-known flaw, I'd really appreciate it.
Can you actually recieve a new email doing this?
can you actually send a mail?
have you seen either of those be done using replayed traffic? if not, I have an idea.
You can send and receive email on all accounts. You can construct a new mail message and send it, and you can receive new email.Quote:
Originally Posted by Aardpsymon
This works with other webmail providers.
I now believe that there is a fundamental problem at work here.
Your NOT breaking SSL at all with that procedure, I can't stop lol'ing long enough to explain where the "fundamental" problem is here, and that too would result in some roflol'ing.
Quote:
Originally Posted by Farmikol0t
Run what windows program?