Trellix logo
Trellix CEO
Our CEO on Living Security

Trellix CEO, Bryan Palma, explains the critical need for security that’s always learning.

Gartner Marketplace Guide (XDR)
Gartner® Report: Market Guide for XDR

As per Gartner, "XDR is an emerging technology that can offer improved threat prevention, detection and response."

Trellix Launches Advanced Threat Research Center
Trellix Launches Advanced Research Center

Trellix announced the establishment of the Trellix Advanced Research Center to advance global threat intelligence.

The Threat Report - Summer 2022
Latest Report

Our Summer 2022 threat report details the evolution of Russian cybercrime, research into medical devices and access control systems, and includes analysis of email security trends.

Trellix CEO
Our CEO on Living Security

Trellix CEO, Bryan Palma, explains the critical need for security that’s always learning.

Stories

The latest cybersecurity trends, best practices,
security vulnerabilities, and more

The Bug Report — September 2022 Edition

The Bug Report – September 2022 Edition
As long as it works....

Why am I here?

Welcome back to the Bug Report, don’t-stub-your-toe edition! For those in the audience unfamiliar with how we do things here, every month we filter down that month’s bugs to just a handful of the most critical ones so you can sleep in and tell your boss what great research you’ve been doing.

With a couple of exceptions, September has been a very welcome slow month for major bugs. As such, we’ll step out from the norm a little and cover some vulns maybe more relevant to certain teams than others.


CVE-2022-34721 + CVE-2022-34718: Because two is always better than one

What is it?

While we avoid basing our bug report strictly on CVSS scores, a 9.8 usually catches our attention. There were several to choose from in Microsoft’s September Patch Tuesday, but two in particular seemed especially critical. I decided to take care of both Patch Tuesday bugs in one section because why not? The first is a Remote Code Execution IKE bug, CVE-2022-34721. IKE, or Internet Key Exchange, is the protocol that sets up key exchanges for IPsec used in Virtual Private Networks. Essentially, all modern Windows versions with IPsec enabled are impacted. Do you remember all those work-from-home folks you set up VPNs for? Yeah, those are the ones you should be concerned about.

The second Patch Tuesday bug that caught my attention was CVE-2022-34718, another 9.8 RCE. This vulnerability is found in the Windows TCP/IP stack and, like CVE-2022-34721, it impacts systems running IPsec. Only those running IPv6 will be affected, but you’d have to disable IPv6 entirely to mitigate it. This bug is highly likely to be wormable, highly likely to be exploited, and highly likely to have a working PoC out there in the wild. How do I know the latter? Because a PoC was leaked on Github and was quickly taken down by administrators. That’s not before some automated PoC collection tools discovered it, however. It’s naïve to think no one else got a copy before it was removed.

Who cares?

Do you use VPNs on Windows? That means you should care. If you’re running IPv6 you should double care. Pretty much every Windows shop with remote workers or frequent travelers should be paying close attention to this one.

What can I do?

As I stated before, these were from September’s Patch Tuesday. If you need to do anything you are already a month late. Get those patches ASAP! Make sure your users are up-to-date and scold them (as nicely as possible) if they are not. I get it, sometimes you can't patch right away. However, we’re talking about a wormable unauthenticated RCE bug with a leaked PoC here. A month is too long to wait!


CVE-2022-32917: If I had an Apple for every time...

What is it?

Privilege escalation vulnerabilities don’t often get the attention they deserve. Why not? They’re essential to many malware campaigns. True, they aren’t as flashy as RCEs, but without them many campaigns and malware families would just fall flat. What makes CVE-2022-32917 interesting is that it effects MacOS, iOS, and iPadOS. That pretty much covers every device in Apple’s infamous “ecosystem.” Well, maybe not Apple Watches but are those company-managed anyway? To make matters worse, Apple has acknowledged that there are reports of attacks in the wild. Not much more information is available yet, but an actively exploited kernel privilege escalation across all your Apple devices should kick start your morning.

Who cares?

Apple users and the IT shops that manage them should care. You can be sure cybercriminals will. Again, this is actively exploited so if you haven’t patched, you’re already behind. It impacts common BYOD items such as iPhones so containment may become an issue. As we all know, users always keep their devices up to date.

