This Week in Security: PHP Attack Defused, Scoreboard Manipulation, and Tillitis

If you use PHP, you likely use the Composer tool for managing dependencies, at least indirectly. And the good folks at SonarSource found a nasty, potential supply chain attack in this tool, when used in the Packagist repository. The problem is the support for arbitrary README filenames. When a package update shows up on Packagist, that service uses a Version Control Service (VCS) like Git or Mercurial to pull the specified readme location. That pull operation is subject to argument injection. Name your branch --help, and Git will happily run the help argument instead of doing the pull intended. In the case of Git commands, our intrepid researchers were unable to weaponize the issue to achieve code execution.

Composer also supports projects that use Mercurial as their VCS, and Mercurial has a --config option that has… interesting potential. It allows redefining a Mecurial command as a script snippet. So a project just has to contain a malicious payload.sh, and the readme set to --config=alias.cat=!hg cat -r : payload.sh|sh;,txt. For those keeping track at home, the vulnerability is that this cursed string of ugly is accepted by Composer as a valid filename. This uses the --config trick to redefine cat as a bit of script that executes the payload. It ends in .txt because that is a requirement of Composer.

So let’s talk about what this little hack could have been used for, or maybe still used for on an unpatched, private install of Packagist. This is an unattended attack that jumps straight to remote script execution — on an official package repository. If discovered and used for evil, this would have been a massive supply chain attack against PHP deployments. Instead, thanks to SonarSource, it was discovered and disclosed privately back in April. The official Packagist repo at packagist.org was fixed the day after disclosure, and a CVE and updated packages went out six days later. Great work all around.

Scorekeeper’s Advantage

[Maxwell Dulin] AKA [Strikeout] was watching a high-school basketball game, and suddenly noticed the wireless scoreboard controller. What if he could change the score? How hard could it be? You probably know how this goes. He’d been nerd-sniped. He spent a few months on this one, even getting his ham license in the process. The conclusion? More challenging than you might think.

Part one of this hack starts with reading the documentation on the radio chips, then doing some real captures and analyzing the data. About that data. One small change in what was sent resulted in a huge change in the data in-the-air. To the tune of 128 bits changing at a time. This simple little scoreboard system was encrypted! AES-128 encryption protected the system from casual tampering. But our hero isn’t just a casual tamperer.

Hence, Part 2. Next up was looking at the hardware again, and mapping out the PCB traces. The transmitter is an ATmega connected to a HopeRF transceiver. The receiver is a matching transceiver and ATMega, connected to a Raspberry Pi 3 A+ handling the scoreboard display via HDMI. The Raspberry Pi is a good start, with both an SD Card to investigate and a USB drive in the USB port. Of great interest on the ATmega board are both a serial port and a serial-based debug port. Plenty of potential attack surfaces. And investigating the Pi’s firmware did lead to a major win. The software that decodes the wireless packets is written in C#, and can be decompiled using DNSpy. While this is a big step, what’s missing of note is the encryption key itself.

Time to solder on to the ATmega, and see if that will spill its secrets. ICSP, that debug interface mentioned earlier, has a command that allows reading out the entire chip’s memory. Perfect! And because it couldn’t be that easy, the chip’s security setting was enabled, which prohibited that command. The traditional serial port approach similarly failed, as the traces are grounded on the production board. There’s one more interface to look at, the Serial Peripheral Interface (SPI) connection between the ATmega and the transciever. What data is sent over that link during system boot? It turns out that the RF modules are doing the encryption heavy lifting in this system, and those modules have the quirk of totally losing their configuration when powered off. Sniffing the key led to an easy win, and a key value of 0x01020304050607080102030405060708. That’s, umm, probably not a random value.

Part three takes this important find, and moves into the realm of actually sending wireless packets. It’s not easy sailing, though, as there’s “data whitening” do deal with. This odd term is just a reference to a problem with clock-drift, when too many “0”s or “1”s are sent in a row on a clockless signal. Whitening uses a Linear Feedback Shift Registers (LFSR) algorithm, and once you work out that math, you just lack the initialization value. Thankfully, there’s some data sent with every packet that’s whitened, and not encrypted — and this algorithm has only 511 possible initial states, so finding the right IV isn’t hard. What did look like a challenge is figuring out the Cyclic Redundancy Check (CRC). These are non-cryptographic error checking routines, they exist in a whole bunch of places, and there are a multitude of different variations. And of course, none of the published options seemed to fit. To save the day is CRC RevEng, a purpose-built tool for figuring out exactly how a given CRC works, just from captured example data. It works! (With a minor hack for long packets)

