Abit on "Ferret and Hamster", it was written by Robert Graham and was officially released during the Defcon conference in 2007, where he log into a list of victims' webmail (shown on a the big screen such as Gmail, Hotmail). Those victims were actually the audience that were still using their webmail during presentation.
This tool actually sniff the network traffic (either wireless or wired) and extract the session-id from the HTTP cookies. Many web sites use SSL encryption for login pages to prevent attackers from seeing the password, but do not use encryption for the rest of the site once authenticated. With the session-id, you can gain access to the victim's account without the need of username and password.
Updated
After posting the video on sidejacking, i feel that i should also provide some simple advise to user on protecting against such attacks.
1> Make sure you use "HTTPS" in your broswer address (e.g "https://mail.google.com") when accessing the login page of a web application, such as Gmail or Hotmail.
2> Check your web application setting whether there is any option to use only SSL(HTTPS) connection. For Gmail, you can set to "Always use https" (shown below).
3> To confirm if your connection is secured after logging in, check to see if there is a "lock" icon in the Status Bar on bottom right of your browser.
7 comments:
What's the best practice for Web apps that do not have option to SSL every page? Eg. Facebook.
If the website such as Facebook do not provide SSL connection, try not to access those site using unprotected network such as public wireless access or internet kiosk.
Hi,
Thanks for sharing.
may i know if they can hijack INBOUND packet as well?
i've posted a reply in ur hwz. I have decided to repost here so we can discuss.
[Original Post as below]
-------------------------
really educational. SSL/TLS will not be the solution because of slowness.
Maybe this can solve.
A) Encrypt the session ID using a public key. Since Public key is not sensitive, the key can always be stored in Client Scripting ie javascript or in HTML elements ie Hidden input. It doesnt matter the whole world can know it.
B) This may not be able to be stop man-in-middle since the Encrpyted SessionID can be hijacked and be imitated as u and try to replay the request. Therefore ensure "Run-Once" by including a TimeStamp and encrypt it together with sessionID.
The hijacker will never be able to know the session ID since he dont have the private key to decrypt. Only person who can is the WebServer. He will never be able to "Replay attack" since the TimeStamp has expired. The encrypted SessionID will use useless when it's being "Run-Onced" already.
Actually is same way SSL is working except it encrypt nothing but the sessionID, except smaller overhead since u encrypt lesser info. When login, the password should be massaged the same way if u dont like SSL/TLS.
PS (limitation):
1) This is not enough if u have "remember-me" on and if someone else has access to your machine. Attacker can access ur session or cookie store.
2) Session handling is pretty high level function in much more web frameworks, it's difficult to Override it. The solution is to make use Cookie and invent ur own PersonalSessionID. This PersonalSessionID is assigned by ur Application. It does nothing except validation of ur credential. Or ur PersonalSessionID can be included in ur HTML in case ur client doesnt allow Cookie. (Much like how Viewstate works in asp.net)
3) Can the TS pls advice me as i am not familiar with Sniffer. Can it Sniff INBOUND packet? If it can, it will already sniffed out the SessionID when the Server is assigned to Broswer. So nothing gonna work.
----------------------------
Good video!But i have a question.
When i scan my wireless lab network with wireshark it only shows the traffic of the
machine i run wireshark on.
When i connect other machines,iphone,virtual machine,..
no traffic is shown!
Do i need to put the wireless card in monitor mode to see all trafic?
found it,using ettercap is a solution.
c0r
Does this method still work? I've heard that since then, gmail has applied a patch that secures this method.
Hi diggz, this is not a system vulnerability. It is a design loophole for web site like facebook and internet forum.
These sites do not enable encryption after authentication, maybe due to performance or simplicity on their application
As shown in this post, Google provide "Always use https" option for user to protect their Session ID. This option is not enabled by default. Many other website such as Facebook still do not have this option. So you are still vulnerable to this attack.
Post a Comment