Our goal for you at the end of the talk: Understand how AD FS works, how to attack AD FS and why it is an attractive target for attackers, and how we can keep AD FS safe
So before we can dive into attacking AD FS we need to understand it. Welcome to the whirlwind tour of AD FS
At its most basic AD FS can be defined as…
Lets unpack how this actually works
Before we dive in lets answer an important question – why are we even here? I always find it a good idea to discuss motivations for a talk/research
So let's begin our tour
- the currency of AD FS is claims. Claims are statements that tell us about a user's identiy
- they are going to come from an attribute store, in most cases Active Directory
Claims are acted on by rules which follow a speicfic language
- conditions
- statements
These rules are collected into a pipeline
A very simplified view of our pipeline
- don’t really care about the first inputs
- the last set of rules issuance rules, are what we care about
The output of the issuance rules is the final set of claims that makes its way into the security token
In our previous example use case, the bulk of what AD FS does is when it sources claims (statements about an identity), and processes them into a security token. That process is called the claims pipeline
There are three main stages to the pipeline
After the third stage we have claims that are ready to be packaged into a usable security token
The security tokens are what a relying party is going to ultimately consume
Some key terms to be know before we go further
Lets understand how these different terms come into play with an example use case
Some key terms to be know before we go further
Lets understand how these different terms come into play with an example use case
A typical example of the WebSSO authentication flow using AD FS
User navigates to https;//login.microsoftonline.com
They type in their organization email address and O365 issues a 302 redirect to the AD FS URL, sts.doughcorp.com
The AD FS proxy opens a connection to the AD FS server, presenting a web auth form
The user types in their email address and AD password into the web form
The ADFS server talks to the claim’s provider attribute store, AD to authenticate the user
Upon successful auth, the federation service receives claims from the claims provider, and puts them through the claims pipleline The pipeline checks if the user is authorized, transforms the claims and generate a signed security token
The user’s browser receives the security token and sends it to Office 365 where it is verfieid and exchanged for a usable authentication token (a session cookie)
A typical example of the WebSSO authentication flow using AD FS
User navigates to https;//login.microsoftonline.com
They type in their organization email address and O365 issues a 302 redirect to the AD FS URL, sts.doughcorp.com
The AD FS proxy opens a connection to the AD FS server, presenting a web auth form
The user types in their email address and AD password into the web form
The ADFS server talks to the claim’s provider attribute store, AD to authenticate the user
Upon successful auth, the federation service receives claims from the claims provider, and puts them through the claims pipleline The pipeline checks if the user is authorized, transforms the claims and generate a signed security token
AD FS retrieves these attribute values from the store and creates claims based on that information
The user’s browser receives the security token and sends it to Office 365 where it is verfieid and exchanged for a usable authentication token (a session cookie)
A typical example of the WebSSO authentication flow using AD FS
User navigates to https;//login.microsoftonline.com
They type in their organization email address and O365 issues a 302 redirect to the AD FS URL, sts.doughcorp.com
The AD FS proxy opens a connection to the AD FS server, presenting a web auth form
The user types in their email address and AD password into the web form
The ADFS server talks to the claim’s provider attribute store, AD to authenticate the user
Upon successful auth, the federation service receives claims from the claims provider, and puts them through the claims pipleline The pipeline checks if the user is authorized, transforms the claims and generate a signed security token
The user’s browser receives the security token and sends it to Office 365 where it is verfieid and exchanged for a usable authentication token (a session cookie)
We already talked about how AD FS transforms a user authentication event into a security token which is sent to the relying party
Now we are going to go just a little deeper to understand how AD FS itself is architected
Mention: MSSQL DB another option for structured data storage
When you set up AD FS authentication is configured to only allow the service account
Not even a DA will be able to access the database in its base configuration
Exploring this configuration database we can see a table ServiceSetting
It contains a single row, whose data is a large XML doc
Perusing that document we see a tag “SigningToken” with a child element of “EcnryptedPfx”
Well that looks interesting doesn’t it
- If you look at the XML document from ServiceSetting table it also contains a tag called “DKMsetting” which I thought was interesting
A quick google search showed that it is related to encryption, interesting..
In fact, AD FS uses DKM to store an symmetric key that we can use to decrypt that “EncryptedPFX” blob
Opening up AD explorer we can see the container stored as the following
And we can see besides the groups we would eexpect (DA, EA, etc) the AD FS service account also has read/write permissions over this object..
So lets try and piece together how the DKM key is used to decrypte the Encrypted Signing Token by doing a code walk
AD FS is written entirely in .NET, so we can easily inspect the code using tools such as DnSpy
Eventually we can trace to the LoadCertificateCollection() function
First it tries to load the certificates from the cert store, which is where they get placed after the first service start
If that fails however we can see it reads the EncryptedPFx value, decodes it and then passes it to this “Unprotect” method of the _protector clas
_protector is actually of type DKMDataProtector… we are on the right track
We can see that Unprotect is calling another Unprotect method from a _dkm attribute
This is of type Dkm.Groupkey so we are still on the hunt..
- Finally in the DKMBase class we can see where the magic happens
Unprotect method here is doing a lot of tings
It turns out that the EncryptedPFx binary blob is not a simple data type. Rather it is binary data containing ASN1 types
Those ASN1 types contain important information needed to decrypt the signing certificate. Things the IV for the decryption method, the alrogithm types, and a MAC code for verification
We can also see that the DKM key stored in AD is not actually the decryption key. Rather it serves as input for a Key Derivation function that is used to obtain the actual key we need
We can see here an overview of an example EncryptedPFx binary blob and the different encoded ASN1 types.
The decodeprotectedblob() function is unpacking all these structures
Following the ReadKey method we can see how DKM is acutally used to store data
The key derivation is using the standard Microsoft crypto library
From the name we can see it should follow the NIST standard SP 800-108
After tracing the code I found it is a very close follower of the standard, but not quite
Finally we understand how this works
The EncryptedPFX base64 data is read and decoded from the config database