Microsoft Exchange 2013, the newest product in the Exchange series, is more and more enrolled in enterprise environments. With the new and enhanced features, for example the integration of SharePoint or Lync, the new Exchange is a well-designed piece of software which in parallel addresses different security concerns. Like Lync 2013 and the whole Microsoft Office Suite, Exchange is available as on premise installation or as Office365 solution, even a combination of both worlds is possible. There is for example the Exchange Online Protection solution which could be combined with a on premise installation.
Exchange 2013 Workloads
Compass Security would like to share their recent experience to enlighten some of the risks and security issues within an Exchange environment. This post is not about fuzzing or testing the product itself, it’s more about the secure configuration of the Exchange environment. The other heavy-weight product from Microsoft, the Lync 2013, was also a recent blog topic where I wrote about the security issues, the privacy configuration and the missing security features.
At least the following built-in security features are available:
- Encryption: Transport security is enabled by default and can’t be disabled. The communication is always RPC over HTTPs (Outlook Anywhere)
- Fine-grained role-based-access-control (RBAC) system. A similar RBAC system is also used in a Lync eco-system
- Passive databases and lagged database copies for high availability and disaster recovery
- Archiving and Journaling possibilities for backup and compliance requirements
- An optional anti-spam and anti-malware detection framework built into Exchange
- Data Loss Prevention (DLP) engine to filter sensitive information, based on pattern matching
Besides these security features, following security issues must be properly addressed:
- RBAC: When the RBAC system is used too loosely, too many people have too many privileges on the sensitive enterprise e-mail content. Therefore, like in Lync, the RBAC roles must be implemented with the least-privilege principle. Custom roles should be implemented for enterprise-specific requirements:
Read all roles:
Get-ManagementRoleAssignment | select roleassigneename –Unique
Read all members of all the role groups:
foreach ($rg in Get-RoleGroup) { ` Get-RoleGroupMember –Identity $rg.Name ` | select name,@{n="RoleGroup";e={$rg.Name}} | ` ft -autosize }
Read members of a specific role group:
Get-RoleGroupMember "My AD Group"
List all allowed cmdlets for a specific group:
Get-ManagementRoleEntry "RoleName\*"
Or list all groups in which a specific cmdlet is allowed:
Get-ManagementRoleEntry "*\cmdlet-name"
- E-mail encryption: However, transport security is used within the whole Exchange environment. End-to-end encryption must be implemented with e.g. RMS (Right-Management-System) or S/MIME. The email content is not encrypted by default. Furthermore, when using Exchange Cache Mode, on every enterprise workstation a “<filename>.ost” file is stored unencrypted on the disk. This file contains the whole email and calendar and other sensitive information in a mailbox. With tools like “Kernel to PST” the .ost file could be opened and accessed as with Outlook.
Cached Exchange Mode Settings under Account Settings in Outlook:
Tool to read the content of .ost files is for example “Kernel for OST to PST“.
- Auditing: Tracking mailbox access and configuration changes is essential for forensic analysis and security investigations. There exist the admin (RBAC) and mailbox auditing. The latter can be enabled for the owner, delegates or admins. Furthermore, the auditing can be set for different actions, e.g. move, copy, open delete.
Admin audit:
Get-AdminAuditLogConfig | fl AdminAuditLogEnabled, ` AdminAuditLogCmdlets, AdminAuditLogParameters, LogLevel
Mailbox audit:
Get-Mailbox | select userprincipalname,auditenabled | ft –AutoSize
List all actions which are logged for a specific mailbox:
get-mailbox <username> | % { ` "Displayname: {0}" -f $_.displayname; "AuditEnabled: {0}" ` -f $_.auditenabled; "AuditAdmin: {0}" -f $_.auditadmin; ` "AuditDelegate: {0}" -f $_.auditdelegate; "AuditOwner: {0}" ` -f $_.auditowner }
Identify mailboxes which are excluded from the auditing:
Get-MailboxAuditBypassAssociation -ResultSize unlimited | ? ` { $_.AuditBypassEnabled -match "True" }
- Mailbox permissions: It’s well known, that the private flag is only respected within the Exchange Eco-System (e.g. Outlook, OWA). When directly access Exchange with Exchange Web Services (EWS), private flagged items (e.g. private appointments) can be read. Therefore, the permissions for a mailbox should be set to “limited details” and for the inbox the allowed delegates must be set very rare. “Reviewer” permissions would allow access to the private appointments through EWS.
Get-MailboxFolderPermission <username>:\Calendar
Example Output:
FolderName User AccessRights ---------- ---- ------------ Calendar All {LimitedDetails}
The same is used for the inbox:
Get-MailboxFolderPermission <username>:\Inbox
- Connector Security: Connectors are the interfaces from and to the Exchange servers. Outlook clients, IMAP/POP clients, any other SMTP server and also third-party applications like scanners or FAX devices.
List given details for all connectors
Get-ReceiveConnector | fl Name, AuthMechanism, PermissionGroups
To verify, that a connector is not used as anonymous open relay, read the extended AD permissions for a specific connector:
Get-ReceiveConnector | % ` { $_.name; Get-ADPermission -identity $_.name -user ` "NT AUTHORITY\ANONYMOUS LOGON" | ft extendedrights ` -HideTableHeaders –AutoSize }
“Ms-Exch-SMTP-Accept-Any-Recipient” should not be available for any anonymous connector.
- OWA Offline Storage: In respect to information leakage, disabling offline storage would prevent the application from storing the following information on the client: up to 150 emails or content of last 3 days, all contacts, calendar entries for the next year but not attachments.
Get-OwaMailboxPolicy | fl AllowOfflineOn
- Management Interface: The new Exchange Administrative Center (EAC) is the management web application (/eac) for the Exchange. The same EAC is used by normal users to change their password or change other account settings. This leaves us in an unpleased situation where the management interface can’t be hided from the client network because both the administration and the user settings are handled with the same application.
As with Lync, the provided Exchange security mechanisms are good and give an enterprise a solid baseline for a secure email, calendar and contact manager solution. However, there are different locations which must be considered in the design and configuration phase: auditing must be enabled, custom RBAC roles should be used to limit access to sensitive mailbox content and connector security settings should be hardened to only allow authenticated users.
Thanks to Marek Madrzycki for the review and comments for this post.
References
- Book “Mastering Microsoft Exchange Server 2013”, David Elfassy, 2014
- Exchange Server 2013 Product Site, https://products.office.com/en-us/exchange/microsoft-exchange-server-2013
- Exchange Server 2013 , https://technet.microsoft.com/en-us/library/bb124558.aspx
- Exchange 2013-Cmdlets, http://technet.microsoft.com/de-de/library/bb124413(v=exchg.150).aspx
- Security Cmdlets: http://technet.microsoft.com/en-us/library/dd351246(v=exchg.150).aspx
- Exchange Conference 2014, http://channel9.msdn.com/events/mec/2014
- Exchange Online Protection, https://products.office.com/en-us/exchange/microsoft-exchange-online-protection-email-filter-and-anti-spam-protection-email-security-email-spam
- EWS reference for calendar view, https://msdn.microsoft.com/en-us/library/aa564515.aspx
- Active Directory Rights Management Services, https://technet.microsoft.com/en-us/windowsserver/dd448611.aspx
- OWA Offline Storage, http://blogs.technet.com/b/exchange/archive/2012/11/06/offline-access-in-outlook-web-app-2013.aspx
- Post titel image source: Microsoft
Leave a Reply