Monday, June 27, 2016

is RBAC in Microsoft Exchange flawed?

Is RBAC in Microsoft Exchange flawed?

If you ask Microsoft, they will tell you that it is not. If you ask me or my friend, we think there is a rather serious flaw in the way that permissions via RBAC work in the Exchange world.


RBAC (Role-Based Access Control) is the method in which permissions are granted to accounts in Microsoft Exchange. By using a combination of Management Roles, Management Role Assignments, Management Role Entries as well as Role Groups and Role Group Members, it is possible to assign fine-grained policies for Microsoft Exchange tasks. For example, you could permit one user account to only be able to mount and dismount mailbox databases beginning with the letter A, or you could let an account be able to change any attributes on distribution groups in a certain Active Directory OU.

So what’s the problem then?

The problem is that when an Exchange PowerShell command runs, it is not actually run under the user account that executes the command, rather, RBAC checks that the user has the necessary permissions, and then runs it in the context of the Exchange Server itself.

Well, I sort of understand that, but why is that a problem?

Do you know all the accounts that are able to log on locally to any of your Exchange Servers worldwide? Are you sure? Every single backup account, antivirus account, SCCM account, etc.? Are you sure somebody can’t do a Mimikatz, or even reset the local Administrator password on one of the Exchange servers with a Live CD?

Not sure, but why is that important?

Try this (only with your Exchange Admin’s permission of course): Log on locally on an Exchange Server with an account that is a local admin, preferably with an account that has absolutely no Exchange permissions whatsoever and run a “PSEXEC –sid cmd” (you might need to download the PSEXEC command). You now have a cmd box running as the Exchange Server itself. From there you can start Active Directory Users and Computers, or PowerShell (Exchange Management Shell), or the Exchange MMC snap-in (the last one only in Exchange 2010) or whatever.

Yeah, so I’m the Exchange Server, whoopee, so what?

Well, if you’re using the split RBAC permissions model that Microsoft recommends (but not always used) then it’s not too bad, you just have full Exchange Organizational Admin permissions across the entire Org, you can stop and start databases, create and delete them, set permissions on any mailbox, create, change and delete connectors, just about anything really, you’re basically an Exchange god for the complete Exchange org… so just for fun, run a “get-mailbox –resultsize unlimited | remove-mailbox -whatif”. That would (without the –whatif) cut down a lot of your Email traffic, deleting every single mailbox throughout the complete Active Directory forest. (Don’t really do this, people may get upset).

Additionally… if you’re not running the split permissions model that Microsoft recommends, then, using this method, you are not only Exchange god as explained in the previous paragraph, but also quite a powerful Active Directory Admin , you can create, delete and modify users, groups and contacts in ANY domain throughout the forest (that have been domain-prepped for Exchange which is normally all of them), reset any non-AdminSDHolder password from any domain, the only thing you can’t play with are AdminSDHolder accounts from an Active Directory point of view (although you can still play with their Exchange attributes)

Well that sounds quite serious, do Microsoft know about this?

Yes, the matter was reported to Microsoft, but their answer was simply “If you can’t trust your Admins, you’ve already lost”. Now that maybe O.K. for them to say, but for some companies, it is sometimes not possible to know every Administrator in every location, never mind knowing every user that has physical access to an Exchange server with a trusty reset-password boot CD to hand, but you’re still meant to trust them.

What do we think?

We can understand Microsoft from the point of view that if your server is compromised, you’ve already lost, but the differences between a compromised Exchange Server compared to other Microsoft Server products is rather great. Compromise a SQL Server, whoopee, you’ve got a SQL Server. Compromise a SharePoint server, whoopee, you’ve got a SharePoint Server. But, if you're able to log on to one Exchange Server, you’ve got the whole Exchange Org under your control, and possibly, depending on if you have not split the AD Permissions, 99% of the Active Directory forest (yes, forest, not domain).

Is there a solution?

Sort of, although you’re probably not going to like it. Change to using the split-AD permission model, remove all possibility of anyone being allowed to log onto an Exchange server that is not an Exchange Org Admin (including SCCM, SCOM, …) and physically secure the servers. Also, make sure that the backup account passwords are only known by the Exchange Org Admins or find some other way of doing backups. There’s more… if you’re particularly paranoid, lock down the AdminSDHolder accounts in all domains so that the Exchange Server cannot modify their attributes. Also, you may want to turn on Bitlocker, and/or use BIOS passwords, so that the Password reset CD will not work. Now just make sure that nobody has access to the local users and computers on any Exchange Server so that they can’t add anybody to the administrators group, and you’re almost done. Finally, though, keep your fingers crossed, you never know, it might help.

Is there a better solution?

Yep, simple to state, hard to implement, but Microsoft could change RBAC so that the command actually runs in the user context instead of the server context, but as you’ve already heard, it’s not an RBAC issue, it’s a trust issue, so there’s no need to fix it.


Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?