joana&pedro

joana&pedro

We found out that reusing a key pair across different versions and modes of IPsec IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. These vulnerabilities existed in implementations by Cisco, Huawei, and others.

This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

Attacks on IKE implementations

With our attacks we can impersonate an IKE device: If the attack is successful, we share a set of (falsely) authenticated symmetric keys with the victim device, and can successfully complete the handshake – this holds for both IKEv1 and IKEv2. The attacks are based on Bleichenbacher oracles in the IKEv1 implementations of four large network equipment manufacturers: Cisco, Huawei, Clavister, and ZyXEL. These Bleichenbacher oracles can also be used to forge digital signatures, which breaks the signature based IKEv1 and IKEv2 variants. Those who are unfamiliar with Bleichenbacher attacks may read this post by our colleague Juraj Somorovsky for an explanation.

The affected hardware test devices by Huawei, Cisco, and ZyXEL in our network lab.

We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.

We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Where's the bug?

The public key encryption (PKE) based authentication mode of IKE requires that both parties exchanged their public keys securely beforehand (e. g. with certiﬁcates during an earlier handshake with signature based authentication). RFC 2409 advertises this mode of authentication with a plausibly deniable exchange to raise the privacy level. In this mode, messages three and four of the handshake exchange encrypted nonces and identities. They are encrypted using the public key of the respective other party. The encoding format for the ciphertexts is PKCS #1 v1.5.

Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.

PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not ofﬁcially available. There is no documentation and no conﬁguration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.

Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.

We were able to conﬁrm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):

Cisco: CVE-2018-0131, Security Advisory
Huawei: CVE-2017-17305, Security Advisory
Clavister: CVE-2018-8753, Security Advisory
Zyxel: CVE-2018-9129, Security Advisory

On an abstract level, these oracles work as follows: If we replace the ciphertext of the nonce in the third handshake message with a modiﬁed RSA ciphertext, the responder will either indicate an error (Cisco, Clavister, and ZyXEL) or silently abort (Huawei) if the ciphertext is not PKCS #1 v1.5 compliant. Otherwise, the responder continues with the fourth message (Cisco and Huawei) or return an error notiﬁcation with a different message (Clavister and ZyXEL) if the ciphertext is in fact PKCS #1 v1.5 compliant. Each time we learn that the ciphertext was valid, we can advance the Bleichenbacher attack one more step.

A Bleichenbacher Attack Against PKE

If a Bleichenbacher oracle is discovered in a TLS implementation, then TLS-RSA is broken since one can compute the Premaster Secret and the TLS session keys without any time limit on the usage of the oracle. For IKEv1, the situation is more difﬁcult: Even if there is a strong Bleichenbacher oracle in PKE and RPKE mode, our attack must succeed within the lifetime of the IKEv1 Phase 1 session, since a Diffie-Hellman key exchange during the handshake provides an additional layer of security that is not present in TLS-RSA. For example, for Cisco this time limit is currently ﬁxed to 60 seconds for IKEv1 and 240 seconds for IKEv2.

To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the conﬁdentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.

Bleichenbacher attack against IKEv1 PKE based authentication.

The figure above depicts a direct attack on IKEv1 PKE:

The attackers initiate an IKEv1 PKE based key exchange with Responder A and adhere to the protocol until receiving the fourth message. They extract the encrypted nonce from this message, and record the other public values of the handshake.
The attackers keep the IKE handshake with Responder A alive as long as the responder allows. For Cisco and ZyXEL we know that handshakes are cancelled after 60 seconds, Clavister and Huawei do so after 30 seconds.
The attackers initiate several parallel PKE based key exchanges to Responder B.

In each of these exchanges, they send and receive the ﬁrst two messages according to the protocol speciﬁcations.
In the third message, they include a modiﬁed version of the encrypted nonce according to the the Bleichenbacher attack methodology.
They wait until they receive an answer or they can reliably determine that this message will not be sent (timeout or reception of a repeated second handshake message).

After receiving enough answers from Responder B, the attackers can compute the plaintext of the nonce.
The attackers now have all the information to complete the key derivation and the handshake. They thus can impersonate Responder B to Responder A.

Key Reuse

