Last updated at Thu, 20 Jul 2017 19:19:33 GMT

Updating Like It's 1999

Now, before I get started, let me just say that I love the folks over at Malwarebytes. They do a lot of good work, and I'm constantly recommending their products to my friends and family in those vulnerable times of need. And if that all sounds like an apology, it is. Sorry, guys. But dang.

This week, we have an exploit module from community contributor Gabor Seljan which exploits a design flaw in the way MalwareBytes handled updates prior to October of 2014. This flaw was reported by Yonathan Klijnsma in June of 2014. Turned out, the mechanism to check for updates was done entirely over cleartext, relying completely on trusting that this unauthenticated, unencrypted connection was legit.

In other words, a malicious actor -- say, a malware author -- could hijack the process that Malwarebytes used to check for updates by monkeying with anything in that trust chain -- the HTTP responses, the DNS resolution of MalwareBytes' content hosts, or simply by hijacking name resolution via a malicious entry in the local hosts file. By using that last technique, I'm able to quite reliably hijack the update process and drop a Meterpreter shell on the victim.

As shown here, sometimes there's a race, and MalwareBytes identifies my Metepreter executable as a threat -- but I get the shell anyway. That's pretty fun. Also, once I've hijacked the update, I seem to have a permanent, respawnable shell. Any time I restart the Anti-Malware client, I execute my saved payload, and get a reconnect to my Metasploit listener. Even uninstalling and re-installing Anti-Malware in the usual way didn't seem to wipe my evil update. Only a revert to snapshot (as a VM) was doing the trick.

Now, if the malware is on the endpoint and has sufficient permissions, it can do whatever it wants, with or without this vulnerability. This attack is only reasonable if the attacker can poison DNS responses or interfere with the HTTP connection or otherwise meddle with the network traffic, without having to first get on the target. This is completely possible when the victim is on an untrusted local network, and that's a more difficult trick. But, even the local attack is much easier if there is no attempt at secure comms.

This brings up several concerns. First, if you're going to be operating in the hostile space of malware, you absolutely need to ensure that you're, at a minimum, using reasonably secure protocols for communication. In this day and age, it's pretty unconscionable to rely on plaintext for anything important. As Ian Goldberg said at his ShmooCon 2014 address, we need to get to a point where ciphertext is the default. There's really no excuse any more. Death to HTTP.

Another troubling thing here is that while CVE-2014-4936 was assigned, and the vulnerability was reported to the vendor, there seems to be no mention of this problem in MalwareBytes' release notes. It's customary to thank the discoverer there, but more importantly, alert the user base that this is a real problem and they need to update, pronto. So, while Yonathan was thanked in the Hall of Fame, users don't appear to have been alerted. Even if they were, they would update normally... and are exposed to exactly the risk introduced by the vulnerability in the first place. It's a Catch-22 for sure, but MalwareBytes could and can mitigate this by offering some kind of offline update and announcement, and some hash signatures of a safe, manual update. So far, that doesn't seem to have happened. No release note, no announcement on Twitter, no sticky post on its forums... nothing. This is not a healthy response from a security-centered company.

I don't want to pick on MalwareBytes. Really, I don't. Everyone ships the occasional vulnerability. But if these guys, who are plenty smart and savvy to the ways of network and consumer security dropped these particular balls, how do we expect non-expert software vendors to update and handle disclosure sensibly? We need to knock this cleartext business off for starters, that much is sure. Then, let's get some kind of consistency around communicating updates, especially in the face of bugs in the updaters themselves.

New Modules

In addition to the Anti-Malware exploit, we have ten new modules since the last Wrapup blog, including a new sandbox escape exploit for Microsoft Internet Explorer, MS15-004, implemented by our own Juan Vazquez. That's a pretty big deal -- you can read up on that over at TrendLabs.

Exploit modules

Auxiliary and post modules