We would like to take the time to detail the security improvements made to our firmware, initially detailed on the blog post New firmware update 1.4.1 available for the Nano S published on the 6th of March. Following a transparent and responsible disclosure process, we are giving a full detailed assessment of the fixed attack vectors that the Firmware 1.4 patches, which were initially reported by three security researchers.

As the publication of these technical details might elevate the threat level of non-patched devices, we strongly encourage our users to update their firmware by following our step by step guide.

.

Summary
Bounty Program & Responsible Disclosure
Recommendations
Detailed Security Updates
Take away: the firmware update patches three security issues. The update process verifies the integrity of your device and a successful 1.4.1 update is the guarantee that your device has not been the target of any of the patched attack. There is no need to take any other action, your seed / private keys are safe.

For more details, and an in-depth explanation of all the attack vectors, please read this article. We also invite you to consult the FAQ at the end.

Bounty Program & Responsible disclosure
We would like to congratulate the three security researchers who found these bounties. We have been working closely with them to understand their findings and assess how serious it could be.

With their permissions, these three security researchers are (in alphabetic order by last name):

Timothée Isnard – Oracle padding on SCP
Saleem Rashid – MCU fooling
Sergei Volokitin – Isolation Exploit
We want to stress out the professionalism and skills of these three white hats who worked together with our security team and strictly respected our Bounty Program process. We fully appreciate their contribution, and they certainly deserve their rewards. We have asked each security researcher to sign our Ledger Bounty Program Reward Agreement, that you can review as part of our transparency process (this document doesn’t prevent the researcher to publish their own reports).

In the security world, responsible disclosure is very important to prevent hackers from using the vulnerability. This is what distinguishes a white hat from a black hat, an irresponsible security researcher from a responsible security researcher.

You will find after our recommendations a description of the issues reported by these three researchers. Buckle your security belt, it’s gonna be a bit technical 🙂

Recommendations
Upgrading the Nano S with the firmware 1.4.1 entirely secures it, as it immediately solves all potential security threats. The firmware update process verifies the integrity of your device and a successful 1.4.1 update is the guarantee that your device has not been tampered with.

Important note: if your firmware update fails, it doesn’t mean that your device is compromised! Please see our FAQ at the end of the article for more information.

As you may want to understand more precisely the impact of the mitigated security issues, you will find below an overview of each attack’s impact.

Oracle Padding on SCP
No impact regarding the security of your device.

MCU fooling
By having physical access to the device before generation of the seed, an attacker could fool the device by injecting his seed instead of generating a new one. The most likely scenario would be a scam operation from a shady reseller.

If you bought your device from Ledger or an authorized reseller, it is extremely unlikely that your device could have been compromised using the above scenario;
If you bought your device from a different channel, if this is a second hand device , or if you are unsure, then you could be victim of an elaborate scam. However, as no demonstration of the attack in the real has been shown, it is very unlikely;
In both cases, a successful firmware update is the proof that your device has never been compromised.

Isolation exploit
This attack can be achieved only by having physical access to the device, knowing your PIN code and installing a rogue unsigned application. This rogue app could break isolation between apps and access sensitive data managed by specific apps such as GPG, U2F or Neo.

If you have never installed an unsigned application yourself (requiring the use of command line tools and ignoring a security warning on the device), then you are perfectly safe.

Detailed Security Updates
Oracle padding on SCP – Timothée Isnard
Loading and upgrading BOLOS
The load and upgrade of BOLOS is performed using a Secure Channel. It’s inspired from the Global Platform SCP-02 standard, modified by replacing T-DES with AES. This protocol guarantees authenticity and confidentiality. It’s based on an “Encrypt then MAC” scheme.

When BOLOS needs to be upgraded, a secure channel is established between the Secure Element of the device and Ledger’s HSM. This channel allows to send our firmware in an encrypted way. Furthermore, it also allows the HSM to attest the Ledger device to which it’s connected is genuine. Finally, the firmware authenticity is proven using a standard signature. The modified version of our SCP-02 we implemented did not embed the MAC part allowing an Oracle Padding attack.

