This Week In Security: Android Exposes ADB, ShinyHunters Get Paid, Robot Dogs, And More

Google has patched an Android ADB bug in the May security patch set. If you have a Pixel phone you should already have the patches, and most other major manufacturers should be close behind. Unfortunately, the biggest risk from this patch will be to the vendors who are also the least likely to release timely – or any – security updates.

ADB, the Android Debug Bridge, is the main tool for installing apps during development and debugging apps while they’re running. It can also be used to side-load apps from a PC. While most normal users are unlikely to ever enable it, developers typically do and some power users might when jailbreaking a device or setting parameters not exposed in the Android UI. Debugging can be done locally via USB, or optionally over the network. To protect the device, the user must unlock the Android device and authorize each new debug agent.

Covered by Risky.Biz, a bug introduced in 2020, and present in every Android release since, allowed bypassing authorization entirely if network debugging was enabled and at least one connection had been made to the ADB service in the past. This happens because ADB compares the certificate of the incoming debug connection with the list of saved certificates. If the certificate type does not match — for instance supplying an Ed25519 certificate instead of a RSA certificate — ADB has been incorrectly handling the error code, and allowing the connection.

In most programming languages, false is considered zero, and true is considered anything not zero. The certificate API returns a 1 for a valid match, a zero for an invalid match, and a negative-one for a type mismatch. Negative one is not zero, so when treated as a boolean value, it becomes true.

To exploit the bug, ADB must be enabled in wireless mode, and there must be at least one trusted device in the ADB configuration. For the average user this is an unlikely combination, but for developers, the time to update is now.

Continue reading “This Week In Security: Android Exposes ADB, ShinyHunters Get Paid, Robot Dogs, And More”

This Week In Security: BYOVD, Spectre Vx, More Octal Headaches, And ExifTool

I learned a new acronym while reading about a set of flaws in the Dell BIOS update system. Because Dell has patched their driver, but hasn’t yet revoked the signing keys from the previous driver version, it is open to a BYOVD attack.

BYOVD, Bring Your Own Vulnerable Driver, is an interesting approach to Windows privilege escalation. 64-bit versions of Windows have a security feature that blocks unsigned kernel drivers from the kernel. The exploit is to load an older, known-vulnerable driver that still has valid signatures into the kernel, and use the old vulnerabilities to exploit the system. The caveat is that even when a driver is signed, it still takes an admin account to load a driver. So what use is the BYOVD attack, when it takes administrative access to pull off?

SentinelLabs is witholding their proof-of-concept, but we can speculate. The particular vulnerable driver module lives in the filesystem at C:\Windows\Temp, a location that is writable by any process. The likely attack is to overwrite the driver on the filesystem, then trigger a reboot to load the older vulnerable version. If you’re still running Windows on your Dell machines, then make sure to go tend to this issue. Continue reading “This Week In Security: BYOVD, Spectre Vx, More Octal Headaches, And ExifTool”

This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets

So first off, remember the Unc0ver vulnerability/jailbreak from last week? In the 13.5.1 iOS release, the underlying flaw was fixed, closing the jailbreak. If you intend to jailbreak your iOS device, make sure not to install this update. That said, the normal warning applies: Be very careful about running out-of-date software.

Apple Sign In

An exploit in Apple’s web authentication protocol was fixed in the past week . Sign In With Apple is similar to OAuth, and allows using an Apple account to sign in to other sites and services. Under the hood, a JSON Web Token (JWT) gets generated and passed around, in order to confirm the user’s identity. In theory, this scheme even allows authentication without disclosing the user’s email address.

So what could go wrong? Apparently a simple request for a JWT that’s signed with Apple’s public key will automatically be approved. Yeah, it was that bad. Any account linked to an Apple ID could be trivially compromised. It was fixed this past week, after being found and reported by [Bhavuk Jain]. Continue reading “This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets”