Security Advisory: Targeting AD FS With External Brute-Force Attacks

On July 2019 Patch Tuesday, Microsoft released a patch for CVE-2019-1126, an important vulnerability discovered by Preempt Research Labs. The vulnerability discovered leads to security issues that create a wide scale denial-of-service against exposed organizations, and potentially, identity compromise.

While Microsoft only released one patch, we believe there are two vulnerabilities that allow attackers to remotely launch brute-force attacks on AD FS servers from the outside of the network. Attackers can bypass the Extranet Lockout Protection security feature and also bypass the Microsoft AD lockout policy(!) in certain scenarios. The implications vary between account compromise (due to weak passwords) or a massive denial-of-service to all domain accounts. All AD FS versions are vulnerable.

A Short Introduction to AD FS

AD FS (Microsoft Active Directory Federation Services) is a software product offered by Microsoft that provides federation services for AD (Active Directory) and other directories (AD FS 5.0) using SAML and WS-Federation. The software allows federation of an account identity in AD to be used to login to other applications that are not part of the particular AD domain. AD FS is commonly set up to offer a web interface allowing users to authenticate to different applications. Simultaneously, the AD FS server uses AD to validate the users’ credentials and extract the relevant properties.

AD FS is especially useful in scenarios where integrating the application directly with AD is not applicable. Common scenarios include: cloud applications that require authorization of on-premises AD accounts, allowing users connecting from the external network to use on-premises applications or  allowing users from different AD forests to use forest applications without setting up cross forest trust. For these reasons, many organizations are using AD FS to enable cloud applications on Azure or Office 365 without syncing passwords to a cloud directory. In addition, organizations use AD FS to enable access to on-premises applications such as Sharepoint/Exchange to external users. As a result,  AD FS is the second-most important authentication provider in the network (after AD) for which any security or functional failure can have a critical impact on the entire organization. 

A typical AD FS deployment would include an internal AD FS server and an AD FS proxy that is open to the external network. The AD FS proxy acts as a transparent proxy: relaying all HTTP requests to the internal AD FS server. In many cases, AD FS is one of the only servers open to the internet and can be a target of many internet attacks such as DDoS and credential scanning. Brute-force attacks have a double risk: If an account has a weak predictable password, the attacker might be able to successfully guess the password and compromise the account. If the account’s domain enforces a lockout policy, it might be possible for an attacker to remotely lock some or all accounts in the domain without having any physical access to the internal network. These issues are amplified by the fact that it is extremely hard to mitigate attacks coming from the internet and set up an effective policy allowing only legitimate IP addresses. To overcome the issue of an attacker being able to lock accounts using AD FS APIs, Microsoft had introduced the AD FS Extranet Lockout Protection feature.

In a nutshell, when the feature is enabled, AD FS validates the Bad-Pwd-Count LDAP attribute of an account before sending any authentication request to an AD server. If the bad password count exceeds the configured threshold, and the authentication is from the external network (i.e., the Internet), then the request is rejected automatically. When this feature is used in conjunction with an enabled internal AD lockout policy, it ensures that an external actor cannot lock internal AD accounts. When the feature is used without an internal AD lockout policy, it prevents external actors from brute-forcing internal accounts passwords. 

(See “Secure Federated Access: Threat Prevention for Cloud Applications” video)

The Vulnerabilities

The key issue causing both described attacks is that AD FS supports two authentication methods: Form authentication (where the user submits a plain-text password) which is protected and WIA (Windows Integrated Authentication) where the user uses Kerberos or NTLM SSO capabilities to authenticate to AD FS without presenting a plain-text password. As it turns out, WIA is protected very poorly, and each protocol can be abused by attackers connecting from the external network to launch the following attacks:

• NTLM Brute-Force (CVE-2019-1126) – We have found out that the Extranet Lockout Protection is simply not applied on WIA authentication requests. When WIA is used in conjunction with NTLM, the users are required to provide a proof of knowledge of the main account’s secret. An attacker that implements WIA authentication over HTTP and sends crafted NTLM messages to the WIA URL on the AD FS can brute force account passwords directly while bypassing the Extranet Lockout Protection. This means an attacker can lock/crack all accounts in the network. 

