Ledger App Isolation Bypass04 August 2020
This post will disclose a vulnerability in the Ledger hardware wallets that can lead to theft of user funds.
An attacker can exploit this method to transfer Bitcoin while the user is under the impression that a transaction of another, less valuable altcoin (e.g. Litecoin, Testnet Bitcoins, Bitcoin Cash, etc.) is being executed
If you use bitcoin forks on your device, you could be affected. You should avoid using these ledger apps until fixes are available.
The issue has been disclosed to Ledger but remains unaddressed. See Disclosure Timeline.
Update: Ledger has released new application versions that warn the user in these scenarios.
The ledger device exposes bitcoin (mainnet) public key and signing functionality outside of the "Bitcoin" app. It presents misleading transaction confirmation requests indicating the selected app's addresses and amounts when in fact different transactions are being signed.
To support an asset on Ledger devices, you must install the corresponding app. Ledger devices support multiple apps and typically users will use it to store a variety of cryptocurrencies.
Ledger apps are intended to be isolated. Such that only one app is unlocked on the device at once. Unlocking the asset allows external communication to prompt for various functions for example:
- Exporting public keys
- Signing messages
- Confirming transactions
Thus, from a security perspective, the expectation is that locked apps are untouchable by external messages.
It was discovered that for Bitcoin and Bitcoin forks, the device exposes it's functions for any of the assets. In other words, having unlocked the Litecoin app, you will receive a confirmation request for a Bitcoin transfer while the interface presents it as a transfer of Litecoins to a Litecoin address. Accepting the confirmation produces a fully valid signed Bitcoin (mainnet) transaction.
Steps to reproduce:
Open the Litecoin app
Retrieve mainnet bitcoin (segwit) addresses using
Query UTXOs and construct a bitcoin transaction to spend outputs
createPaymentTransactionNew(...)to prompt device for signing this transaction
Receive Bitcoin Mainnet valid signed transaction
Expectation: Ledger device should throw an error at step 2 and step 4 and prevent execution
Actual: Ledger prompts user for a litecoin transaction and produces a valid signed transaction spending the Bitcoin utxos
+----------------------------------+ ++ Amount ++ ++ ☓ LTC 5.25512356 ✓ ++ +----------------------------------+ +----------------------------------+ ++ Address ++ ++ ☓ ltc1q3fjf... ✓ ++ +----------------------------------+
Proof of Concept
The PoC demonstrates retrieving a valid signed bitcoin mainnet transaction from the ledger device while user is under the impression that a litecoin transaction is being signed.
It spends from the first 20 receive and change addresses of the native segwit bitcoin wallet.
The implications are serious. As briefly covered, users expect to be protected by the ledger device when they have not unlocked their Bitcoin app. Yet, while having an altcoin unlocked, external applications can still:
- Read the Bitcoin xpub (thereby knowing all addresses belonging to the wallet)
- Prompt Bitcoin transactions from the device that will be displayed as altcoin transactions
The methods of attack here are many. Essentially, any trust placed on altcoin ledger apps can be exploited. Consider the following:
- You are invited to try out a new service with testnet coins, that actually sweeps real Bitcoin out of your wallet.
- You swap low value coins on an untrusted exchange. The exchange can read your Bitcoin balances and given a good enough opportunity will take the exit. You wouldn't have applied the same level care with altcoins.
- You could be targeted with a patched version of Ledger Live that sends Bitcoin instead of altcoins. Then prompted to do a P2P trade with altcoins.
No investigation has been done on instances of this exploit in the wild.
Firmware: All versions. Currently 1.6.0
App Versions: All versions. Currently 1.4.3
Apps: Any apps deriving from the Bitcoin app as per btchip_context.h
Apps Tested: Bitcoin Testnet, Litecoin
Recommendations for Ledger and users.
Apps should be completely isolated with regards to the derivation paths that they are allocated to. No public key info or signing functionality should be exposed while they are not open.
- Altcoin apps should be disabled on the Ledger live app directory and users should be notified to avoid using altcoin apps until fixes are available
- Apps/firmware should be updated to prevent this bypass
- Users should be notified to urgently upgrade to the patched versions.
- Avoid using altcoin apps until fixes are available
Interactions with Ledger
Based on my experience from the first disclosure (Jan 19), I understood that that they weren't motivated to see this issue to completion.
Ledger was aware of the issue before the disclosure as they indicated the latest firmware update includes fixes. Post disclosure, they described that the app updates were under QA and that the issue would be disclosed publicly once updates have been made. No further progress was observed and requests for update received no response.
With the second, more serious disclosure, expectations were already low. I observed that:
- They minimised the issue to privacy initially
- When pressed for their plans in addressing the vulnerability, had no input.
- Still insisted on a 90 day disclosure period despite being fully aware of issue for 1y 6mo minimum (during development of firmware 1.5.5)
- No further communications regarding steps to fix or disclose. Requests for comment had no response.
Based on the interactions described above, it was apparent that there was no intention to address the issue and the disclosure period would not yield any results. Nonetheless I gave them the benefit of the doubt and afforded some patience.
I do not consider myself a security expert. Despite this, I was able to discover this issue while developing and experimenting with Ledger support on Liquality. It is worrying that the vulnerability did not utilise any complicated techniques such as side-channel attacks, buffer overflows etc. This could indicate that there are other issues undiscovered or in plain sight.
Perhaps the most shocking conclusion is the negligence from Ledger regarding the handling of this issue. For an issue with this severity, to not attempt a fix, not communicate progress and avoid disclosure, is disrespectful towards the trust that people (including myself) have placed on them. With their increased focus in other departments (integrating alt coins, trading), I urge them to reconsider their attention to security. Such should be the commitment to a hardware wallet.
- 18 Jan 2019 - Privacy related aspect of the vulnerability (reading addresses) disclosed to Ledger via report and
PoC. ([email protected])
- Ledger: Firmware was updated but apps still need to be updated.
- Prompted for public disclosure: Bug will be disclosed once apps are updated.
- 30 Apr 2019 - Disclosed issue unfixed - Ledger contacted for update. No response. ([email protected])
- 1 May 2020 - Discovered root cause expands to signing functions and can be exploited to steal funds ([email protected])
- 2 May 2020 - New report detailing bypassing the isolation for signing disclosed to Ledger with new report and PoC ([email protected])
- 4 May 2020 - Ledger investigating. ([email protected])
- 10 May 2020 - No response. Follow up. ([email protected])
- 12 May 2020 - Issue acknowledged - mistakenly at first as only privacy related - set out disclosure timeline ([email protected])
- 13-14 May 2020 - Exchanges with ledger clarifying severity and awareness ([email protected])
- 17 June 2020 - Request for update (bo[email protected]) - No response
- 28 July 2020 - Request for update sent to Ledger Donjon (Twitter DM) - No response
- 03 Aug 2020 - Vulnerability not fixed or disclosed by Ledger. Public disclosure
- 05 Aug 2020 - Ledger updates the applications to provide a warning in these scenarios.