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

[David Buchanan] acknowledges that while this is an interesting exploit, there isn’t much utility to it at this point. That could change, but let’s look at the flaw for now. Snapshots are a cool feature in the V8 JavaScript engine. When you navigate to a web page, the JavaScript context for that page has to be generated in memory, including loading all the libraries called by the page. That doesn’t take too long on a desktop, but on an embedded device or a cell phone loading a local interface, this initialization step can represent a large percentage of the time needed to draw the requested page. Snapshots are a great hack, where the context is initialized, and then saved. When the interface is later opened, the V8 engine can be called with that file, and the context is pre-initialized, making the launch of the app or interface appreciably faster. The only catch is that V8 expects snapshots to only be loaded from a trusted source.

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.

PBX Backdoors

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 file, gunzip, and 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.

SAM Spoofing

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. 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.