What can I do?

Without more information about the vulnerability and the in-the-wild exploits, your only option is to patch. iPadOS and iOS should be running version 15.7 (or 16, for iOS). MacOS should be running either 11.7 or 12.6. Beyond that? Sit and wait. Since Apple knows of the exploits, we hope to see some form of writeup soon. It’s not uncommon for security researchers to give some time for patches to be applied before disclosing their findings. Until then, patch, patch, patch.


CVE-2022-39197: September, Please-Don’t-Hack-Back month...

What is it?

Cobalt Strike may not be familiar to your average IT professional, but it’s the bread and butter for many red teams out there. On September 20th an out of band patch for Cobalt Strike was deployed to fix several issues, including CVE-2022-39197, a Cross-Site Scripting (XXS) vulnerability. Typically, XXS vulnerabilities don’t hit our radar, but partially because of the slow month and partially because of the irony of a hacking platform exploit, here it is. Essentially, a bad actor can set malformed usernames in a beacon configuration and get code execution on the Cobalt Strike servers. Of the existing PoCs I’ve found, most have simply been used to troll the servers with random images. Those who live by the sword, eh?

Merci, l’ANSSI (mais where is ze CVE number)
Figure 1: Reproduction by @xzajyjs from https://www.cnblogs.com/xzajyjs/p/16724512.html

Who cares?

If you’re a large company, you may hire a red team for a security assessment. Maybe you even have your own. In either case, those red teams should care, as a very large portion of them use Cobalt Strike. For any cybercriminals using Cobalt Strike, you should not care. Ignore the patch and keep the old vulnerable version, everything will be just fine.

What can I do?

Make sure you’re on version 4.7.1. In your TeamsServer.prop file, you should have limits.beacons_xssvalidated=True set. If it’s set to False, you have a problem. If you’re negotiating a red team engagement with a third party, ask them what tools and versions they intend to use. Point them to this bug report or the official disclosure if you find they’re using an old version of Cobalt Strike.


CVE-2007-4559: Wait, 2007? Is that a typo?

What is it?

That’s not a typo. We’ll finish off this bug report with a 15-year-old Python bug that keeps on giving! Some new research on this bug puts its potential impact at 350,000+ open-source repositories. Full disclosure, that was us. In our defense, the original bug was published on August 27th of 2007, which is really really close to September 2022 - give or take 15 years. So, what does this bug do? Essentially, it’s a directory traversal bug in which use of tarfile.extract() or tarfile.extractall() could allow an attacker to overwrite arbitrary files on the system. In some circumstances, this can even lead to code execution. It’s a very easy mistake to make as the default behavior of the tarfile module, and the most straightforward implementation, leads to this vulnerability. Just look how simple it is:

Figure 2: Vulnerable extractall()
Figure 2: Vulnerable extractall()

Who cares?

Developers who write Python code or use Python open-source software should be aware of it and its prevalence. Why is it so prevalent? Because the response to this bug was to warn about the dangers of using untrusted tar files in the official documentation. Of course, we all read the official docs, right? Most developers either failed to read the warning or ignored it altogether! Now, I’m all for ignoring annoying things but security warnings should be an exception. Skip ahead 15 years and now most open-source software packages using tarfile do things insecurely and may have found their way into your supply chain.

What can I do?

In this case we’re trying to do the hard work for you. We have been hard at work patching as many of these open-source projects as possible. Pull requests kicked off late September, so project maintainers can add the patch to their code base. If you are a project maintainer, keep an eye out for our pull request or write your own tarfile sanitization patch as soon as possible. If you are a user of open-source software, update your packages as soon as they have a patch applied. Not every project will get patched, nor will every maintainer accept the pull request. In those cases, and for closed-source software, you can use tools like Creosote to scan your own projects. For you developers out there, now you know. Read the warnings. Your code may stick around a looong time so let’s keep this ancient bug from surviving another 15 years.

Get the latest

We’re no strangers to cybersecurity. But we are a new company.
Stay up to date as we evolve.

Please enter a valid email address.

Zero spam. Unsubscribe at any time.