Oracle Padding
Oracle padding is a famous cryptographic attack discovered in 2002 by Serge Vaudenay. It allows an attacker to know whether the padding of an encrypted message is correct or not. This mechanism allows to decrypt the datastream without actually knowing the key being used. Mounting this attack can be a bit tricky, especially considering that the throughput of the leakage is very low.

In our case, the researcher demonstrated that it was possible to mount the attack but was only able to retrieve a few bytes of the datastream.

He worked a lot on understanding our protocol and how the secure channel is mounted. It consists first on an ECDH to share a common secret which is used afterwards as the key for the AES-CBC. The IV is initially 0x0. The padding check is performed by the device, if it’s not found, a status error is raised 0x6802, otherwise, the message is handled normally.

To implement it, it’s necessary to brute force all possible value of a byte paddings so that the guessed plaintext byte turns into a 0x80, mounting another Secure Channel each time in order to retrieve which one gives the correct message. The throughput is thus very low since our HSM is shared with all our users and mostly because there are a lot of different padding values to test.

From a user perspective, it’s not a problem. We don’t base the security of our devices on the confidentiality of our firmware. The security of your device is based on the value of your seed which is protected by our OS and the Secure Element. Decrypting our firmware wouldn’t give to the attacker more information on your seed/secret data.

On the contrary, what is important from a user perspective is to able to prove the genuineness of your device and the authenticity of the firmware you load. Those two security claims remain intact.

Countermeasure
Our SCP has been updated to add the MAC part which prevents this kind of attack. Furthermore, additional countermeasures have been implemented server side mitigating the issue until the 1.4.1 upgrade is available.

What should you do
Upgrading the firmware will fully mitigate the attack. No need to change your seed as this attack vector could not have compromise anything.

All the security team would like to congratulate Timothée for this good work, his help and his professionalism through the disclosure process.

MCU fooling – Saleem Rashid
Architecture
In order to understand correctly the vulnerability reported, one has first to understand the Nano-S architecture.

The Nano-S architecture delegates the display and input validation to a non secure chip (STM32).

At each bootup both chips are paired – the SE is requesting the STM32 firmware, hashing it and checking a signature to guarantee the device integrity.

This is that mechanism which has been dodged in this attack scenario.

.

The overall idea
The generic attack scenario is to modify the STM32 firmware while faking its genuiness to the SE.

The STM32 firmware can be modified :

When launching in bootloader mode (boot with left button pressed)
When physically obtaining the device, over the exposed STM32 debugging interface (JTAG)
From this, several attacks scenario can be designed involving changing the display or faking user confirmation.

To avoid these attacks scenarios, the secure element authenticates the MCU. It sends a command which requests to the MCU entire content of its memory and the signature.

This verification was not robust enough and it’s been demonstrated that some code caving was possible still respecting the signature of the MCU firmware.

Code caving is pretty tricky. The idea is to hide code inside unused part of the memory. But in order to get a correct signature verification, the firmware dump command must be modified.

When the SE verifies the signature, it sends a command to the MCU requesting the MCU to dump its memory and to send it to the secure element. The idea is then to modify this function in order it sends the same stream to the SE without actually dumping the memory.

However, these scenario are difficult to put in place because of a very simple reason: the memory size of the STM32 is very small (32 Kb) – the attacker has to include both code modifications and the existing code in order to pass the validation.

Two different kinds of scenarios have been imagined by the security researcher:

The first one consists in getting a physical access to the device under attack. Then load a modified firmware on the MCU which would try to trick the user or the SE. For instance it could simulate button pushes. In this scenario, a malware on the desktop PC would try to ask for transactions to the Nano S. As soon as the user enters its PIN, the malware would present a transaction to be signed and the modified firmware would simulate the buttons press bypassing the explicit user consent.
One should note this scenario has not been demonstrated while theoretically possible.

In the second scenario presented by the researcher, the attack would allow to mount a scam. A malicious seller would load a modified firmware on a preseeded wallet which would trick the user. On this modified firmware, the seed generation phase is replaced. And instead of generating a new seed it would just display the 24 words pre-configured by the attacker.
This scenario has been demonstrated by the researcher.

Thanks to our versatile architecture using a secure element, we can update our firmware and connect back to our root of trust the Secure Element.

This attack cannot extract the private keys or the seed. The Secure Element (containing the secrets) is not at all concerned by the MCU fooling.

