Thanks to the precise four-week length of February this year, last month’s coincidence of Firefox and Microsoft updates has happened once again.
Last month, Microsoft dealt with three zero-days, by which we mean security holes that cybercriminals found first, and figured out how to abuse in real-life attacks before any patches were available.
(The name zero-day, or just 0-day, is a reminder of the fact that even the most progressive and proactive patchers amongst us enjoyed precisely zero days during which we could have been ahead of the crooks.)
In March 2023, there are two zero-day fixes, one in Outlook, and the other in Windows SmartScreen.
Intriguingly for a bug that was discovered in the wild, albeit one reported rather blandly by Microsoft as Exploitation Detected, the Outlook flaw is jointly credited to CERT-UA (the Ukrainian Computer Emergency Response Team), Microsoft Incident Response, and Microsoft Threat Intelligence.
You can make of that what you will.
Outlook EoP
This bug, dubbed CVE-2023-23397: Microsoft Outlook Elevation of Privilege Vulnerability (EoP), is described as follows:
An attacker who successfully exploited this vulnerability could access a user’s Net-NTLMv2 hash which could be used as a basis of an NTLM Relay attack against another service to authenticate as the user. […]
The attacker could exploit this vulnerability by sending a specially crafted email which triggers automatically when it is retrieved and processed by the Outlook client. This could lead to exploitation BEFORE the email is viewed in the Preview Pane. […]
External attackers could send specially crafted emails that will cause a connection from the victim to an external UNC location of attackers’ control. This will leak the Net-NTLMv2 hash of the victim to the attacker who can then relay this to another service and authenticate as the victim.
To explain.
Net-NTLMv2 authentication, which we’ll just call NTLM2 for short, works very roughly like this,:
- The location you’re connecting to sends over 8 random bytes known as a challenge.
- Your computer generates its own 8 random bytes.
- You calculate an HMAC-MD5 keyed hash of the two challenge strings using an existing securely-stored hash of your password as the key.
- You send off the keyed hash and your 8-byte challenge.
- The other end now has both 8-byte challenges and your one-time reply, so it can recompute the keyed hash, and verify your response.
Actually, there’s a fair bit more to it than that, because there are actually two keyed hashes, one mixing in the two 8-byte random-challenge numbers and the other mixing in additional data including your username, domain name and the current time.
But the underlying principle is the same.
Neither your actual password or the stored hash of your password, for example from Active Directory, is ever transmitted, so it can’t leak in transit.
Also, both sides get to inject 8 bytes of their own randomness every time, which prevents either party from sneakily re-using an old challenge string in the hope of ending up with the same the keyed hash as in a previous session.
(Wrapping in the time and other logon-specific data adds extra protection against so-called replay attacks, but we’ll ignore those details here.)
Sitting in the middle
As you can imagine, given that the attacker can trick you into trying to “logon” to their fake server (either when you read the booby-trapped email or, worse, when Outlook starts processing it on your behalf, before you even get a glimpse of how bogus it might look), you end up leaking a single, valid NTLM2 response.
That response is intended to prove to the other end not only that you really do know the password of the account you claim is yours, but also (because of the challenge data mixed in) that you’re not just re-using a previous answer.
So, as Microsoft warns, an attacker who can time things right might be able to start authenticating to a genuine server as you, without knowing your password or its hash, just to get an 8-byte starting challenge from the real server…
…and then pass that challenge back to you at the moment you get tricked into trying to login to their fake server.
If you then compute the keyed hash and send it back as your “proof I know my own password right now”, the crooks might be able to relay that correctly-calculated reply back to the genuine server they’re trying to infiltrate, and thus to trick that server into accepting them as if they were you.
In short, you definitely want to patch against this one, because even if the attack requires lots of tries, time and luck, and isn’t terribly likely to work, we already know that it’s a case of “Exploitation Detected”.
In other words, the attack can be made to work, and has succeeded at least once against an unsuspecting victim who themelves did nothing risky or wrong.
SmartScreen security bypass
The second zero-day is CVE-2023-24880, and this one pretty much describes itself: Windows SmartScreen Security Feature Bypass Vulnerability.
Simply put, Windows usually tags files that arrive via the internet with a flag that says, “This file came from outside; treat it with kid gloves and don’t trust it too much.”
This where-it-came-from flag used to be known as a file’s Internet Zone identifier, and it reminds Windows how much (or how little) trust it should put in the content of that file when it is subsequently used.
These days, the Zone ID (for what it’s worth, an ID of 3 denotes “from the internet”) is usually referred to by the more dramatic and memorable name Mark of the Web, or MotW for short.
Technically, this Zone ID is stored in along with the file in what’s known as an Alternate Data Stream, or ADS, but files can only have ADS data if they’re stored on NTFS-formatted Wiindows disks. If you save a file to a FAT volume, for example, or copy it to a non-NTFS drive, the Zone ID is lost, so this protective label is not perrmanent.
This bug means that some files that come in from outside – for example, downloads or email attachments – don’t get tagged with the right MotW identifier, so they sneakily sidestep Microsoft’s official security checks.
Microsoft’s public bulletin doesn’t say exactly what types of file (images? Office documents? PDFs? all of them?) can be infiltrated into your network in this way, but does warn very broadly that “security features such as Protected View in Microsoft Office” can be bypassed with this trick.
We’re guessing this means that malicious files that would usually be rendered harmless, for example by having built-in macro code suppressed, might be able to spring into life unexpectedly when viewed or opened.
Once again, the update will bring you back on par with the attackers, so: Don’t delay/Patch it today.
What to do?
- Patch as soon as you can, as we just said above.
- Read the full SophosLabs analysis of these bugs and more than 70 other patches, in case you still aren’t convinced.
- Consider blocking outbound network traffic to TCP port 445 if you can. If you don’t need to authenticate to external servers (or you can create a definitive allowlist of servers that you need to access, and block all others), then preventing server connection traffic is a sensible precaution anyway. (Microsoft lists this as an official mitigation.)
