What goes through your mind when one of the largest companies in the world declares a security breach? In 2014, Yahoo’s CIO (Chief Information Security Officer), Bob Lord, read the following published statement: “...we believe an unauthorized third party, in August 2013, stole data associated with more than one billion user accounts and we have not been able to identify the intrusion associated with this theft.”
If Yahoo has suffered a security breach despite their resources, aren’t the rest of us at serious risk too? Considering the method (of forging cookies) these attackers used, how can other companies avoid this from happening to them?
What is cookie forgery?
An online cookie is when a website automatically logs you into a website that you frequent. This saves users loads of time typing in their passwords and simply logs them in automatically. Cookie forging entails faking an authentication without actually having one. By doing this, Yahoo’s attackers gained access to targeted accounts and were even able to remain logged in for longer periods of time—up to weeks or even months.
This was an ingenious technique used to hack Yahoo’s users. Cookie forgery is something that has many different aspects to it; so let’s learn more about it and how it can be prevented.
A website cookie is a small piece of data sent from a website that you visit and placed onto your computer. This small piece of data reminds the website that you visited the site and that your session ID is one that has accessed it before.
What is the significance of the session token / identifier?
A session identifier is a temporary, server-controlled code for the session duration of the user. It’s up to you as the user when the session starts, and when it stops. There are two security characteristics that form part of a session identifier:
- They are always unique, since no two sessions can have the same identifier
- Session identifier codes cannot be ‘guessed’ or ‘hit’ when trying random ones
Considering the above, cookie forgery is the method of hacking into a system and deciphering the cookie generation process. If hackers are successful in this, they can impersonate legitimate users and gain valuable information.
Disturbingly, cookie forgery is on the rise—especially against systems where applications build and maintain a custom logic to generate and maintain session tokens and pass them via cookies. Some blogs have reported two examples of these instances:
- If there is a flaw in the cookie formation and cryptography application, a hacker can craft, guess or create a valid cookie that impersonates a legitimate user
- If there is a flaw in the comparison logic of the server, a hacker can trick the server’s comparison logic into accepting invalid cookies as valid ones
If there is a flaw in the comparison logic of the server, a hacker can trick the server’s comparison logic into accepting invalid cookies as valid ones
Flaw in the cookie formation and cryptography application
A normal process of user credentials being validated starts with the user being authenticated and the response of that authentication being sent back to the client for the purpose of creating a session ID cookie. The structure thereof looks like this:
This can be broken down as follows:
- COOKIEHASH : MD5 hash of the site URL (to maintain cookie uniqueness)
- USERNAME : The username for the authenticated user
- EXPIRY_TIME : When the cookie should expire, in seconds since the start of the epoch
- MAC : HMAC-MD5 (USERNAME. EXPIRY_TIME) under a key derived from a secret and USERNAME. EXPIRY_TIME.
The complicated process of authentication is carried out each time your browser makes a request to WordPress, and the software then verifies the cookie to make sure you are who you say you are. So how can an attacker impersonate other users and bypass the authentication mechanism shown above?
Example: A website already has a registered user names “john”. The hacker’s objective is to impersonate john and use his account details. To achieve his objective, he registers a new user account and selects the username “john0”. When the hacker logs in to the application, he gets back an authentication cookie that looks something like this:
This logic causes the hacker to impersonate other users. Now that we know the expected value of HMAC_FUNCTION for the string "john01209331305", it now becomes a valid value. The comparison with $HMAC would result in the user being authenticated, and session would be set for the user under the new $username ( john0).
The hacker can now remove the 0 from the end of the username and attach it to the expiration time, keeping the HMAC value the same:
This action will cause the HMAC function to return a valid string that would be equal to the value of HMAC, thus yielding the comparison true. Furthermore, the value of the variable USERNAME would be fetched and the session would be set for that user. In this case the value inside USERNAME is “john”, and so the details of “john” would be fetched. The hacker was able to impersonate “john” with the credentials of a different user, “john0”
How can this be prevented?
The fix is to use a delimiter to ensure there is no ambiguity between the username and the expiration when calculating the HMAC. So when the hacker logs in as the “john0” user, his cookie looks like this:
The $key generated in this case will now have a proper separation between the username and the expiration, preventing the system from being fooled.
Next time, we’ll look at what happens when there is a flaw in the comparison logic of the server, and how to prevent a hacker from tricking the server’s comparison logic into accepting invalid cookies.