Cookie Hijacking Leads to Massive Disney Slack Compromise

Disney is the latest in a growing list of corporate hacking victims. Messages from 10,000 Company Slack channels have been downloaded and made public by an apparent ‘hacktivist’ called Nullbulge. This group (or individual, no one can be sure) claims to conduct attacks against people and organizations who they think have breached their list of ethical rules, and in Disney’s case, they say they are unhappy about the company’s use of AI to potentially take business from working artists.

As yet, only partial details have emerged about what methods the group used to steal 1.1TB of employee messages, code, images, and unreleased projects, but we wouldn’t be surprised if cookie hijacking was involved in some way. Cookie hijacking was the method attackers used in the hack of gaming giant EA in 2021. In that case, they bought stolen cookies for $10 on an underground forum, used them to slide into its Slack account, and from there managed to download 750GB of data, which it put on sale for $28 million. Although profit doesn’t seem to be the motive in this latest Disney case, the fact that both attacks involve Slack makes us wonder whether cookie hijacking may be involved somewhere in the mix this time as well.

What is Cookie Hijacking?

Let’s start with a definition of session cookies. These are small text files that are used to store information about a user’s browsing session. They identify the current user and keep track of their activities on a website, noting things such as what items they have in their shopping cart, their login status, and preferences. They make life more convenient for users because they can remember whether they are logged into a website, so they don’t have to constantly re-authenticate. When a user logs into a website, the server generates a unique session ID and stores it in a cookie on the user’s browser. This cookie is sent back to the server with each subsequent request, allowing it to identify the user and maintain their logged-in state.

Here’s that process broken down:

As long as the session cookie is present and valid, the user will remain logged in without having to re-enter their credentials. This provides a seamless and convenient experience for the user, but it also provides the perfect alias for cybercriminals. Once they have stolen a session cookie, they can impersonate the user from a different device, using their access privileges to spy on everything that they do. They could even change their passwords and lock them out entirely.

Anatomy of a Cookie Hijacking Attack

With cookie hijacking, also known as session hijacking, the attacker gains unauthorized access to a user’s active web session by stealing or intercepting their session cookies. To do this they might intercept it as it’s being transmitted between the user’s browser and the website, or another approach is to exploit vulnerabilities in the website or in the user’s device to gain access to it.

Some attackers will try social engineering techniques, perhaps a phishing attack to trick the user into providing the cookie. They may even try impersonating the user. In the case of the EA attack, they phoned up IT staff and claimed to have lost their phone at a party. The IT staff promptly issued them with a multi-factor authentication token that allowed them into the corporate network. From there they used the stolen cookie to access Slack.

Here are some of the ways that attackers steal those cookies:

Packet Sniffing

They can monitor unencrypted network traffic to capture session cookies being transmitted between a user’s computer and a web server. This allows them to obtain the session cookie and potentially impersonate the user.

If you want to find an unencrypted network, then just log into your local café’s Wi-Fi! Public Wi-Fi is very convenient, but also very exposed. In 2010 a developer called Eric Butler released a Firefox extension called Firesheep to demonstrate how easy it was to capture users’ session cookies when they access websites that encrypt the login process but not the cookies created during the login process.

Cross-Site Scripting (XSS)

In this case, the attacker exploits the lack of an HTTPOnly flag by injecting malicious JavaScript that runs in the user’s browser. Such scripts can steal session cookies and send them to the attacker’s server. This is why it’s best practice to always set cookies to HTTPOnly.

Man-in-the-Middle Attacks

When HTTP is used instead of HTTPS, data is left unencrypted and vulnerable. The attacker takes advantage by positioning themselves between the user and the web server to intercept the user’s cookies during transmission, which allows them to steal their session cookies.

Social Engineering

The attacker tricks the user into revealing their session cookies through phishing or other deceptive techniques, such as by convincing the user to enter their credentials on a fake website. These websites usually have a name that’s similar to the genuine one, like ‘Facebok’ instead of Facebook for example. The user misses the slight difference, and types in their credentials, and the attacker can then use them to log into the genuine website. When this happens, the web server will send a genuine session cookie to the attacker’s browser, and they are in. They are then free to change their password, or even set up two-factor authentication to lock the genuine user out of any accounts they were logged into during the session.

