Playing back wireless traffic

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. :)

Quote:

---

Originally Posted by bballad

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.

---

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 nihil

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

---

The procedure is provided below.

Quote:

---

Originally Posted by sandcraft

READ the SSL RFC to see why this is just a wet dream.

---

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 d34dl0k1

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.

---

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 .

---

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.

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.

Quote:

---

Originally Posted by Aardpsymon

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.

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

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.

---

Run what windows program?