Hacking Summer Camp: Sniffing and replaying ADFS claims with Fiddler

 

 

Here comes the last, but not least episode of CQURE Academy’s Hacking Summer Camp! 🌴

We hope you’ve enjoyed these intense 2 months of security training and will find the presented tricks useful for your work.

Here’s a list of all the previous parts, so you can catch up:

Episode 1

Episode 2

Episode 3

Episode 4

Episode 5

Episode 6

Episode 7

 

Prepare a big cup of coffee, and let’s go with the last one! 👇🏼

 

Episode 9: Sniffing and replaying ADFS claims with Fiddler

In this article, we are going look into the process of authentication with ADFS. We will use “Fiddler” – a free web debugging proxy tool to analyze network conversation between the website to which the 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 a man-in-the-middle (MITM) attack can see and do, and how to prevent a token replay attack.

 

Basics

But first, let’s start with the basics. What is ADFS and why use it? Active Directory Federation Services is a standards-based service that allows 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 the 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 the 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 the 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 the Capture and Decrypt HTTPS checkboxes. You will be prompted to install a newly generated “Trusted Root Certificate” and from now on Fiddler will act as a man-in-the-middle between your web browser and any other server. The screens below present configuration steps.

 

Without closing Fiddler, we’ll start the web browser and go to the website that is a federated Resource Provider in our test environment, which is https://sdc01.cqure.lab/ (#2 in the figure below). The resource requires authentication and the user is redirected from sdc01.cqure.lab to Identity Provider configured in the web.config file (https://adfs.cqure.lab) #3. After successful authentication, the user’s web browsers receive response #5 with an HTML web form that contains token signed by ADFS with all claims issued for RP that was requesting authentication. The webform 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 the RP is controlled by IdP administrators and is determined during the configuration of the federation with other parties. Sometimes the RP might require to send claims containing sensitive information that we do not want to share with anyone else besides the RP. In this example, you can see a private phone number. Of course, all messages are sent through SSL tunnel but in case of a MITM attack between the RP and client web browser, hackers 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 the IIS hosting website. The 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 ->  Relying Party Trust ->  Your RP Name (properties) -> Encryption (tab) and browse for the public key of the certificate (figure above).

The second step is to add information about the certificate to the web.config file. Add serviceCertificate inside the <microsoft.identityModel> <service> section.

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

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

 

Preventing a token replay attack

As mentioned before, the token created by ADFS is sent to the client’s web browser in HTML Web Form which is then posted to the RP website. By default, this token can be used to authenticate at RP again if it’s captured by the MIMT attack. And now let’s test this. Again we go to line #5 in Fiddler but this time we choose TextView on lower tabs list and click View in Notepad in the bottom right corner.

This will open a new notepad instance with the HTML code. We save this file as replayToken.html.

We need to remember to sign out from the website and restart the 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 the ADFS login page but this time instead of providing our credentials we simply open the previously saved replayToken.html. Depending on settings of our web browser we will see the HTML Web Form and a 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 the web.confing file and add tokenReplayDetection entry inside the <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, the token will still work but the second attempt will generate an error SecurityTokenReplayDetectedException error, that should be handled by the application code.

 

We hope that this short article will help you to understand the basics of the 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 a token replay attack in your web application.

Want to learn more? Contact us at info@cqureacademy.pl or leave a comment below!

Stay safe!
CQURE Experts