Decoding the Okta Hack, Part 2: PAM’s Overlooked Role in Cyber Defense

Welcome back to Part 2 of our in-depth exploration into session hijacking, a critical security concern brought into sharp focus by the sophisticated Okta breach in October 2023. In our previous post, we dissected the dynamics of the Okta incident, revealing how session hijacking played a pivotal role in the breach’s execution. Building on that foundation, this blog post will delve into the technical intricacies of session hijacking attacks. We’ll examine the methods attackers use to compromise session tokens and gain unauthorized access, and discuss strategies to fortify against such vulnerabilities in your application’s design.

Introduction to session management

Session management is a critical component in the architecture of web applications, facilitating user-state management over stateless HTTP transactions. A session in web terms is a series of HTTP requests and responses that create a stateful interaction between a client and a server, despite HTTP’s inherent stateless design. Each session is identified and tracked through unique session identifiers (session IDs), ensuring that requests are part of a continuous user interaction sequence, rather than isolated events.

HTTP stateless nature poses a challenge in maintaining a stateful interaction over a series of stateless requests and responses which is solved by server-side or client-side session management. It essentially binds a series of stateless HTTP transactions into a cohesive user session, enabling functionalities like user authentication, shopping cart management in e-commerce, and personalized user experiences.

The primary mechanisms in session management include, among the others:

1. Cookies: The most prevalent method, where session data is stored in a small file on the user’s device.
2. URL Rewriting: This involves appending the session ID to the URL. While it’s a useful alternative when cookies are disabled, it has its drawbacks, such as the potential exposure of session IDs in server logs or browser history.
3. Hidden Form Fields: This method involves sending the session ID as part of a hidden field in HTML forms. This approach, however, is limited to requests sent via forms and does not cover every interaction within a session.
4. Token-based Authentication: In modern web applications, particularly those following RESTful principles, token-based systems like JSON Web Tokens (JWT) are increasingly popular. These tokens are typically sent in the HTTP header.
5. Secure Storage in Client-Side Scripting: Some applications use client-side scripts (like JavaScript) to store session information securely. However, this method requires careful implementation to avoid security vulnerabilities.
6. Server-Side Session Management: The session data is stored on the server, and only a unique session identifier is sent to the client. This method can be more secure, as sensitive data does not leave the server, but it requires server resources for session data storage.

Each method has its advantages and drawbacks, and the choice depends on the specific requirements and security considerations of the web application. In practice, a combination of these methods might be used to balance usability, performance, and security.

Understanding session management mechanisms is essential for identifying and mitigating vulnerabilities. For example, as shown in our previous post about the Okta hack, session hijacking exploits the session management system by unlawfully obtaining or manipulating session IDs to gain unauthorized access to users or services sessions. Thus, a robust understanding of session management is not only crucial for building secure web applications but also for diagnosing and preventing security breaches within these systems.

In the remainder of this article we are going to delve deeper into the specific topic of session hijacking, examining its mechanisms, risks, and the strategies to mitigate such vulnerabilities in web applications.

Session Hijacking

As shown in Figure 1, session hijacking is essentially an unauthorized entity gaining access to a user’s session, often by commandeering the user’s session ID or cookies. This form of cyber intrusion allows the attacker to masquerade as the victim and assume control as if they were the rightful user.

Fig 1: overall scheme of a generic session hijack attack

The significant leverage for the attacker stems from the fact that they bypass the need to access confidential data directly since the victim’s session is already authenticated. There are three primary forms of session hijacking attacks: active, passive, and a combination known as hybrid. These attacks target session management systems to circumvent the usual authorization and authentication checks, posing a substantial threat to the integrity of online/remote assets such as sensitive data.

