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.

Detect Starlink Satellites Passing By

November 29, 2021 by Bryan Cockfield 16 Comments

The Starlink beta has semi-officially ended, but it seems as though the global chip shortage is still limiting how many satellites are flying around the world for broadband internet access for those that might not be served by traditional ISPs. Not every location around the world has coverage even if you can get signed up, so to check that status the hard way you can always build a special antenna that tracks the Starlink beacons as they pass overhead.

[Derek] is using this project to show of some of his software-defined radio skills, so this will require an SDR that can receive in the 1600 MHz range. It also requires a power injector to power the satellite receiver, but these are common enough since they are used to power TV antennas. The signals coming from the Starlink satellites have a very high signal-to-noise ratio so [Derek] didn’t even need a dish to focus the signals. This also helped because the antenna he is using was able to see a much wider area as a result. Once everything was set up and the computer was monitoring the correct location in the spectrum, he was able to see very clearly how often a satellite passed him by.

Of course, [Derek] lives in an area with excellent coverage so this might be a little more difficult for those in rural areas, but possibly not for long as the goal of Starlink is to bring broadband to people who otherwise wouldn’t have access to it. There is some issue with how much these satellites might interfere with other astronomical activities though, so take that with a grain of salt.

Thanks to [Spritle] for the tip!

Christian Hahn Starlink capture showing guard region.

Analyzing Starlink Satellite Downlink Communications With Software Defined Radio

November 26, 2021 by Maya Posch 23 Comments

Often, mere curiosity is sufficient to do something. This is also the case with people trying to analyze the communication setup and protocol which SpaceX is using with their Ku-band based Starlink satellites. One of these fine folk is [Christian Hahn], who has recently posted some early findings to r/StarlinkEngineering over at Reddit. Some of the captured data seems to include the satellite ID system that ground-based user stations would presumably use to keep track of overhead Starlink satellites.

For the capturing itself, [Christian] is using a second-hand dish for capture and a DIY SDR using KC705 FPGA-based hardware – which may have begun its life as crypto mining hardware – along with the usual assortment of filters and other common components with this kind of capture. Even at this early time, some features of the Starlink protocol seem quite obvious, such as the division into channels and the use of guard periods. Nothing too earth-shattering, but as a fun SDR hobby it definitely checks all the boxes.

[Christian] has also announced that at some point he’ll set up a website and publish the findings and code that should make Starlink signal analysis easy for anyone with a readily available SDR receiver.

Hackaday Links: November 7, 2021

November 7, 2021 by Dan Maloney 3 Comments

More trouble for Hubble this week as the space observatory’s scientific instruments package entered safe mode again. The problems started back on October 25, when the Scientific Instrument Command and Data Handling Unit, or SI C&DH, detect a lack of synchronization messages from the scientific instruments — basically, the cameras and spectrometers that sit at the focus of the telescope. The issue appears to be different from the “payload computer glitch” that was so widely reported back in the summer, but does seem to involve hardware on the SI C&DH. Mission controller took an interesting approach to diagnosing the problem: the dusted off the NICMOS, or Near Infrared Camera and Multi-Object Spectrometer, an instrument that hasn’t been used since 1998. Putting NICMOS back into the loop allowed them to test for loss of synchronization messages without risking the other active instruments. In true hacker fashion, it looks like the fix will be to change the software to deal with the loss of sync messages. We’ll keep you posted.

What happened to the good old days, when truck hijackings were for things like cigarettes and booze? Now it’s graphics cards, at least according to a forum post that announced the theft of a shipment of EVGA GeForce RTX 30-series graphics cards from a delivery truck. The truck was moving the cards from San Francisco to the company’s southern California distribution center. No word as to the modus operandi of the thieves, so it’s not clear if the whole truck was stolen or if the cards “fell off the back.” Either way, EVGA took pains to note that receiving stolen goods is a crime under California law, and that warranties for the stolen cards will not be honored. Given the purpose these cards will likely be used for, we doubt that either of these facts matters much to the thieves.

