In the past two weeks, Log4j has continued to drive security news, with more vulnerable platforms being found, and additional CVEs coming out. First up is work done by TrendMicro, looking at electric vehicles and chargers. They found a log4j attack in one of the published charger frameworks, and also managed to observe evidence of vulnerability in the Tesla In-Vehicle Infotainment system. It isn’t a stretch to imagine a piece of malware that could run on both a charger, and an EV. And since those systems talk to each other, they could spread the virus through cars moving from charger to charger.
Log4j is now up to 2.17.1, as there is yet another RCE to fix, CVE-2021-44832. This one is only scored a 6.6 on the CVSS scale, as opposed to the original, which weighed in at a 10. 44832 requires the attacker to first exert control over the Log4j configuration, making exploitation much more difficult. This string of follow-on vulnerabilities demonstrates a well-known pattern, where a high profile vulnerability attracts the attention of researchers, who find other problems in the same code.
There are now reports of Log4j being used in Conti ransomware campaigns. Additionally, a Marai-based worm has been observed. This self-propagating attack seems to be targeting Tomcat servers, among others.
WebOS Falls to a Snapshot
On to the WebOS platform itself. Individual apps are sandboxed, but web apps run their code in the context of the WebAppMgr (WAM), their browser based on Chromium/V8. While the individual apps are sandboxed, WAM is not. The kicker is that a web app can specify its own snapshot to load into V8. Loading a corrupted snapshot gave [David] JS type confusion, and an arbitrary read/write primitive as a result. From there, breaking out of running JS and into actual shellcode was fairly easy. This RCE runs as the “wam” user, but this is a mildly privileged account. Notably, wam has access to
/dev/mem — direct access to system memory. Escalation to root is nearly trivial.
[David] has published the full PoC, noting that LG notoriously underpays for bug bounties. I do disagree with his assertion that this attack entirely relies on side-loading a malicious app, for the simple reason that LG does run their Content Store for this platform. A malicious developer may be able to bypass any malware detection routines that LG uses to vet apps. Malicious apps on the app store is certainly nothing new, after all. The worst part of this exploit is that it’s difficult to put one’s finger on where the vulnerability lies.
Four-Bug Team in Teams
[FABIAN BRÄUNLEIN] found some interesting unintended behavior in Microsoft Teams’ link preview feature. The first issue is an Server Side Request Forgery. The link preview is generated at the Teams server side, and by definition requires opening the page to generate the preview. The problem is the lack of filtering — linking to 127.0.0.1:80 generates a preview of what is located on the Teams server’s localhost.
Up next is a simple link spoofing technique. This one uses a tool like Burp to change the data sent by the Teams client. Part of the message that gets sent when embedding a link is the URL to call for preview generation. No further validation is done, so it’s possible to generate a preview from a benign URL, while the actual link goes to an arbitrary page. The third problem is related, as the link to the thumbnail itself is also in this message, and can be tampered with. The interesting use-case here is that an attacker could set this to a URL that they control, and extract information from a target, namely the public IP address. Now this is blocked by the target’s client on most platforms, but on Android the checks were missing.
And finally, also an Android-only issue, an attacker can send a “Message of Death”, essentially a message malformed that crashes the app just by trying to render the preview. This one crashes the app every time the user tries to access the chat, effectively locking the user out of the app altogether. Now these aren’t earth-shattering issues, but Microsoft’s collective shrug in response is… underwhelming. They have stealth-patched the IP address leak, but it’s apparently still possible to spoof link previews, as well as crash the Android app.
Researchers at RedTeam Pentesting took a look at a PBX designed by Auerswald, a German manufacturer of telecom equipment. What caught their eye was an advertised service, where Auerswald could perform an admin password reset for a customer locked out of their equipment. This is a textbook backdoor, and definitely warranted investigation.
Their approach, rather than attacking the hardware directly, was to grab the latest firmware package from Auerswald’s web site, and analyze that. Use of the
dumpimage utilities gave them the root filesystem they needed. Working through the web of config files, they settled on the webserver binary that probably contained the password reset backdoor. Just a note, it’s very typical for embedded devices to include all their user interface and configuration logic in a single httpd binary.
Given a binary, they turned to what has quickly become the favorite tool of security researchers everywhere, Ghidra. They had one more hint, the “sub-admin” user, so searched for that string using Ghidra. Paydirt. Drilling down through functions, the hardcoded username “Schandelah” was there. A bit more sleuthing came up with the password function. For each of these PBXs, the backdoor password is the first 7 characters of the MD5 hash of, the unit’s serial number + “r2d2” + the current date.
Just for fun, the researchers used Ghidra to search for other uses of the backdoor password function. Turns out, if the admin user is specified, and the password doesn’t match the user-configured password, it’s compared to this algorithm. If it matches? You’re logged in as admin on the hardware. This is obviously more useful than resetting the admin password, as it allows access without any obvious changes to the system. The whole article is a great tutorial on using Ghidra for this sort of research.
Auerswald very quickly pushed out firmware changes to correct the problems identified. A backdoor like this one, that is publicly disclosed, is not nearly the legal and ethical landmine like some of the others we’ve discussed here. There is still a problem with the implementation — a password reset should also reset the device to factory settings and delete user data. Anything less is inviting major data disclosure.
This Windows Active Directory privilege escalation vulnerability is fascinating for its simplicity. It’s a combination of CVE-2021-42287 and CVE-2021-42278. Windows active directory has two distinct kinds of accounts, user and machine accounts. Machine accounts are used to bring specific hardware into the domain, and typically end with the dollar sign (MyMachine1$). By default, a user can create machine accounts, as well as rename those accounts. The first problem is that a user could create and then rename a machine account as the same as a domain controller, just without that final dollar sign. For example, I could create
MyMachine1$, then rename it to
DomainController1$ would still exist, and the domain would see those as separate machine accounts.
Modern Windows Domains use Kerberos under the hood, and Kerberos uses the ticket paradigm. An account can request a Ticket Granting Ticket (TGT) that acts as a temporary authentication token. Think of it as a password replacement, that can be automatically sent with requests. The attack is to request a TGT for the renamed machine account, and then rename that account once again, back to
MyMachine1. The key is that the attacker still has a valid ticket for the
DomainController1 account, even though an account no longer exists with that exact name. Next, the attacker requests a session key from the Key Distribution Center (KDC) using this TGT. The KDC notes that the requesting account doesn’t exist, and helpfully appends the dollar sign and runs the check again. It sees the valid TGT for
DomainController1, and returns a session key authorizing the attacker as
DomainController1$, which happens to be a domain admin account.
Chrome’s Aging Pains
It’s said that we didn’t get a Windows 9, because too many old apps were written with regex that would prevent execution, complaining that the application wouldn’t run on Windows 95 or 98. Chrome is trying to prevent a similar problem, as Google’s developers see version 100 on the horizon. This sort of thing has bitten web browser before, notably when Opera released version 10, further breaking the user-agent string in the process. Firefox is getting in on the fun as well, and both browsers’ developers have a request of you: Browse the web with a spoofed user-agent string, and let them know what breaks as a result of version 100. This would be a good opportunity to test your own sites, too. Let us know if you see any particularly odd results.