Apple, VMware, supply chain and breaches - F5 SIRT This Week in Security - Aug 7th-13th 2022

This Week in Security

August 7th to August 13th 2022

Editor's Introduction

Aaron here as your editor this week, standing in for Lior while he is out on training. 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.

Apple Zero-Day Vulnerabilities

I am clearly breaking protocol here and straying well outside of my lane (my lane, this week, being August 7th to 13th) and bringing you something from just a couple of days ago.

On the 17th, Apple disclosed details of two vulnerabilities[1]; CVE-2022-32893 (sometimes apparently mis-quoted as CVE-2022-32892[2]) affecting WebKit, the HTML renderer used in Apple browsers, and CVE-2022-32894 an arbitrary code execution vulnerability in the iOS and macOS Monterey kernel.

Of course, Apple regularly discloses and patches vulnerabilities, so what is unusual about these two?

Because -32893 allows arbitrary code execution within the context of the browser, an attacker can utilise it to exploit -32894, escape the browser sandbox, and take complete control of the target device - potentially allowing the attacker to install a persistent, invisible, root-kit or steal any information they desire from the target. In isolation, either bug would be bad, but together they are a potent cocktail!

Secondly, both bugs are known to have been exploited in the wild and researchers believe they have already been weaponised as a complete exploit chain. There is also talk—although I haven't been able to track it down—that these vulnerabilities were both disclosed ahead of Apple patching by a disgruntled researcher who gave up waiting for Apple to fix them in a timely manner. This should serve as a warning to all of us who deal with researchers and/or bugs on a regular basis; sometimes they just won't wait for the vendor.

This isn't the first time Apple has patched a 0-day known to be exploited, of course (March 2022, October 2011) and if you don't already have automatic updates turned on - well, you really should.

In short, update to iOS 15.6.1 or macOS 12.5.1* if you haven't already!

*One thing to note; this does not appear to affect macOS versions earlier than Monterey, at least based on Apple's disclosure, since Apple still supports Catalina (10.15) and Big Sur (11) with security updates, and no updates have been released for those versions.

While we're on the topic of late-breaking critical vulnerabilities; don't think you get away scot-free if you run Chrome! Google pushed an update[3] (104.0.5112.101 for Mac/Linux, 104.0.5112.102 for Windows) on the 16th which fixes one Critical vulnerability, six Highs (of which one is known to be exploited in the wild) and four Medium vulnerabilities.

VMware critical vulnerability

Do you remember VMWare announcing two patched vulnerabilities (CVE-2022-31656 and CVE-2022-31659) on August 2nd[1]? I do, mostly because it was the day before our own August Quarterly Security Notification[2] (QSN)! At the time, the reporting researcher teased that they would drop their full analysis after giving VMWare customers time to patch, and that's precisely what they did on August 9th[3], this very quickly led to a PoC for unauthenticated remote code execution in VMware ONE Access, Identity Manager and vRealize Automation[4].

Based on what we have seen previously with Critical vulnerabilities, we can assume that the PoC will have been quickly weaponised and integrated into botnets, and indeed, there are reports of exploitation being detected on the same day the PoC was released[5] but if you haven't, this is another "patch now" if you use VMware ONE, Identity Manager or vRealize Automation.

Source code supply-chain security

A couple of 'big ticket' items from the last week or so relating to the security of the software supply chain, with one being a cautionary tale on why you shouldn't necessarily trust everything you read on Twitter.

First let's talk Python for a moment. Python is an immensely popular language today (according to a StackOverflow survey[1]), used for everything from writing websites to data analysis. Part of that flexibility of use-case comes from the vast landscape of libraries, things like Flask for web development, NumPy and Pandas for data analysis. A vast landscape of libraries needs an easy way to manage dependencies, though, and so that's where tools like pip and PyPI[2] come in. PyPI is a database of libraries used by tools like pip to find, download and install both the library you are looking for any dependencies - it's a kind of name resolution, if you will. And what is popular with the original name resolution system, DNS? Typosquatting. What did someone recently do in PyPI[3]? You can see where I'm going with this.. a malicious PyPI user published around a dozen malicious packages with names very similar to legitimate packages - imagine Padnas, if you will. When these packages were installed by pip, they would run a post-installation script that downloaded Windows malware from a GitHub repository with the aim of carrying out whatever tasks the author wanted.

In the end, it seems the only thing the author was able to do before discovery was launch a Denial of Service attack... which seems like a best-case scenario here, because there are far more nefarious (and stealthy) things which could have been accomplished to breach target organisations, steal intellectual property, inject back-doors into code ultimately deployed to customers and so on. I feel like the author missed a trick here..

