Weak Cipher Vulnerability (2024)

Play Labs on this vulnerability with SecureFlag!

1. Weak Cipher
   1. Description
   2. Impact
   3. Scenarios
   4. Prevention
   5. Testing
   6. References

Description

In modern secure communication systems, encryption algorithms, or ciphers, define the way in which data is transformed into and out of an encrypted state. Strong algorithms endeavor to make the process of reversal beyond reach to malicious actors due to inherent computational complexity. Weak ciphers are those encryption algorithms vulnerable to attack, often as a result of an insufficient key length. In NIST parlance, weak ciphers are either:

• Deprecated (the use of the algorithm and key length is allowed, but the user must accept some risk) or;
• Disallowed (algorithm or key length is no longer allowed for the indicated use).

Ciphers degrade in their efficacy like all other security controls, with new cryptanalysis techniques and an exponential increase in computing power both playing prominent roles in the deprecation and/or complete scrapping of various standards. The below examples are of weak algorithms that are completely broken:

• The Data Encryption Standard (DES) is an algorithm that was adopted as an official standard in 1977 in the US. The original proposal was modified slightly to strengthen against differential cryptanalysis but also significantly weakened against brute-force attacks, particularly as a result of the reduction of key size to 56 bits. With enough horsepower, it was only a matter of time before a key-search machine, capable of rapidly computing every possible key, in turn, was able to break DES.

• Electronic Codebook (ECB) is an algorithm that has been proven to be semantically insecure, as the encryption of two identical cleartext blocks always generates the same block of ciphertext. Thus, it can enable an attacker to determine if two ECB blocks are identical, share a common prefix, or share other identifiable commonalities, including repetitive data.

  See Also

  SSL inspection: Benefits, risks, and how it worksSSL VulnerabilityServer is detected with Weak SSL/TLS Key Exchange on Port 1433 which is used by application SQLSRVR.EXE - Microsoft Q&ASoftware Security | Protect your Software at the Source

• The Cipher Block Chaining (CBC) is largely being replaced by the Galois Counter Mode (GCM), which has the benefit of providing integrity, unlike CBC. Typically, CBC is combined with a Message Authentication Code to ensure the ciphertext has not been tampered with in transit; however, this additional layer of security is often missed.

Impact

Cipher deprecation and/or obsolescence is of perennial concern as it opens the door to malicious actors with the available tools and know-how. Successful brute-forcing of weak ciphers can result in a malicious actor decrypting data containing sensitive information, potentially leading to a complete compromise of confidentiality and integrity. The extent of damage is really only limited to the value of compromised data and the imagination of the attacker.

This sobering collection of statistics regarding the SSL cryptographic protocols presents the pervasiveness of weak ciphers in use at least up to late 2019. Figures that jump out include the fact that in the top 100,000 sites in Q3 of 2018, 6.8% were still using the broken SSL 2.0 & SSL 3.0 versions.

Scenarios

A major chunk of the Internet’s secure communications are funneled through the SSL/TLS cryptographic protocols. It is important to note that these protocols are not insecure per se; however, if improperly configured, they could be susceptible to a type of attack that forces it to switch from using a high standard encryption connection in favor of a weaker mode. The attack takes advantage of configurable options in the TLS cryptographic protocol that allow for backward compatibility with older systems, i.e., they accept inferior/dated/weak ciphers, in the worst case even downgrading encrypted traffic to cleartext.

Prevention

Preventing attacks on weak ciphers can be greatly diminished primarily by not using weak ciphers! There is, of course, a bit more to it than that in terms of implementation and correct configuration, but ensuring adherence to up-to-date standards is the best way to mitigate exploitation.

• Developers must stay up to date with relevant, accepted industry standards from relevant organizations, e.g., NIST.
• The use of weak ciphers and modes that are known to be insecure must be avoided.
• In the case of TLS, since the client and the server can negotiate the choice of algorithm in the event that there are different levels of capability, weak ciphers must be disabled.

This removal of backward compatibility eliminates the possibility of a downgrade.

Testing

Verify that known insecure block modes (i.e., ECB, etc.), padding modes (i.e., PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e., Triple-DES, Blowfish, etc.) are not used unless required for backward compatibility.

• OWASP ASVS: 6.2.5
• OWASP Testing Guide: Testing for Weak Encryption

References

NIST

CWE - Inadequate Encryption Strength

Microsoft - Choose an Encryption Algorithm

Cryptography Stack Exchange - Why shouldn’t I use ECB encryption?

Wikipedia - Data Encryption Standard

Wikipedia - Semantic Security

Wikipedia - Downgrade Attack

ReferralMD - The Impact of Weak Protocols & Ciphers on Healthcare Servers