In the flowchart presented in Figure 2, R. Badlishah Ahmad et al. offer a comprehensive view of session hijacking in their 2018 paper titled “A Preliminary Review on Web Session Hijacking.” This diagram categorically breaks down the types of session hijacking — active, passive, and hybrid — while also identifying the levels at which these attacks transpire, such as network (TCP/UDP) and application (HTTP). Further, it delineates various techniques utilized in these attacks, including IP spoofing, blind hijacking, and MITM strategies, providing insights into the complexities of safeguarding digital sessions.

Fig 2: comprehensive view of session hijacking

The flowchart presents a structured classification of session hijacking attacks, encompassing the nature, target level, and methodologies of the attack.

The first classification is about the type of attack which could be:

• Active: Attacks like the 2014 eBay breach illustrate active session hijacking, where attackers infiltrated the network to manipulate user sessions.
• Passive: In this type, the attacker hijacks a session but remains silent, simply monitoring and recording the traffic flowing between the user and the web service. This allows the attacker to glean sensitive information, such as passwords and source code, without actively interfering with the session. Examples of this approach, as described by an article from Norton could be session sniffing in unsecured locations or tricking users into clicking malicious links that embed the attacker’s session key, leading to unauthorized account access or fraudulent transactions.
• Hybrid: a combination of passive and active.

Then we move to the “level” branch that categorizes session hijacking attacks based on where they occur within the network stack:

• Network Level: This refers to session hijacking that occurs at the transport or network layers. Here, TCP and UDP protocols are exploited using methods like IP Spoofing, Blind Hijack, or Man-in-the-Middle (MITM) attacks. These techniques manipulate the data transmission between two parties, allowing the hijacker to intercept or reroute packets. A real example of a session hijacking attack that occurred at the network level involved a malware called FlyTrap, which compromised thousands of Facebook accounts since March 2021. This malware, classified as an Android Trojan, spread across approximately 10,000 victims. It was capable of collecting a variety of data from the victims, including Facebook IDs, locations, email addresses, IP addresses, and cookies and tokens associated with Facebook accounts. The hijacked sessions were then used to spread further malware and disinformation, leveraging the victims’ social credibility.
• Application Level: This focuses on attacks that happen at the application layer, such as HTTP Session Hijacking. Attackers at this level might use methods to obtain session IDs, observe session traffic for vulnerabilities, or perform brute force attacks to guess session tokens. These tactics directly target the user’s session with the application itself, rather than the underlying transport protocols. An interesting talk given at black hat 2021 by James Kettle and titled “HTTP/2: The Sequel is Always Worse” during which it has been demonstrated how HTTP/2 vulnerabilities enable desync attacks on major websites, leading to client hijacking, cache poisoning, and password theft, surpassing the attack methods existed by that time.

The Execution Flow of Session Hijacking

Despite demonstrating that session hijacking can occur both at the network (TCP) and application (HTTP) levels, and acknowledging that HTTP security is bolstered through encryption with HTTPS, it remains evident that HTTPS is the more prevalent target for session hijacking attacks. This is due to the widespread use of web applications and inherent vulnerabilities at the application layer. Consequently, in the remainder of this section, we will focus on detailing the execution flow of a session hijack specifically within the context of a web application, reflecting its prominence as an attack vector.

Figure 3, published by Anand V. for knowledgehut, displays a flowchart with seven steps describing the process of a session hijacking attack on a web application:

Fig 3: Session Hijacking Workflow

Session hijacking might appear to be a singular, straightforward attack, yet in practice, it is typically neither isolated nor simple. Often, it’s part of a broader assault on networks or systems, preceded and followed by a variety of other attack types. This is reflected in the relationships outlined within the common attack pattern enumeration and classification (CAPEC) ID 593 and summarized in figure 4 where each attack is characterized by its potential to either set the stage for a session hijack or to extend its impact further. These interconnected exploits showcase a complex attack ecosystem where session hijacking is just one element in a chain of security threats, emphasizing the need for comprehensive and proactive defense strategies in network and system security.

Fig 4: session hijacking execution flow and relationships with other linked attacks

