Take your time to study the packet traffic. If you turn on the packet sniffer on yourself, you can login to various sites, or chat with a friend in IM and see what the packets look like. You can also set the filter to only pick up packets that contain important words like user pass.
Yes, most IMs can be read in plain text. If you run the packet sniffer on yourself, you will usually get one-side of the convo - yours. The server returning the other half of the IM might be encrypted or illegible because it might use a secure protocol. If you sniff on the same network as both users, you can get both sides of the convo - i.e. before it goes to the IM server.
No, you can't really lock down your ARP, but you should check it often.
Side jacking also known as surf jacking, because you do it while the target is surfing, like at a public hotspot.
Side jacking, I suppose is different from Session Hijacking. Side jacking is the act of hijacking an engaged Web session with a remote service by intercepting and using the credentials that identified the target to that specific server - the cookie. Side jacking works only if the site caches a
non-SSL cookie out to the logged in target. What that means is you can sniff wifi traffic at a coffee shop and mirror those cookies. Side Jacking is more common on sites that require authentication by a username and password, such as online Web mail accounts as well as social networking sites. They said any Web site that uses SSL would be safe from Side Jacking- but now there are proof-of-concept attack tools to do the same thing with SSL connections.
Session Hijacking is taking over the conversation between the target and the server, usually DoSing the target after it authenticates to the server - you then impersonate yourself to the server as the target, this is done through modifying the
packets in the converstation between server and target. You have to keep the target computer from contacting the server and 'rset' the session, reinitiating the ack/syn handshake all over again.
Side jacking can work after the user session had quit, you prevent the user from logging out or steal the cookie created by "remember my password on this computer" option.
Side jacking can be prevented by short expiration cookies, or cookies that use your mac or IP as well as the login.
Cookies can have a flag called “secure,” which when present causes the browser cookie to be sent only through encrypted channels. When the web browser is redirected to a clear text channel (HTTP rather than HTTPS), such cookies are not included in the HTTP request. This behavior solves the problem described and can be easily implemented on web services that separate services that need encryption from those that do not. One such service is E-banking, which is normally segregated on a web site such as
https://secure.bank.com/.
There are cases where setting the Cookie secure flag is not an easy option. A web service such as Google shares a session and credentials across various domains and switches between HTTP and HTTPS depending on the service. In this case, the solution is not as easy as setting the Cookie to “secure” because that would not scale well with the rest of the infrastructure. Google appears to be have mitigated this for Gmail by providing the “use only HTTPS” option - but other Google services such as Google Docs remain vulnerable to attack.”
http://blogs.techrepublic.com.com/networking/?p=634
http://erratasec.blogspot.com/2007/08/s ... er_05.html
http://www.erratasec.com/sidejacking.zip
One trick is that URLs also contain unique identifiers. In order to sidejack a HotMail or Yahoo! Mail connection, you have to know which URL to use. The other is that when starting in the middle of a session, you see the "Cookie:" commands the browser sends to the server, but not the "Set-Cookie:" commands the server sent in the opposite direction. Sometimes things don't work because when I clone cookies sent with the path /aaa/bbb, I won't know that I should also send them with the path /aaa/ccc. I've found that when you gain access to a site, but the access is flaky, if you start browsing around the site, you'll eventually get the correct "Set-Cookie:" from the server, then everything will work correctly.
---------------
Gmail now supports an account option to enforce the
secure only bit on session cookies and keeps your entire gmail session
on SSL. this makes attacks like Mike Perry's active side jacking
impossible, as the session cookie is no longer sent in the clear when
http:// non-SSL links are injected into browser content.
to enable this feature:
- at top of page select "Settings"
- scroll to bottom of section for "Browser connection:" preference
- select "Always use https"
this will pass the Secure / secureonly option when settings the GX=...
session cookie used to identify your authenticated session. this
cookie will then never be sent over plain-text connections, protecting
you from passive / active side jacking attacks.
http://archives.seul.org/or/talk/Aug-2008/msg00058.html
------
it was mentioned more then once that it is about the tools or at least the combination of them: proxy + sniffer + packet content analyzer - something that was not available before that. Ferret and Hamster is for sniffing like Metasploit for exploits. It is innovation, because the next generation of hacker sniffing tools will concentrate on getting the most of the captured data without wasting too much time
-------
Aug 14, 2008 | 06:15 AM
By Tim Wilson
DarkReading
Researchers at Enable Security this week published a proof of concept that shows how an attacker might hijack browser sessions secured by the popular HTTPS encryption scheme.
HTTPS is used by many banks, e-commerce sites, and other businesses to provide a secure link between a browser and a Web server. But in a paper published Sunday, Enable Security's Sandro Gauci outlined a way that hackers might hijack HTTPS links and defeat the encryption.
In a nutshell, the proof of concept describes a way to use the "301 Moved Permanently" redirection message to fool browsers that are seeking HTTPS sessions. Rather than breaking the encryption, surf jacking essentially takes advantage of the fact that many HTTPS servers and browsers do not make use of the "secure" flag in the browser cookie.
"The result is that, even though the traffic between the server and client is transported over a secure protocol, an attacker sitting in between the victim client and the victim Web server can launch a downgrade attack to reveal the session cookie," Gauci states in the paper. A short video of the exploit is also available on the Web.
The new proof of concept builds on Errata Security's concept of "side jacking" HTTP sessions, which was demonstrated at the Black Hat conference last year.
http://www.darkreading.com/security/per ... =211201383
-----
DNR