This article is part of a series where we look at a recent NSA/CISA Joint Cybersecurity Advisory on the top cybersecurity issues identified during red/blue team exercises operated by these organizations. In this article, you will find a more in-depth look at the specific issue, with real-world scenarios where it is applicable, as well as mitigation strategies that can be adopted to limit or overcome it. This expands on the information provided by the NSA/CISA report.

–

Centralized identity management systems, recommended for reducing authentication risks across multiple platforms, inadvertently create a vulnerability. These systems, which confirm an account’s status and access level, exchange messages often encrypted but not immune to interception. Weak encryption, shared secrets, or vulnerable third-party systems can allow malicious actors to observe and capture authentication messages. They might then “replay” these messages to gain unauthorized privileges.

How Does This Work Exactly?

Centralized Authentication Woes

It is recommended that organizations run centralized identity management systems to reduce the risk associated with having authentication and authorization spread over multiple systems, any one of which thus becoming a liability in case of an incident. However, this centralization of processes leads to a necessary mechanism through which a third party system asks for confirmation of a given account’s status – authorized or not – and access level (ie, the privileges that should be awarded after login).

This mechanism relies on message exchange between the centralized identity management system and the third party system, through a network and usually encrypted. However, due to multiple factors – from weak encryption to shared secrets or improperly protected third-party systems – a malicious actor can observe the authentication process as it happens, and collect the resulting message. In some scenarios, it is then possible to “replay” that resulting message and trick systems into accepting it implicitly, without further checks, and grant unwarranted privileges to the malicious actor or to processes under his or her control.

The Active Directory Example

Active Directory’s Kerberos authentication is a notable case where hash values are exchanged between systems, leading to vulnerabilities. Here, exploits like “Golden Ticket” and “Pass-the-Hash” have become prevalent in cybercriminal arsenals:

• Pass-the-Hash Attack: This technique involves capturing a hash (a fixed-size alphanumeric representation of a password or key) used in the authentication process. Attackers then use this hash to authenticate themselves and gain access to network resources, bypassing the need for the actual password.
• Golden Ticket Attack: This attack targets Kerberos, a network authentication protocol used in Windows environments. Once attackers gain access to a key domain controller, they can create a ‘golden ticket,’ which grants authentication as any user within the domain, often leading to unrestricted access across the network.

So I’m Perfectly Safe When Running Linux?

These types of attacks are not specific to any operating system or platform. They also come in many forms, Kerberos just being one example. If nothing else, the fact that centralized identity management supplied by Active Directory is (or can be) consumed in different ways in Linux systems inevitably exposes those systems to the same problem.

Also, the reverse is also possible: you can find Active Directory stand-ins running on Linux providing ldap connectivity and authentication to Windows-based systems. The risk should not be neglected, regardless of whether you’re running Active Directory on Windows or not.

In fact, this problem isn’t even specific to Active Directory environments either, or even to the internal network and systems. Bypassing System Access Controls can also be achieved, for example, through improperly secured authorization tokens on popular online platforms, such as code hosting, email, and social media services. If a token is created that provides access to a given asset and then that token is stolen, leaked, or accidentally published online, whoever has access to it can obtain the privileges associated with the token without having to re-authenticate with the service, thus bypassing whatever access controls are in place.

Mitigation Strategies: A Comprehensive Approach

Effective defense against access control bypass requires a holistic strategy:

• Enforced Single-Use Privileges: Authentication should be a one-time process for each session. Once a session ends, re-authentication must be mandatory.
• Geo-Location Validation: Unusual login locations should trigger immediate re-authentication, a crucial step in preventing session hijack attacks.
  • A further refinement can even check for the origin client system’s location and ip, rather than the specific user. A change in the usual device from where the connection initiates and a re-authentication should be triggered. 
  • This type of event should be thoroughly monitored for and high risk alerts should be in place when it happens.
• Strong Encryption Standards: Ensure communication between systems using the strongest mutually supported encryption – avoiding default, weaker standards.
• Regular System Updates: Modern systems with updated services can better counteract these attacks, necessitating an ongoing commitment to technological updates.

The post Bypass of System Access Controls appeared first on TuxCare.

*** This is a Security Bloggers Network syndicated blog from TuxCare authored by Joao Correia. Read the original post at: https://tuxcare.com/blog/bypass-of-system-access-controls/