We can also detect if this attack has been deployed in the field every time a device connects back to our server using Ledger Manager to load an application or update the firmware. Our genuineness check have been upgraded to counter this.

Countermeasures
Our upgrade is quite simple while completely efficient.

The MCU code has been refactored preventing simple code caving
The signature verification is now enforced using two different mechanism;
Address fetch randomization
Timing constraints preventing the MCU to “uncompress” data to send to the SE
Several CRC code and checks are added filling up the MCU memory and preventing the modification of the memory without detection

What should you do
Upgrading the firmware will fully mitigate the attack. Moreover, a successfull firmware upgrade is the proof that your device was never the target of such attack.

All the security team would like to congratulate Saleem for this good work, his help and his professionalism through the disclosure process.

Isolation exploit – Sergei Volokitin
BOLOS Architecture
In order to understand all the work performed by Sergei, it’s important to have an overview of BOLOS architecture.

BOLOS (Ledger’s OS) is a native and versatile OS which can be implemented on several Hardware architectures. It uses most of the security features brought by the Secure Element (Nano-S case).

.

.

The OS lies on the Secure Hardware and use the certified security functions implemented in the Hardware.

It offers cryptographic primitives which allows applications to compute electronic signatures for instance. To compute an electronic signature the app performs a syscall to BOLOS which takes advantage of the secure hardware to compute securely the digital signature. Furthermore the OS contains certificate allowing to update itself securely. This certificate allows to authenticate your device preventing Ledger devices to be cloned.

It also contains a service which authenticates the applications loaded on top of it. It’s possible to load signed app and unsigned app as well. In this last case a warning is displayed on the screen when launched.

Finally, the OS provides memory isolation. It means for instance that BTC app can not access to the data of the ETH app. This mechanism is enforced using the MPU of the Secure Element.

However, when an app is installed it can derived any key path. So even if the memory isolation implemented, It’s possible to load an app which can access to the private keys of each cryptocurrency. The derived paths during the instal can be checked looking at the loading files.

As it’s a bit technical, Ledger strongly recommend to load only signed (by Ledger) app which only derives their own path.

Bypassing the isolation
The security researcher found a bug in our isolation implementation. In several syscalls offered by BOLOS, the pointers the parameters were not correctly checked allowing to reference NULL pointer, or to give pointers located in other regions of the memories. Additionally, in some conditions, the MPU bounds were incorrectly positioned allowing a malicious app to use these syscalls in order to access data outside of its scope.

NULL Pointer dereferencing
This PoC is particularly smart. The researcher built an oracle allowing to use the Hash primitive to dump part of memory. The idea is to call cx_hash_sha256 with a null pointer varying the length of data to be hashed. The data at offset 0x00 is then hashed by the cx_hash_sha256 service and the result of the hash is returned.

Secure Hash are one-way function but requesting a hash of length 1, allows the attacker to try all possible value for the byte and check which one gives the returned hash. The same process is applied with length 2 knowing the first byte and so on.

Consequences: It allowed the researcher to dump a large amount of data. The seed and private keys remained secure.

Countermeasure: The pointer is now properly checked and the MPU windows correctly positioned.

Pointers length not properly checked
The length of some syscalls (cx_hash_syscall, cx_rsa_sign, cx_ecdsa_sign) was not sufficiently checked.

Using a malicious applet, it’s possible to use these syscalls to retrieve partial information. Indeed, depending on the value of the RSA_key or of the hash structure header, the crypto service returns a different error.

The attack scenario is the following

Load a malicious app which requests one of these crypto service
The crypto service is called with an incorrect length parameters
Depending on the value of the pointed memory, a different exception is raised
Consequences: It allows to distinguish some specific value in the memory.

In the RSA case, it’s possible to know if a specific 32-bit value at a given memory address equals one of these values 0x80000000, 0x00010000, 0x80010000, 0x00020000, or not.

The researcher thought these values were from the RSA key while they belong to the next app.

In the hash case, it’s possible to know if a specific 8-bit value at a given memory address is comprised between 1 and 8.

In the ecdsa_sign, it’s possible to retrieve 64 bytes of the memory of the following application. In this case the implemented mechanism is even trickier and won’t be detailed here.

