Column It is the monster which corrupts all it touches. It is an energy-sucking vampire that thrives on the pain it promotes. It cannot be killed, but grows afresh as each manifestation outdoes the last in awfulness and horror. It is Microsoft Exchange and its drooling minion, Outlook.
Let us start with the most numerous of its victims, the end users. Chances are, you are one. You may be numbed by lifelong exposure, your pain receptors and critical faculties burned out though years of corrosion. You might be like me, an habitual avoider whose work requirements periodically force its tentacles back in through the orifices.
I have recently started to use it through its web interface, where it doesn’t update the unread flags, hides attachments, multiplies browser instances, leaves temp files all over my download directory, tangles threads, botches searchers and so on.
If battling with monsters turns you into a monster, what does marketing them do?
Or you may be one of those poor indentured slaves, the Exchange Admin Tribe. To say it is a picky, bad-tempered master when it works is one thing, but picking up the pieces after it’s spat out its cogs is quite another. The dance of rolling back and rebuilding its baroque catacombs of messages is not the kind of exercise that leaves one feeling refreshed and eager for more.
And Microsoft, the nominal owner and controller of Exchange, is itself damaged by its creation. If battling with monsters turns you into a monster, what does marketing them do?
As of the week of March 1, 2021, it has left you exposed and foolish, with the world looking askance at you even as they struggle to apply the patches to close down the latest security atrocity, then run the scripts necessary to check that the patches - whatever they claim - have applied properly. It’s easy to get things wrong in Exchange admin. After the patches comes not relief, but the hunt for evidence of compromise.
Microsoft fixes four zero-day flaws in Exchange Server exploited by China's ‘Hafnium’ spies to steal victims' dataREAD MORE
This security hole is atrocious. Before the patches were rushed out, there was no defence - it was and is a zero-day pre-authentication remote code execution vulnerability. Attackers can just roll up, drop in their webshells and stroll away with your data. As one Exchange admin wryly commented - if you haven’t lost a night’s sleep already, you’re going to lose two starting tomorrow. (If you’ve been affected by any of the issues raised in this paragraph, then this Reddit thread is the epicentre of self-help.
What raises this from bad not just to very bad but to very very bad, is that this isn’t the first pre-authentication remote code execution vulnerability in Microsoft’s history. In the past couple of years alone, both BlueKeep and SMBGhost have left Windows systems open with no pre-patch defence. In the case of BlueKeep, the vulnerability has been there since the days of XP and Windows 2000 - a long time to survive a regime of regular code reviews and active, evolving test procedures.
Perhaps - whisper it - such regimes may not be Microsoft’s strong suit. The company doesn’t have infinite resources, of course, and prudent management requires always leaving a few billion in petty cash to pay for failed mobile strategies or expensive acquisitions to run down. Yet once you’ve found your first Grade A face-reddener of an open door vulnerability, surely it's worth looking for more?
It’s not that expensive to build a team to go through every place in your code base where packets are handled ahead of authorisation. There are lots of these places, certainly, but if you’ve got code hanging around for more than two decades, you’ve got time to check and check again. Tools and techniques evolve all the time, as does the threat environment. If you’re going to leave your brand of legacy code out there and don’t work to keep it safe, you’ll have to accept the consequences.
The irony is, if Microsoft did things well it would have the chance to capitalise on its work, in so many ways. Let’s say it did have the nous to evolve a testing protocol and tools for flushing out pre-auth vulns before the hackers did - and then open-sourced both. Not only would it get the kudos for being a community-minded security powerhouse ahead of the curve, it would have a much more secure code base while its competitors scrambled to lock theirs down in the face of a world equipped with these new tools.
Here’s the final pulse of poison in Exchange's venom glands, though. Any product that’s so ungainly to use and unwieldy to administrate is going to have a nightmare of a code base to maintain. Good design shines out throughout the lifecycle of a product, in reliability, adaptability and user experience - and so, in precise inversion, does poor design.
Two weeks after Microsoft warned of Windows RDP worms, a million internet-facing boxes still vulnerableREAD MORE
I don’t know what the Exchange and Outlook sources look like: it could be that they are an engineering marvel, a treat to work on and an exemplar of the architect’s art. If so, though, something has gone awfully wrong to disguise the fact. Nightmare monster code bases are nightmare monsters to test and remediate. The evidence is that this is what we have here.
Microsoft can’t end-of-life Exchange, any more than it could avoid putting out BlueKeep patches in 2019 for Windows XP. It can’t magic away all the on-premises Exchange servers into the cloud: this monster has a life of its own. All it can do is commit to, and demonstrate, a program of taming that monster as best it can, by evolving the test systems to find and fix the legacy evils as aggressively as possible.
Until it does that, it’s going to gather in the opprobrium it deserves for foisting so much pain on us mug punters who have to pay for the privilege. Good. ®