Attacking Titan M with Only One Byte

https://blog.quarkslab.com/attacking-titan-m-with-only-one-byte.html

by ZeroCool2u • 4 years ago

175 75 4 years ago

blog.quarkslab.com

ZeroCool2u3• 4 years ago

This is an elegant attack that effectively compromises all Titan M chips. They were even able to dump all securely stored private cryptographic keys, which Google acknowledges in the disclosure timeline.

Even still though, the award Google initially gave was only $10k USD(!). They finally bumped it to $75k USD after complaint and review, but Google's bug bounty program claims up to $1 Million USD.

If fully compromising Google's own security chip to dump all private keys isn't worth the full $1 Million bounty, I honestly don't know what is.

Really, what would, in the mind of those on the internal committee, constitute justification for the $1 Million bounty?

posnet• 4 years ago

Remote 0-day onto all google internal infra?

ClumsyPilot2• 4 years ago

thats literally worth billions, and could be sold to many governments.

If thr right people don't buy these zero-days, yhe wrong people will.

rurban• 4 years ago

Those committee's just lost contact to the real world. Ridiculous

tgv• 4 years ago

I guess there's someone who orders the marketing department to say "1 million", while telling the operational side "10k", because his bonus rides on it.

medo-bear4• 4 years ago

i would imagine higher bounty would be for extracting device keys. from my reading this exploit would not allow you to extract the key needed to unlock a powered off device. im no security expert so please correct me if im wrong

ZeroCool2u3• 4 years ago

2022-06-20: Quarkslab sent Google a new exploit that demonstrates code execution on the chip and exfiltration of encryption keys from it. A detailed description of the exploitation technique, the exploit's source code, and a video showing its use to exfiltrate a StrongBox-protected AES key were provided.

This sounds close enough to me, but perhaps there's some subtle nuance between device keys and other keys in the chip.

izacus• 4 years ago

Really, what would, in the mind of those on the internal committee, constitute justification for the $1 Million bounty?

Probably something that doesn't require physical access to a key for longer time to extract the keys?

rob_c8• 4 years ago

I think the $1M is probably reserved to something that would tank Google stock imo, but maybe I'm cynical

dylan6042• 4 years ago

Nah, you're not cynical enough. My cynical take is there is nothing they would ever pay $1M for. "Up to" is a marketing term to get people to think that if they work hard enough, they might qualify for this mythical unicorn bounty, but at the end of the day they just get peanuts.

NovemberWhiskey2• 4 years ago

From my point of view, the fact that the exploit required either to run as root on a rooted device (or alternatively direct access to an internal serial bus) is enough to justify not paying at the top level.

These things should probably be more transparent, but I would assume the $1M level would be for exploits that could be deployed on a fresh-from-the-box device with no rooting/mods.

medo-bear4• 4 years ago

is isb access an issue? your phone could get stolen

joshuamorton• 4 years ago

Quoting a random article from when this was initially announced:

Google says that if researchers manage to find "a full chain remote code execution exploit with persistence" that also compromises data protected by Titan M, they are willing to pay up to $1 million to the bug hunter who finds it.

So a compromise that doesn't require physical access or root, presumably.

Cue also the inevitable discussion that bug bounties are too low.

Svoka2• 4 years ago

Google bug bounty program is a sham. When I tried to report critical vulnerability in their authentication system, they told it's a 'feature' and threatened to sue if I disclose.

Then fixed it in two and a half years, and wrote an article on how complicated bug they just found and how proud and secure they are with their pentesters.

deepsun• 4 years ago

Do you have a link?

Spivak• 4 years ago

You have inadvertently discovered the value of pentesters which is making handling security issues a win for the the management.

Lorin2• 4 years ago

On what grounds could they sue you if it was truly considered a "feature", and they used that exact terminology in their response?

miohtama• 4 years ago

For 2018 chip and for a company like Google, the decision to go with C despite their all knowledge oN C/C++ memory issues (hello Chrome) is a bit sad.