In these 3 cases, this is partial information dump but leads at least to an entropy reduction and is thus considered as an attack. Again the seed and private keys remained secure.

Again these 3 vectors are very smart oracles.

Countermeasure: The length parameters are now properly checked and the MPU windows correctly positioned.

Device wipe
After 3 PIN resets, the device wipes the OS data memory, erasing the seed and the private keys which are stored in the OS data memory. But the device does not wipe the apps data. The researcher showed it’s possible to retrieve the data in a previously installed app. The scenario is the following:

Get a device
Perform 3 wrong PINs to trigger a wipe
Install a specific (unsigned) app with a large uninitialized data zone and a command allowing to dump this zone
Consequences: This allowed the researcher to dump memory of already installed app breaking thus the isolation. In our signed applications, secret data are not stored in their flash zone. Only the following applications could have been revealed application data information:

Neo (a third party app)
PGP (a developer app). It allows the user to import its private key which is clearly not protected by the seed
Monero Beta: this app is only a beta app since it’s released yet. Monero offers different way to handle the key. At the beginning there was no BIP derivation.
U2F: on this app, the researcher proved it was possible to retrieve the HMAC Key and the current value of the counter of the U2F app.
Again the seed and all private keys of other apps remained secure.

Countermeasure: The flash user zone is also wiped after 3 wrong PINs. This wipe is checked at startup. The new design is completely tearing proof.

What should you do
Updating the firmware fully mitigate the attacks. Seed and private keys remained secure so no other action necessary.

All the security team would like to congratulate Sergei for this good work, his help and his professionalism through the disclosure process.

Charles GUILLEMET – Chief Security Officer at Ledger

(Source: https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ )

Photo link "source" @AzadHaso

●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●
🔥🔰 Secure your Crypto with Hardware Wallets:
💎Buy a Ledger Nano S
💎Buy a TREZOR
💎Buy Bitcoin with Debit or Credit card

●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●

🌐Stay in touch! You can find us on ↓ ابق على تواصل! يمكنك أن تجد لنا على:

Steemit ➥ Azad Haso
D.Tube ➥ Azad Haso
Busy ➥ Azad Haso
YouTube ➥ Azad Haso
FutureNet ➥ Azad Haso
Twitter ➥ Azad Haso
Facebook ➥ Azad Haso
Google+ ➥ Azad Haso
Telegram ➥ Azad Haso
Blog ➥ Azad Haso
Azad Haso WebSite ➥ http://www.AzadHaso.com

☮️ @AZADHASO 💚❤️💛

A FREE Man refuses to be a Slave
رجل حر يرفض أن يكون عبداً
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●

🚫🚫🚫 WARNING DISCLAIMER 🚫🚫🚫

The information in this Video & Blog is for educational purposes only and is not investment advice. Please do your own research before making any investment decisions. Online And Cryptocurrency investments are a volatile and high risk in nature. Don't invest more than what you can afford to lose. Crush Crypto makes no representations, warranties, or assurances as to the accuracy, currency or completeness of the content contained in this video or any sites linked to or from this video.

🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫🚫

إخلاء المسؤولية

المعلومات في هذا الفيديو والمدونة هي لأغراض تعليمية فقط وليس مشورة استثمارية. يرجى إجراء البحوث الخاصة بك قبل اتخاذ أي قرارات الاستثمار. الاستثمارات في الانترنيت و العملات الرقمية هي متقلبة ومخاطر عالية في الطبيعة. لا تستثمر أكثر مما يمكن أن تخسره. لا يقدم سحق التشفير أية تعهدات أو ضمانات أو تأكيدات بشأن دقة أو محتوى أو اكتمال المحتوى الوارد في هذا الفيديو أو أي مواقع مرتبطة بهذا الفيديو أو منه.

●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●

🙏🏼PLEASE DON’T FORGET TO
👍🏻Upvote, ✍️comment, 🚼follow, and ♨️resteem!

🙏🏼Thanks for your contribution!

1-Photo link "source" follow Azad Haso

3- Photo link "source" Steemit-Upvote-Comment-Follow, and ♨️Resteem-

Photo link "source" @AzadHaso.Com

.

@AzadHaso

.

(Source: https://www.ledger.fr/2018/03/20/firmware-1-4-deep-dive-security-fixes/ )