A note on Enhanced Protection for Authentication (EPA): EPA can be enabled on AD FS (and it should!). By default, EPA is an optional feature and thus can be bypassed easily by negotiating it off. If EPA is required and enabled, it might protect you from a bypass if the AD FS proxy and the AD FS server use different certificates, however, this is simply not likely. Microsoft’s official statement requires that both the AD FS proxy and the AD FS server use the same certificate for WIA to work properly. This requirement leads to security flaws because when both servers leverage the same certificate, brute force attackers can easily bypass EPA. 

Figure 1 – External attacker using NTLM over AD FS to brute-force AD accounts

• Kerberos Brute-Force – Using WIA with Kerberos makes the situation trickier. In Kerberos, the service ticket in a TGS request is encrypted using the service account’s password hash. Attackers can launch a brute-force attack against the AD FS account by sending crafted TGS requests with service tickets encrypted using different password hashes. If they successfully guess the AD FS service account’s password, they can compromise the entire AD FS infrastructure. This technique is similar to Kerberoasting, except instead of getting the password hash from a ticket, we are forging tickets using different password hashes. We refer to this technique as Reverse-Kerberoasting. Interestingly, since if the ticket is encrypted using an incorrect password hash, no communication with the domain controller is required. Hence, this brute-force attack does not lock accounts in AD and does not leave any trace that we were able to uncover in the Windows event logs. 

Another note on EPA: in the Kerberos case, EPA actually does not protect against the brute-forcing attempt itself since the wrong password for an AD FS service account will yield a different HTTP status than a wrong channel binding certificate hash. If the AD FS service account hash is cracked, EPA might be able to protect against actual exploitation of the account.

Disclosure Timeline

Our research team discovered these security flaws in January and have been in contact with Microsoft since then:

1. 01/24/2019 – AD FS Kerberos brute-force attack disclosed to Microsoft

2. 01/31/2019 – MSRC denies issues and recommends gMSA and disabling RC4 as mitigations

3. 05/01/2019 – External Lockout Protection bypass disclosed to Microsoft

4. 06/06/2019 – MSRC acknowledges the issue and is working on a fix

5. 07/09/2019 – Microsoft fixes the External Lockout Protection bypass as part of CVE-2019-1126

Protecting Your Network

To protect your network against these threats, we recommend that you follow these steps:

1. Apply the relevant Microsoft patch. 
2. Patching is not enough. If you haven’t configured AD FS Extranet Lockout Protection, you are still vulnerable to many other attacks.
3. Ensure that the AD FS service account is using a strong (>15 characters) and randomly generated password. The easiest way to accomplish this is by managing the AD FS account as a gMSA. MSRC also recommends disabling RC4 encryption to make Kerberoasting (or Reverse-Kerberoasting) harder for attackers.
4. Practice good security hygiene by maintaining strict security practices – the issues we have disclosed are only a symptom of the complexity of maintaining a good security posture in a modern organization. Similar attacks are possible on other servers and different credential scanning attacks are still possible even on AD FS. To be fully protected, we recommend also adhering to the following security steps:

• Disallow weak passwords: Make sure no account in the network is using a breached or vulnerable password that an attacker can crack using brute-force. 
• Revise lockout policy: A lockout policy devised in a sloppy manner can create more harm than good and make IT spend endless hours unlocking user accounts. Make sure that your lockout policy has a high threshold against any suspicious activity. 
• Monitor for suspicious activity: Instead of simply locking down accounts, monitor account activity for failed authentication, anomalous activity, and malicious authentication attempts.
• Enable MFA: Require all accounts in the network to use MFA. If enabling MFA everywhere is too difficult, start with riskier areas of the network such as AD FS authentication and turn your focus towards administrative accounts.

How Preempt Helps

While we encourage everyone to follow the aforementioned steps, please note that you can mitigate the attack surface with Preempt by allowing for:

1. Detection of Brute-Force attacks with NTLM (from AD FS as well as any other endpoint)
2. Alerting on weak passwords within the AD FS service account
3. Preventing account compromise with the Preempt AD FS MFA plugin that will ensure MFA when users login through AD FS

If you currently have AD FS deployed, we recommend that you take action immediately. Attackers can now remotely launch brute force attacks on AD FS servers from the external network, which opens up the attack surface exponentially. Because AD FS is ubiquitous across all verticals and organizational sizes, we believe the impact of this vulnerability is far-reaching.

Enabling customers to protect both their network and federated cloud applications has always been critical to our mission, and we are here to help. If you need any additional resources or have questions about this particular vulnerability disclosure, you can contact us at [email protected].