Maintaining individual keys and key pairs for each protocol version, mode, and authentication method of IKE is difﬁcult to achieve in practice. It is oftentimes simply not supported by implementations. This is the case with the implementations by Clavister and ZyXEL, for example. Thus, it is common practice to have only one RSA key pair for the whole IKE protocol family. The actual security of the protocol family in this case crucially depends on its cross-ciphersuite and cross-version security. In fact, our Huawei test device reuses its RSA key pair even for SSH host identification, which further exposes this key pair.

A Cross-Protocol Version Attack with Digital Signature Based Authentication

Signature Forgery Using Bleichenbacher's Attack

It is well known that in the case of RSA, performing a decryption and creating a signature is mathematically the same operation. Bleichenbacher's original paper already mentioned that the attack could also be used to forge signatures over attacker-chosen data. In two papers that my colleagues at our chair have published, this has been exploited for attacks on XML-based Web Services, TLS 1.3, and Google's QUIC protocol. The ROBOT paper used this attack to forge a signature from Facebook's web servers as proof of exploitability.

IKEv2 With Digital Signatures

Digital signature based authentication is supported by both IKEv1 and IKEv2. We focus here on IKEv2 because on Cisco routers, an IKEv2 handshake may take up to four minutes. This more relaxed timer compared to IKEv1 makes it an interesting attack target.

I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.

If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].

Evaluation and Results

For testing the attack, we used a Cisco ASR 1001-X router running IOS XE in version 03.16.02.S with IOS version 15.5(3)S2. Unfortunately, Cisco's implementation is not optimized for throughput. From our observations we assume that all cryptographic calculations for IKE are done by the device's CPU despite it having a hardware accelerator for cryptography. One can easily overload the device's CPU for several seconds with a standard PC bursting handshake messages, even with the default limit for concurrent handshakes. And even if the CPU load is kept below 100 %, we nevertheless observed packet loss.

For the decryption attack on Cisco's IKEv1 responder, we need to ﬁnish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.

But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default conﬁguration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.

We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.

For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.

Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.

Responsible Disclosure

We reported our ﬁndings to Cisco, Huawei, Clavister, and ZyXEL. Cisco published ﬁxes with IOS XE versions 16.3.6, 16.6.3, and 16.7.1. They further informed us that the PKE mode will be removed with the next major release.

Huawei published ﬁrmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identiﬁed. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.

Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a ﬁx. For the successor models, the patched ﬁrmware version ZLD 4.32 (Release Notes) is available.

FAQs

Why don't you have a cool name for this attack?
The attack itself already has a name, it's Bleichenbacher's attack. We just show how Bleichenbacher attacks can be applied to IKE and how they can break the protocol's security. So, if you like, call it IPsec-Bleichenbacher or IKE-Bleichenbacher.
Do you have a logo for the attack?
No.
My machine was running a vulnerable firmware. Have I been attacked?
We have no indication that the attack was ever used in the wild. However, if you are still concerned, check your logs. The attack is not silent. If your machine was used for a Bleichenbacher attack, there should be many log entries about decryption errors. If your machine was the one that got tricked (Responder A in our figures), then you could probably find log entries about unfinished handshake attempts.
Where can I learn more?
First of all, you can read the paper [alternative link to the paper]. Second, you can watch the presentation, either live at the conference or later on this page.
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods including IKEv2 and it gives message flow diagrams of the protocols. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2. Furthermore, we describe the quirks of Huawei's implementation including crash bugs that could allow for Denial-of-Service attacks. Last but not least, it describes a dictionary attack against the PSK mode of authentication that is covered in a separate blogpost.

Media Coverage, Blogs, and more

English

German

Related word

joana&pedro

HashDB IDA Plugin

Malware string hash lookup plugin for IDA Pro. This plugin connects to the OALABS HashDB Lookup Service.

Adding New Hash Algorithms

The hash algorithm database is open source and new algorithms can be added on GitHub here. Pull requests are mostly automated and as long as our automated tests pass the new algorithm will be usable on HashDB within minutes.

Using HashDB

HashDB can be used to look up strings that have been hashed in malware by right-clicking on the hash constant in the IDA disassembly view and launching the HashDB Lookup client.

Settings