Physical Access

An attacker with direct access to a user’s device may be able to retrieve session cookies from the browser’s cache or by using malware installed on the device.

Session Fixation

This method exploits the improper handling of session identifiers. It forces a user to use a known session ID, which the attacker can use to hijack the session after the user logs in. It’s a good idea to regularly rotate and invalidate session IDs to minimize the risk of session fixation.

Cookie Tossing

This approach exploits cookie handling inconsistencies between browsers and servers. It involves sending a specially crafted cookie that gets accepted by the server, potentially leading to session hijacking.

Weak Encryption Algorithms

All algorithms are not created equal! Outdated or weak encryption algorithms can be broken, and the attacker will be tempted to take advantage of this, especially if the encryption keys are short or poorly managed. Always use modern, strong encryption algorithms for cookie data to prevent the breaking of encryption.

Cookie Hijacking: The Process

Using one or more of the above methods, the attacker typically follows these steps:

1. Identify a target website or web application and select an appropriate method to capture the user’s session cookies.

2. Obtain the user’s session cookie using the chosen method.

3. Impersonate the user by sending requests to the web server with the stolen session cookie, tricking the server into believing the attacker is the legitimate user.

4. Use the stolen session cookie to access the user’s account, view sensitive information, or perform actions on the user’s behalf without their knowledge or consent.

Once the attacker has the session cookie, they can use it to impersonate the legitimate user and gain access to their active session on the website. They can then perform actions as if they were that user because they have effectively stolen the victim’s online identity, so now they have all their privileges, which could let them access sensitive personal and financial information, modify settings, change linked accounts, and more.

Bypassing 2FA

You may be wondering why cookies are still being stolen when more people than ever are aware of the need to use two-factor authentication. It’s touted as best practice, and it looks impregnable. After all, someone using your credentials to log into a website is not going to be able to confirm your identity if they can’t see the one-time code that was just sent to your phone by SMS, right?

Well, maybe they don’t have to. If they first steal your session cookie, for example, by using a packet sniffing or man-in-the-middle attack, when you subsequently attempt to access the web application and this triggers the 2FA prompt, the attacker can use the stolen session cookie to piggyback on your authenticated session. Since they’ve stolen the valid session cookie, they can make requests to the web application and bypass the 2FA challenge entirely. The web server will continue to authenticate their requests based on the stolen session cookie, without requiring the 2FA code. The key vulnerability here is that 2FA typically adds an extra layer of security at the login stage, but it doesn’t necessarily invalidate or protect the session cookie once the attacker has obtained it.

Best Practices: How to Avoid Cookie Hijacking

Despite the vulnerabilities of two-factor authentication, you shouldn’t abandon it. It only becomes vulnerable if the attacker has managed to steal your session cookies using one of the listed attacks, and you can defend against these using a combination of vigilance, best practices, and web threat management platform like Reflectiz. Here are some practical steps to take:

Always use secure HTTPS connections to encrypt the transmission of cookies (The ‘S’ stands for secure!) One of the weak spots revealed in the EA hack was that 15 of its sites served login pages over HTTP rather than HTTPS, which is asking for trouble. Mark cookies as “Secure” to ensure they are only transmitted over HTTPS connections, and “HttpOnly” to prevent them from being accessed by client-side scripts. As we mentioned, this helps mitigate cross-site scripting (XSS) attacks.
Enforce the use of Transport Layer Security (TLS) and Secure Socket Layers (SSL) to ensure that cookies are encrypted in transit between a user’s browser and a web server. This prevents eavesdropping by third parties.
Implement session timeouts and session invalidation mechanisms. Set a reasonable session timeout, after which the session cookie is no longer valid.
Invalidate the session cookie on the server side when the user logs out or after a period of inactivity.
Educate users on the importance of protecting their session cookies and login credentials. They should never share passwords on Slack or any other channel. An encrypted password manager is a better bet.
Decommission all your unused subdomains, or at least keep their certificates up to date to protect their networks.
Delete your cookies regularly.
Always use a VPN. A virtual private network encrypts the entire connection when you’re online. It secures traffic and protects sensitive data.
Use Session Tokens Instead of Session IDs. Instead of using a simple session ID, use a cryptographically secure session token that is more resistant to guessing or brute-force attacks.
Implement 2FA for all sensitive actions and not just logins. In combination with other measures, this can still be a safe and effective protection against session hijacking.
Use multifactor session binding. Bind the session cookie to other elements of the user’s context, such as IP address, device fingerprint, or location. This makes it more difficult for an attacker to reuse a stolen session cookie from a different device or location.
Implement session rotation. This means generating a new session cookie and invalidating the old one after certain events, such as a login, logout, or user activity. This reduces the window of opportunity for an attacker to exploit a stolen session cookie.
Use a Content Security Policy (CSP) to define trusted sources of content, prevent cross-site scripting (XSS) attacks, and so ensure that attackers can’t steal cookies.

