Share via

Office 365: we need to talk about Security

  • Article

By: Caio Ribeiro César

This post will comment some Compliance updates/functionalities available to O365 administrators. We will also discuss Security scenarios that are common in the daily life of support engineers.

SecureScore

  • Some customers call Support asking for feedback or ways to improve Security in O365. Secure Score is a tool that will do the initial analysis for administrators – gathering what are the recommended security improvements/missing configurations and therefore rating the organization with a Score. This tool can be executed with the "runlevel" of your O365 administrator Account (access in https://securescore.office.com) .

Exchange Online Audit

We have already discussed this before, but remember is to live again.

a) Auditing: how to enable it?

b) Mailbox Audit, how to expand?

  • You can validate if all mailboxes have Mailbox Audit enabled and then export the list of the missing ones (using ExchangeGuid is a way of being sure you are exporting the unique value for each mailbox):

Get-Mailbox -ResultSize Unlimited | where {$_.AuditEnabled -match "false"} | fl ExchangeGuid

>  The administrator can use the result of this cmdlet in order to build a simple .ps1 using the ExchangeGuid attribute with the Set-Mailbox.

  • As soon as you have Mailbox Audit enabled, these tags are monitored inside the mailbox:

“Update,SoftDelete,HardDelete,SendAs,Create”

If the administrator wants to expand monitored tags, use Set-Mailbox:

Set-mailbox auditedmailbox -AuditDelegate update,softdelete,harddelete,sendas,create,folderbind

  • Older mailbox audit entries are removed automatically (+90 days). This limit can be increased by running:

Set-mailbox mailbox -AuditlogAgeLimit 24855.03:14:07

All mailboxes:

Get-Mailbox -ResultSize Unlimited | where {$_. AuditlogAgeLimit -match "90.00:00:00"} | fl ExchangeGuid > exchangeGuidlist.log

“Set-mailbox ExchangeGuid* -AuditlogAgeLimit 24855.03:14:07”

*using Guids from exchangeGuidlist.log

c) How to collect the logs?

This is invisible to the end user, but Mailbox Audit logs are located inside each mailbox ( /Recoverable Items/Audits).

O365 will collect logs and save them in a Unique DB (UnifiedAuditLogDatabase) that is also used by other O365-products, such as Azure AD Report, ExO Admin Audit, OneDrive, Sharepoint Online.

d) Role Based Access Control. How to segregate admin roles so they can have access to Mailbox Audit Logs?

  • Pshell: Direct Role assignment via New-ManagementRoleAssignment -Role "Audit Logs" -User <Identity>  or
  • EAC: Pre-Created RBAC Groups (Exchange Admin Center > Permissions > Admin Roles). Add your Compliance staff to the “Compliance Manager” group or
  • EAC: Create a new group with the “View-Only Audit Logs” Role.

Pentesting O365

It is also common for Support to get Partner/Customer calls with a Pentest/Vulnerability Assessment report created by 3rd party tools. Before creating a ticket with support (asking to help on the analysis or to fix something that appears to be a security glitch) take into consideration:

  • A valuable PenTest/Vulnerability Assessment is the one that the Security Admin running it fully understands the report. There are several false-positives or security measurements that are done in different layers of your structure – outside of O365;
  • Immutable Law of Security & Security Administration. Theory before practice, this knowledge is needed before taking any action requested/proposed by Assessment Reports.
  • The harder you make for users to access data, less usability you have. You can read great books about this specific matter or start with this:

secvsusa[1]

  • Man-in-the-Middle (MitM) doubts are common. It not only applies to O365/Outlook, but administrators usually ask how to prevent it. Let’s elaborate how MitM works (again, even when I am focusing on Outlook attacks, this is not O365-only).

MitM

MitM attack is a step-by-step procedure that focuses in gathering user passwords even when the communication client-server is encrypted (it can also be done with non-encrypted protocols).

Sniffing tools will use Arp Poison Routing [APR]. An MitM attack to capture encrypted protocols (such as https/ldaps/sftp/ssh) will start with APR. Several tools can be used for this spoof, and I will quote one I found to have good external documentation.

