Cookie hijacking: Learning through replay attack examples !

Cookie hijacking and Replay attacks !!
The attacker seizes some of the data and replicates it within the intention of misleading the receiver, thereby making him believe it is a legitimate piece of information. In many cases, the captured and replicated data is authenticated, while the attackers are trying to gain access masquerading as the permissible user. 
Let's explore this attack using two real world scenarios.

Replay Attack# 1: 

Ram has a savings bank account with Bank XYZ and has recently got access to Internet Banking. He went to a cyber cafe to access his bank account via bank’s IB portal. He logs in using his credentials, making sure his username and password are not saved on the public PC he’s using. Taking all precautions, after completing the transactions – clearing all cookies, stored passwords and deleting all temp files; he leaves the cyber cafe. 
As soon as Ram leaves the cafe, another person Simon enters and starts using the same machine that Ram had used. He checks the history and finds someone has been trying to access Bank XYZ’s Internet Banking portal. Simon also notices that there are certain details that the URL has in the query parameters. One parameter is JSESSIONID that he’s aware is used to track a user session.
Simon copies the value of JSESSIONID and creating a cookie JSESSIONID with the value; hits the same URL replaying the cookie in the HTTP request.
There he is – successfully logged into Ram’s bank account. 
The attack continues to exploit the vulnerability and the damage is done by the time Ram gets to know about it. 
How did the attacker gain access to customer’s IB account? 
When Ram logged into his IB account, the application created a unique value to track his session and returned JSESSIONID cookie with the unique value. The session was passed back in the next GET request as a query parameter.
The attacker smartly replayed the value as a request cookie and was able to gain access to the customer’s IB account. 
What could have Bank ensured protection from this kind of replay attacks? 
  1. Never expose JSESSIONID or any session/user related information to the end client/browser.
  2. Add a timestamp along with the session info (JSESSIONID) that signifies the time till when the session is valid. This will protect the hacker to replay the session after the timestamp expires/session timeout. The application should clean the session info after the timeout & reject requests that it receives with an invalid session-id.This timestamp can either be part of the JSESSIONID cookie value or a different cookie/header.
  3. A way of protecting the session-id and the timeout period is to wrap the JSESSIONID cookie and the time-stamp cookie/header into a super cookie and encrypt the value. In every request, the super cookie is decrypted and relevant session details extracted to be used by the Application. 
What could have Ram/user could have done to protect the account from replay attack?
A user must always log off from the website/internet banking application using the provided logoff link/button. This will instruct the application server to clear off the user session, making the JSESSIONID invalid. This is a very basic protection that almost all websites in today's web world have. All organization must ensure this protection is provided to the user. 
Is the Internet Banking application secure now?. Let's explore with the help of another real world scenario:

Replay Attack# 2

Previously we saw how JSESSIONID was exposed to the browser and used by a hacker to replay the cookie to gain access to a customer’s account.
So, the bank decides to hide the session-id and encapsulate JSESSIONID along with a timestamp as a header into a super cookie. The value in the super cookie is encrypted so nobody knows what it contains. Does this make the website secure? Is something missing that a hacker can exploit? 
Well well well. Internet Banking website for bank XYZ is still vulnerable to attacks.
How? Let's see. 
Ram as a much aware customer logs on to the Internet Banking website, does all his transactions and logs off from IB. He also clears the cookies and temporary files from the PC he used. He does all that a customer should be doing to keep one's bank account secure.
What he doesn't know is that the public PC he used is infected with a malware. Every request from the browser and every response from the bank's server is intercepted and been send to the hacker. While Ram is busy doing his transactions, the hacker copies the value of the super cookie (that has the session-id and the timeout timestamp) and uses it do replay the funds transfer request that Ram had initiated (this time changing the beneficiary account number to his). As soon the hacker replays the request, the bank's server transfers the funds to hacker's account. 
Not only Ram, there were several PC's that were infected by the malware – transferring small amounts from thousands and lacs of customers everyday. 
The weakness that the hacker exploited!! 
Though the bank XYZ implemented the way of securing the user sessions but this was not enough. The user session is valid for a considerable amount of time ensuring the customer is allowed to think & act in that time period.
Till the time the session is valid (timeout timestamp has not expired), the same super cookie can be used to send multiple requests to the application server (& getting a successful response back).
The hacker exploited the above vulnerability and was able to send a request (as a genuine user) to the Internet Banking application and rest is history!! 
What could Bank have done to protect from this type of replay attacks? 
The nonce is the answer.
In cryptography, a nonce is an arbitrary number that may only be used once. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. They can also be useful as initialization vectors and in cryptographic hash function.
Along with the session-id & timeout timestamp, if we add another header with value as a counter (can be per user or a single counter for all users)- this counter will be unique for each response. The session-id, timeout timestamp & the counter/nonce can then be encapsulated together, encrypted and this encrypted value be used to create a super cookie in the response. This way every value of a super cookie (encrypted) can use only in 1 request/used only once. 
How? For every request, the super cookie value is decrypted and all the 3 values are extracted – 
  1. Session-id: To track the user session
  2. Timeout timestamp: determines the time period till when the session is valid
  3. Counter/Nonce: a unique number that the application checks against the counter against the session-id. Application server increments the counter/nonce once the request is processed. If a request with the same nonce reaches the application, the request would be rejected as the number has already been used.  
This way even if a hacker hijacks the super cookie, he/she will not be able to replay the cookie. Hence, protecting the user's account from replay attacks.


As per CISSP, Timestamps & sequence numbers are two countermeasures to replay attacks (as seen above). The request can contain sequence numbers, so each machine will expect a specific number of each receiving packet. If a request has a sequence number that has been previously used, this is an indication of a replay attack.
Authored By - Raj Bhatia
TCS Enterprise Security and Risk Management
Rate this article: 
No votes yet
Article category: