Thread by @MalwareJake

On today’s #dogWalkingThread, let’s talk about the recently disclosed abuse of SAML by attackers to “bypass” MFA.

For those not familiar with the concept, SAML allows the separation of identity providers (IDP) and service providers (SP). Why the separation? 1/

Suppose you want to access a service, and the service needs to authenticate you, but you really don’t want the service ever having your credentials (EVER). As long as the SP trusts the IDP, this is no problem. You authenticate with the IDP and the IDP tells the SP “trust them” 2/

Let’s consider passports as an analogue. I’ve traveled to many countries I wouldn’t want to have all my identity data, but the State Department serves as my identity provider. Because the country I’m entering trusts the US State Department, the passport is enough. 3/

How does immigration know the passport is legitimate? The anti-forgery tech like watermarks, holograms, etc. ensure it’s legit (forget e-passports for a minute, nuance will break the analogy). So long as these features are present, the passport is trusted to validate identity. 4/

The passport application process is very analogous to multi factor authentication. You must provide a photo, information, and a county certified birth certificate. The State Department trusts the county seals. The birth certificate is the second factor here. 5/

And yet you never provide the birth certificate to immigration. They trust that your IDP (State Department) validated this.

Back to reality, the service provider (SP) constructs a SAML request to the IDP. The IDP validates that you have authenticated successfully. 6/

The SP generally doesn’t care what the IDP has validated - password, palm print, retina scan, or forehead temp. And it doesn’t matter to the SP whether these things were really verified, only that the IDP *says* it did. Now how does the SP know the IDP’s assertion is legit? 7/

The IDP signs the assertion (SAML uses XML) with a private key and the SP has a corresponding public key that validates that trust.

Here’s the rub: the whole system relies on the private key remaining private. If an attacker compromises the IDP and takes the key, game over. 8/

When you hear “ZOMG they bypassed MFA” this is what is meant in this case. The attackers compromised the IDP and took the private key. Now they can sign their own assertions, claiming they completed the MFA challenge without actually doing so. 9/

Back to our passport analogue. Suppose a criminal steals boxes of actual blank passport books and the machine(s) used to create real passports. At this point the attacker can create fake passports. But are they really fake? Only in that they weren’t issued by the State Dept. 10/

From the perspective of foreign immigration, they are legit in every way that matters. Our analogy breaks down when the SP (immigration) calls the State Department (IDP) and asks “did you issue this?” No big deal though, because that’s not how SAML works. 11/

So how do you, the victim, detect this in the real world? You generally need logs from the IDP *and* the SP. Generally speaking, you are looking for resource usage at the SP for which there is no corresponding assertion signed at the IDP. This sounds easy. It is not. 12/

Most intrusion analysis involves looking for something in the logs, but this is looking for something that ISN’T in the logs.

Once the attacker has stolen the signing private key from the IDP, the attacker need not have any persistence on the IDP, in fact that’s a liability. 13/

The whole reason to steal the private key from the IDP to sign your own SAML assertions is to remove the need to retain access to the IDP.

This thread brought to you by best boi Cypher. Not as good tonight, but good enough to get this out. /FIN