Saturday, May 3, 2008

Gmail Session Hijacking in 7steps

Session tokens are crown jewels of user identity on a web application. It's no hidden fact that attacks such as XSS (Cross Site Scripting) are on all time rise that steal these tokens leading to user identity theft.

Although adequate community emphasis has been laid on XSS & its countermeasures, there are other prevalent techniques and wide-spread issues that can steal session tokens perhaps more easily.

The one that I share here is network eavesdropping/sniffing.

A vast majority of the web applications that I have come across use HTTP, post authentication. Example: Gmail, Yahoo, Orkut or for that matter any popular public portal. The list includes several intranet/online financial and payroll apps we see day in and day out.

Below we see a step-by-step attack where we steal session ID of a Gmail user and hijack it in the process. (The credit for this exercise is shared with my colleague, Raj, rajaol@gmail.com):

1. The screenshot below simulates a victim (c00kytest@gmail.com) who is currently accessing his/her Gmail account over a corporate LAN, Cyber Cafe' or Wi-fi hotspot. As we see in the URL bar, the communication is happening over HTTP, i.e. plain text.



2. The second screenshot simulates an attacker sitting somewhere in the same LAN. Though the LAN is a switched environment, the attacker has used a tool called Cain & Abel to become man-in-the-middle (MITM) (there are many tools that can be used to set this up. Ettercap is a good example. We use Cain & Abel for our long time friendship with the tool. We have used it to sniff passwords travelling on SMTP and POP on numerous occasions).



The blue circle in the screenshot (IP: 192.168.0.1) highlights the Internet gateway address that we ARP spoof for victim (IP: 192.168.0.110), highlighted in red circle. The second red circle below confirms the success of first step of attack where all victim traffic is getting routed from attacker's machine. By now we should be able to see all traffic going from victim machine.

Let's fire up wireshark to read the victim data (again, you can use any sniffing tools for this) The above screenshot shows wireshark getting started.

3. As shown in the next screenshot we steal victim's gmail cookie details. This is highlighted in the red circle (IP: 192.168.0.110)



4. We copy the cookie details and paste it on a notepad as shown below



Gmail uses GX token from cookie to track users. It's highlighted in the screenshot above. We just need this value to hijack victim's account.

5. As shown in the screenshot below, we go back to attacker's login (rajaol@gmail.com) and use a firefox add-on called Cookie Editor to insert the stolen cookie.



6. We now paste the stolen GX value in the cookie editor as shown below. (We did some trial and error and removed many other cookies. We also changed token value for gmailchat=c00kytest@gmail.com)



7. Alright. We are done. Now change the URL in the attacker's browser to the one highlighted in the screenshot below (some other gmail links were logging us out directly. This one didn't. There might be others too that could give you the access similarly. It's all trial and error). Gmail shows you logged on as victim !!!
(highlighted in second red circle)



Now that we have seen how simple this attack can be (Wi-fi would be even easier. No ARP spoofing required. It's all broadcast. On top of that many still use WEP. WEP is trivial to crack) and the associated threats, let's look at the countermeasures.

Countermeasures:

1. Use HTTPS
CAVEAT: On a switched LAN, MITM is still possible but your browser will warn you. It will show a certificate error. Users need to take this error seriously and alert the support/security staff. Gmail provides optional email access over https://gmail.com but it is insufficient as it makes other requests over HTTP. Nevertheless you will get a browser warning as soon as the MITM happens (certificate error). You can act upon it accordingly. Yahoo & majority of the other public portals do not provide options HTTPS access.

2. If HTTPS is not possible for performance reasons, use multiple cookies & continuous (page-wise or request-wise) tracking mechanism that detects a sudden new connection & logs out the user automatically.
CAVEAT: This might still be breakable by an attacker if the MITM started before victim's first access to the site.

21 comments:

  1. Great one dude, thanks for sharing the awareness.

    ReplyDelete
  2. wReally nice information . Thanks sharing :-)

    ReplyDelete
  3. Hello Bishan, excellent stuff on security. a layman is never aware of these facts. Many thanks for educating us.

    ReplyDelete
  4. Hi Bishan.Very nice information & Thanks for sharing

    ReplyDelete
  5. Hi Bishan,
    Very knowledgable facts to share with and increase alertness.

    ReplyDelete
  6. Knowledgable information with good facts and alertness.

    ReplyDelete
  7. Knowledgable information with good security alertness.

    ReplyDelete
  8. Knowledgable information with good security alertness.

    ReplyDelete
  9. Its a very useful info..Thanks Bishan.
    Could you post some more info on Banking/Financial site security

    ReplyDelete
  10. Its good one...very useful..Thanks Bishan.

    ReplyDelete
  11. There is a problem with this method. The cookie is encrypted and as usual contains the timestamp. So if you have try put this cookie after the cookie expires, which may be 10-20 mins. You won't be able to login.

    Bottomline, you need place the cookie in time in order to hack the account.

    ReplyDelete
  12. Sandeep, the technique in itself is flawless.

    How to keep cookie in time is another ball game.

    And if you were to believe me, it isn't difficult.

    Majority of the tests I have done I have not encountered situations where cookie expired before I could do something.

    Nevertheless majority of the cookies refresh time-out window based on time it was last accessed. So keep accessing the link using an automated scripted daemon and you should have cookie almost never expiring in most of the cases, unless the user logs out. Now let me ask you, how many of us logout?

    That apart, there are still several other ways to keep cookie in game and as I said earlier it needs a separate discussion all together.

    ReplyDelete
  13. The same is explained with open source tools on blog tech-spirit.blogspot.com

    this attack can be protected with SALTED MD5 and HTTPS.

    ReplyDelete
  14. I tried this method lately by replacing the GX and gmailchat values but no success. You mentioned that you have removed other cookies as well. Can you please name those as well? Thanks

    ReplyDelete
  15. Did you try the same URL as mentioned in the Step 7 screenshot?

    Some of the URLs will log you out, but this one didn't.

    In my test I just had to steal GX and nothing else. Try repeating, may be something didn't go well in your case.

    At times it is a trial and error case, may be use Firefox & search forums to see if Gmail has changed some of the cookie behaviour.

    ReplyDelete
  16. These technicians work 24/7 and even on 365 days and does preserve any holidays. They are available for round the clock assistance. They work in rotational shifts to ensure the presence of technicians all the time.https://infogr.am/3fbc1ae7-a96c-4ff8-b028-29bec1dfbb14

    ReplyDelete