Properly Configuring Session Timeouts and Invalidation

We mentioned session timeouts and invalidation, but they deserve a more in-depth look. Before diving into configuring them, let’s clarify the terms:

A session timeout is the duration of inactivity after which a user’s session is automatically terminated. The session cookie becomes invalid, and the user is logged out.

Session invalidation is the immediate termination of a user’s session, regardless of inactivity. This might happen due to explicit user logout, security breaches, or other critical events.

Factors Affecting Session Timeout Configuration

Sessions should be timed out as appropriate, according to different factors:

Highly sensitive data requires shorter timeouts to minimize exposure.
Consider how long users typically remain active on the site and set timeouts at a slightly longer duration than this.
Various regulatory requirements: some industries have specific guidelines for session duration.
Security posture: shorter timeouts increase security but may adversely affect user experience.

Best Practices for Session Timeout Configuration

Set a reasonable timeout that balances security with user convenience. Typically, 20-30 minutes is a common starting point, but you can adjust this based on your specific requirements.

Use progressive timeouts, i.e., implement a warning system let’s users know that the session will be expiring soon. This gives them a chance to save their work and extend the session.

You could also consider the amount of user activity. Some systems will look at user interactions, as measured by mouse movements or keystrokes, use these as a basis for extending sessions.

Session Invalidation

You can ensure that the session is terminated immediately when a user logs out, invalidate sessions and enforce a logout after a user changes their password, and do the same in response to detections of suspicious activity that might point to a compromised session.

Technical Implementation

The specific way this is implemented depends on the technology stack you’re using. In general, for server-side configuration, most web application frameworks (like ASP.NET, Java Servlets, PHP) provide mechanisms to set session timeout values. If session data is stored in a database, you can implement invalidation logic by deleting or updating session records, and with regard to cookie management, you should ensure the session cookie is set correctly with appropriate expiration and security attributes (e.g., HttpOnly, Secure).

Additional Considerations

For mobile applications, consider different timeout rules due to varying network conditions and user behavior, and while it’s crucial to maintain security, avoid overly aggressive timeouts that frustrate users. It’s worth thoroughly testing your session management implementation under various conditions to ensure it’s appropriate. Here’s an example configuration:

Example: ASP.NET Configuration

Session.Timeout = 20; // Sets the session timeout to 20 minutes

Use code with caution.

Example: PHP Configuration

PHP

ini_set(‘session.gc_maxlifetime’, 1200); // Sets the session lifetime to 1200 seconds (20 minutes)

Use code with caution.

Remember: Proper session management is a critical component of overall application security. Regularly review and update your configuration based on changing threats and requirements.

The Reflectiz Solution

Our web threat management solution continuously monitors your threat surface, actively defending it against the kind of attacks that cybercriminals use to capture session cookies, such as cross-site scripting and man-in-the-middle. It keeps a close eye on these and other tracking technologies to ensure they aren’t misconfigured or misused and prioritizes alerts to your security teams at the first sign of suspicious events. Sign up with Reflectiz today and significantly reduce your risk of damaging and expensive cookie-hijacking attacks.