More LastPass, Microsoft and a very busy CISA - Mar 4 - 10, 2023 - F5 SIRT - This Week in Security

Aaron back with you as editor this week and I've been keeping an eye on all the interesting news. This month I'm going to give you a little update on the LastPass saga with some information that came to light on the 10th, an urgent and out-of-my-week call to make sure you are patching your Microsoft estates after the March 15th Patch Tuesday (details on why below)

A few other things I read recently but haven't included below - either because they are outside of my week or because I haven't fully digested them yet:

Microsoft on Adversary-in-the-middle phishing kits capable of circumventing MFA available for hire or purchase: https://www.microsoft.com/en-us/security/blog/2023/03/13/dev-1101-enables-high-volume-aitm-campaigns-with-open-source-phishing-kit/
Old Shein application silently sends clipboard contents to Shein servers (which seems awfully suspcious, but I try not to be too tinfoil-hat!): https://thehackernews.com/2023/03/sheins-android-app-caught-transmitting.html
FortiNet were in the news again with another critical unauthenticated vulnerability in an administrative interface: https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-fortinet-products-could-allow-for-arbitrary-code-execution_2023-028
and finally, reports of a 0day being used against South Korean financial institutions: https://thehackernews.com/2023/03/lazarus-group-exploits-zero-day.html

LastPass and Plex aka "Incident 2"

Jordan wrote about both of the LastPass incidents last week but since his issue of TWIS a few more details have appeared regarding Incident 2; specifically around the third party software that was exploited on the LastPass engineer's home computer.

I will admit that there is an element of conjecture here, so to set the scene:

We know that LastPass officially disclosed that the initial vector was via "third-party media software"[1]
Information then leaked that this software was Plex (most likely Plex Media Server)[2]
Plex reported that LastPass had not disclosed any details to them regarding what vulnerability was exploited or if this was a new or old issue

Now, fast forward to the 10th of March and CISA added Plex vulnerability CVE-2020-5741 to their list of Known Exploited Vulnerabilites[3]. CISA don't, of course, link the two incidents but this seems at least a little suspicious to most people watching the incident unfold.

CVE-2020-5741 allows an attacker with admin credentials to the Plex Media Server instance to execute arbitrary code by manipulating the Photo Library[4] which means that the attacker who compromised LastPass must first have compromised the engineer's Plex account. So how did they do that?

Well, around the same time-frame (August 2022) Plex notified users of a breach and suggested those affected change their passwords[5] so it seems entirely plausible that the attacker gained access to the vulnerable Plex Media Server simply by re-using a password taken from the Plex breach. Of course, that still leaves one question in my mind: Did the attacker first breach Plex to get the password, or were they simply lucky and able to used leaked passwords from someone elses breach? I suspect we'll never know the answer to that (short of both Plex and LastPass disclosing attribution) but either way this attacker clearly put in quite a bit of work to get to the point of breaching LastPass.

One last thing to point out regarding this chain of events - the Plex vulnerability was disclosed in 2020, two years before this all unfolded. There was more than adequate time for even the most lackadasical user to update their media server software and head this whole problem off at the pass.. but, should a personal workstation even have been allowed access to LastPass' production network? BYOD has always made me nervous for precisely this reason - corporate workstations can be tightly controlled (admittedly frustratingly so, sometimes, as the end user!) while end user devices can have all manner of unapproved, potentially buggy or even outright malicious software installed on them and then connected to your corporate network. There was a more naieve time, perhaps, when BYOD seemed like a good idea - a way to cut capital expenditure, make life easier for employees, enabled road warriors etc, but with the modern threat landscape I'm dubious, at best, that the benefits outweigh the potential costs. Could a breach like this have occurred even without Plex being installed? Absolutely! But could it have at least raised the bar a little if it weren't? Also yes.. at least in this authors opinion.

3/15 Microsoft Patch Tuesday

Fire up the patching machines, folks! As various outlets[1] have reported, this Patch Tuesday[2] set contains fixes for 80 vulnerabilities, eight of which carry a Critical rating along with the 72 others across a variety of products. I'm going to concentrate on just two, though:

CVE-2023-23415 - Internet Control Message Protocol (ICMP) Remote Code Execution Vulnerability

Hands up who remembers the Ping of Death[3] (circa the late 90s) or it's 2013 counterpart for IPv6? Well this time we have Remote Code Execution via ICMP[4], but despite the base CVSS score of 9.8 it seems like this might not be as straightforward to exploit as the details suggest. According to Microsoft this is exploitable by sending a fragmented IP packet inside another ICMP packet, however to actually trigger the vulnerability "an application" on the target must be bound to a raw socket. What isn't clear is if this is a specific application or just any application - if it's any application then InfoSec teams might want to take a close look at any standard-deploy software (like EDR products) to see if they listen on raw sockets. I'd suggest keeping an eye on this one for any PoCs that become available to get a better idea of how this is exploited in the real world and, in the mean time, patch as soon as you can.