The next thing I'd like to bring up also links to GitHub. A report popped up on Twitter, which quickly gained traction, that some 35,000 legitimate GitHub repositories had been breached and had malicious code injected[4] which would send the environment of the script (e.g. security keys, AWS keys etc) off to an attacker-controlled server. That tweet on August 3rd pretty quickly gained thousands of retweets and tens of thousands of likes, and even though the original author very quickly corrected himself to '35k "code hits", not repositories' and clarified that these repositories were clones of legitimate repositories[5] with typosquatting names, the original message is the one that got picked up and run with. GitHub very quickly responded[6] to confirm that no compromise had taken place, so this just serves as another reminder to be very careful what code you ingest into your projects and to make very sure you don't accidentally typo in the name of a library you're installing, and also, make sure the person whose tweet you are reading has actually finished their research before posting...

Recent breaches

What issue would be complete without a couple of breaches for good measure?

On August 8th, Twitter disclosed a breach which had allowed an attacker to gain access to the account data from 5.4 million users[1] (if you ask Elon Musk, 5.39 million of those are bots[2]..). The impact here, isn't really that data was leaked - I know my data has been leaked by many other sites prior to this, though I was also impacted by the Twitter breach according to www.haveibeenpwned.com - but that the leak would allow someone to tie phone numbers back to user accounts. If those phone numbers also appeared in other breach data, they could potentially de-anonymise an anonymous Twitter account, leading to fears of reprisals from people in vulnerable positions. Compounding this, of course, is the fact that Twitter strongly advises two-factor authentication and the default option is for SMS based 2FA rather than an authenticator app like Duo, Google Authenticator or Authy. SMS 2FA is infinitely better than nothing in every scenario except for the one where it leaks your phone number and erases your anonymity..

On August 10th, Cisco[3] disclosed a breach which had taken place in May. The breach happened when an attacker compromised an employee's personal Google account, and used stored corporate credentials within that account to subsequently breach Cisco. In order to defeat MFA they phished the user via telephone calls to persuade them to accept the push notifications being delivered to their MFA device and, from that point were able to enroll their own MFA devices and remove any reliance they had on social engineering. Looking at the Talos briefing the attacker dropped just about every tool you can think of (from TeamViewer to Mimikatz) and aimed for persistence, likely to then sell-on the access they had gained.

The Talos briefing is excellent and I highly recommend reading it - they win points for their transparency, too.

On August 15th, reports appeared that a ransomware gang had breached one of the UKs water companies[4] - Thames Water being cited initially but with other analysis suggesting South Staffordshire Water - and had access to employee data, internal systems and, most worryingly, the industrial control systems responsible for maintaining the chemical balance of our drinking water. A breach of critical infrastructure like this could easily cause real, material damage to people's livelihoods and lives so perhaps we should rethink that whole "everything on one network" approach and have some air-gapped SCADA networks? Just a thought from a bystander.

Lastly, the 117th Congress

On August 17th a tweet appeared[1] and quickly gained traction suggesting that it would soon be practically impossible to sell any software into the DoD/DHS because the bill requires software to be "free of all known vulnerabilities". The full text of the Congressional Bills is available online[2] and the section we're discussing here is sec. 6722 where the relevant paragraphs actually say:

(1) A certification that each item listed on the submitted 
        bill of materials is free from all known vulnerabilities or 
        defects affecting the security of the end product or service 
        identified in--
                    (A) the National Institute of Standards and 
                Technology National Vulnerability Database; and
                    (B) any database designated by the Under Secretary, 
                in coordination with the Director of the Cybersecurity 
                and Infrastructure Security Agency, that tracks 
                security vulnerabilities and defects in open source or 
                third-party developed software.
...
            (3) A notification relating to the plan to mitigate, 
        repair, or resolve each security vulnerability or defect listed 
        in the notification required under paragraph (2).

Now, I know how I read that and it isn't the same way the author of the tweet read it. I am not a lawyer, but my hot take on this is:

For first-party vulnerabilities (that is, directly in code you own) you comply with this by following responsible disclosure. The vulnerability, for the purposes of this bill, doesn't exist until it is disclosed. So, like most already do, you fix and then disclose to MITRE/NVD.
For third-party vulnerabilities (that is, vulnerabilities in libraries you have bought in, or open source components you use) there is a problem; it's not an insurmountable one because the bill actually allows for a fix or mitigation. Fixing third party vulnerabilities in your product and shipping those fixes can often be time consuming (carrying out regression testing, deal with the inevitable breakages) but understanding, documenting, and offering a mitigation for the issue is almost always possible. It costs money in time and resources, of course, but it can be significantly easier to document a mitigation than to provide the fix, especially in a short timeframe.

Time will tell how this particular bill plays out, but it is certainly something that your compliance orgs should be looking at now, if they are not already, especially in conjunction with the executive order of last year[3].