CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.

On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code.

The simplest way to use this vulnerability is to replace the verification routine with NoOp instructions. The older T4 devices copy the Android image before the trusted OS is loaded, so it’s possible to load unsigned code as the Secure OS image. If you want to dig just a bit further into the technical details, [Ryan] has published notes on the CVE.

So what does this mean for the hobbyist? It allows for things like running uboot at the equivalent of ring 0. It allows running more recent Android releases on Tegra devices once they’ve been end-of-lifed. It might even be possible to load Nintendo Switch homebrew software on the Nvidia Shield TV, as those are nearly identical pieces of hardware. Hacks like this are a huge boon to the homebrew and modding community.

We’ve seen this before, and I suspect this style of vulnerability will show up in the future, especially as ARM devices continue to grow in popularity. I suggest this class of vulnerability be called Bootjacking, as it is a highjack of the boot process, as well as jacking instructions into the existing bootloader.

Leaky SSH Certificates

SSH certificates are a serious upgrade over simple passwords. So much so, services like Github and Gitlab have begun mandating SSH keys. One of the quirks of those services: Anyone can download public SSH keys from Github. When a client connects to an SSH server, it lists the keys it has access to, by sending the corresponding public keys. In response, if any of those keys are trusted by the server, it sends back a notification so the client can authenticate with the secret key.

[Artem Golubin] noticed the potential data leak, and wrote it up in detail. You could pick a developer on Github, grab his public SSH key, and start checking public-facing SSH servers to find where that public key is recognized. This seems to be baked into the SSH protocol itself, rather than just an implementation quirk. This isn’t the sort of flaw that can be turned into a worm, or will directly get a server compromised, but is an interesting information gathering tool.

HackerOne Exposed

HackerOne is a bug-bounty-as-a-service that represents a bunch of tech companies. Just recently they announced that a vulnerability had been found in the HackerOne infrastructure itself. A security researcher using the platform, [Haxta4ok00], was accidentally given an employee’s session key during a back-and-forth about an unrelated bug report, and discovered that session key allowed him to access the HackerOne infrastructure with the same permissions as the employee.

Session key hijacking isn’t a new problem; it is one of the attacks that led to the HTTPS everywhere approach we see today. Once a user has authenticated to a website, how does that authentication “stick” to the user? Sending a username and password with each page load isn’t a great idea. The solution is the session key. Once a user authenticates, the server generates a long random string, and passes it back to the browser. This string is the agreed upon token that authenticates that user for all further communication, until a time limit is reached, or the token is invalidated for another reason.

Not so long ago, most web services only used HTTPS connections for the initial user log-on, and dropped back to unencrypted connections for the bulk of data transfer. This session key was part of the unencrypted payload, and if it could be captured, an attacker could hijack the legitimate session and act as the user. The Firesheep browser extension made it clear how easy this attack was to pull off, and pushed many services to finally fixing the problem through full-time HTTPS connections.

HTTPS everywhere is a huge step forward for preventing session hijacking, but as seen at HackerOne, it doesn’t cover every case. The HackerOne employee was using a valid session key as part of a curl command line, and accidentally included it in a response. [Haxta4ok00] noticed the key, and quickly confirmed what is was, and that it allowed him access to HackerOne internal infrastructure.

The leak was reported and the key quickly revoked. Because it was leaked in a private report, only [Haxta4ok00] had access. That said, several other private vulnerability reports were accessed. It’s worth mentioning that HackerOne handled this as well as they could have, awarding $20,000 for the report. They updated their researcher guidelines, and now restrict those session keys to the IP address that generated them.

Via Ars Technica

StrandHogg

One of the more notable stories in the past week was all about Android, and malicious apps masquerading as legitimate ones. StrandHogg has been exploited in one form or another since 2017, and was first theorized in a Usenix paper from 2015. In some ways, it’s an extremely simple attack, but does some very clever things.

So how does it work? A malicious app, once installed, runs in the background waiting for a target app to be launched. Once the target app is detected, the malicious app jumps to the forefront, disguised as the target. From here, a phishing attack is trivial. More interesting, though, is the permissions attack. Your benign application appears to request file system permissions, camera permissions, etc. It’s not immediately apparent that the malicious app is the one that is actually requesting permissions.

The only actual vulnerability here seems to be the ability of a malicious app to rename and “reparent” itself, in order to spoof being part of the target app. Do note that at least on permissions popups, the name of the requesting application is blank during a StrandHogg attack.

Contactless Payment

Contactless payments look like magic the first time you see them. Just wave a compatible card or mobile device over the payment terminal, and payment happens over NFC. Since you’re reading this column, it’s safe to assume that quickly after that first moment of awe wears off, you starting wondering how this is all done securely. That is what [Leigh-Anne Galloway] and [Tim Yunusov] wanted to know as well. They just released their research, and managed to find several nasty tricks. A tin-foil hat might be overkill, but maybe it’s time to invest in an NFC blocking wallet.

They manipulated data in transit, allowing for much larger payments without a PIN entry, made purchases via an NFC proxy, and even illustrated a practical pre-pay attack where a card could be read, make a fake transaction, and then play that fake transaction back for a real payment terminal.

Superfish returns?

Twitter is a fascinating place. Sometimes simple observations turn out to be CVEs. An interesting interaction took place when [SwiftOnSecurity] pointed out an odd DNS name, “atlassian-domain-for-localhost-connections-only.com”, with the description that it allowed a secure HTTPS connection to a service running on localhost. Our friend from Google’s Project Zero, [Tavis Ormandy], pointed out that a valid https cert installed on localhost means that Atlassian must be shipping a private certificate for that domain name as part of their software. Follow the link, and you too can host this oddball domain with a valid HTTPS certificate.

This is a bad idea for several reasons, but not the worst thing that could happen. The worst case scenario for this style of mistake probably belongs to Superfish. An aptly name adware program was pre-installed on many Lenovo machines in 2014, with the helpful feature of showing you more personalized ads. In order to do this, the software simply added its own certificate authority information to the system’s trusted CA bundle… and shipped the private certificate and key along with the software. Yes, you read that right, any HTTPS certificate could be perfectly spoofed for a Lenovo user.

Looking at the Atlassian domain, another user noted that IBM’s Aspera software had a similar localhost domain and certificate. According to [Tavis], that software also includes a full CA cert and key. If an iteration of IBM software actually added that CA to a system’s root trust, then it’s another superfish: Any HTTPS certification could be successfully spoofed.