CVE-2023-23397 - Microsoft Outlook Elevation of Privilege Vulnerability

This sounds relatively innocuous from the title but is, in fact, a Critical (CVSS 9.8) vulnerability that seems trivially easy to exploit given the right circumstances[5], so much so that Microsoft have released a stand-alone advisory from their threat intelligence team which also indicates that this is being actively exploited by attackers[6].

The problem here stems from a feature that I had certainly never heard of; the sender of an email or calendar invite can specify the audio file they want the recipient to hear when the notification fires. If that didn't sound bad enough (imagine the obnoxious sounds you could subject your coworkers to!) the file can be loaded from a UNC path, i.e. a remote server. If the remote server happens to be an attacker controlled SMB server then Outlook will quite happily attempt NTLM negotiation allowing the attacker to harvest the token from their server and attempt to use it in replay attacks against the target infrastructure to gain access with the privileges of the email recipient. Note that this is a zero click vulnerability; the email only needs to be delivered to an Outlook client, it does not need to be opened or interacted with in any way.

If you haven't already, I (and Microsoft) suggest blocking access to SMB (TCP port 445) servers outside of your network which, frankly, has been a good idea for a very long time regardless, but that won't help you if your Outlook clients are outside of your network.

If you must allow outbound SMB then Microsoft also document the option of adding sensitive users to the Protected Users Security Group, but note that this will also disrupt other NTLM activities and might be a deal-breaker for general user accounts.

Microsoft have also provided a script to determine if you have been a target already, and note that they believe a Russian threat actor has already used this vulnerability to target some government, transportation, energy, and military sectors in Europe.

All in all this one is a bit of a howler - it strikes me as a feature that never needed to exist in the first place, though I can absolutely believe how a long lived product like Outlook could end up with a feature like this, that was implemented extremely poorly and in an entirely insecure fashion. This is exactly the kind of thing that a Secure Development Lifecycle is designed to protect against through threat modelling of new features, threat assessments after implementation, code reviews and so on, and Microsoft does - now - have a very robust SDL[7] (as do we here at F5, backed by regular training), but as I say, Outlook has been around for a long time and I wonder just how long ago this feature was introduced.. Remember folks, never operate blindly on user input, because user input is untrusted, and definitely don't operate blindly on things like UNC paths!

There is a complete and excellet write-up of how this vulnerability operates from MDSec, here: https://www.mdsec.co.uk/2023/03/exploiting-cve-2023-23397-microsoft-outlook-elevation-of-privilege-vulnerability/

CISA has been busy

We already talked about the Known Exploited Vulnerability (KEV) list CISA maintains but I spotted a couple more news articles about CISA initiatives last week as well; the first being CISA's Red Team Assessment Key Findings[1] or, as ZDNet more eloquently put it "Do these three things to toughen up your network against hackers"[2], those three things being:

Establish a security baseline of what is normal for you
Conduct regular assessments of your network to ensure your procedures are working
Use phishing-resistant MFA to the greatest extent possible

Now we saw in my opener that phishing kits are out there designed specifically to bypass MFA but, we have to be honest, it's the most easily deployable and most understood (by your end users) mechanism available to add security right now - but in the longer term it is probably worth looking into FIDO passkey if you aren't already (which F5 Labs talked about in their 2023 predictions[3]).

The thing I want to circle back to most, though, is establishing a baseline - this is true of your network behaviour but also crucial to your externally facing services as well; in ESRP incidents we see a big difference in how quickly and effectively we are able to help companies mitigate attacks when the company has a good baseline we can use to distinguish what is normal from what is not, so I can't stress enough how important it is to build those baselines and document that knowledge in your teams.

The second CISA article I saw pointed me to their Ransomware Vulnerability Warning Pilot (RVWP)[1] which amounts to continual scanning for vulnerable devices commonly exploited to launch ransomware attacks - at least for organisations considered part of the US critical infrastructure - and then proactive notification and assistance for organisations found to have vulnerable devices. This is an interesting pilot and I hope it will be something rolled out across a greater section of organisations and mirrored in other countries, though I would be interested to see how these notifications play out; hopefully they will always land with folks with the time and resources to undertake the required patching and not under-staffed, over-streched and under-funded departments who are able to do very little about the problem!