Before the plugin can be used to look up hashes the HashDB settings must be configured. The settings window can be launched from the plugins menu Edit->Plugins->HashDB.

Hash Algorithms

Click Refresh Algorithms to pull a list of supported hash algorithms from the HashDB API, then select the algorithm used in the malware you are analyzing.

Optional XOR

There is also an option to enable XOR with each hash value as this is a common technique used by malware authors to further obfuscate hashes.

API URL

The default API URL for the HashDB Lookup Service is https://hashdb.openanalysis.net/. If you are using your own internal server this URL can be changed to point to your server.

Enum Name

When a new hash is identified by HashDB the hash and its associated string are added to an enum in IDA. This enum can then be used to convert hash constants in IDA to their corresponding enum name. The enum name is configurable from the settings in the event that there is a conflict with an existing enum.

Hash Lookup

Once the plugin settings have been configured you can right-click on any constant in the IDA disassembly window and look up the constant as a hash. The right-click also provides a quick way to set the XOR value if needed.

Bulk Import

If a hash is part of a module a prompt will ask if you want to import all the hashes from that module. This is a quick way to pull hashes in bulk. For example, if one of the hashes identified is Sleep from the kernel32 module, HashDB can then pull all the hashed exports from kernel32.

Algorithm Search

HashDB also includes a basic algorithm search that will attempt to identify the hash algorithm based on a hash value. The search will return all algorithms that contain the hash value, it is up to the analyst to decide which (if any) algorithm is correct. To use this functionality right-click on the hash constant and select HashDB Hunt Algorithm.

All algorithms that contain this hash will be displayed in a chooser box. The chooser box can be used to directly select the algorithm for HashDB to use. If Cancel is selected no algorithm will be selected.

Dynamic Import Address Table Hash Scanning

Instead of resolving API hashes individually (inline in code) some malware developers will create a block of import hashes in memory. These hashes are then all resolved within a single function creating a dynamic import address table which is later referenced in the code. In these scenarios the HashDB Scan IAT function can be used.

Simply select the import hash block, right-click and choose HashDB Scan IAT. HashDB will attempt to resolve each individual integer type (DWORD/QWORD) in the selected range.

Installing HashDB

Before using the plugin you must install the python requests module in your IDA environment. The simplest way to do this is to use pip from a shell outside of IDA.
pip install requests

Once you have the requests module installed simply copy the latest release of hashdb.py into your IDA plugins directory and you are ready to start looking up hashes!

Compatibility Issues

The HashDB plugin has been developed for use with the IDA 7+ and Python 3 it is not backwards compatible.

Download Hashdb-Ida

Related news

joana&pedro

One of the many reasons users prefer Android devices is the ability to expand the amount of available storage space using the MicroSD Card. Since we have the ability add up to 256GB of external storage to Android devices today, you're bound to choke up when the SD card crashes without any tell-tale signs.

If you're experiencing issues on how to repair a crashed SD card on your Android device, there are certain fixes you can try out. Since there's not a singular solution to SD Card issues, we've created a guide to help you detect the issue with your external storage and mentioned multiple solutions to get your SD card working and even retrieve your stored data along with it.

Before you start

Don't format the card if you want to retain any of the photos on it. You can follow the tips in our separate article on how to format a write-protected SD card after you've tried to recover any files that are on your card.

Now, try and find a different card reader. If you've inserted an SD card into your laptop or PC's built-in slot and nothing happens, try using a different computer or a USB card reader.

Read More;- Hacking Gmail For Free Custom Domain

Sometimes it's the reader at fault – not the card. You can buy a USB SD card reader online for just a couple of pounds which will accept both microSD and standard SD cards.

Steps to Repair a Crashed SD Card and Protect your Data:

Step 1 – Physically clean the SD Card

Despite being durable and built to last, SD cards are prone to crashing sometimes due to physical damage. Since you carry your phone around everywhere, some dirt and dust are bound to fill up in the cracks, that can make SD card stop working from time to time.

The first thing you can try to do on how to repair a crashed SD card is physically scrub and clean it.