For a APR, it is expected: “it enables sniffing on switched networks and the hijacking of IP traffic between hosts”. In other words, we have the victim PC and a reroute of encrypted packaged to the sniffing tool (due to the spoofing). The APR is only going to work if the attacker has the IP vs. MAC association.

This can be done with a MAC Scan (usually the MitM tool has this option) or even through good and old Social Engineering.

Let’s say we have the correct “setup” running: the sniff tool is doing a MitM for the client > server communication and the packages are being collected.

They are encrypted - thus protected, right? Correct!

But... the attacker won’t stop. If he can intercept all protocols, consequently he can read unencrypted protocols. What is missing? The possibility to read encrypted protocols.

As soon as the MitM setup is finished, the next step is to make the end user accept an invalid certificate (that looks very much like the valid one) so the sniffing is “trusted” by the client. This is called “certificate injection * ” - if the certificate is trusted and the communication is being sniffed, then the attacker has the passwords even if they are encrypted.

Facts:

  1. Outlook communication with O365 is encrypted. A sniff without certificate injection will not collect any useful data for an attack. This doesn’t show a failure in the product (O365 or Outlook) - your network has been compromised and the end user has accepted an invalid certificate;
  2. This same attack would work for browsers (and this is the main focus for most of the attackers out there). Outlook for O365 uses MAPI over HTTPS, meaning any other HTTPS communication with this same attack would be vulnerable.
  3. If the end user is connecting to a network that is out of your management (Aiport Networks, and so on) and it has been breached, the attacker will have the same result. Meaning the attacker had access to 1) connect; 2) spoof; 3) sniff; 4) inject. Law#1 : If a bad guy can persuade you to run his program on your Computer, it’s not solely your computer anymore;
  4. Attacks are usually done in layers. So is the protection of it. IDS/IPS tools can prevent spoof/injection in a network level, Multi Factor Authentication can protect the access to data (how can I access an account when I have the password, but not the device or the app password).
  5. IDS/IPS: if configured correctly can also detect certificate injection (anomaly based detection) or detect an additional hop in the communication (Host Intrusion Detection). But this is something to be discussed with the Network guys :)

Let’s see how MitM works, described by Oxid:

1) The HTTPS filter is enabled by the user in the configuration dialog;
2) APR is enabled by the user using the button on the toolbar -> the Man-in-the-Middle   attack is ready;
3) The victim client starts a new session to an HTTPS enabled server;
4) Packets from the client are hijacked by APR and captured by Cain's sniffer by mean of Winpcap driver;
5) APR-HTTPS search for a fake certificate associated to the requested server in the Certificate Collector; if present the certificate will be used if not it will be automatically downloaded, properly modified and stored locally for future usage;
6) Packets from the victim are modified so that they are re-directed to the local acceptor socket; modifications are made on MAC addresses, IP addresses and TCP source ports (Port Address Translation "PAT" is used to handle multiple connections). The data captured is then sent again into the network using Winpcap but it is this time addressed to the local socket that will accept the Client-side connection;
7) The Server-side socket is created and connected to the real server requested by the victim;
8) OpenSSL libraries are used to manage encryption on both sockets using the fake certificate victim-side and the real certificate sever-side;
9) Packets sent by the Client-side socket are modified again to reach the victim's host;
10) Data coming from the server is decrypted, saved to session files, re-encrypted and sent to the victim host by mean of the Client-side socket;
11) Data coming from the client is decrypted, saved to session files, re-encrypted and sent to the server by mean of the Server-side socket.

Although it can be noticed from the fake certificate file used, this kind of attack is STEALTH from a client point of view because the victim thinks to be connected to the real server; try a "netstat -an" on the client to check yourself.

Once decrypted, traffic from the client is also sent to the HTTP sniffer filter for a further analysis on credentials.

[1] https://flylib.com/books/1/36/1/html/2/images/01fig01.jpg