A flaw in the way Microsoft Azure Active Directory (AD) Connect configures the AD synchronisation account in Office 365 hybrid installations, creates stealthy admins in the user group by default.
Enterprises with Office 365 deployments and on-premise Active Directory, who then use Azure AD Connect to sync between on-premise and cloud, will have been exposed to this privilege escalation vulnerability.
When Roman Blachman and Yaron Zinar, security researchers at preempt, reviewed one customer network they discovered 85 percent of all users had unnecessary admin privileges. Something you might think should be easy to spot as Active Directory will, more often than not, highlight such excessive privilege problems. Unless, as the researchers point out these users have "elevated domain privileges directly through domain discretionary access control list (DACL) configuration." Preempt refers to these as 'stealthy admins.'
The problem with stealthy admins being that they can effectively bypass the complex nesting hierarchy of the Microsoft permissions model, and achieve domain admin permissions without being part of any protected security group.
Back to the researchers as to how this particular vulnerability operated with an Azure AD Connect account when installed using the Express Settings configuration: "Azure password synchronisation is used as an on-premises extension of Azure AD as a way to sync passwords between on-premises network and cloud services. Therefore obviously it requires domain replication permissions to extract the passwords." The account so created has no AdminSDHolder protection as the user is not considered an admin. Oh, and other non-privileged users are able to reset its password. "In many networks we found that this account was a main attack path for attackers with Account Operator permissions" the researchers conclude "to escalate their privileges and become full domain admins."
Someone has to say it, and it might as well be us: just what was Microsoft thinking? Surely this represents a massive lapse in secure coding and design, creating a privileged account in the users group would not seem like an obvious choice for a secure-minded developer.
"I'd posit to failure in their internal security process" says Ugochukwu Enyioha, managing consultant at Synopsys "the blackhat presentations in the article that discussed the concern were given by Microsoft researchers so they can't say they were not aware of this class security concern. If this realisation happened after the fact, did they forget to connect the dots back to their ADFS sync tool? It would seem more likely they either missed this during their scrub for concerns, or they hadn't gotten to it."
Paul Blore, managing director at Netmetix, speaking to SC Magazine feels this was "an oversight, or a technical bug" continuing "several security mechanisms are already in-place, including SDHolder, that will mitigate this particular risk, regardless of whether it is placed in the Users OU." Blore adds that Microsoft does, after all, specifically state that the built-in Account Operators Group should not be used.
This particular vulnerability has been addressed by Security Advisory 4056318 . Microsoft acknowledged the issue and has released a Microsoft Security Advisory 4056318 and (and a PowerShell script to adjust permissions of the Active Directory domain accounts, modifying the properties of the AD DS synchronisation account.
But what should the enterprise be doing to mitigate against this type of privilege escalation vulnerability?
"Protection starts with hardening systems" James Plouffe, lead solutions architect at MobileIron advises. While that may seem like a rather daunting task, Plouffe points out that "there are a number of free resources such as the CIS Benchmarks, the NSA Hardening Guides, DISA Secure Technical Implementation Guides (STIGs), and publications from organisations like ENISA that provide concrete and detailed information on how to improve the baseline security of your technology infrastructure." All of which are great resources for eliminating insecure defaults that exist in many environments.
Is Zero Trust really achievable given the complexity in finance service organisations?
Brought to you in partnership with Forescout