5 ms·

Still Got Your Crypto: In Response to Wallet.fail’s Presentation

49 points by asymmetric 8y ago

Ayesh 8y ago
I didn't watch the 35c3 presentation, but it certainly looks like it's an absurd attack. Kudos to Ledger people for constructively replying to it. Some talks in 35c3, defcon, etc remind me of the rubber hose security (https://xkcd.com/538/ https://xkcd.com/538/). On the other hand, www.ledger.fr web site does not properly redirect to HTTPS (e.g http://www.ledger.fr/bounty-program/ http://www.ledger.fr/bounty-program/) and that would've been a more practical one.
- 32032141 8y ago
  Ledger has for a long time been grossly inept in security, there's really nothing absurd about this attack at all. In the Bitcoin industry we frequently see very detailed setup for long timeframe attacks and substantial effort going into identity theft and physical compromise. Worse, for these deices in particular a backdoored device is almost undetectable due to the way ECDSA can be used to transmit encrypted data in its signatures. Ledger was recently compromised, or showed that they have no release process (both equally bad) by releasing a version of their application which stole user funds. Their claim is that they released a development version from a dirty git clone that contained "testing" code which happened to have a hardcoded address for sending every transaction to. https://www.ledger.fr/2018/08/03/important-message-concerning-the-ledger-wallet-ethereum-chrome-app/ https://www.ledger.fr/2018/08/03/important-message-concernin...
  - tgsovlerkhgsel 8y ago
    That's indeed impressively bad. The full address seems to be https://etherscan.io/address/0xC33B16198DD9FB3bB342d8119694f94aDfcdca23 https://etherscan.io/address/0xC33B16198DD9FB3bB342d8119694f... There don't seem to be any outbound transactions from that address, so Ledger refunded the victims separately instead of sending the funds back. That means they likely don't control the key. OTOH, the funds (worth about $40k for the Ether + another $20k for the tokens) haven't moved at all, so "test key that was lost long ago" does seem plausible. (Especially since it also was used on the testnet before https://ropsten.etherscan.io/address/0xC33B16198DD9FB3bB342d8119694f94aDfcdca23 https://ropsten.etherscan.io/address/0xC33B16198DD9FB3bB342d...) Could of course also be an attacker who was hoping for a bigger loot and didn't want to risk getting caught over $60k, but as you said, not sure what's worse - incompetence or compromise.
    - 32032141 8y ago
      Yep. Either they are so incompetent that they released software out of their git tree from someone's work environment, and had absolutely no process to catch a ridiculous and obvious failure. Otherwise they got popped and are lying about it. Neither is anything but a disaster.
pmorici 8y ago
This seems a little disingenuous to me. The implication of the first attack is not that someone might sneak into your house and modify your Ledger hardware. It's that hardware could come to you with modified firmware from the get go.
- 32032141 8y ago
  This is largely the issue with 'hardware wallets', the security models aren't particularly well defined and this leads to ambiguity like this. You're absolutely correct in that the concern is the device is not genuine, which is what attestation of the firmware is supposed to prevent. In the case of the Ledger, the attestation doesn't prove anything about the safety of the device unfortunately for a number of reasons (this attack, and other logical ones). The obvious one is that the security domains in the device are idiotic. There's a "secure" processor with almost no processing power or IO, and a "insecure" one which handles the screen, buttons and IO. Both of them handle secrets (for example, the seed shown on the screen), which leaves you with essentially no gain whatsoever. The more logical hardware implant than the one shown at CCC is a bluetooth module that can simply read the I2C lines going to the screen and transmit the seed as a beacon whenever it is plugged in. This has the advantage of not needing presence as with their demonstration, and with assistance doesn't need any physical presence. I described this as a concept for a security review of a cold storage setup which was "unbreakable". Is this sort of thing realistic? Perhaps. Is a $5 wrench attack more sensible? Probably. It's worth considering what supply chain attacks are possible though.
  - lima 8y ago
    > The obvious one is that the security domains in the device are idiotic. There's a "secure" processor with almost no processing power or IO, and a "insecure" one which handles the screen, buttons and IO. Both of them handle secrets (for example, the seed shown on the screen), which leaves you with essentially no gain whatsoever. I think the idea is that the secure processor will verify the insecure processor's firmware (the "MCU check"), making such attacks impractical. Of course, the design is broken and it can be bypassed by emulation, but security isn't all or nothing - "no gain whatsoever" is not true.
anonymouzz 8y ago
What bothers me is that they did not responsibly disclose the vulnerabilities to the manufacturers ahead of time. This is not moral, and I'm not sure what one gains by not doing that. I think that conference organizers should pressure presenters to do that before talks. Either that or attendees should apply bottom up pressure and ask live questions like "what did you do to responsibly disclose this issue?". I think I'll do that on future security conferences I attend.
- 32032141 8y ago
  I've been doing security research in this industry for a while and it's effectively not worth anybodies time to attempt to report hardware wallet, or software bugs 'responsibly'. I've found that by far the most common responses are being told that the attack doesn't fit into their design (as here), it's not reasonable to expect, or that for some reason. For a long time the Trezor wallets custom crypto library was simply python transliterated and had a sidechannel attack so large that you could measure the EC multiply operation with a SDR from across a room. This was supposedly out of their scope (but has been since somewhat fixed, but not entirely) for some reason, despite being something that is easily fixed using industry standard constant time operations. Responses you do get at protecting the fact that a lot of the bugs are burned into hardware and can't be fixed by anything but them re-issuing it. It's not in the interests to ever acknowledge issues.
  - wbl 8y ago
    Power analysis is a lot harder to fix then you think. Constant time isn't enough: you probably need blinding and some hardware assistance with features that are inevitably under NDA.
    - 32032141 8y ago
      This is true. Many of these devices are using effectively joke crypto libraries however, theres a world of difference between something that needs a sophisticated setup, and the python crypto library that was transliterated into C and makes absolutely no effort at being constant time. The original Trezor software took something in the order of 300ms to produce a single signature. You could probably have done recovery of the nonce from ec multiply with a stopwatch. If your security appliance is using an ECDSA library for Arduino that has absolutely zero tests or review, you just outright lost. Some of the more well known products in the space do exactly this. https://github.com/kmackay/micro-ecc/blob/master/test/test_ecdsa.c https://github.com/kmackay/micro-ecc/blob/master/test/test_e...
paulpauper 8y ago
i have occasionally heard stores of ppl losing funds from hardware wallets. usually it's after buying it on Amazon.
- coralreef 8y ago
  Its usually because the buyer was duped into following a fake instruction setup. The scammer will produce an official physical 'card' of recovery words that ships with the wallet, tricking the user into putting money into accounts that the scammer also has access to.

49 points by asymmetric 8y ago

I didn't watch the 35c3 presentation, but it certainly looks like it's an absurd attack. Kudos to Ledger people for constructively replying to it. Some talks in 35c3, defcon, etc remind me of the rubber hose security (https://xkcd.com/538/ https://xkcd.com/538/). On the other hand, www.ledger.fr web site does not properly redirect to HTTPS (e.g http://www.ledger.fr/bounty-program/ http://www.ledger.fr/bounty-program/) and that would've been a more practical one.

32032141 8y ago
Ledger has for a long time been grossly inept in security, there's really nothing absurd about this attack at all. In the Bitcoin industry we frequently see very detailed setup for long timeframe attacks and substantial effort going into identity theft and physical compromise. Worse, for these deices in particular a backdoored device is almost undetectable due to the way ECDSA can be used to transmit encrypted data in its signatures. Ledger was recently compromised, or showed that they have no release process (both equally bad) by releasing a version of their application which stole user funds. Their claim is that they released a development version from a dirty git clone that contained "testing" code which happened to have a hardcoded address for sending every transaction to. https://www.ledger.fr/2018/08/03/important-message-concerning-the-ledger-wallet-ethereum-chrome-app/ https://www.ledger.fr/2018/08/03/important-message-concernin...
- tgsovlerkhgsel 8y ago
  That's indeed impressively bad. The full address seems to be https://etherscan.io/address/0xC33B16198DD9FB3bB342d8119694f94aDfcdca23 https://etherscan.io/address/0xC33B16198DD9FB3bB342d8119694f... There don't seem to be any outbound transactions from that address, so Ledger refunded the victims separately instead of sending the funds back. That means they likely don't control the key. OTOH, the funds (worth about $40k for the Ether + another $20k for the tokens) haven't moved at all, so "test key that was lost long ago" does seem plausible. (Especially since it also was used on the testnet before https://ropsten.etherscan.io/address/0xC33B16198DD9FB3bB342d8119694f94aDfcdca23 https://ropsten.etherscan.io/address/0xC33B16198DD9FB3bB342d...) Could of course also be an attacker who was hoping for a bigger loot and didn't want to risk getting caught over $60k, but as you said, not sure what's worse - incompetence or compromise.
  - 32032141 8y ago
    Yep. Either they are so incompetent that they released software out of their git tree from someone's work environment, and had absolutely no process to catch a ridiculous and obvious failure. Otherwise they got popped and are lying about it. Neither is anything but a disaster.

pmorici 8y ago

This seems a little disingenuous to me. The implication of the first attack is not that someone might sneak into your house and modify your Ledger hardware. It's that hardware could come to you with modified firmware from the get go.

32032141 8y ago
This is largely the issue with 'hardware wallets', the security models aren't particularly well defined and this leads to ambiguity like this. You're absolutely correct in that the concern is the device is not genuine, which is what attestation of the firmware is supposed to prevent. In the case of the Ledger, the attestation doesn't prove anything about the safety of the device unfortunately for a number of reasons (this attack, and other logical ones). The obvious one is that the security domains in the device are idiotic. There's a "secure" processor with almost no processing power or IO, and a "insecure" one which handles the screen, buttons and IO. Both of them handle secrets (for example, the seed shown on the screen), which leaves you with essentially no gain whatsoever. The more logical hardware implant than the one shown at CCC is a bluetooth module that can simply read the I2C lines going to the screen and transmit the seed as a beacon whenever it is plugged in. This has the advantage of not needing presence as with their demonstration, and with assistance doesn't need any physical presence. I described this as a concept for a security review of a cold storage setup which was "unbreakable". Is this sort of thing realistic? Perhaps. Is a $5 wrench attack more sensible? Probably. It's worth considering what supply chain attacks are possible though.
- lima 8y ago
  > The obvious one is that the security domains in the device are idiotic. There's a "secure" processor with almost no processing power or IO, and a "insecure" one which handles the screen, buttons and IO. Both of them handle secrets (for example, the seed shown on the screen), which leaves you with essentially no gain whatsoever. I think the idea is that the secure processor will verify the insecure processor's firmware (the "MCU check"), making such attacks impractical. Of course, the design is broken and it can be bypassed by emulation, but security isn't all or nothing - "no gain whatsoever" is not true.

anonymouzz 8y ago

What bothers me is that they did not responsibly disclose the vulnerabilities to the manufacturers ahead of time. This is not moral, and I'm not sure what one gains by not doing that. I think that conference organizers should pressure presenters to do that before talks. Either that or attendees should apply bottom up pressure and ask live questions like "what did you do to responsibly disclose this issue?". I think I'll do that on future security conferences I attend.

32032141 8y ago
I've been doing security research in this industry for a while and it's effectively not worth anybodies time to attempt to report hardware wallet, or software bugs 'responsibly'. I've found that by far the most common responses are being told that the attack doesn't fit into their design (as here), it's not reasonable to expect, or that for some reason. For a long time the Trezor wallets custom crypto library was simply python transliterated and had a sidechannel attack so large that you could measure the EC multiply operation with a SDR from across a room. This was supposedly out of their scope (but has been since somewhat fixed, but not entirely) for some reason, despite being something that is easily fixed using industry standard constant time operations. Responses you do get at protecting the fact that a lot of the bugs are burned into hardware and can't be fixed by anything but them re-issuing it. It's not in the interests to ever acknowledge issues.
- wbl 8y ago
  Power analysis is a lot harder to fix then you think. Constant time isn't enough: you probably need blinding and some hardware assistance with features that are inevitably under NDA.
  - 32032141 8y ago
    This is true. Many of these devices are using effectively joke crypto libraries however, theres a world of difference between something that needs a sophisticated setup, and the python crypto library that was transliterated into C and makes absolutely no effort at being constant time. The original Trezor software took something in the order of 300ms to produce a single signature. You could probably have done recovery of the nonce from ec multiply with a stopwatch. If your security appliance is using an ECDSA library for Arduino that has absolutely zero tests or review, you just outright lost. Some of the more well known products in the space do exactly this. https://github.com/kmackay/micro-ecc/blob/master/test/test_ecdsa.c https://github.com/kmackay/micro-ecc/blob/master/test/test_e...

paulpauper 8y ago

i have occasionally heard stores of ppl losing funds from hardware wallets. usually it's after buying it on Amazon.

coralreef 8y ago
Its usually because the buyer was duped into following a fake instruction setup. The scammer will produce an official physical 'card' of recovery words that ships with the wallet, tricking the user into putting money into accounts that the scammer also has access to.