WinRAR, human curiosity and VM escapes - Nov 13th - 19th, 2023 - F5 SIRT - This Week in Security

This Week in Security
November 13th - 19th, 2023
WinRAR, human curiosity and new CPU-based virtualization escape vulnerabilities

Editor's introduction

Aaron here as your editor this week for a round-up of notable security news that caught my eye. Keeping up to date with new technologies, techniques and information is an important part of our role in the F5 SIRT. The problem with security news is that it's an absolute fire-hose of information, so each week or so we try to distill the things we found interesting and pass them on to you in a curated form.
It's also important for us to keep up to date with the frequently changing behaviour of bad actors. Bad actors are a threat to your business, your reputation, your livelihood. That's why we take the security of your business seriously. When you're under attack, we'll work quickly to effectively mitigate attacks and vulnerabilities, and get you back up and running. So next time you are under security emergency please contact F5 SIRT.

WinRAR and CVE-2023-38831

My colleague Lior wrote about WinRAR vulnerabilities back in August and since that time WinRAR has continued to pop up in the news. Lior previously wrote about CVE-2023-40477 being actively exploited but there's another vulnerability - CVE-2023-38831 - which keeps popping up. First added to CISAs Known Exploited Vulnerabilities Catalog on 08/24/2023, we have since seen evidence that this vulnerability, which allows an attacker to install malware when a user opens apparently innocuous files within an archive, has been exploited by threat actors associated with nation state activities.

For example, on November 14th the Computer Emergency Response Team of Ukraine (CERT-UA) detailed a phishing campaign deploying a Remote Access Trojan (RAT) using fake adverts for BMW vehicles, attributing the activity to APT29, a threat group attributed to Russia's Foreign Intelligence Service (SVR). Just a few days earlier on November 10th, NSFOCUS published a new report on DarkCasino, the threat actor earlier detailed by Group-IB in August, as well as DarkPing, Konni and Ghostwriter along with a number of other threat actors apparently targeting governments worlwide using CVE-2023-38831.

I think it's safe to say that this won't be the last we see of threat actors delivering exploits using these WinRAR vulnerabilities; small utilities like this tend to be widely installed (especially when they're free.. although we all bought a WinRAR license, right?) and, I think, very infrequently updated. RAR and ZIP archives have existed for more than 30 years and I think we all assume they are so well field-tested and understood at this point that nothing could possibly go wrong, so utilities operating on them are probably the last thing we think about updating and the last thing we think about as a threat vector. The actions of these threat actors serve to remind us that we have to consider all of the software installed on our systems and keep everything up-to-date - remember, these aren't shiny 0days dropped yesterday but rather vulnerabilities dropped three months ago, still in wide-scale exploitation because users are generally extremely slow to update even mundane utilities.

As an aside, the history of the ZIP file format, PKZIP utility and PKWARE is a pretty interesting look into the 1990s and BBS culture; I highly recommend watching Jason Scott's excellent "BBS: The Documentary" in entirety, or just episode 8 if you'd like to learn more.

From WinRAR to .. Stuxnet?

OK, Stuxnet is a leap, but that's what I first thought of when I read this report of an allegedly Russian APT dropping USB sticks containing a new worm dubbed "LitterDrifter" to target Ukrainian entities. This isn't a new technique (clearly! Stuxnet goes back to at least 2010) and you would think we woud all be more than aware of the risks of untrusted media at this point, but I think this and other attacks (like malicious QR codes or Qishing) really tap into that most human of feelings - curiosity.

Clearly, we will never cure people of their curiosity and nor should we; if it weren't for curiosity we wouldn't all be sitting here in front of computers, reading this text, I wouldn't have had a career in technology, and quite possibly none of this technology would even have been invented, but we need better guardrails around our human curiosity. Of course that probably comes down to better scanners (virus, links and so on) and that puts us back into the technological arms race between threat actor and defender - a race that defenders will always lose. Perhaps "Zero Trust" really is the ultimate goal, then; an operating system with complete compartmentalisation between processes would be the most secure way to open or view any untrusted content, short of a virtualization escape bug either in software or hardware, of course. I believe that was the premise beneath Qubes OS, which I remember seeing at BlackHat a few years ago when Zero Trust was the hot new thing, but that level of compartmentalisation comes with some serious drawbacks in usability for the average office worker, so would it ever catch on?

Clearly, I have no answers..

Speaking of escaping virtualization..

There's another new Intel CPU vulnerability! Dubbed Reptar by Google (or CVE-2023-23583 for the rest of us), the vulnerability could allow an attacker to crash the virtualization host, escalate privileges or leak information across security boundaries (i.e., from one guest to another or guest to host) if the attacker can run untrusted code on one guest instance. The complete technical write-up in all it's brilliant x86-64 assembly detail can be found on Tavis Ormandy's blog:

To be clear, there is no evidence this is being exploited in the wild and the only exposure is if you are able to run untrusted (malicious) code on a guest running on a vulnerable CPU at which point you probably have a great many vulnerabilities to worry about, not just this one!

Lest AMD users feel left out, this last week also saw the publication of CacheWarp (or CVE-2023-20592), a vulnerability allowing an attacker (who, again, must be able to run untrusted code on a guest instance) to exploit AMD's Secure Encrypted Virtualization technology (SEV) Secure Nested Paging (SNP) to affect the inegrity of the protected memory space, potentially allowing for privilege escalation across security boundaries. What's interesting to me about this is the attack exploits a feature designed to improve security; SEV-SNP was added in 2020 to build upon SEV and SEV-ES (Encrypted State) and add hardware based security protections for virtualized memory, intended to prevent a malicious hypervisor from accessing the memory contents of protected guests (I am slightly over-simplifying here, the full AMD paper on SEV-SNP can be found on AMD's website). In other words, we tried to make things more secure and someone found a way to exploit that new feature to make things less secure.

The original research paper for CacheWarp appears to be down at the time of writing, but if it comes back online it will be available here:

Remember that in both cases an attacker has to be able to run untrusted arbitrary code on a guest instance in order to exploit this vulnerability - these aren't network based attacks. For virtualization-at-scale platforms like the public cloud this is a significant problem since you cannot guarantee what workloads will be run on your hosts, but for private-cloud systems or virtualization such as we have in BIG-IP with vCMP or Virtual Editions this is significantly less of an issue since untrusted code should be prevented from running by the simple fact that the administrative interfaces are protected and accessible only to trusted networks. F5 is, of course, investigating, and will publish Securirty Advisories as soon as the complete impact is understood for any affected hardware platforms (F5 has no currently supported AMD-based platforms, so there is no impact from CVE-2023-20592, while CVE-2023-23583 is under investigation at the time of writing) - for potential impact to your virtualization platforms (e.g., VMWare) you should reach out to your hypervisor and/or hardware vendors.
Updated Dec 01, 2023
Version 2.0

Was this article helpful?

No CommentsBe the first to comment