Sniffing and replaying ADFS claims with Fiddler!

In this article we are going look into the process authentication with ADFS. We will use “Fiddler” – free web debugging proxy tool to analyze network conversation between website to which user is authenticating and its web browser. This is a very useful tool for troubleshooting ADFS authentication problems and we will learn what the attacker using man-inthe-middle (MITM) attack can see and do and how to prevent token replay attack.

Basics

But first let’s start with the basics. What is ADFS and why to use it? Active Directory Federation Services is a standardsbased service that allows the secure sharing of identity information between trusted (federated) partners. When a user wants to access resources from one of the federated partners (RP – resource provider) they are redirected to their own organization for authentication (IdP – Identity Provider) and only claims (signed statements about user) are returned to the resource provider. Main benefits of using ADFS: you never reveal your credentials to third parties, users can experience single sign-on, simplified (centralized) user account management, centralized federated partner management and many more.

Sniffing network conversation

To analyze network traffic during the federated authentication process we will use Fiddler which can be downloaded from Telerik’s web site http://www.telerik.com/fiddler. Additionally, we will use Fiddler Inspector for Federation Messages to simplify the analysis of SAML 2.0 and WS-Federation format messages. To add this to your Fiddler installation just simply download the archive from http://identitymodel.codeplex.com/releases/view/52187 and copy content from \bin\Debug folder into \Inspectors folder in Fiddler installation path.

After installation start your Fiddler and go into Tools -> Tellerik Fiddler Options -> HTTP (tab) and check Capture and Decrypt HTTPS checkboxes. You will be prompted to install newly generated “Trusted Root Certificate” and from now on Fiddler will act as man-in-the-middle between your web
browser and any other server. Screens below present configuration steps.

Without closing Fiddler, we’ll start a web browser and go to the website that is federated Resource Provider in our test environment, which is https://sdc01.cqure.lab/ (#2 in the figure below). Resource requires authentication and the user is redirected from sdc01.cqure.lab to Identity Provider configured in web.config file (https://adfs.cqure.lab) #3. After
successful authentication, user’s web browsers receives response #5 with HTML web form that contains token signed by ADFS with all claims issued for RP that was requesting authentication. Web form is automatically posted and sent to sdc01.cqure.lab #6 where the token is verified and authorization is processed by RP based on claims issued by IdP.

So let’s see how the token looks like. We need to select #5 on the list of HTTP/S requests and on the right side of Fiddler chose Inspectors and Federation from lower tabs list.

Listing below presents part of the token sent in XML format containing  RequestSecurityTokenResponse. Besides information about where and when this token was created, we can find all claims issued during the authentication process.

What is sent to RP is controlled by IdP administrators and is determined during the configuration of federation with other parties? Sometimes RP might require to send claims containing sensitive information which we do not want to share with anyone else besides RP. In this example, you can see a private phone number. Of course, all messages are sent through SSL
tunnel but in case of MITM attack between RP and client web browser, a hacker could receive private information.

Encrypting claims

To be sure that no one except RP can read claims sent with authentication token we need to encrypt their content. First, we need to have a certificate installed on IIS hosting website. Content of the token will be encrypted with the public key of that certificate so we need to publish it in RP’s metadata or copy it to our ADFS server and chose it in AD FS management console.

Go to AD FS console -> Trust relationships -> Relaying Party Trust -> Your RP Name (properties) -> Encryption (tab) and browse for public key of certificate (figure above). 
The second step is to add information about the certificate to the web.config file. Add serviceCertificate inside <microsoft.identityModel> <service> section.

Remember that Windows user account which application pool is using must have access to private key of certificate to decrypt claims, otherwise we will receive an error. We can grant this privileges using MMC console for computer’s certificates. Locate certificate, then choose All Tasks  Manage Private Key and grant read permission to
IIS Apppool\<NameOfAppPool> user.

Now when we are sniffing token we see only encrypted data unless we have access to private key.

Preventing token replay attack

As mentioned before token created by ADFS is sent to client’s web browser in HTML Web Form which is than posted to RP website. By default this token can be used to authenticate at RP again if it’s captured by MIMT attack. And now let’s test this. Again we go to line #5 in Fiddler but this time we choose TextView on lower tapict 9bs list and click View in Notepad
in the bottom right corner. This will open a new notepad instance with HTML code. We save this file as replayToken.html.

We need to remember to sign out from the website and restart web browser so we are sure that we are no longer authenticated. Next, we try to access the website again and it should redirect us to ADFS login page but this time instead of providing our credentials we simply open previously saved replayToken.html. Depending on settings of our web browser we will see HTML Web Form and button to send it or we will be automatically redirected to the website.

This attack will work until the token expiration time. To prevent this kind of attack we need to enable Token Replay Detection in our application.
To do this open web.confing file and add tokenReplayDetection entry inside <microsoft.identityModel> <service> section. 
We can specify how long and how big should be the history of used tokens.

After saving changes we can test the replay token attack again. Remember that the first time after the change token will still work but the second attempt will generate an error SecurityTokenReplayDetectedException that should be handled by the application code.

I hope that this short article will help you to understand the basics of ADFS authentication process and that you’ve learned how to use Fiddler to sniff tokens. This sill is very important for troubleshooting. Also now you know how to protect your claims from unauthorized access and protect from token replay attack in your web application.

Contact us at info@cqure.us if you want to learn more about ADFS or setting your own test environment for this article.

Stay CQURE!

Michael Jankowski-Lorek (CQURE Academy)