GitHub Desktop may have stopped working for you yesterday, Febuary 2nd. The reason was an unauthorized access to some decidedly non-public repositories. The most serious bit of information that escaped was code signing certificates, notably used for GitHub Desktop and Atom. Those certificates were password protected, so it’s unlikely they’ve been abused yet. Even so, Github is taking the proper steps of revoking those certificates.

The only active certificate that was revoked was used for signing the Mac releases of GitHub Desktop, so quite a few older versions of that software is no longer easily installed. If nothing else, it’s a reminder that even a project with a well run security team can have problems.

Sh1mmer-ing Chromebooks

There’s a new, clever attack on the Chromebook, specifically with the goal of unenrolling the device from an educational organization. And the “vulnerability” is a documented feature, the RMA Shim. That’s a special boot loader target that contains a valid signature, but allows the booting of other code, intended for troubleshooting and fixing devices in a repair center. Quite a few of those images have leaked, and Sh1mmer combines the appropriate image with a boot menu with some interesting options.

The first is unenrolling, so the device will act like a privately owned computer. This gets rid of content blocks and allows removing extensions. But wait, there’s more. Like rooting the device, a raw Bash terminal, and re-enabling developer mode. Now, as far as we can tell, this doesn’t *directly* break device encryption, but it’s likely that the RMA shim could be abused to tamper with the device’s filesystem. Meaning that the leak of a bunch of signed shims is a big problem for device security. If you use a Chromebook, it might be time to do some research on whether that model’s shim has been leaked.

Google Fi Fouled

Google Fi customers have received notice of a breach, in which some bits of customer data was leaked. The timing suggests that it could be related to the T-mobile breach about the same time. There’s more worrying element of this, at least one user seems to have been the victim of a SIM swap attack, pulled off as a result of the breach. Just a reminder, that SMS as a two factor authentication method is a terrible idea.

Realtek

There’s a big ongoing campaign against Realtek-based devices, and it’s because of CVE-2021-35394, a vulnerability in the Realtek Jungle SDK. Buckle up, this one has been known to lead to double-facepalms.

Back in 2015, a handful of vulnerabilities were found and disclosed in D-Link and TRENDnet devices. One of those was the UDPServer process, which seems to be a debugging interface. It listens on UDP port 9034, and just executes whatever commands are received. Totally unauthenticated. And on some devices, this process starts automatically. Oof.

This was reported in 2015, and Realtek fixed it. Observe:

if(!memcmp(buf, "orf", 3)){
  strcat(buf, " > /tmp/MP.txt");
  system(buf);
}

Yes, this is the solution they went with. Make sure the command string starts with orf, then redirect the output to a temp file. So secure. And now, someone is spamming port 9034 all across the internet, with orf;malicious_command. Shodan shows 80 different models on the Internet with this port open, and it’s possible even more won’t normally start the vulnerable service, but can be launched via an unauthenticated web endpoint, reachable if the device is configured to allow remote management. It speaks badly of Realtek to fumble a fix this badly, and even worse of vendors to have left this service in place. Patches are available for many of the affected devices.

Hacking your Ipod With wInd3x

[Serge Bazanski] found a new hobby to ride out Covid, and he’s finally ready to share it with the world. Hacking ancient iPods. The goal here is to crack open the platform, get a Linux kernel booting, and then finally engaging in that most noble of pursuits, running Doom on unexpected hardware.

But even in 2008, the iPod Nano 4G was doing a sort of secure boot, and was designed to not load arbitrary boot images. The bootloader will only load properly signed images, and the signing key never leaked. But that’s only a foolproof system so long as there’s not a big bug in the boot sequence that bypasses the security.

One of the tricks the iPod has under its metaphorical hat is to boot off USB for recovery, using Device Firmware Update (DFU). The implication is that the bootloader has to have a USB stack to pull this trick off, and that’s a good place to look for a vulnerability. And there’s a pretty nifty one, where data provided in the USB setup packet is used to index another array, without any sanity checks.

This just happens to be a function pointer lookup, and code execution jumps to the lookup result. Send something bogus, and it crashes the device. Massage the program state correctly, and execution jumps to a bit of code that works as a “trampoline”, bouncing execution back to … *wait-for-it* … The beginning of the USB packet that triggered the vulnerability.

[Serge] is proud of this part, and rightfully so. His exploit is a polyglot — it’s both a valid USB packet, and valid ARM code. It works on the Nano 4G, but he really wanted to take a crack at the 5G, which doesn’t even have boot ROM dumps available. The vulnerability worked, but the memory layout was different enough that the exploit would need re-engineered. The first task was trying to find that trampoline code, and brute-forcing the possible locations led to an interesting finding. One memory location resulted in a device restart when triggered. Time to throw the polyglot packet at it and see what happened. It worked, and he had code execution, but blind execution with no map. He would need the rest of the memory layout to do something useful.

He could make the device do something, at least. Jumping code execution to memory location 0 did a reboot. And triggering an infinite loop made it hang. So, just manually leak memory layout information one bit at a time. That’s a lot of dedication just to run Doom on an iPod. And the work is still in progress, but it looks like the iPod nano Gen5 finally has a booting Linux kernel. Bravo!

PlugX

USB malware still lives. It’s thankfully not as bad as the old days, when Windows would actually autorun a binary as soon as the USB drive was plugged in to the computer. But some new tricks make for a pretty effective trap for the insufficiently wary.

The core trick is that folder names using the Unicode 00A0 character, non-breaking space, don’t render correctly in Windows Explorer, and the folders are not displayed at all as a result. An infected USB drive contains one of these invisible folders, as well as a shortcut bearing the same name as the drive. That shortcut points to a legitimate copy of the x32dbg.exe debugger binary, in the hidden directory, but also lurking there is a malicious x32bridge.dll file.

A quirk of the Windows library loading procedure is that the local directory will be checked first, even if the DLL exists in a system directory. And since DLLs aren’t signed like executables are, this DLL side loading has become a popular technique for running malware without any warning prompts. In the case of PlugX, it runs the payload, and then opens another hidden folder that serves as the fake root of the drive. All your expected files are there. And if you’re not paying attention, the extra step of launching the shortcut would be easy enough to overlook.

Bits and Bytes

The new Meta Account Center had no rate limiting for SMS verification codes, until [Gtm Mänôz] discovered and reported the issue. This allowed an interesting attack, where you could add a phone number belonging to another account, and by brute-forcing the six digit code, the number would be unlinked from the legitimate Facebook or Instagram account. If it was being used for 2FA, that security feature would simply be turned off on that account. The issue was fixed, and he earned a nice $27,200 for the find.

An international effort managed to take down the infrastructure behind Hive Ransomware. Law enforcement was able to compromise Hive servers several months ago, and ran a scam on the scammers, quietly handing out decryption keys to victims. In time, physical servers were located, in Los Angeles of all places, and the scheme shut down. Unfortunately there have yet to be any arrests announced as part of the operation.

Grey Hat really doesn’t do [Shashwat Kumar] justice. This hack is definitely a Chaotic Good action. After learning about a scammy free points offer, he discovered a malicious app that collected credit card information, and copied incoming SMS messages to a remote server. On that server, he found a dashboard with a SQL injection flaw. Upon confirming that this was indeed a malicious scam, the natural course of action was to abuse another SQL injection flaw to wipe the database of data. And then, change the app’s welcome message to warn users that it was malicious. Technically illegal, but obviously for the greater good. Huzzah!