Figure 4 categorizes various web security attack vectors by their relationship to session hijacking, labeled with their nature. “ChildOf” indicates an attack that session hijacking may lead to, in this case, Exploitation of Trusted Identifiers. “ParentOf” denotes attacks that can precede session hijacking, which include reusing session IDs (also referred to as session replay), session fixation, session sidejacking and cross site tracing. “CanFollow” refers to attacks that could occur after a session hijacking. These are HTTP request/response smuggling, HTTP response splitting and HTTP request splitting.

As regards the attacks that can precede session hijacking we have, among the others:

• Session Replay: Session replay as a follow-up to session hijacking represents a strategic maneuver where an attacker reuses a captured session token or identifier to mimic a user’s actions within a session. Once a session is hijacked and the session token is in the attacker’s possession, they can use session replay to execute actions as if they were the legitimate user. This approach is particularly effective for maintaining unauthorized access over a period, as it allows the attacker to continuously mimic the user’s behavior or perform new actions within the hijacked session. It can be used to bypass periodic authentication checks or to execute transactions, modify settings, or access sensitive data without raising immediate suspicion. Session replay in this context amplifies the impact of the initial session hijacking, extending the attacker’s ability to exploit the compromised session more extensively and over a longer duration. It underscores the need for robust session management and monitoring systems that can detect and respond to anomalies in user behavior, thereby mitigating the risks of prolonged unauthorized access.
• Session Fixation: a session hijacking strategy where the attacker imposes a predetermined session ID on the user, which they can later exploit to take over the session. In this attack, the victim is lured into initiating a session with an ID that the hacker has already set, often through a malicious link. Unlike other hijacking methods that involve intercepting or deducing a valid session ID, session fixation cunningly establishes the session ID in advance of the user’s login, and then the attacker seizes control post-authentication. Attackers employ session fixation to circumvent authentication processes and access the user’s account or confidential data.
• Session Sidejacking: another method for executing session hijacking that intercepts the exchange between a user’s browser and the server to capture session cookies. Specifically, session sidejacking takes advantage of unsecured Wi-Fi networks to pilfer session cookies. If a user accesses a site on such a network, the attacker can snatch the user’s communication with the site and acquire the session cookies, which enables them to take over the user’s session and access their account or confidential data.
• Cross Site Tracing/Scripting: In the context of session hijacking, Cross-Site Scripting (XSS) and Cross-Site Tracing (XST) present different avenues of attack. XSS involves embedding malicious scripts into web pages, which are then executed in the browsers of unsuspecting users. This can lead to the unauthorized capture of session cookies or tokens, thereby enabling attackers to hijack user sessions and perform actions on their behalf. It’s an indirect method, relying on users interacting with compromised web content. In contrast, XST targets the HTTP TRACE method on servers to exploit session hijacking. By using this method, attackers can retrieve entire HTTP requests, including headers that contain sensitive session cookies. This enables them to bypass certain security measures applied to cookies, such as HTTP-only flags, and gain unauthorized access to user sessions. While XST is more dependent on specific server configurations, it offers a more direct approach to hijacking sessions by capturing essential session data. Both XSS and XST, despite their different approaches, ultimately facilitate session hijacking by enabling attackers to access and manipulate session tokens or cookies, albeit through different mechanisms within the web application architecture. In a sophisticated attack scenario, Cross-Site Tracing (XST) might be employed after a successful session hijacking to deepen access. XST can bypass additional security measures not compromised initially, gather more comprehensive server or session data, and ensure prolonged, discreet access, especially if the initial hijack method risks detection or the session token changes. This strategy represents an advanced, layered approach to extending infiltration within a system.

On the other hand, when it comes to attacks that could occur after a session hijacking, figure 4 lists the main used one which are as follow:

• HTTP Request/Response smuggling: following a session hijack, HTTP request smuggling and HTTP response smuggling are advanced techniques that allow attackers to further manipulate server communication. HTTP request smuggling works by confusing the server about where one request ends and another begins, enabling the injection of malicious requests into the data stream. This can lead to unauthorized activities performed under the guise of the hijacked session. HTTP response smuggling operates on a similar principle but affects how responses are returned to the client, potentially leading to the delivery of malicious content or sensitive information leaks. Both methods exploit the established trust of a hijacked session, thereby enhancing the attacker’s ability to covertly perform malicious actions or subvert web application security mechanisms.
  HTTP request and response smuggling are real and potent threats to web security, as evidenced by a notable incident reported by Akamai. The company documented an attack exploiting HTTP/2 request smuggling vulnerabilities, underscoring the practical risks associated with these techniques. The Akamai incident serves as a stark reminder of the sophistication of modern cyber-attacks and the importance of securing web infrastructure against such vulnerabilities.
• HTTP Request/Response Splitting: it is another cyber attack technique that could follow a session hijack, where the attacker manipulates the end of one HTTP request and the beginning of another, effectively splitting the HTTP communication into two separate requests. This method confuses the target web server or proxy about the sequence and content of requests. In the aftermath of a session hijack, an attacker who already has control over a session could use HTTP request splitting to inject arbitrary HTTP headers or even entire requests into the server’s data stream. This could lead to a range of malicious outcomes, including cache poisoning, cross-user defacement, or the unauthorized execution of actions on behalf of the compromised user. It is a sophisticated form of attack that leverages the established session hijack to further manipulate server-side actions and can lead to significant security breaches if not properly mitigated. During the latest Offzone conference, Sergey Bobrov from Kaspersky presented insights into the power of HTTP request splitting as a hacking technique. His presentation focuses on an nginx real example and shows that despite advancements in web security, this method remains a formidable tool for cyber attackers. The technical sophistication of HTTP request splitting allows for the manipulation of web server processing, creating vulnerabilities that can be exploited to compromise web applications and user data. This reinforces the necessity for ongoing vigilance and up-to-date security practices to protect against such enduring threats.
  Similar to request splitting, HTTP response splitting is another technique where an attacker crafts input to include header-specific control characters (like carriage return or line feed). If the application fails to sanitize this input, it can lead to the splitting of HTTP responses. When used as a follow-up to session hijacking, response splitting can magnify the attack’s impact by altering subsequent responses from the server. This can lead to additional exploits such as cache poisoning, cross-site scripting (XSS), and page hijacking. The ability to forge arbitrary HTTP responses makes it a critical concern following the compromise of a session.

Potential Consequences

The potential consequences of session hijacking are significant and can lead to major security breaches. Following our first blog post and the initial report from Okta Security, a new thorough review and re-examination of the threat actor’s activities has been conducted which included recreating and analyzing reports and files accessed by the attacker.

This led, on November 29th 2023, to a new announcement from Okta that revealed how names and email addresses of all users in their customer support system have been leaked. This affected all Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers, except those in separate support systems like FedRamp High and DoD IL4 environments. The report accessed by the threat actor included fields like user’s full name, username, email, company name, user type, address, date of last password change or reset, role name and description, and contact details.

Okta has raised concerns about the potential misuse of this information for phishing or social engineering attacks, especially since many users of the support system are Okta administrators who access it using their Okta accounts. Given the significant role of these administrators, the risk of targeted attacks is heightened.

In response, Okta has stressed the importance of multi-factor authentication (MFA) for all users, particularly administrators, to protect against similar security breaches. With 94% of their customers already mandating MFA for administrators, Okta recommends all customers to implement MFA and consider phishing-resistant authenticators for enhanced security. The incident serves as a critical reminder of the importance of robust security measures in protecting against sophisticated cyber-attacks like session hijacking.

Mitigation and Detection Strategies