Lt_Riza_Hawkeye• 4 years ago

I would imagine it wasn't a hard decision - they likely needed to build something in an environment where they are already paying 40-80k C++ developers, and I would guess something like 1-10k Rust developers, who are scattered around various teams and may not want to hop on a new team right now. Also it was released to the consumer market in 2018, so probably built in 2016-17. Rust and other memory-safe systems programming alternatives didn't have nearly the same uptake back then - so maybe 1-2k would be a safer bet. Not to mention, Rust didn't get tier-1 ARM support until 2021 - and even then, that's only when running on linux, which the Titan M chip is most likely not running.

wyldfire2• 4 years ago

This article [1] includes a quote describing a specific vulnerability that would pay the $1 million.

"We are introducing a top prize of $1 million for a full chain remote code execution exploit with persistence which compromises the Titan M secure element on Pixel devices. Additionally, we will be launching a specific program offering a 50% bonus for exploits found on specific developer preview versions of Android, meaning our top prize is now $1.5 million," Jessica Lin of the Android security team said.
The Titan M bounty applies to the Google phones that have the chip, which include the Pixel 3 and 3 XL, 3a and 3a XL, and 4.

[1] https://duo.com/decipher/hack-the-titan-m-get-usd1-million

lnyng• 4 years ago

For a moment I thought this is something related to the anime

Stevvo• 4 years ago

Myself pulled in hoping for a historical tale of attacking vulnerabilities in Titan ICBMs.

flyaway123• 4 years ago

Just curious - if the usage of acronym here a soft-euphemism? (So that only those who knew or care to know gets it)

edit: Thanks for the clarifications. That helps. I'm asking for 2 reasons:

  1. Discussing "nukes" openly where I come from would raise some eyebrows.

  2. I see acronyms used on HN frequently - sometimes ambiguously even considering the context.

its_bbq• 4 years ago

That would be "only one bite"

2OEH8eoCRo0• 4 years ago

As a reminder, there are two conditions to perform this attack. First, we need to be able to send commands to the chip, either from a rooted device (required to use nosclient), or physically accessing the SPI bus.
Then, we need a way to access the key blobs on the Android file system, which can be done again by being root, or with some exploit to bypass File Based Encryption or the uid access control.

userbinator• 4 years ago

A lot of software can be cracked "with only one byte". Finding which one is the hard part.

Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.

tialaramex3• 4 years ago

hide secrets from its owner.

It makes sense to use exactly the same technology even if you are "the owner" unless you are somehow only ever running software you wrote on data you obtained, and maybe not even then if other people are able to influence that data.

Most of use a lot of software we didn't write, to process data we got from some third party who may or may not have our best interests in mind.

ClumsyPilot2• 4 years ago

well there are cases where owner and current user aren't one and the same. Like an ATM terminal, or when someone else is using your computer.

The whole security landscape seems to have many catch-22's

IncRnd2• 4 years ago

Don't lose sight of the fact that the purpose of this and other TPM-like devices is to hide secrets from its owner.

That's a complete misunderstanding of a TPM's security model. A TPM guards against key theft in a compromised environment by securely storing artifacts and authenticating the platform. The user doesn't enter this threat picture. It is the platform that gets authenticated, not the user.

nyanpasu64• 4 years ago

SafetyNet and "authenticating the platform" is used for remote attestation, so app authors can deny phones access to apps and services if they're running root/kernel-level CPU code chosen by the user (or also an attacker without access to the phone's OS signing keys) rather than by the phone's manufacturer.

vlovich123• 4 years ago

The one bit I didn’t understand was how they bypassed W/RX. How did they manage to get the new code to be marked as RX after writing?

I thought I read the whole thing. Did I miss that explanation?

teo_zero• 4 years ago

AIUI, they didn't inject code, just mangled the stack to hijack the execution flow towards specific code fragments ("gadgets") already in the executable memory.

keepquestioning• 4 years ago

Hmm, doesn't ARM have mitigation against Return oriented Programming

ISL• 4 years ago

