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.
Background
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.
Labels: RBAC Microsoft Exchange
