The recent Cybereason report titled “A new persistent attack methodology targeting Microsoft Outlook Web Application (OWA)” probably caused some heart flutters for Exchange administrators who might have imagined that the client had been compromised in some fundamental way. I didn’t have quite that reaction because I don’t think the results described in the report are valid.
[Update: You can read the Exchange team's commentary on the issue on the EHLO blog. They are much more polite about the situation than I am]
The first issue is that I don’t believe the researchers know Exchange and it seems to me that some background and experience in how Exchange works is necessary to understand the threat that might exist and whether the vectors available to attackers are valid. Statements like “Contrary to other web servers that typically have only a web interface, OWA is unique; it is a critical internal infrastructure that also faces the Internet, making it an intermediary between the internal, allegedly protected DMZ, and the web” make me wonder whether the authors understand the architecture of the technology that they are analyzing and have any knowledge about how Exchange servers are deployed.
The attack appears to rely on a hacker being able to place a compromised (“backdoored malicious”) version of OWAAUTH.DLL on an Exchange server to capture Active Directory credentials provided by users who authenticated mailbox connections. The bad OWAAUTH was loaded and used by Exchange. It seems like the bad DLL was picked up after a reboot due to a change made to the registry. Or some Jedi magic. In any case, once the DLL was loaded, the attackers could harvest authentication requests made to Active Directory after decryption, so everything was in clear text. Password data was stored in an encrypted file (C:\log.txt), which seems like an unlikely place for anyone to want to hide data that they wanted to use. The researchers say that they were able to recover 11,000 password pairs from the log file. Clearly this was a busy server for a reasonably sized Exchange organization.
I’ve no doubt that it is possible to create a DLL containing code to retrieve user credentials, to place it on a Windows server, and to use the .NET assembly cache to hide the compromised code. Updating the system registry is not hard, providing you have the right permissions. However, the question then arises as to how the attacker was able to access the targeted server in the first place and how they did this with elevated permissions. Properly secured and maintained servers shouldn’t allow hackers to be able to place compromised files in system folders. No details are given as to how the cunning attackers did the dirty deed.
The exploit also seems to depend on the placement of the targeted Exchange server in the DMZ with direct access to the Internet because “the customer was using OWA to enable remote user access to Outlook”. Well, forgetting the mix-up between Outlook (a client) and Exchange (the server), this is an odd configuration. Although it is possible (and has been debated since 2002), not many Exchange administrators place servers in the DMZ. Microsoft has improved Exchange's ability to resist attack over the last few versions and it is possible to secure a well-managed and well-maintained Exchange 2013 server - even in the DMZ - against attacks like this.
Fears of attack often cause administrators to prefer keeping their servers behind a firewall on the basis that it reduces the potential for attack. In addition, deployment in the DMZ is not needed to support remote access to mailboxes via Outlook Web App, Outlook, or any other client. Today’s clients are happy to connect via HTTPS to servers located safe and well behind solid firewalls inside internal networks.
The only Exchange servers that Microsoft supports for deployment in the DMZ are those running the Edge role. These servers are not domain joined and are not part of the Exchange organization that hosts user mailboxes and don’t serve any role in authenticating user connections against Active Directory, so I cannot see how this attack would affect the operation of Edge servers or be able to compromise user authentication as described.
The odd configuration is one reason why I am unsure of the value of the report. The second reason is that the report lacks some essential details about the software configuration. What version of Exchange was running on the compromised server? What version of Windows was used? Was Windows fully up to date with security and other updates? Without this knowledge it is impossible to assess whether this report covers obsolete Exchange servers that are no longer in use or the latest cumulative update of Exchange 2013.
I also have issues with the conclusions. The authors state that “Almost by definition, OWA requires organizations to define a relatively lax set of restrictions” but no information is provided in the report to tell us what these restrictions are and why OWA requires organizations to configure lax security.
It seems to me that Cybereason wrote this report to gain visibility for themselves and their products by exposing a threat that doesn’t exist in real-world situations when Exchange is deployed properly. The customer they were working with badly needs some help and advice to manage Exchange servers properly or they will continue to shoot themselves in the foot.
It’s kind of sad to see that respected sites like ArsTechnica picked up and shared the hyped up conclusions reached in this report. But I guess it resulted in some additional page views and that’s more important than accuracy in some cases.
Follow Tony @12Knocksinna
