iOS, SQLite and Chrome CVEs, novel C2s and web tracking - This Week in Security - Oct 23rd to 29th

This Week in Security

October 23rd to October 29th, 2022

iOS fixes, Chrome and SQLite vulnerabilities, novel command & control techniques and defeating web tracking

Aaron back with you as your editor this week, and this week I'll be looking at what happened in the week of October 23rd through October 29th, 2022; as always, a lot of news happened and I'm going to pick the top few things that I think were important and focus on those.

In the F5 SIRT we invest a lot of time in understanding the frequently changing behavior of bad actors. Bad actors are a threat to your business, your reputation, and 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 facing a security emergency please contact the F5 SIRT!

Apple iOS & iPad OS

Yet again, here I am, writing about Apple iOS kernel vulnerabilities, is that literally every time I write This Week In? Possibly, because I talked about them in August and September, and here I am again! I suppose I did skip October, but in my defence I didn't write a This Week In during October..

That's hardly surprising, though, if you consider that this is the ninth exploited in-the-wild vulnerability this year which Apple is addressing. This one is known as CVE-2022-42827 and is yet another out-of-bounds write potentially leading to arbitrary code execution with kernel privileges, allowing sandbox escape and complete compromise of the device. Apple fixed this in HT213489 on October 24th for iOS 16.1 and iPadOS 16 and subsequently back-ported the fixes to iOS 15.7.1 and iPadOS 15.7.1 in HT213490 on October 27th so this is your timely reminder that if you don't have automatic updates turned on, you should; but more than that, if you aren't running iOS 16 (and you are using a device which supports it) that you should really move to iOS 16 as soon as possible and then stay up to date moving forward. Apple, like many vendors will drop fixes in the most recent branch first and then back-port them back; sometimes that isn't as obvious as it is in this instance but, generally, fixes tend to be developed in the most recent code branch of a system and then back-ported, even if release order means that the most recent branch isn't the next version to be released, and the closer you are to the head of the line, the more quickly you'll get fixes for bugs.

Although the kernel vulnerability is arguably the most widely impactful vulnerability fixed recently - especially as it is known to be exploited in the wild - that's not all Apple patched recently; in the same security updates Apple also addressed CVE-2022-32946, a bug in the Bluetooth stack dubbed SiriSpy which could have allowed a malicious application with Bluetooth access to record audio destined for Siri or the dictation feature, without needing to request microphone permissions nor any other indications it was listening to the microphone. Some sources indicate the same issue affected (and has been fixed for) MacOS, though I was unable to find confirmation in the official Apple security update notifications.

In short, make sure you are on iOS 16.1/iPadOS 16 or iOS 15.7.1/iPadOS 15.7.1 as soon as possible.

SQLite and a vulnerability old enough to drink

Sometimes, just occasionally, a vulnerability will be disclosed in a piece of open source software that has existed for a long time without ever being discovered; at least, not by someone committed to responsible disclosure. For example, Shellshock was disclosed to the maintainters of bash on the 12th of September, 2014, but had existed in the bash source code since 1989, some 25 years earlier. Shellshock was a huge deal - easily exploitable, impacted almost every Linux system, and was quickly exploited en-masse once disclosed; at least, in this case, evidence suggests that mass exploitation was not underway prior to disclosure.

Fast forward to 2022 and on the 25th of October CVE-2022-35737 was announced as affecting the SQLite library API and, like Shellshock, the vulnerable code had existed for years. Specifically, since at least as early as October 2000, some 22 years prior. Fortunately, unlike Shellshock, the bug is unlikely to result in remote code execution on modern systems (unless you have compiled the library without stack canaries and/or other modern stack protection systems) and will most likely only result in a denial-of-service due to a crash. SQLite is deployed extensively within other applications in everything from embedded systems upward, and without an easy way to know if your application is impacted you are back to code review to determine exposure.

