In last post to session hacking series we saw how to attack weak token generation methods. In this post we will see how session tokens are mishandled and how they are attacked for mishandling. An important point that you must note that no matter how much secure coding you implement while creating session tokens if they are mishandled there’s no way you can protect session from getting hacked. Next thing that you should keep in mind is that implementation of SSL doesn’t guarantee 100% security against session hacking. Implementation of SSL helps in protecting tokens if implemented properly but honestly speaking there are many websites which does not really implement SSL properly thus leaving even SSL open to attack.
Attacks Against Disclosure Of Tokens On Network:
This is really damn big problem which is proof of the concept SSL can be wrongly implemented. Following are some real world examples of such faulty implementation,
Facebook uses HTTPS to protect user’s credentials while logging in but turns back to HTTP after logging in thus credentials are made safe but not the session tokens. Reality is that those token are transmitted every-time when page is changed or reloaded thus leaving session tokens readily available for sniffing. Any packet sniffing tool for example wireshark, ettercap, dsniff, Cain And Abels, Ace Sniffer etc can be used for attacking such disclosure over network. Read our post how to hack facebook password using wireshark to get real idea bout how attack is performed on this foolish implementation.
You may have noticed several websites on which when you arrive at log-in page you see HTTP in URL but when you press log-in it tries to switch to HTTPS. If an attacker positioned properly between user and website he/she can downgrade such connection completely to use HTTP to reveal session tokens over network or simply he/she will modify victim’s browser to use only HTTP. Attack on such connection can be made using Ettercap and SSL strip.
A website using both HTTP and HTTPS connection simultaneously is also vulnerable to attack.
In all any kind of wrong SSL implementation can be attacked using Packet sniffer.
Attacks Against Disclosure Of Tokens In Logs:
Several websites show token logs in their URL while browsing, for example consider following example,
as you can see the session id is highly visible. Though this visibility might be for fraction of seconds while logging in but is highly vulnerable. This type of token visibility makes session vulnerable even though HTTPS is implemented but the major problem it faces that it is not only visible to one user it is visible to everyone. This vulnerability can be attacked using Burp Suite. All you have to do is intercept session from URL and try to alter it to hijack session.
Attacks Against Improper Storage Of Cookies:
By default many websites save cookies in default path in web browser i.e ‘ / ‘. That leaves tokens open to get detected by hacker. For example suppose you visit http://www.vulsite.com/page1/page2/app.jsp then cookies will be set to domain http://www.vulsite.com and to path /page1/page2/ of your web browser. Since all cookies will be directly set to default path they become vulnerable to get stolen and that’s why cookie stealer are able to retrieve cookies from your web browser since path is already known. By the way we will cover how different types of cookie stealer are made some other day but for now keep in mind improper storage of cookies can be attacked using cookie stealer.
So in next post to this we will see countermeasures that can be implemented against session hacking. Till then thanks for reading have a nice time and keep visiting.