A few weeks ago, I gave a presentation at Proofpoint Protect Global on the common methods of bypassing multi-factor authentication (MFA) and summarised my findings in this recent blog post. I demonstrated new vulnerabilities that bypassed MFA and showed how an attacker could act on behalf of the account holder, which includes full access to Office 365/Azure development and production environments, email, email rules, cloud apps and more. I tested several Identity Provider (IdP) solutions and demonstrated the vulnerabilities with Okta and OneLogin, who had already resolved these security issues. In this blog post, I will elaborate on some of the technical details on how attackers bypass MFA.
My Path to WS-Trust
During my research on how MFA can be bypassed, I researched many protocols, applications and directions, but one stood out.
When testing the common application Skype for Business (SfB), and how it communicates with its servers and the IdP, an inconsistency came to my attention. In some scenarios with some IdPs, SfB did not ask for MFA during the login even though MFA was always enabled for this tenant. As a researcher, this alarmed me. I started digging into the protocols used, the implementation and the flow of data between different endpoints. The entire process took many days as I was not familiar with SfB protocols at all, nor did I know the rabbit hole I was getting into.
After a few attempts that included code injection into the process, sniffing and trying to break parts of the encryption, I was able to use the tokens provided for Skype to communicate with users and extract information about the tenant that I should not have been able to get without MFA. This prompted me to research the origin and flow of these tokens. I needed to determine how Skype gets these tokens, and how it was able to bypass MFA entirely, which led me to WS-Trust protocol and active endpoints.
What Is the WS-Trust Protocol?
According to Wikipedia, WS-Trust is a WS-* specification and OASIS standard that provides extensions to WS-Security, specifically dealing with the issuing, renewing and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between, participants in a secure message exchange.
Web Services Security (WS-Security, WSS) is an extension to SOAP to apply security to Web services. It is a member of the Web service specifications and was published by OASIS. The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as Security Assertion Markup Language (SAML), Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.
Since so much information is available on these protocols, I’ll just highlight what we need to know in order to understand this attack: WS-Trust is used with active endpoints. WS-Federation is used with passive endpoints. The active endpoint is usually used for legacy protocols authentications. The passive one is usually used by browsers or modern clients. In general, these endpoints reside on the IdP side to verify logins.
Usual Mitigations Will Not Protect You
“The best way to protect your account from malicious authentication requests made by legacy protocols is to block these attempts altogether.” —Microsoft
The usual mitigations do not help against this MFA bypass. The known mitigation of disabling legacy protocols in Azure does not protect against this bypass as the attacker can pivot to modern authentication. Pivoting the token will lead Azure to report and believe that the login was made using modern authentication. This can also mislead the administrator to believe that the session was authorised with MFA and is safe.
Since WS-Trust was not designed with MFA in mind as it was designed many years ago (approved at March 2007), it lacks the native support for MFA. Hence, IdPs have to invent their own solutions for MFA (or to block it).
How an Attacker Can Leverage New Vulnerabilities to Bypass MFA
Basically, this attack works by:
- Finding the endpoint address
- Sending a SAML request directly to the IdP
- Getting a SAML V1 token
- Converting it to modern token via Microsoft services
- Using OAuth 2 token\cookie for full control over the account
For example, let’s say that “Alice” wants to connect to MS 365 to send an email to her old friend “Bob”. Note that the MS 365 tenant uses federation and SSO services with MFA enabled provided by an IdP. Instead of Alice providing her credentials directly to MS 365, she would browse to outlook.office.com and click the login button. Her login will then be forwarded to the IdP for authentication via the passive endpoint. After she provides the correct credentials, she will proceed to perform the MFA challenge. From there she will be forwarded back to MS 365 logged in with her user credentials.
In a vulnerable flow example, Oscar wants to send an email to Bob from Alice’s account. Oscar steals Alice’s credentials via phishing. Instead of browsing to outlook.office.com, he sends the request directly to the active\legacy endpoint containing only the username and password with crafted headers. If the endpoint is susceptible to this vulnerability, the IdP will return a SAML 1 token that is valid to the whole of Microsoft federation. Oscar will pivot this token to a modern one using the method described below and will be able to browse and send emails as if Alice passed the MFA challenge.
While Oscar is logged in, he can also use Alice’s Azure account to steal source code and install a “malicious” third-party (OAuth) app to remain persistent in the account even if Alice changes her password. No MFA is required.
Details of Attack Flow
A typical SAML request by the attacker would look like this:
Image 1: SAML Request by an Attacker
All the details needed are username and password. The rest of the fields can be obtained without any effort while the attacker requests access to the whole Microsoft online federation (described later under Reconnaissance).
Below is the kind of reply the attacker would get from the WS-TRUST endpoint once the credentials are validated.
Image 2: Reply From WS-Trust Endpoint
As you can see, email@domain.com was given a signed token and can now be pivoted to modern token.
Pivoting SAML 1 token to modern token can be done by sending POST request to https://login.Microsoftonline.com/login.srf. In return, the attacker would get a cookie called ESTSAUTH that can be used to access all of Microsoft federation via a simple cookie injection to the browser.
Reconnaissance
The recon for this vulnerability is easy and very automation friendly. For example, getting the endpoint address is a very simple task and does not require any credentials. All an attacker needs to do is to browse to https://login.microsoftonline.com/getuserrealm.srf?login=demo@somedomainname&xml=1 and replace demo@somedomainname with the requested domain name.
The query will result in something similar to:
Image 3: DNS Query Screenshot
The STSAuthURL is the active endpoint that I was able to attack and show during my presentation at Protect Global Conference.
Additional Vulnerabilities
IP Spoofing
Furthermore, I have discovered that in some cases, one can use X-MS-FORWARDED-CLIENT-IP as the request header and bypass the IP limitations on the endpoint.
Some organisations use the IP address of the user to determine if a VPN was used or not. They assume that their VPN has static IP ranges and that they cannot be forged. Trusting the VPN IP address might lead some organisations to assume that MFA was already performed and not required again. However, the header above was able to fool some IdPs as they lacked the features needed to ignore it.
During the Proofpoint Protect conference, I presented a demo of this attack and limited the allow-list of IPs only to 127.0.0.1 (localhost) at the IdP side. While in theory, this setting should have blocked the endpoint completely for users outside the local IdP machine, I was able to bypass this mitigation using the header and access the account without MFA.
One might ask how an attacker would know what the IP limitations are on the endpoint and how the attacker would be able to retrieve them. While phishing a user’s credentials, an attacker can simply extract the session IP and save it along with the credentials to compromise the account in the future.
Empty User-Agent And A Missing Option
In my research, I found that in some cases the IdP did not provide an option to disable the active endpoint, in another case, even disabling the active endpoint in the IdP was not enough to protect the organisation against this attack. When I sent a request with an empty user-agent, I could bypass the mitigation and access the disabled WS-Trust active endpoint. I had tested this on a development environment and was told that this bug does not occur in production.
The Little “/” Who Could
The production environment did not allow me to proceed even with empty user-agent. However, after a few hours of attempts, I discovered another bug. Adding slash to the end of the production endpoint address did let me in the legacy environment even when it was disabled.
Not Being Logged
In some cases, direct access to WS-Trust endpoint was not logged on the IdP side. Hence, security systems and professionals could completely miss the attack.
Note that such an attack can be automated and happen in less than 1 second from start to account takeover.
Attack Flow at a Glance
It starts with python code, postman or any other tool that can send a POST request with custom body and headers. The custom payload containing the username and password is sent to a vulnerable WS-Trust endpoint that was discovered via the above.
The vulnerable endpoint will return a SAML 1 token, without any MFA needed. The attacker can take this token, add some headers to the request and send it to the website provided before.
Upon seeing the valid token, Microsoft provides the attacker with a cookie called ESTSAUTH. That cookie can then be used directly in the browser or in any relevant automation tool to take over the account. The automation tool can also provide the attacker with an OAuth token to the account.
Lessons Learned
- Vulnerabilities are there to be discovered. Compromised account detection and remediation can work where other security measures fail.
- Tracking the source of a token can be useful for research.
- Double-check that the settings work the way you expect them to.
- Consider disabling all X-Forwarded-For headers if you can.
- Legacy should be legacy and not used when possible.
- While MFA is an important link in the chain of effective cloud security, it is by no means an end all be all solution. Vulnerabilities like this one (and other methods described in our previous blog) are bound to be discovered by bad actors. Once found, they can be automated and weaponized to infiltrate many different organisations over prolonged periods of time. For enhanced security, we recommend layering MFA with a strong suite of cloud security solutions, including a CASB with a strong affinity to threat detection.
Learn More:
Learn more about Proofpoint’s solution by downloading our whitepaper, Getting Started with CASB.