Remove the MicroSD card from your Android device and place it on a clean surface. Make sure that you turn off your phone before pulling out the SD card for safety.
Flip the MicroSD card and using a white eraser, gently scrub the gold contact pins of the SD card to get rid of any residual dirt or grime.
If you have an alcohol-based cleaning solution or even nail polish remover around, dab it on to the connector pins using a Q-tip and gently rub it.

Once the SD card has dried out, you can plug it back into your Android device and turn it on to see if the solution has worked.

Also Read;- How To Get Grammarly Premium Account Free 2018

Step 2 – Format the SD Card

If your SD card is being detected by the Android device but you're having trouble accessing the saved files, there's a good chance that the files are corrupt. This could either be due to a particular broken file in the saved storage, or a virus that is causing the issue.

Either way, the only option there is left for you to try out is make the SD card reusable for formatting it.

From the home screen of your Android device, head over to the Settings app and then scroll down to find the Storage
In the Storage tab, you'll be able to find the Erase SD Card option, so go ahead and select it.
Confirm your action to delete all of the files and folders stored on your SD card and this should effectively solve the issue.

Step 3 – Check the SD card compatibility

If you are trying to figure out how to repair a crashed SD card on an older Android device, you might just need to look at the details more carefully. If your SD card fails to be recognized on the mobile device but works with your computer, the problem could be related to compatibility.

Also Read;- How To Install and Run Backtrack On Android

If the MicroSD card that you are trying to use with your older phone is SDXC version (built for higher transfer speeds), it will not be recognized.
Look up the maximum capacity of expandable storage that is supported by your device, since they can vary from starting at 64GB to all the way up to 256GB.

Step 4 – Diagnose the SD card using a PC

If a simple format did not help you solve the SD card problem, you might need a more technical analysis of the issue. To do so, you can plug in your SD card into a computer and use the diagnostic tools to find out the pertaining errors and effectively fix them.

Connect your Android mobile device to a computer using a USB cable.
Make sure that you connect Android as MSC (Mass storage mode) and not MTP (Media transfer mode). You can do this using the notification menu once you connect the phone to your computer.
Launch the Windows Explorer and right click on the SD card driver you see on the screen. In the options menu, choose Properties – Tools – Error Checking and wait for the entire process to complete.
The computer will try to update the software for your SD card and fix any errors that are causing it to crash.

Step 5 – Use chkdsk to fix/repair a corrupted SD card without data loss

The "chkdsk" command is your first choice for damaged SD card repair. Requiring no format, it allows you to fix or repair a corrupted SD card and regain access to all your important files on the device. Let's see how it works. (I'm using Windows 7 for this demonstration)

1. Plug in your SD card to your computer with a card reader.

2. Go to the start menu, type in "cmd" in a search bar, hit enter and then you can see something named "cmd. exe" in a list of programs.

3. Right-click "cmd. exe" and then you will get the following command windows that allow you to fix your corrupted SD card without formatting.

4. Type in "chkdsk /X /f sd card letter:" or "chkdsk sd card letter: /f ", for example,"chkdsk /X /f G:" or "chkdsk h: /f".

After finishing all the steps, Windows will have checked and fixed the file system of the SD card. It usually takes several minutes. After that, if you see "Windows has made corrections to the file system" in the command window, then congratulations! The damaged SD card is successfully fixed and you can see your data again. If not, you should try a third-party data recovery software to retrieve your files from the damaged SD card and repair it by formatting.

Once the process has been completed, you can go ahead and pop the SD card back into your Android device and see if the issue has been resolved.

Step 6 : Use EaseUS Data Recovery Wizard to recover data from damaged SD card

1. Connect the corrupted SD card to your PC, launch EaseUS's data recovery software, select the card and click "Scan".
2. A quick scan will first start to search all the lost and existing data on the SD card. And after that, a deep scan will automatically launch in order to find more files.

3. After the scan, choose those files you want to recover and click the "Recover" button to retrieve them back.

Final Words :

So finally through this article, you have got to know about the method by which the SD card could be repaired and hence the data in it could be saved for the further access. We have tried to present the method in easy to grab manner and we believe that you could possibly get to know about it easily. Hope that you would have liked the information in this post, if it is so then please share it with others. Also, do not forget to share the post with others, let most of the people know about the method. Share your comments about the post through using the comment box below. At last never the fewer thanks for reading this post!