Building a strong defense against session hijacking requires integrating technical strategies with advanced security measures. Starting with the basics, disabling unnecessary remote services like SSH and RDP whenever possible, as suggested by MITRE ATT&CK, helps reduce the attack surface. This is complemented by network segmentation, where firewall rules create secure zones, limiting potential breaches and unauthorized lateral movements within the network.

Additionally, the management of privileged accounts, crucial to this strategy, involves not just regulating remote access but also adhering to the least privilege principle. Here, the implementation of Multi-Factor Authentication (MFA) is key, especially using phishing-resistant methods as emphasized by Okta following their security incident. Okta’s additional security features like Admin Session Binding, demanding reauthentication from new IP addresses, and Admin Session Timeout settings aligned with NIST guidelines, further reinforce the security posture.

On the detection front, vigilant monitoring is essential. This includes tracking command executions and logon sessions for anomalies indicative of session hijacking efforts, such as session fixation, sidejacking, or replay attacks. Network traffic analysis, particularly with SSL/TLS inspection, plays a pivotal role in identifying covert activities, bolstered by process and command line monitoring for new or unusual operations. This level of scrutiny is vital to address the complexities of various attack vectors and extend to authentication processes, ensuring no unexpected session tokens or cookie manipulations go unnoticed.

Conclusion

In this new article we have thoroughly examined the workings of session hijacking, highlighting the various types that hackers might use. We also discussed the significance of the recent Okta hack, as disclosed by Okta, emphasizing the urgent need for businesses to protect themselves against such attacks to avoid the detrimental impacts Okta is currently facing. Understanding these threats is crucial for any business looking to safeguard its digital assets and maintain the trust of its users.

So now that we’ve seen the severity of session hijacking, you might wonder: Is Excalibur secure against such threats? Are we adhering to the best practices?

Absolutely, we are!

Excalibur was conceived and developed with security at its core, particularly for secure remote access. Let’s delve into how Excalibur implements and even surpasses these security protocols to ensure robust protection against session hijacking threats.

Excalibur’s security architecture showcases a sophisticated approach that not only aligns with but also significantly enhances the best practices for defending against session hijacking as outlined by MITRE ATT&CK and Okta. Starting with its session lifecycle management, Excalibur goes beyond basic session timeout strategies. The system tracks sessions meticulously, enabling remote operations like Lock and Logout, which can be initiated from various endpoints, ensuring that unauthorized access can be swiftly curtailed. Furthermore, Excalibur’s policy framework elevates the concept of “Admin Session Binding.” Rather than solely relying on IP address changes for re-authentication, it incorporates advanced criteria such as geofencing, client-specific restrictions, and temporal parameters like time of day or week (see figure 5). This multifaceted policy enforcement, which includes additional verification layers involving managerial or administrative oversight, ensures a comprehensive security model that extends far beyond traditional IP-based session binding.

Fig 5: Excalibur advanced authentication and verification criteria

The “Four Eyes Principle” implemented through Excalibur’s “peer verification” system is yet another element that underscores its commitment to robust security practices. Indeed, this principle requires a secondary individual to verify and approve critical actions, thereby adding a substantial layer of security against risks like session hijacking. By mandating that key operations undergo scrutiny by another trusted user, Excalibur greatly amplifies its security beyond the standard least privilege approach, catering effectively to environments where stringent security measures are essential.

Finally, Excalibur’s approach to Privileged Access Management (PAM) session monitoring aligns perfectly with best practices of tracking command executions and logon sessions for anomalies. By allowing managers, administrators, and auditors to observe and attach to user sessions (see figure 6), the system provides an effective platform for the real-time monitoring of user activities. This feature is crucial for detecting unusual or unauthorized actions and forms a critical part of the system’s capabilities in maintaining security and identifying potential security breaches.

Fig 6: Excalibur monitoring dashboard

In conclusion, Excalibur’s comprehensive and technically advanced security features place it at the forefront of solutions against session hijacking, offering enhanced protection that goes beyond the standard recommendations.