Shulou(Shulou.com)05/31 Report--

This article mainly introduces the example analysis of SAML vulnerabilities, which is very detailed and has a certain reference value. Friends who are interested must finish it!

This article is limited to technical research and discussion, and it is strictly forbidden to be used for illegal purposes, otherwise all the consequences will be borne by themselves.

Preface

During a test of a Web application, I found a security vulnerability in the SAML (Security claim markup language) implementation of the application. The application adopts unsafe practical methods when implementing its SAML function, and its own self-defined authentication mechanism also has security problems, which leads to the existence of this loophole.

In this article, we will show you how to use these insecure configurations in combination with effective phishing attacks to help attackers remotely access secure pages that may contain sensitive information.

Application Overview

The client of the Web application we tested allows users to create simple Web pages as well as Web tables. Customers can not only use this application to collect end-user information, but also serve as a portal site for hosting human resources files and other potentially sensitive materials. At the same time, users can protect the security of these materials in a variety of ways. For example, they can set password protection for pages that will only be accessible to authorized users. Furthermore, the application also supports the use of SAML for single sign-on (SSO, that is, users only need to log in once to access all trusted applications). Therefore, it is very important to test these authentication mechanisms, because the implementation of security configuration is tedious and complex, and many organizations can not handle these configurations correctly.

Verification function

I logged in to the application using an administrator account and created a simple page. Next, I added the following text: "If you can see this,good for you." Finally, I modified the configuration to require the use of SSO authentication. I named the page "samlpage", saved the configuration, and generated a new URL:

Https://clientwebsite.com/samlpage

When I tried to load this page using an unauthenticated browser session, I received the following message:

A few seconds later, the page was redirected to our single sign-on page. The SAML identification provider (IDP) is the SimpleSAMLphp of Anitian, which is mainly used to test the SAML implementation. The Web page is then redirected to the following login interface:

If you enter the wrong password, you will not be able to log in; if you enter the correct credentials, I will be redirected to our client application. After several redirects, I was certified by App and successfully visited the SAML-protected page.

So far, all the basic functions are normal.

Next, I'm going to test it with BurpSuite's SAMLRaider plug-in, which can do some standard security tests, such as signature changes, and it's easy to execute. During my analysis, most of the basic SAMLRaider tests failed. But I found that I was able to replay the SAML response returned by IDP to the client application or service provider (SP). The validity of the SAML response is, in theory, only therefore, one-time. However, during testing, if multiple valid sessions are used under the same user account, the same SAML response can be used multiple times. If attackers can intercept SAML responses, they can open their own sessions and bypass the authentication mechanism. This attack is similar to obtaining a user's password, but the impact is more severe because the attacker will now be able to bypass the multi-factor authentication mechanism of the IDP deployment.

After analyzing the SAML traffic between SP and IDP, I found that when SP redirected the user to IDP for authentication, the GET parameter included a SAML declaration parameter and the other parameter was RelayState.

This RelayState parameter contains the URL address of a page within the client application. The decoded address is as follows:

Https://clientwebsite.com/samlpage?sp_id=73

This address is the protection page address I created, but now it contains an extra parameter called "sp_id". SP takes its own parameters and sends the address to IDP. After logging in to IDP, the user will receive a redirect request directed to SP (our client). IDP will forward the SAML response to SP with the parameter RelayState, which cannot be modified and returned to SP as is.

The SAML response is sent to the / sso/saml/acs/73 page and the user is redirected to the / samlpage protected page.

After looking at the Burp log, you will find that the SAML response has been sent again in clear text. This time the request is sent for a protected resource, which acts like the RelayState parameter. The previous URL is:

Https://clientwebsite.com/samlpage?sp_id=73

But this time the URL is as follows:

Https://clientwebsite.com/samlpage?saml_token=

I can't decode the saml_token parameter, but based on the parameter name, I think it should be important. I guess it should be used to determine whether access to samlpage pages is allowed. For testing, I loaded this address and the saml_token parameter using an unauthenticated browser session. Interestingly, I went directly to the protected page without redirecting to IDP, and I didn't log in. If I have a valid saml_ token value, I can access and view the protected page.

The next question is, what is the response of the RelayState value? If I can modify the parameter values and then redirect the user to any site, then this is an open redirection vulnerability.

After remaking the SSO request, I intercepted the original SAML request sent to IDP and modified the RelayState value, so I chose to use one of my own Web servers. The original URL is as follows:

Https://clientwebsite.com/samlpage?sp_id=73

I revised it to:

Https://anitianwebsite.com/owned

After forwarding the request to IDP, the browser loads the login page, and after logging in with a known valid account, IDP redirects me to SP. After intercepting the request, I found that the RelayState parameter still contains my modified value. The client application can still authenticate the validity of the SAML request and redirect me to the protected page. And I can redirect this URL, which means that there is an open redirection vulnerability:

Https://anitianwebsite.com/owned?saml_token=

And to make matters worse, saml_token was also sent to my Web server:

This vulnerability is even more serious, because when I get the saml_token as the key to accessing the protected page, I no longer need a user password or SAML response, I just need it to access any protected page.

The above is all the contents of the article "sample Analysis of SAML vulnerabilities". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.