FUD continues over OWA backdoor exploit

Last week, I wrote about a report issued by security company Cybereason that reported how an attacker had gathered 11,000 sets of user credentials after planting a compromised OWAAUTH.DLL file on an Exchange server. A spirited debate duly resulted and Cybereason commented back on the original post. I could have replied to that comment, but feel that the topic needs more attention, especially as Cybereason continues to trumpet their achievement around the “OWA Backdoor attack”.

In their comments, Cybereason say that I misunderstand their write-up. They say:

“the analysis explicitly stated this was a malware analysis and not an exploit report. As we wrote in our paper there was no vulnerability of OWA used in this attack. We discovered no new attack vector against OWA. “

Cybereason’s assertion that Active Directory is considered a high-priority target for attackers is accurate. I am glad that Cybereason now accept that no new attack vector against OWA was found. In fact, the issue with OWAAUTH.DLL is covered in a DELL SecureWorks report of 5 August 2015, which describes the threat as follows:

“OwaAuth web shell — A web shell and credential stealer deployed to Microsoft Exchange servers. It is installed as an ISAPI filter. Captured credentials are DES-encrypted using the password "12345678" and are written to the log.txt file in the root directory.”

The DELL report goes on to say that it is the IIS w3wp.exe process that loads the compromised OWAAUTH.DLL file.

It seems pretty clear that Cybereason should have presented its report as was “How we detected a well-known threat”. But that’s not what it did. If you look at the coverage the Cybereason report received, you find headlines such as:

“New attack targeting Microsoft Outlook Web App (OWA) to steal email passwords”

“New OWA attack steals Outlook passwords”

“Microsoft Outlook Web App Vulnerable to Password Hacking via “Backdoor””

“Outlook mailserver attack steals massive number of passwords”

And so on. These examples are drawn from a quick Google search and are broadly representative of the coverage generated by the report. Cybereason’s PR company did a great job of making sure that the report was picked up by many different outlets and Cybereason is “excited about the vast press coverage we have received due to the publication of our latest discovery”,

However, you have to ask yourself if was “not an exploit report”, then why did all the reporters focus on OWA in the absence of “no new attack vector against OWA” (true because DELL had already described the vector). The answer lies in the text and framing of the report where anyone who reads it would be forgiven for assuming that the purported problem is completely centered on Outlook Web App.

There is no doubt that the text would have been improved had it been reviewed by a subject matter expert (in Exchange) before publication to address the erroneous references to non-existent technology such as the “OWA Server”. The assumption Cybereason makes in their comments to my post such as “So what's special about OWA? Well, OWA is always put in the DMZ,” reveal a lack of understanding of the environment in which such a vector can be exploited and would have been challenged by an expert. OWA (or rather, an Exchange mailbox server that is capable of servicing client requests to use Outlook Web App) is absolutely not always put in the DMZ and the reverse is more usual. At least, that’s been my experience over the 18 years since Exchange first introduced a web client. Remember, Microsoft’s formal support stance is that only Edge servers can be placed in the DMZ and these servers don’t service client requests to use Outlook Web App.

Once a server is placed in the DMZ it becomes a viable target for attackers. The DELL report explains how an attack of this nature develops and how the attackers attempt to place the compromised DLL on Exchange servers that they identify. Neither DELL nor Cybereason identify what versions of Exchange might be prone to this form of attack, but the use of the .NET assembly cache points to a recent version. And of course, if the attackers can’t get to those Exchange servers because they are well-protected behind a well-managed firewall, the exploit is useless.

Because everyone knows that badly managed servers exist, Microsoft should not hold to this their stance that attacks like this are not possible "if a system is properly managed, secured, and up-to-date." Instead, Microsoft should fix the problem that allows DLLs like OWAAUTH to be compromised. 

For good reason, Cybereason has received a lot of criticism from the Exchange community. Better writing, more detail, and a focus on the worth of their technology (cited as a “unique ability to detect malicious activity using automated behavioral analysis” – a capability I am sure the company has) rather than a previously known vulnerability might have resulted in a better outcome. Unless of course you’re simply interested in getting the word out that you’re in the security game and have some interesting techniques to detect malicious code. But PR is like that – if you gain publicity, you can expect comment, especially where holes in the story are easily detected and explored.

In closing, it would have been nice if the Twitter discussion that erupted over this topic had been kept polite and focused. I’m not a troll “desperate for attention” as Cybereason’s Dan Mitchell enquired. I actually have some background in security as I led security strategy for HP for a number of years and was well educated about threats and vulnerabilities by some very competent HP Labs researchers. Anyway, I’m a grumpy old man and insults tend to just bounce off me.

But I really didn’t like the response to Michael Van Horenbeeck. It was neither nice nor professional. A company that communicates like this, even in social media, loses a lot of my respect. Just saying.

Follow Tony @12Knocksinna