At least the outcome of exploitation here is generally a crash rather than remote code execution, so we can be reasonably (but never completely) sure that bad actors haven't been quietly exploiting this for the last 22 years..

For me this highlights three things:

Open source software is not necessarily more secure than closed source software (the theory of "many eyes" does not really hold true, IMHO)
SBOMs make responding to events like this significantly easier
One day, a bug like this will be disclosed and we will realise that bad actors have been exploiting it, silently, for years

The full details of the problem are eloquently described in the original blog linked below, but in short - you may be vulnerable to this if you use SQLite in your 64-bit application and you pass potentially attacker controlled data to any of the SQLite printf functions without sanitisation and without length restrictions, and are using the format substutition types %Q, %q or %w.

Google Chrome call-to-update

Hopefully, by the time you're reading this, you've already updated Google Chrome. But if you're staring at that little orange (or possibly red, by now) reminder, this is a further reminder - restart to update! On October 27th Google rolled out 107.0.5304.87 for Mac & Linux and 107.0.5304.87/88 for Windows to fix CVE-2022-3723, a vulnerability in the JavaScript engine which is, as of the 28th, known to be exploited in the wild. It does not surprise me that a browser vulnerability would be quickly weaponised, even if the researchers did not disclose a PoC, especially for an open source browser engine where the fixes could be quickly reverse engineered by highly motivated attackers - a browser vulnerability is a great way to deliver other malware onto a target system, especially if exploitation is as easy as directing a victim to visit a maliciously crafted website (for example through a phishing attack), assuming of course you don't just write a malicious Google Play Store app instead, which also seems to be quite common!

Cranefly group and their new techniques

I thought this was an interesting piece on a group and technique I hadn't come across before; the blog is a relatively short read so I'll stick to the highlight: Malware being dropped on an IIS server and using the IIS logs to receive Command and Control instructions. If done well, that means that the attacker doesn't need any outbound access from the compromised host - instead, they send all of their C2 commands and data in the form of disguised web requests, the dropper then scans the legitimate IIS logs for these requests and extracts the contents, saving them as second stage files (in this case, dropping ASP.NET backdoors). Very neat.

Super short version: If you see the strings "Wrde", "Exco" or "Cllo" in your IIS logs, you are potentially being targeted by this group and technique.

Leaking data through tracking pixels

This isn't exactly a breach, but is really a cautionary story on why you need to be careful what information you are collecting and sharing with partners; though for anyone affected (and whose Protected Health Information - PHI - may have been shared with marketing partners), the distinction is probably quite unimportant. Two things stood out to me in this report, though:

First, this isn't the first time we've seen exactly this problem - two months ago, Novant Health made the same notification, and way back in 2015 the healthcare.gov website made exactly the same mistake.

Secondly, healthcare.gov was passing PHI between pages using URL parameters (including income, smoker and pregnancy status) which seems like a huge blunder. Contents of the URI have long been considered unprotected; even if the site in question is served over HTTPS, they are commonly logged on servers, passed in Referer strings and easily accessible in JavaScript.

It isn't clear if Advocate Aurora Health made the same blunder or if they made a different blunder, but either way, they potentially shared quite a long list of PHI/PII with Meta & Google:

IP address
The dates, times, and/or locations of scheduled appointments
Their proximity to an Advocate Aurora Health location
Information about their provider
The type of appointment or procedure
First, last name, first name of a proxy, and medical record number
Information about whether they had insurance

In the article linked below, Malwarebytes naturally suggest using their own Browser Guard to help stop this kind of tracking, but you could also consider Privacy Badger, Ghostery or uBlock Origin; all three are available across the common browsers. Personally, I use both Privacy Badger and uBlock Origin.

That's all for this week - of course a great deal more happened in the week and it is impossible to cover it all, and I'm sure in the next issue of This Week In Security you can look forward to reading about the recent OpenSSL vulnerability which started tickling the news headlines on the 27th, but wasn't really resolved until November 1st.

Updated Nov 10, 2022

Version 3.0

security

twis