Remember “Jet Pack Man”? We sure do, from a series of reports by pilots approaching Los Angeles International airport stretching back into 2020 and popping up occasionally. The reports were all similar — an object approximately the size and shape of a human, floating aloft near LAX. Sightings persisted, investigations were launched, but nobody appeared to know where Jet Pack Man came from or what he was flying. But now it appears that the Los Angeles Police may have identified the culprit: one Jack Skellington, whose street name is the Pumpkin King. Or at least a helium balloon version of the gangly creature, which is sure what an LAPD helicopter seems to have captured on video. But color us skeptical here; after all, they spotted the Halloween-themed balloon around the holiday, and it’s pretty easy to imagine that the hapless hero of Halloween Town floated away from someone’s front porch. More to the point, video that was captured at the end of 2020 doesn’t look anything like a Skellington balloon. So much for “case closed.”

Speaking of balloons, here’s perhaps a more productive use for them — lifting a solar observatory up above most of the atmosphere. The Sunrise Solar Observatory is designed to be lifted to about 37 km by a balloon, far enough above the Earth’s ozone layer to allow detailed observation of the Sun’s corona and lower atmosphere down into the UV range of the spectrum. Sunrise has already flown two successful missions in 2009 and 2013 which have netted over 100 scientific papers. The telescope has a one-meter aperture and automatic alignment and stabilization systems to keep it pointed the right way. Sunrise III is scheduled to launch in June 2022, and aims to study the flow of material in the solar atmosphere with an eye to understanding the nature of the Sun’s magnetic field.

And finally, what a difference a few feet can make. Some future Starlink customers are fuming after updating the location on their request for service, only to find the estimated delivery date pushed back a couple of years. Signing up for Starlink satellite service entails dropping a pin on a map to indicate your intended service location, but when Starlink put a new, more precise mapping app on the site, some eager pre-order customers updated their location to more accurately reflect where the dish will be installed. It’s not clear if the actual location of the dish is causing the change in the delivery date, or if just the act of updating an order places you at the bottom of the queue. But the lesson here may be that with geolocation, close enough is close enough.

GPS? With Starlink, We Don’t Need It Any More!

October 10, 2021 by Jenny List 58 Comments

To find your position on the earth’s surface there are a variety of satellite-based navigation systems in orbit above us, and many receiver chipsets found in mobile phones and the like can use more than one of them. Should you not wish to be tied to a system produced by a national government though, there’s now an alternative. It comes not from an official source though, but as a side-effect of something else. Researchers at Ohio State University have used the Starlink satellite broadband constellation to derive positional fixing, achieving a claimed 8-metre accuracy.

The press release is light on information about the algorithm used, but since it mentions that it relies on having advance knowledge of the position and speed of each satellite we’re guessing that it measures the Doppler shift of each satellite’s signal during a pass to determine a relative position which can be refined by subsequent observations of other Starlink craft.

The most interesting takeaway is that while this technique leverages the Starlink network, it doesn’t have any connection to the service itself. Instead it’s an entirely passive use of the satellites, and though its accuracy is around an order of magnitude less than that achievable under GPS it delivers a position fix still useful enough to fit the purposes of plenty of users.

Earlier in the year there was some amusement when the British government bought a satellite broadband company under the reported impression it could plug the gap left by their withdrawal from the European Galileo project. Given this revelation, maybe they were onto something after all!

Thanks [Renze] for the tip.

StarLink Terminal Unit Firmware Dumped

July 7, 2021 by Al Williams 17 Comments

There’s a lot of expense in what telephone companies call “the last mile” — delivering service from the main trunks to your home or business. StarLink wants to avoid that cost by connecting you via an array of low-orbit satellites and some users are already using the service. In Belgium, [Lennert Wouters] managed to dump the terminal’s firmware and has some interesting observations.

The teardown is actually more than just a firmware dump. His “level 1” teardown involves exposing the board. This can be tricky because there are apparently different versions of the terminal out already, so advice from one source might not match your hardware, and that was the case here.

Continue reading “StarLink Terminal Unit Firmware Dumped” →

Hackaday Links: July 4, 2021

