Attacking FreeIPA — Part IV: CVE-2020–10747

I was informed on Wednesday June 17th 2020 that CVE 2020–10747 was revoked after it had been initially issued on June 15th 2020. Red Hat issued this statement regarding the security boundary for FreeIPA and as justification for the revocation.

Roles are used to classify permitted actions but are not used as a tool to implement privilege separation or to protect from privilege escalation. As a result, using privileges to gain additional privileges is not something considered unexpected. This bug has been rejected as a security flaw. Users with privileges should be reserved to trusted persons.

MITRE defines privilege escalation as follows:

The adversary is trying to gain higher-level permissions.

Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives.

Utilizing one permission to obtain another higher-level permission or privilege, is ultimately an example of privilege escalation.

RedHat has retained the fixed pull request despite the CVE being revoked and the vulnerability being reclassified as “CLOSED NOTABUG” on https://bugzilla.redhat.com/show_bug.cgi?id=1810160.

This post is the final part in a series about my experiences attacking FreeIPA. In Part I of this series, we reviewed some of the background and underlying technologies utilized by FreeIPA. We also discussed several authentication mechanisms, and forms of credential material, specifically how to identify, parse, and re-use credentials as an attacker. In Part II of this series we discussed the various different types of objects inside of a FreeIPA environment, and a little bit about their significance, as well as how these objects can be enumerated to obtain situational awareness. In Part III of this series we conducted lateral movement inside of a FreeIPA environment to accomplish two red team objectives.

If you haven’t read the first three parts of the series you can find them here:

• Part 1: Authentication in FreeIPA
• Part 2: Enumeration in FreeIPA
• Part 3: Finding a Path

Introduction

During an assessment of a cloud environment managed through FreeIPA our team was able to uncover a vulnerability in how FreeIPA integrates with existing technologies. This vulnerability allowed for our team to escalate to the “root” account and obtain UID 0. It also allowed us to bypass all existing HBAC rulesets and conduct lateral movement throughout the environment. This vulnerability was reported to RedHat through their vulnerability disclosure program and CVE 2020–10747 was assigned.

Vulnerability Overview

To explain this vulnerability I have created a small lab environment replicating the assessment environment as closely as possible. Inside our lab we have recently compromised an account with some permissions inside the environment, but lack the cleartext credentials needed to utilize sudo and escalate to root.

Specifically compromised account had access to the “User Administrators” privilege.

With this privilege comes a lot of different power to affect users inside the environment. Using this privilege we can make a new user inside the FreeIPA domain named root.

Once the user is created in the domain we can obtain a ticket for the account with kinit.

Now we can attempt to SSH using our newly created root domain account.

As shown this drops the user into the local root account! So simply by creating a domain user for a local user we were able to authenticate using the root@WESTEROS.LOCAL account and obtain the user context of the local root account.

But how does this account behave when an HBAC rule prevent access to a host. To test this theory let’s make another account named lowpriv and compare the two accounts privileges. Then we will attempt lateral movement with both accounts.

Now let’s compare lowpriv@WESTEROS.LOCAL and root@WESTEROS.LOCAL.

Now that we confirmed neither account is a member of any HBAC rules, or privileged groups let’s attempt to laterally move with each account.

Conclusion

This post is the culmination of my FreeIPA series. Hopefully this series has provided some value to red teamers, offensive engineers, penetration testers and blue teamers, detection engineers, system administrators. Understanding the core functionality, how it can be abused, and what the implications of the configuration decisions that we make, is critical in designing secure systems.

The bug reporting process for this vulnerability was ultimately not as clean and efficient as it could have been. Despite CVE 2020–10747 being revoked, I am still grateful that a patch has been issued.

If you are an administrator of a FreeIPA or IPA environment. It is critical to understand RedHat’s position on the role of Privileges and Permissions available in FreeIPA. As they stated:

“Roles are used to classify permitted actions but are not used as a tool to implement privilege separation or to protect from privilege escalation. As a result, using privileges to gain additional privileges is not something considered unexpected.”

Ensure that all users inside your environment that are assigned a Role, Privilege, or Permission are treated as critical assets, and monitor these individual accounts heavily as it is not unexpected that they can be abused to obtain additional privileges inside the environment.

DISCLOSURE TIMELINE

As committed as SpecterOps is to transparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publicization of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.

• March 3rd, 2020: Initial Disclosure.
• March 3rd, 2020: RedHat security team acknowledged the disclosure and began the process to validate the vulnerability.
• March 18th, 2020: Update requested to confirm validation of the vulnerability.
• March 18th, 2020: RedHat confirms that they are still investigating the vulnerability and will report back when they have completed the validation.
• April 1st, 2020: RedHat validates the vulnerability, and start investigating solutions to the problem.
• May 5th, 2020: Update requested to see the progress the RedHat team is making on a potential fix.
• May 6th, 2020: RedHat responds that the issue is more difficult to remedy then expected. The SSH team does not consider this as a bug, but an expected feature, and there are ongoing discussions about the best way to solve the problem.
• May 22nd, 2020: RedHat reports CVE-2020–10747 has been assigned to a flaw
• May 26th, 2020: Disembargo date of June 15th, 2020 is agreed upon
• June 15th, 2020: Initial post released and CVE 2020–10747 issued
• June 17th, 2020: RedHat revokes CVE 2020–10747
• June 20th, 2020: Update requested as to the reason for the revocation
• June 22nd, 2020: RedHat responds that they are working to clarify the documentation of what a security boundary consists of in FreeIPA
• June 23rd, 2020: Update requested to provide an official statement from Red Hat on what the security boundary is in order to update this post and the resulting documentation around the vulnerability.
• June 26th, 2020: RedHat updates the bug documentation to reclassify the vulnerability as “CLOSED NOTABUG” and leaves a comment with their official statement