Let’s Encrypt has made an enormous difference to the landscape of the web. The protocol used for authenticating and receiving certificates, ACME, has spawned quite a few clients of various flavors. Some are written in Rust, some in Python or Go, and a few in straight Bash shell script. One of those last ones, acme.sh, was doing something odd when talking to a particular “Certificate Authority”, HiCA. This pseudo-CA only supports acme.sh, and now we know why. The folks behind HiCA found an RCE exploit in acme.sh, and decided to use that exploit to do certificate issuance with more “flexability”. Oof.

The nuts and bolts here is that HiCA was working as a CA-in-the-Middle, wrapping other CA’s authentication services. Those services don’t support ACME authentication at all, and HiCA used the acme.sh vulnerability to put the authentication token in the place SSL.com expected to find it. So, just a good community member offering a service that ACME doesn’t quite support, right?

Well, maybe not so innocent. The way it appears this works, is that the end user sends a certificate request to HiCA. HiCA takes that information, and initiates a certificate request off to SSL.com. SSL.com sends back a challenge, and HiCA embeds that challenge in the RCE and sends it to the end user. The end user’s machine triggers the RCE, which pushes the challenge token to the well-known location, and bypasses the ACME protection against exactly this sort of CA-in-the-middle situation.

The last piece of the authentication process is that the signing server reaches out over HTTP to the domain being signed, and looks for the token to be there. Once found, it sends the signed certificates to HiCA, who then forward them on to the end user. And that’s the problem. HiCA has access to the key of every SSL cert they handled. This doesn’t allow encryption, but these keys could be used to impersonate or even launch MitM attacks against those domains. There’s no evidence that HiCA was actually capturing or using those keys, but this company was abusing an RCE to put itself in the position to have that ability.

The takeaway is twofold. First, as an end user, only use reputable CAs. And second, ACME clients need to be hardened against potentially malicious CAs. The fact that HiCA only supported the one ACME client was what led to this discovery, and should have been a warning flag to anyone using the service.

Leaking LEDs

Side channel attacks are always interesting, particularly when they don’t require compromise of the target device to be usable. Malware that can bridge an air gap by blinking an LED is boring. But a technique to sniff data from an LED, just because different processor instructions change the power state of the system? That’s interesting.

The researchers behind the work refer to it as video-based cryptanalysis, and it contains a few really fascinating tricks. The idea is to take over an IP camera that has Pan Tilt Zoom (PTZ) capabilities, and zoom all the way in, centered up on the target device’s LED. Then, by turning the framerate to max, and the shutter speed to as fast as possible, the camera is pushed into using a rolling shutter, meaning that each row of pixels are queried in order, with a bit of delay between. If you don’t care about resolution, then this gives a dramatically increased effective framerate — high enough to catch the changes in LED brightness that correspond to cryptographic processing.

It’s interesting and exciting, but to steal a smart card’s secret key, the camera needs to record 10,500 signing operations. When it was being constantly used for signatures, this still took 65 minutes of footage, and would be *much* slower in a real world attack. Should you put black tape over all your LEDs? The real solution, of course, is cryptographic code that uses constant-time and constant-power routines.

Bitwarden Desktop for Windows

Bitwarden on Windows uses the Windows Credential Manager for unlocking the vault, mainly so Windows Hello can be used. Turns out, that wasn’t a good approach, as the Windows API will hand over the biometric master key even without a Windows Hello authentication. The conclusion is that a malicious application running on the machine could access the locked database. Not great. Thankfully, 2023.4.0 has some fixes to address this, but if this weakness matters to you, it’s quite important to turn on the option to require a password on first login.

Android Apps Hiding Malware

Bitdefender turned on a new feature in their Mobile Security platform, what they call Anomaly Detection. And promptly discovered a whopping 60,000 unique malicious apps on Android phones around the world. This isn’t a case of malware showing up on the official Play Store, these are all direct APK downloads.

The apps all claimed to be something useful, like a cracked game or modded app. But in each case, the app is actually nameless and lacks an icon. Upon install, a bogus error is shown, and the user is prompted to “uninstall”. Naturally, the app isn’t uninstalled, it’s just invisible and forgotten about. If that sounds familiar, go to your list of installed apps, and look for a nameless app with an all-white icon.

Once installed, these apps will sleep for a few hours, and then show full-screen ads from time to time. Just enough to make a little ad revenue money, but not enough to tip off an unwary user that something is off.

Bits and Bytes

VMWare has recently fixed a series of issues in their Aria Operations for Networks product. A post on a couple of those issues from Summoning Team is instructive. The foot-in-the-door is a regular expressions issue in an nginx rule, and seems to be tracked as CVE-2023-20889. Using a doctored URL, an internal endpoint can be reached, that is not intended for external access. From there, CVE-2023-20887 is a command injection flaw that allows arbitrary execution. All three flaws are fixed by KB92684.

Fortinet has released an update for the Fortigate devices, fixing CVE-2023-27997. This is a pre-auth RCE in the SSL-VPN service. And unfortunately, it appears that it’s already being exploited in the wild. This one is nasty, with all of 500,000 deployed Fortigate firewalls — so long as they have the SSL VPN exposed. Buckle up, and get to patching.

And remember MOVEit? That seems to be the gift that keeps on giving, as multiple government agencies have reportedly been hit with breaches related to that software. Agencies are confident that there won’t be “significant impacts” as a result of these attacks. Time will tell.