This Week In Security: Github, Google, And Realtek

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.


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");

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!


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!

4 thoughts on “This Week In Security: Github, Google, And Realtek

  1. > The most serious bit of information that escaped was code signing certificates

    Please don’t do this. Certificates, be they code signing certificates or otherwise, are not secret. There’s no harm in them getting out. Heck, you can print a certificate on a flag and fly it above your house and nothing bad will happen. The things that need to be kept secret are the private keys, which is presumably what was “leaked” in this case (albeit in encrypted form, so the chance of compromise could very well be minimal).

    I understand that the original blog post from github described the exfiltrated items as “certificates”. That’s unfortunate. But it doesn’t mean Hackaday has to propagate the same mistake. Of course people intimately familiar with PKI will read between the lines and understand what actually happened. But glibly misusing the term does a disservice to those readers who could benefit from a better understand of the nature and risks involved in certificates and private keys.

  2. ive been a rockbox user for almost as long as ive been an ipod user. granted i started with a 3rd gen, which was knocked off a counter by a kitten and destroyed, but my second ipod the 5th gen, only lasted about 6 months before i installed rockbox. getting rid of itunes and making it something i could just copy mp3s to really improved the experience (and itunes was awfully slow on pc). the 5th gen is one of the best ipods to run rockbox on. and doom comes stock, on a bring your own wad basis. rockbox was kind of an evolutionary dead end, as they wouldnt support a wider range of players or newer ipods. so ive been stuck on a 5th gen for years. it still runs good though but could use a fresh battery and an ssd upgrade.

    if a new hacked firmware comes around and enables me to move to a newer unit, thats nice, but at this point i dont really care as ive gotten past the age where i carry headphones and a music player everywhere.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.