The Bug Report – July 2022 Edition

By Trellix · August 3, 2022
This story was also written by Kasimir Schulz and Jesse Chick

Your Cybersecurity Comic Relief

Why am I here?

Welcome to the Bug Report, Heat Wave Edition! In the face of chronic irritability and soggy-pants syndrome, we are back at it again, trawling for this month’s spiciest software-defined mishaps for your schadenfreudian pleasure. (Or, rather, we made the intern do it.) So crank up the AC, kick your feet up with your cold beverage of choice, and enjoy the cream of July’s vulnerability crop.

Fortunately, most of the vulnerabilities that we report cannot cause fires no matter how they are abused. This month, however, we have something special for you with CVE-2022-2107. But don’t worry, if that’s too hot for you to handle we also have two more vulnerabilities that cause headaches:

• CVE-2022-2294: WebRTC
• CVE-2022-2107: MiCODUS MV720
• CVE-2022-20857: Cisco Nexus Dashboard

CVE-2022-2294: Heaps of 4th of July fun in Mountain View!

What is it?

We have all heard and rolled our eyes at the banal adage that money cannot buy happiness (unless, of course, you are in Las Vegas). Money also cannot buy immunity from critical browser vulnerabilities, as one of the richest companies in the world learned once again earlier this month. While we in the United States were out celebrating Independence Day—or “Good-riddance Day,” as it’s known across the Pond—Google was busy hustling out a patch for a high-severity heap-based buffer overflow (CWE-122) in WebRTC.

If you are like us and have seen “WebRTC” crop up in technical documentation time and time again without sufficient cause to look up what it is, here is all you need to know. WebRTC stands for Web Real-Time Communication. It is used in most common browsers (including, most notably for us, Google Chrome) to enable browser-to-browser video and audio streams without the need for plugins or other third-party installations. It is enabled by default in Chrome.

Who cares?

If you are reading this article, you’re using a web browser. If I were to guess, you are viewing this article with Chrome and, according to statcounter, I’d be right about two out of three times. Although the existing proof of concept (POC) referenced below was tailored to Chrome running on Windows hosts, it is likely that all browsers leveraging WebRTC are vulnerable to similar exploitation. This list includes Safari and Edge, the runners-up in the Chrome-dominated browser market. And it’s not just desktop applications; this vulnerability affects Android devices as well. You get the idea. True enough, an attacker will almost surely need to go to all the effort of concocting an elaborate attack chain around CVE-2022-2294 to do serious damage. Still, how safe does that make you feel?

Due to the give-and-take nature of responsible disclosure, very few details about the precise nature of the vulnerability tracked as CVE-2022-2294 have reached the public domain. What we do know for certain, thanks to some crafty forensic work from security researchers with Avast, is that this vulnerability has been exploited in the wild numerous times by known threat actors as part of a larger, targeted attack chain deployed against specific organizations in the Middle East.

Perhaps the most accessible path to appreciating the potential impact of this on information security is through a cursory understanding of the event which led Avast to report the vulnerability to Google in the first place. Attackers were able to gain initial access to a Lebanese news agency’s protected network via cross-site scripting (XSS). Their malicious JavaScript then scanned the set of accessible hosts for indications of vulnerability to CVE-2022-2294, delivering the exploit with precision. The shellcode execution achieved via WebRTC was used to deliver a sophisticated form of spyware known, graphically, as DevilsTongue, which was injected into the victim’s kernel to furtively siphon off private data to the attackers. The good people at Avast elaborate further on the details of CVE-2022-2294’s discovery and its in-the-wild exploitation in their own blog.

What can I do?

Luckily for us, Google engineers don’t like fireworks and pushed out a patch within days of initial disclosure. Microsoft followed suit the following day (July 5) with a patch for Edge, and Apple, taking its sweet time, patched Safari on the 20th. If you have automatic browser updates enabled (which you probably should, hint hint), you are already impervious to this piece of mischief. Chrome users who prefer manual updates should ensure they are running version 103.0.5060.114 or newer.

CVE-2022-2107: Anyone know a good automotive exorcist?

What is it?

Let’s be honest, hacker movies piss us off. Simply enter the master password and you’re in? Give us a break. Well, looks like Hollywood isn’t that far off after all. CVE-2022-2107 is a hardcoded key in the API server belonging to MiCODUS, a company that sells professional GPS trackers. This CVE may just be a hardcoded key in the API server, but it allows attackers unauthenticated access to log into the web server, to impersonate users, and directly send commands to the GPS trackers of MiCODUS MV720 devices. Rather than logging in and obtaining a key, attackers can use the hardcoded key when accessing API endpoints. CVE-2022-2107 gives attackers power on par with Jeff Goldblum in Independence Day, letting a hacker use any device with internet capabilities to take down entire fleets of vehicles. By using the hardcoded key an attacker can cut off fuel to vehicles, enable and disable alarms, and track the vehicles’ GPS location in real time. The key also allows attackers to access and modify all other data such as routes and geofences. Now, I know what you must be thinking, this sounds too good to be true, there must be some catch or some sort of condition for when this vulnerability can be exploited, and you would be right. In order to target the GPS trackers an attacker will need to know the device ID, but sadly for the users, this is sequentially generated.

