To start our week with vulnerabilities in total, there is a potentially huge vulnerability in Android phones, but that’s Apple’s fault. OK, that’s maybe a little harsh – Apple released the code for their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache license. This code was retrieved and sent as part of the driver stack to several devices from various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was awful, a researcher called it a “wandering colander” of security issues.
Apple has corrected their code internally over the years, but has never pushed these updates to the public code base. It’s a fire-and-forget-source release, and it can cause issues like this. The fact that ALAC was released under a licensed license may contribute to the problem. Someone (besides Apple) has probably found and fixed the security issues, but the permissible license does not require these fixes to be shared with a wider community. It is worth considering whether a Copyleft license like GPL would have had a fix distributed years ago.
Either way, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This kind of error has been used by actors like the NSO group to compromise devices via messaging apps.
Nimbuspwn
Researchers at Microsoft have been looking at D-Bus and the various demons that listen to it. This is interesting because many of these demons run as root, but a non-root program can make calls to D-Bus. It seems likely that some unintended interaction could lead to security issues. Right on the tip, a few issues in networkd-dispatcher can be linked to elevate privileges from user to root. The issues were fixed in networkd-dispatcher version 2.2, so look for at least that release on your Linux distro.
CVE-2022-29799 and CVE-2022-29800 are the two errors, the first being a directory crawl error. A message can be sent indicating a state field for a library name such as ../../maliciousScripts/. The second is a TOCTOU (time-of-check-time-of-use) error, where a script is verified to be rooted, but execution does not begin immediately. Since symlinks can be used in these directories, the trick is to set up symlinks to what appear to be properly secured scripts, and after the check is performed, the link changes to the attacker-controlled scripts.
Via Ars Technica
VirusTotal Got Total
It is difficult to deal with live malware, and running a public website dedicated to security research tends to attract both good and bad attention. In this case, it was other security researchers who discovered that VirusTotal was vulnerable to attack. The error was CVE-2021-22204, a vulnerability in exiftool. VirusTotal uses this as part of its file analysis feature and had not yet integrated the patches. It was straightforward to embed the malicious command and send the file for scanning. When individual hosts embarked on the malware test, they hit the exploit and launched inverted shells back to the researchers. A total victory. After confirming that they had actually hit pay dirt, the researchers from Cysrc handed over their results to Google, which runs VirusTotal, and the vulnerable binary has since been updated.
Yes I agree, what could go wrong?
Do you read the End User License Agreements on the apps you install? Have you ever found the EULA so burdensome that you refused to accept? We may all want to get out of the habit of thoughtlessly accepting the terms of service. Many of these apps use GPS location data, and many of these EULAs indicate that your location data may be sold to advertisers. The data is “anonymized”, which simply means that instead of names or email addresses, the location data is tied to pseudo-random numeric IDs. No one would surely take the trouble to get your data and reveal your identity, right? Right?
According to The Intercept, a few intelligence agencies have taken up location data en masse and automated the de-anonymization process. How many people have their data captured in this real version of The Machine? Something along the lines of three billion units. Yikes.
So about the Pentest …
This was the question [DiabloHorn] considered, with some good guidelines to help any of us in the awkward situation. The first task is to ask what led to a zero result? Was the test delimited too narrow? Too many restrictions on techniques? Not given enough time? It’s all good information to report so the next test can be more profitable. In addition, what worked? If the code used was bulletproof due to a really good test package where fuzzing was already performed, that’s good info too. The whole recipe is a thoughtful exercise, even for the rest of us who are just trying to stay safe.
Psychic signatures continue
Last week we brought the story of Java Psychic Signatures, and less than a week later there’s a particularly fun Proof of Concept to take a look at: Breaking TLS. Since the flawed implementation can be used to secure HTTPS traffic via TLS, it means that a malicious server can authenticate as any desired host. Looks like this would also defeat HSTS and Certificate Liability. The attack also extends to Man-in-the-Middle attacks. Keep in mind that this vulnerability only applies to Java clients that have not been updated. See last week’s coverage for more information.