Sniffing a cookie?
-
Lyecdevf
- cyber Idi Amin
- Posts: 1222
- Joined: 16 Mar 2006, 17:00
- 18
- Location: In between life and death.
- Contact:
Sniffing a cookie?
I am now on vacation and I am using public internet connections a lot. Because I am always concerned about security I was wondering if it is possible to sniff the cookie of the site you are loged in. Let's say that I have loged in with the password on some secure internet connection and you know no one could get it but than you take your laptop to some cyber caffe and you surf on the the same site because you have not loged out and the cookie session is still active. Would it be possible for some one who is sniffing to get your cookie and get access to your account even if he did not actually sniff the password?
We will either find a way, or make one.
- Hannibal
- Hannibal
I agree, the cookie is sniffable like other packets. This would be a threat for replay for sites that use cookies to keep a user logged in. You just have to watch the inital handshake between client and server. Keyword: SessionID, USER, and keep-alive
With HTTPS you have encrypted convo. So sniffers try to look for plaintext logins - when the site is still in HTTP mode, the user logs in, then the server moves over to HTTPS.
With HTTPS you have encrypted convo. So sniffers try to look for plaintext logins - when the site is still in HTTP mode, the user logs in, then the server moves over to HTTPS.
-
He gives wisdom to the wise and knowledge to the discerning. He reveals deep and hidden things; he knows what lies in Darkness, and Light dwells with him.
He gives wisdom to the wise and knowledge to the discerning. He reveals deep and hidden things; he knows what lies in Darkness, and Light dwells with him.
Wireshark should be enough, i don't know since i don't really use sniffers much. However, The security of HTTPS is ensured through private and public keys. The process is as follows: (information used from wikipedia)
A TLS client (ex. a web client using https) and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.
* The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, and presents a list of supported ciphers and hash functions.
* From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.
* The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA), and the server's public encryption key.
The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is authentic before proceeding.
* In order to generate the session keys used for the secure connection, the client encrypts a random number (RN) with the server's public key (PbK), and sends the result to the server. Only the server can decrypt it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK and (after decryption of the client's message) RN. A third party may only know PbK, unless PvK has been compromised.
* From the random number, both parties generate key material for encryption and decryption.
This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes.
If any one of the above steps fails, the TLS handshake fails, and the connection is not created.
¯\_(ツ)_/¯ It works on my machine...
Spied on despite encryption
In order to prevent misuse it is always advisable to use encrypted connections for sensitive activities, like online banking, or reading emails at services like Google Mail. However, in certain circumstances, attackers may still gain access to bank or email account data, despite the encryption.
The technique used is a special form of cookie theft. Although it was already discussed a year ago, it has only now received the attention it deserves – the main reason being that a tool has now become available which allows actual attacks to be carried out.
The problem arises because many services handle session management and sometimes also authentication, via cookies. This isn't detrimental when cookies are exchanged via encrypted https connections. However, encryption can't be guaranteed, as many sites don't mark important session cookies with the security flags that prevent the browser from reusing the cookies for unencrypted connections. As a result, browsers may send cookies via unencrypted connections, which can be spied on when users simply access a normal page at their mail provider's web site.
The actual attack can be carried out like this: victims use an encrypted wireless connection to log into a service like Google Mail and read their emails – also encrypted. While still logged in, users then access an arbitrary, non-secure web page. An attacker on the same wireless system, injects this page with a reference to an image, allegedly stored at the unencrypted http://mail.google.com site. The browser tries to retrieve the image, sending the Google Mail cookie to the server in the process – unencrypted. The attacker listens in on this exchange and can subsequently use the cookie to open the user's mailbox at Google Mail.
The attack can not only be carried out in wireless lans, but also via ARP spoofing, for example in corporate networks, or by poisoning the DNS cache of basically any network. Successful targets are those who use services which authenticate via cookies and whose server does not set the secure flag. According to Perry, these include Google Mail, as well as Facebook and Amazon. Gauci even claims to have found two banks that are vulnerable.
Unfortunately, users normally don't have access to their cookies' security settings. Google, however, recently introduced the option to always use a secure connection for accessing Google Mail. As it happens, this option also causes the server to set the secure flag, exclusively restricting the Google Mail session cookie to encrypted connections. The search engine provider unfortunately neglected to document this measure.
http://www.h-online.com/news/Spied-on-d ... n--/111303
Surf Jack
http://code.google.com/p/surfjack/
Nice PDF
http://digitalnomad.suck-o.net/DNR/red/surf_jacking.pdf
DNR
In order to prevent misuse it is always advisable to use encrypted connections for sensitive activities, like online banking, or reading emails at services like Google Mail. However, in certain circumstances, attackers may still gain access to bank or email account data, despite the encryption.
The technique used is a special form of cookie theft. Although it was already discussed a year ago, it has only now received the attention it deserves – the main reason being that a tool has now become available which allows actual attacks to be carried out.
The problem arises because many services handle session management and sometimes also authentication, via cookies. This isn't detrimental when cookies are exchanged via encrypted https connections. However, encryption can't be guaranteed, as many sites don't mark important session cookies with the security flags that prevent the browser from reusing the cookies for unencrypted connections. As a result, browsers may send cookies via unencrypted connections, which can be spied on when users simply access a normal page at their mail provider's web site.
The actual attack can be carried out like this: victims use an encrypted wireless connection to log into a service like Google Mail and read their emails – also encrypted. While still logged in, users then access an arbitrary, non-secure web page. An attacker on the same wireless system, injects this page with a reference to an image, allegedly stored at the unencrypted http://mail.google.com site. The browser tries to retrieve the image, sending the Google Mail cookie to the server in the process – unencrypted. The attacker listens in on this exchange and can subsequently use the cookie to open the user's mailbox at Google Mail.
The attack can not only be carried out in wireless lans, but also via ARP spoofing, for example in corporate networks, or by poisoning the DNS cache of basically any network. Successful targets are those who use services which authenticate via cookies and whose server does not set the secure flag. According to Perry, these include Google Mail, as well as Facebook and Amazon. Gauci even claims to have found two banks that are vulnerable.
Unfortunately, users normally don't have access to their cookies' security settings. Google, however, recently introduced the option to always use a secure connection for accessing Google Mail. As it happens, this option also causes the server to set the secure flag, exclusively restricting the Google Mail session cookie to encrypted connections. The search engine provider unfortunately neglected to document this measure.
http://www.h-online.com/news/Spied-on-d ... n--/111303
Surf Jack
http://code.google.com/p/surfjack/
Nice PDF
http://digitalnomad.suck-o.net/DNR/red/surf_jacking.pdf
DNR
-
He gives wisdom to the wise and knowledge to the discerning. He reveals deep and hidden things; he knows what lies in Darkness, and Light dwells with him.
He gives wisdom to the wise and knowledge to the discerning. He reveals deep and hidden things; he knows what lies in Darkness, and Light dwells with him.