Now to turn the code into real wireless signals, one only needs an SDR and GNU Radio. The trick here is to corrupt the legitimate signals in the air, and then send your bogus commands in-between. With this, you are the scorekeeper. Giving your son’s basketball team 100 extra points could be fun, but that’s totally going to get noticed. [Strikeout] has some sneakier suggestions. The most clever of which is to run the clock 10% faster than normal, to ride a lead out to a win. Alternatively, change the possession indicator over halftime to give your team possession at the next jumpball. Or even crash the scoreboard for an extra, uncharged timeout. And because our *totally random* AES key is the same for every one of these units, you can spread havoc anywhere you come across a unit. Bonus points for anyone that puts together a wardriver program, looking for scoreboard signals.

Pixel Patch Puzzling

Google’s May security bulletin contained a serious-looking RCE in the bootloader. Bootloaders are particularly interesting as attack vectors, because most devices will let you flash old, potentially vulnerable bootloaders over newer ones. Google’s security team is well acquainted with this trick, and has a safeguard against it, the anti-rollback feature. A new bootloader will contain a bootloader version that get’s written permanently to the device, and firmware older than that just refuses to write to flash.

This RCE was bad enough that Google turned the anti-rollback up to eleven thirteen. All this hubbub convinced [Gagnerot Georges] of eShard to take a look. He takes us on a well-written journey through reverse engineering the patch, and then finally reminds us that this is the hard way to do things, as Google open-sources their bootloaders. Tricksy. Part 2 is more information on taking read and write primitives, and pulling off a Return Oriented Programming (ROP) exploit with them. You won’t quite get a copy-n-paste exploit from the posts, but definitely a good nudge in the right direction.

The Kaminski and Hidden DNS Resolvers

We’ve talked about the Dan Kaminski DNS attack before. DNS uses UDP, and it was too easy to spoof DNS responses, particularly when you could control what domains a given resolver would request at a given time. The attack was privately disclosed to the major vendors, and fixed back in 2008. We know it’s fixed, because we can scan the world’s DNS resolvers. But, what about the resolvers we can’t check? Were those all fixed? With a DNS resolver only available to trusted parties, and hidden behind a corporate firewall, surely it’s safe.

Except DNS is now used for spam detection. My apologies if you’ve had to make these technologies work — but Sender Policy Framework (SPF); Domain Keys Identified Mail (DKIM); and Domain-based Message Authentication, Reporting & Conformance (DMARC) all use DNS records to store information about email settings. Send an email to a user @Corp.com, and corp.com’s email server will likely do several DNS lookups on your sending domain. And thus, these hidden resolvers are no longer hidden. So what’s the results? Scanning just 7000 domains turned up 25 servers around the world that are still vulnerable to the Kaminski attack.

Bits And Bytes

Wireshark 4.00 has been released. There’s a handful of new protocols supported, and the normal library bumps you would expect. Some features see a speed improvement, and the interfaces have gotten a bit of spit’n’polish.

Want a hardware security token, but really want it to be fully open? Tillitis might be for you. It’s a USB platform for experimenting with new security key ideas, and is fully open-source, including the hardware. There isn’t a place to go and order one yet, but you could have your favorite PCB manufacturer build one for you. The first revision also lacks some hardware hardening that really needs to be present for high-value use cases, but this project is one to watch.

Google has released the Hacking Google game/experience. It’s a series of Capture The Flag challenges, just for fun, but good practice working though a security problem.

There’s yet another PS5 exploit being developed, based on a known WebKit vulnerability. Trick the console’s browser into loading a cooked file, and you trigger the exploit. It’s useful, but still a work-in-progress, and doesn’t defeat the hypervisor or run arbitrary code yet.

Last week we covered a fake job application scam, and this week it’s a fake recruiter. An email caught the eye of [osint_matter], because it was well-written, sent to a business address, and had the email DNS records set up correctly. It linked to a decent looking recruitment website: MHS partners. Maybe it was legit? Ah, no, that site was filled with stock photos, and the partner names were references to American TV shows. A Google image search on the pictures came up with other, similar sites with different company names. While this was one of the better-run cons, it still appears to be a phishing expedition. In this case, looking for resumes and other information to sell or otherwise misuse.