I'm very happy to see that a vulnerability introduced in a May 2022 was found, diagnosed, and fixed in a June 2022 update.

After something went wrong, a bunch of things went right very quickly. Nice to have good news on a Monday morning.

bumbledraven• 4 years ago

It's a bit confusing to me. The doc says:

… the vulnerable firmware was introduced by Google's Pixel security update of May 2022.

However, further down, in the timeline section, the doc indicates that the issue was reported before May 2022, all the way back in March 2022:

2022-03-02: Vulnerability reported. Opened issue 222318108 in Google's Issue Tracker, providing a technical description of the bug and a Proof of Concept (PoC) exploit…

rob_c8• 4 years ago

Very cool.

I wonder why companies still leave the UART pins accessible. Fine they're on the chip, but just remove the trace and slow down attack evolution is worth the cost of a board revision surely...

nickzana• 4 years ago

Isn't it better to leave them exposed and make it easier for security researchers who genuinely want to test the chip? Someone interested in and capable of developing and using/selling an exploit won't be deterred by needing a special cable to get a UART console, whereas a security researcher might appreciate the simpler access.

So long as it doesn't weaken the actual security model, companies should make their products as easy to analyze as possible imo.

rob_c8• 4 years ago

Then sell a dev unit surely, not a consumer grade device...

dmitrygr3• 4 years ago

If THAT is your idea of security, i hope you do not work on any hardware whose security matters. First thing anyone would do is find the pins and connect to them. It buys you nothing, and if anything tells me that i should go look for them.

Visible and labeled UART pins tell me that you've (hopefully) thought through the consequences of me having access to them. Hidden UART tells me that most likely nobody ever gave that half a thought.

rob_c8• 4 years ago

Do you have __any idea__ how difficult removing the chip and re-surface mounting it for an attack...

Removing the trace means an extra step which is the whole point. Ffs

trhway2• 4 years ago

Sounds like an amateur hour at that Google team. While post authors are putting blame on the un-safeness of C, absence of user input validation, like that integer from a message, is a path to a very unhappy place independent of language. The rest of the exploited places of that Titan software seem to be similarly sloppy.

atwood222• 4 years ago

Most languages don't let you (or at least make it hard to) directly convert user input into memory locations though. The scope of the issue in other languages would likely be much more limited.

trhway2• 4 years ago

It is unrelated. For example the input may be used only as a parameter for reading operations - ie. one can easily imagine a situation where even in a safest language using un-validated input may result in a call/query producing info outside of what would be expected for valid parameters.

alexbakker• 4 years ago

This is amazing work!

I was surprised to see that the reward was set at 10k initially. Granted, it was bumped to 75k later, but even that seems on the low side considering the degree of compromise that occurred here.

I may have given up too early during my (fairly brief) research on CVE-2019-9465. I let the lack of firmware source code availability stop me at the time, but in hindsight the presence of "0dd0adde0dd0adde" in the ciphertext likely indicated a crash in Titan M as well. Perhaps there would have been a similarly interesting path to exploitation there.

mastax• 4 years ago

Thanks to the leak functionality that we built with this exploit, we can now read arbitrary memory on the chip. This means we can now have access to any readable address. As a consequence, we can dump the secrets stored in the chip (such as the Root of Trust sent by the Pixel bootloader when the Titan M is updated).
One of the most interesting consequences of this attack is the ability to retrieve any StrongBox protected key, defeating the highest level of protection of the Android Keystore. Similarly to what happens in TrustZone, these keys can only be used inside Titan M, while they are stored in an encrypted key blob on the device.

I thought the whole point of making a hardware security chip (rather than using a general purpose microcontroller, possibly with crypto acceleration hardware) is that the private keys would be protected by the hardware design. So you could use the private key to e.g. create a digital signature but its impossible to read out the private key itself, outside of potential side-channels.

sedatk• 4 years ago

They missed the opportunity to call the article "Attack on Titan M".

Attacking Titan M with Only One Byte

Related Stories