Keyloggers. Such a simple concept — you secretly record all the characters typed on a keyboard, and sort through it later for interesting data. That keyboard sniffer could be done in software, but a really sneaky approach is to implement the keylogger in hardware. Hardware keyloggers present a unique problem. How do you get the data back to whoever’s listening? One creative solution is to use Apple’s “Find My” tracking system. And if that link won’t let you read the story, a creative solution for that issue is to load the page with javascript disabled.

This is based on earlier work from [Fabian Bräunlein], dubbed “Send My”. As an aside, this is the worst naming paradigm, and Apple should feel bad for it. At the heart of this cleverness is the fact that Apple used the standard Bluetooth Low Energy (BLE) radio protocol, and any BLE device can act like an Apple AirTag. Bits can be encoded into the reported public key of the fake AirTag, and the receiving side can do a lookup for the possible keys.

A fake AirTag keylogger manages to transfer 26 characters per second over the “Find My” system, enough to keep up with even the fastest of typists, given that no keyboard is in use all the time. Apple has rolled out anti-tracking protections, and the rolling key used to transmit data also happens to completely defeat those protections.

Zephyr RTOS

[Marco Ivaldi] has opted to do security research on Open Source projects for a while, following a less than stellar experience trying to report vulnerabilities to Oracle. So to celebrate 20 years of vulnerability hunting, [Marco] is disclosing 12 vulnerabilities in the Zephyr Real-Time Operating System (RTOS).

Of those, five are rated CVSS 7.0 or more serious, with the top two tying at 7.6. Those are each buffer overflows in the transmit functions of CANbus and IEEE 802.15.4 respectively. As the overflows are on transmit, they’ll be much harder to exploit, but there are still clever attacks that make use of such vulnerabilities, so it’s good to get these cleaned up. Of the twelve vulnerabilities, one was fixed with Zephyr 3.4.0, ten in 3.5.0, and one additional vulnerability that is still pending.

Looney Tunables Joins the Show

We talked about the Looney Tunables vulnerability when it first dropped. For a quick recap, that is a buffer overflow in the glibc dynamic library loader. Proofs of Concept (PoCs) have been published, and the inevitable has happened. The vulnerability is now being used in real attacks, being used by a threat actor known as Kinsing.

Atlassian Confluence Not To Be Outdone

The other serious vulnerability to make it to active exploit is the Atlassion Confluence authentication bypass. Attacks started in mass Saturday night, and at least three discrete IPs were making attempts to use the exploit. At least one of those attacks is a ransomware attempt from an unknown group, “C3RB3R”.

PRTG Network Exploitation

And one of the next exploits we’ll likely see in the attacker toolkit is this RCE in the PRTG Network Monitor system. PRTG works by installing sensors to various machines on the network, managed by a central server. The problem is that the server can make live changes to the sensor config, and one of those changes can inject arbitrary parameters. And a valid parameter is the debug flag.

Debug options left in production should fill the reader with a bit of dread. Here that debug flag allows for file creation with a few caveats. The approach taken by Baldur Security to demonstrate the flaw was to write out a .bat file, which can then be executed as a sensor. Compromise the PRTG machine, and you can push arbitrary code running as SYSTEM to every monitored machine.

Bits and Bytes

If you had any doubt, typosquatting & Co are alive and well, with one of the latest reports coming from python-land. Eight packages all claimed to be related to code obfuscation, and each name started with “Pyobft”. In fact, the code would spy on the developers that were unfortunate enough to install them, steal passwords and files, and then finally encrypt the hard drive. Ouch.

There are good responses to disclosure, there are bad responses to disclosure, and then there’s this guy. [Eddie Zhang] found a pair of open Amazon S3 buckets that were obviously not intended to be public. Monash University did everything right, and even shared public recognition, as well as rapidly fixing the problem. An unknown CIO took the other road, complaining that this was the third time this month someone had wasted the company’s time with news of a breach. [Eddie] has opted to submit through a few third parties, including [Troy Hunt], and leave it at that. I would actually encourage full disclosure after 90 days, as this companies customers absolutely deserve to see how their data is being handled.

And finally, the Industrial and Commercial Bank of China was hit with a ransomware attack in their US offices. It’s a reminder just how much the world relies on digital systems, and how bold the ransomware gangs have gotten — attacking one of China’s largest industrial banks.