Security Assertion Markup Language (SAML) is a method for exchanging authentication and authorization between trusted parties. It’s essentially an XML schema that allows for federated Single Sign-On (SSO) to work.
Any illicit party can gain access to the system if the SSO gets compromised; hence, Single Sign-On represents a significant attack vector for the adversaries. In this blog, we will discuss major SAML attacks and how to detect or prevent them.
How SAML Work?
Before discussing SAML attacks we will first have a look at the legitimate SAML authentication process. The process usually involves three steps.
- A user attempts to access an application – the Service Provider (SP)
- The Service Provider (SP) sends a SAML authentication request to the Identity Provider (IdP)
- The identity provider (IdP) sends a signed assertion back to the Service Provider (SP) once successfully authenticated and authorized, whilst identifying the user and allowing the SP to log them in.
SAML Replay Attack
In a replay attack, the attacker steals the assertion from a legitimate user and then sends it to the SP as shown below. With the help of this, an attacker can authenticate with the SP at any time if the expiration is not set by the IdP. Also, the attacker might authenticate with a different SP that uses the same IdP.
Prevention of SAML Replay Attack:
- SP should keep a list of IDs of accepted assertions, for the lifetime of the assertion to prevent replay attacks.
- Use TLS secured connection between IdP and SP communication to prevent Man-In-The-Middle attacks.
Golden SAML Attack
The Golden SAML attack technique enables attackers to forge SAML responses and bypass ADFS authentication to access federated services. Golden SAML was one of the major techniques used by the threat actor as part of the SolarWinds attack by compromising the SAML signing certificate using their Active Directory privileges. An attacker must first gain administrative access to the ADFS server and extract the necessary certificate and private key to successfully leverage Golden SAML.
Through additional lateral movement and privilege escalation, the attacker will proceed according to the following steps.
- The attacker first accesses the ADFS server and extracts the private key and certificate.
- User attempts to access desired service (e.g., Office 365).
- The SP redirects the attacker to ADFS for authentication.
- Bypassing ADFS authentication, the attacker signs a forged SAML response with a stolen key.
- The attacker presents desired service with a signed SAML response and receives access.
Detecting Golden SAML Attack
Correlating SP login events with corresponding authentication events in ADFS and Domain Controllers
To detect Golden SAML authentications, search for any logins to service providers using SAML SSO, which do not have corresponding Event ID 4769, 1200, and 1202 events in the Domain. This strikes at the core difference between a legitimate SAML authentication and a Golden SAML attack.
Identifying certificate export events in ADFS
A Golden SAML attack requires the private key and certificate of the ADFS. Access to these can be obtained by exporting the certificate from the ADFS server. Check for the Event ID 1007 (enabled by default) in the Windows Event log.
Mitigation Techniques for SAML Attacks
- For containing the impact of a previously forged SAML token, rotate the token-signing AD FS certificate in rapid succession twice, which will invalidate any tokens generated using the previous certificate. (MITRE ID: M1015)
- Enable advanced auditing on ADFS. Check the success and failure audit options in the ADFS Management snap-in. Enable Audit Application Generated events on the ADFS farm via Group Policy Object. (MITRE ID: M1047)
- Restrict permissions and access to the ADFS server to only originate from privileged access workstations. (MITRE ID: M1026)
- Ensure that user accounts with administrative rights follow best practices, including the use of privileged access workstations. (MITRE ID: M1018)