Already sweating like Ted Striker in Airplane? Well… BitSight, the company that reported this CVE, reported several other vulnerabilities including information about device usage and vulnerable attack surfaces. Among these vulnerabilities was a way to send commands directly to the tracker (CVE-2022-2141) allowing an attacker to execute commands if they had the password for the device. BitSight also found that since the device did not prompt the users to change their password, most (94.5% of the sample) devices used the default password of 123456.

Who cares?

Are you part of a Fortune 50 company in energy, oil, or gas? How about a national government or law enforcement agency? Maybe you are part of a manufacturing conglomerate? No? So, then you think that you probably shouldn’t worry about this vulnerability, right? Wrong. Not only does the vulnerability have the potential to shut down entire supply chains by turning off fleets of cars, but the vulnerability also allows attackers to shut off cars potentially causing accidents on the road resulting in potential injuries. Over the course of several months, BitSight gathered data and identified differences in the usage of the MiCODUS devices throughout the globe as seen in the graphic below.

In their report, BitSight published proof of concept attacks for each reported vulnerability along with publishing the hardcoded key for the API server. BitSight first contacted MiCODUS on September 9, 2021, however, luckily for malicious actors, MiCODUS has been slower than congressional proceedings when it has come to patching. As of the writing of this blog the hardcoded key can still be used to access any API endpoint injunction with the device ID. Device IDs are easy to guess through brute force methods as they are sequentially generated based on the format 72011XXXXXX.

Geographical differences in sector usages found by BitSight

What can I do?

If you have read our bug reports in the past you know that normally our advice is to Patch, Patch, Patch!! However, with this CVE there is nothing that the average users can do other than disable their devices. The vulnerability described in CVE-2022-2107 exists within MiCODUS’s server and can only be patched by them. For users and organizations hosting their own API server, make sure that you have proper authentication on API endpoints.

While there is nothing the average user can do for CVE-2022-2107 other than disabling their devices, there are things that they should do for the other CVE’s filed by BitSight. The most important of these is to update your default password. According to BitSight, 94.5% of the devices they sampled were using the default password and could therefore be controlled without the need for other vulnerabilities.

CVE-2022-20857: Ignorance isn’t always bliss…

What is it?

It’s not only college business majors who enjoy pretty, graphical abstractions of dense technical information; we command line folks love a nice interactive overview of our networked devices, too. That is assuming, of course, that said dashboard is not riddled with vulnerabilities, like the Cisco Nexus Dashboard. During a recent internal audit of Cisco’s product suite, ASIG (Cisco’s Advanced Security Initiatives Group) discovered three serious vulnerabilities affecting all versions of the Nexus Dashboard, the most critical of which is CVE-2022-20857.

The culprit is a single API endpoint which lacks authentication (CWE-306), exposing an attack vector through which a malicious agent could achieve remote code execution as root over HTTP. To appreciate the scope of the vulnerability more fully, we need to establish a rudimentary understanding of how Nexus Dashboard is architected. Logically speaking, the dashboard consists of a cluster of several services supporting its many available features. This cluster is exposed to two distinct network interfaces:

• The management network, over which information is exchanged between the cluster and the Dashboard GUI, including actions such as firmware uploads and other core services e.g. SSH and DNS.
• The data network, which handles all traffic between the cluster and the rest of the connected Cisco infrastructure, as well as intra-cluster communication.

The vulnerable API endpoint lives in the data network, suggesting that exploitation of CVE-2022-20857 could allow an attacker to pivot to any host reachable by the compromised device.

Who cares?

At risk of stating the obvious, if you or your organization is using the Nexus Dashboard, this and the other vulnerabilities outlined in Cisco’s security advisory should be of top concern. In the worst-case scenario, a compromised host with access to core internal routing and hosting services is about as bad as it can get in information security.

What can I do?

Before any additional sphincter-tightening takes place, you should know that Cisco has patched these vulnerabilities in the May 8th release (2.2.1e) of Nexus Dashboard. If you’re unsure of which version your organization is currently using, you can verify this easily by logging in to the Dashboard’s command line interface via SSH and running acs version. All versions prior to 2.2.1e are vulnerable, so your network administrator should update to this or the subsequent version 2.2.1h, available as of June 6. This can be done by the recommended means of upgrading your entire Dashboard cluster in one go, or by manually upgrading individual nodes in the cluster if needed.