July 4, 2021 by Dan Maloney 9 Comments

With rescue and recovery efforts at the horrific condo collapse in Florida this week still underway, we noted with interest some of the technology being employed on the site. Chief among these was a contribution of the Israeli Defense Force (IDF), whose secretive Unit 9900 unveiled a 3D imaging system to help locate victims trapped in the rubble. The pictures look very much like the 3D “extrusions” that show up on Google Maps when you zoom into a satellite view and change the angle, but they were obviously built up from very recent aerial or satellite photos that show the damage to the building. The idea is to map where parts of the building — and unfortunately, the building’s occupants — ended up in the rubble pile, allowing responders to concentrate their efforts on the areas most likely to hold victims. The technology, which was developed for precision targeting of military targets, has apparently already located several voids in the debris that weren’t obvious to rescue teams. Here’s hoping that the system pays off, and that we get to learn a little about how it works.

Radio enthusiasts, take note: your hobby may just run you afoul of authorities if you’re not careful. That seems to be the case for one Stanislav Stetsenko, a resident of Crimea who was arrested on suspicion of treason this week. Video of the arrest was posted which shows the equipment Stetsenko allegedly used to track Russian military aircraft on behalf of Ukraine: several SDR dongles, a very dusty laptop running Airspy SDR#, an ICOM IC-R6 portable communications receiver, and various maps and charts. In short, it pretty much looks like what I can see on my own desk right now. We know little of the politics around this, but it does give one pause to consider how non-technical people view those with technical hobbies.

If you could choose a superpower to suddenly have, it really would take some careful consideration. Sure, it would be handy to shoot spider webs or burst into flames, but the whole idea of some kind of goo shooting out of your wrists seems gross, and what a nuisance to have to keep buying new clothes after every burn. Maybe just teaching yourself a new sense, like echolocation, would be a better place to start. And as it turns out, it’s not only possible for humans to echolocate, but it’s actually not that hard to learn. Researchers used a group of blind and sighted people for the test, ranging in age from 21 to 79 years, and put them through a 10-week training program to learn click-based echolocation. After getting the basics of making the clicks and listening for the returns in an anechoic chamber, participants ran through a series of tasks, like size and orientation discrimination of objects, and virtual navigation. The newly minted echolocators were also allowed out into the real world to test their skills. Three months after the study, the blind participants had mostly retained their new skill, and most of them were still using it and reported that it had improved their quality of life.

As with everything else he’s involved with, Elon Musk has drawn a lot of criticism for his Starlink satellite-based internet service. The growing constellation of satellites bothers astronomers, terrestrial ISPs are worried the service will kill their business model, and the beta version of the Starlink dish has been shown to be flakey in the summer heat. But it’s on equipment cost where Musk has taken the most flak, which seems unfair as the teardowns we’ve seen clearly show that the phased-array antenna in the Starlink dish is being sold for less than it costs to build. But still, Musk is assuring the world that Starlink home terminals will get down in the $250 to $300 range soon, and that the system could have 500,000 users within a year. There were a couple of other interesting insights, such as where Musk sees Starlink relative to 5G, and how he’s positioning Starlink to provide backhaul services to cellular companies.

Well, this is embarrassing. Last week, we mentioned that certain unlucky users of an obsolete but still popular NAS device found that their data had disappeared, apparently due to malefactors accessing the device over the internet and forcing a factory reset. Since this seems like something that should require entering a password, someone took a look at the PHP script for the factory restore function and found that a developer had commented out the very lines that would have performed the authentication:

    function get($urlPath, $queryParams=null, $ouputFormat='xml'){
//        if(!authenticateAsOwner($queryParams))
//        {
//            header("HTTP/1.0 401 Unauthorized");
//            return;
//        }

It’s not clear when the PHP script was updated, but support for MyBook Live was dropped in 2015, so this could have been a really old change. Still, it was all the hacker needed to get in and wreak havoc; interestingly, the latest attack may be a reaction to a three-year-old exploit that turned many of these devices into a botnet. Could this be a case of hacker vs. hacker?