Crypto Articles - H Crypto List - H 2021 2020 2019 2018 2017 2016
OpenSSL Releases Patches for 2 High-Severity Security Vulnerabilities
27.3.2021 Crypto Thehackernews
The maintainers of OpenSSL have released a fix for two high-severity security flaws in its software that could be exploited to carry out denial-of-service (DoS) attacks and bypass certificate verification.
Tracked as CVE-2021-3449 and CVE-2021-3450, both the vulnerabilities have been resolved in an update (version OpenSSL 1.1.1k) released on Thursday. While CVE-2021-3449 affects all OpenSSL 1.1.1 versions, CVE-2021-3450 impacts OpenSSL versions 1.1.1h and newer.
OpenSSL is a software library consisting of cryptographic functions that implement the Transport Layer Security protocol with the goal of securing communications sent over a computer network.
According to an advisory published by OpenSSL, CVE-2021-3449 concerns a potential DoS vulnerability arising due to NULL pointer dereferencing that can cause an OpenSSL TLS server to crash if in the course of renegotiation the client transmits a malicious "ClientHello" message during the handshake between the server and a user. The issue was introduced as part of changes dating back to January 2018.
"If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack," the advisory said.
Nokia, which has been credited with reporting the flaw on March 17, fixed the DoS bug with a one-line code change.
CVE-2021-3450, on the other hand, relates to an X509_V_FLAG_X509_STRICT flag that enables additional security checks of certificates present in a certificate chain. While this flag is not set by default, an error in the implementation meant that OpenSSL failed to check that "non-CA certificates must not be able to issue other certificates," resulting in a certificate bypass.
As a result, the flaw prevented apps from rejecting TLS certificates that aren't digitally signed by a browser-trusted certificate authority (CA).
"In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose," OpenSSL said.
Benjamin Kaduk from Akamai is said to have reported the issue to the project maintainers on March 18. The vulnerability was discovered by Xiang Ding and others at Akamai, with a fix put in place by former Red Hat principal software engineer and OpenSSL developer Tomáš Mráz.
Although neither of the issues affect OpenSSL 1.0.2, it's also worth noting that the version has been out of support since January 1, 2020, and is no longer receiving updates. Applications that rely on a vulnerable version of OpenSSL are advised to apply the patches to mitigate the risk associated with the flaws.
OpenSSL Project released 1.1.1k version to fix two High-severity flaws
26.3.2021 Crypto Vulnerebility Securityweek
The OpenSSL Project addresses two high-severity vulnerabilities, including one related to verifying a certificate chain and one that can trigger a DoS condition.
The OpenSSL Project this week released version 1.1.1k to address two high-severity vulnerabilities, respectively tracked as CVE-2021-3450 and CVE-2021-3449.
The CVE-2021-3449 vulnerability could be exploited to trigger a DoS condition by sending a specially crafted renegotiation ClientHello message from a client.
“An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack,” State the advisory.
The issue affects servers running OpenSSL 1.1.1 versions with TLS 1.2 and renegotiation enabled, which is the default configuration. The vulnerability was reported by Peter Kästle and Samuel Sapalski from Nokia.
The CVE-2021-3450 vulnerability is related to the verification of a certificate chain when using the X509_V_FLAG_X509_STRICT flag.
“The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check.” reads the advisory published by the OpenSSL Project. “An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates,”
The vulnerability was reported by Benjamin Kaduk and Xiang Ding from Akamai.
In February 2021, the OpenSSL Project released security patches to address three vulnerabilities, two denial-of-service (DoS) flaws, and an incorrect SSLv2 rollback protection issue.
OpenSSL 1.1.1k Patches Two High-Severity Vulnerabilities
26.3.2021 Crypto Vulnerebility Securityweek
OpenSSL 1.1.1k patches two high-severity vulnerabilities
The OpenSSL Project on Thursday announced the release of version 1.1.1k, which patches two high-severity vulnerabilities, including one related to verifying a certificate chain and one that can lead to a server crash.
The first security hole, tracked as CVE-2021-3450, has been described as a “problem with verifying a certificate chain when using the X509_V_FLAG_X509_STRICT flag.” The flaw was discovered by researchers at Akamai.
“Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates,” the OpenSSL Project explained in its advisory.
The second vulnerability, tracked as CVE-2021-3449 and discovered by employees of telecoms giant Nokia, involves sending a specially crafted renegotiation ClientHello message from a client, and it can be exploited for denial-of-service (DoS) attacks.
“If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack,” reads the description of this vulnerability.
Servers running OpenSSL 1.1.1 are affected by CVE-2021-3449 if they have TLS 1.2 and renegotiation enabled — this is the default configuration.
Some companies have already started informing their customers about these OpenSSL vulnerabilities.
OpenSSL has come a long way in terms of security since the disclosure of the Heartbleed vulnerability back in 2014. Only three vulnerabilities were fixed in 2020, and only two of those were rated high severity. No high-severity issues were patched in OpenSSL in 2018 and 2019.
The OpenSSL Project addressed three vulnerabilities
18.2.2021 Crypto Securityaffairs
The OpenSSL Project addressed three vulnerabilities, including two denial-of-service (DoS) issues and a bug in the SSLv2 rollback protection.
The OpenSSL Project released security patches to address three vulnerabilities, two denial-of-service (DoS) flaws, and an incorrect SSLv2 rollback protection issue.
The fist vulnerability, tracked as CVE-2021-23841, is a NULL pointer dereference issue that can be exploited to cause a crash and trigger a DoS condition. The security advisory states that the X509_issuer_and_serial_hash function is never called directly by OpenSSL itself, which means it only impacts applications that invoke the function directly while managing certificates obtained from untrusted sources.
“The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack.” reads the advisory.
The issue has been rated ‘moderate’ in severity, it affects OpenSSL versions 1.1.1i and below. Users should upgrade to version 1.1.1j. OpenSSL versions 1.0.2x and below are also affected by this issue.
The vulnerability was reported by the popular Google Project Zero expert Tavis Ormandy on 15th December 2020, and Matt Caswell fixed it.
OpenSSL also addressed a low-severity integer overflow vulnerability in CipherUpdate tracked as CVE-2021-23840 that could be exploited to cause a crash.
The bug, tracked as CVE-2021-23840, was identified by Paul Kehrer.
“Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash.” reads the advisory.
Versions 1.1.1i and below are affected by this issue along with versions 1.0.2x and below.
The third issue is a low-severity flaw, tracked as CVE-2021-23839, it is an incorrect SSLv2 rollback protection.
The flaw was reported to OpenSSL Project on 21st January 2021 by D. Katz and Joel Luellwitz from Trustwave.
The issue affects servers using OpenSSL 1.0.2 which are vulnerable to SSL version rollback attacks.
In 2010, the Open SSL project addressed three vulnerabilities, including two DDoS issues rated high severity.
Three New Vulnerabilities Patched in OpenSSL
18.2.2021 Crypto Securityweek
OpenSSL updates patch new vulnerabilities
The OpenSSL Project on Tuesday announced the availability of patches for three vulnerabilities, including two that can be exploited for denial-of-service (DoS) attacks and one related to incorrect SSLv2 rollback protection.
The most serious of the vulnerabilities, with a severity rating of moderate, is CVE-2021-23841, a NULL pointer dereference issue that can result in a crash and a DoS condition. The security hole is related to a function (X509_issuer_and_serial_hash) that is never called directly by OpenSSL itself, which means it only impacts applications that use the function directly with certificates obtained from untrusted sources.
The flaw was reported to OpenSSL developers by Google Project Zero researcher Tavis Ormandy and it has been patched with the release of OpenSSL 1.1.1j. Versions 1.1.1i and earlier are impacted.
OpenSSL 1.1.1j also fixes a low-severity integer overflow issue that can also lead to a crash. The bug, tracked as CVE-2021-23840, was identified by Paul Kehrer.
Another low-severity issue, CVE-2021-23839, was reported to the OpenSSL Project by researchers at cybersecurity firm Trustwave, who discovered that servers using OpenSSL 1.0.2 are vulnerable to SSL version rollback attacks. However, an attack can only be launched against certain configurations and OpenSSL 1.1.1 is not impacted.
CVE-2021-23839 has been patched in version 1.0.2y. However, OpenSSL 1.0.2 is no longer supported so the update is only available to premium support customers.
OpenSSL has come a long way in terms of security since the disclosure of the vulnerability dubbed Heartbleed back in 2014. Only three vulnerabilities were patched in 2020, and only two of those, which could be exploited for DoS attacks, were rated high severity. No high-severity issues were fixed in OpenSSL in 2018 and 2019.
Let’s Encrypt Gears Up to Replace 200M Certificates a Day
17.2.2021 Crypto Threatpost
The open CA prepares for ‘worst scenarios’ with new fiber, servers, cryptographic signing and more.
Let’s Encrypt just announced an infrastructure makeover which means the open certificate authority (CA) is able to re-issue up to 200 million certificates in a 24-hour period, something the service said could be necessary in “some of the worst scenarios.”
The upgrade comes a year after Let’s Encrypt was compromised by a Certificate Authority Authorization (CAA) bug and was forced to revoke 3 million Transport Layer Security (TLS) certificates on a single day, March 4, potentially leaving the sites behind them insecure or unavailable.
Let’s Encrypt, a free service of the Internet Security Research Group, has secured nearly 250 million websites, toward its goal of “100 percent HTTPS,” the group’s 2020 annual report said.
Protection Against Breaches
Josh Aas said in a recent blog post about the upgrade that the automated service issues about 2 million certificates every day. But in the event of a wide-scale breach, it could be necessary to replace all of them at once.
Aas explained last March’s CAA bug only impacted 2.6 percent of all Let’s Encrypt’s active certificates, and while disruptive, could have been much worse.
“What if that bug had affected all of our certificates?” Aas wrote. “That’s more than 150 million certificates covering more than 240 million domains. What if it had also been a more serious bug, requiring us to revoke and replace all certificates within 24 hours? That’s the kind of worst-case scenario we need to be prepared for.”
The large-scale upgrade was funded by corporate donations from companies including Facebook, Amazon Web Services, Mozilla, GitHub, Red Hat and others, the group explained. The hardware was provided courtesy of Cisco, Thales and Fortinet, they added.
Aas explained that efforts to improve Let’s Encrypt were focused on five specific areas: database performance, internal networking speed, cryptographic signing module (HSM) performance and bandwidth.
Let’s Encrypt Upgraded RAM
The database, he said, is “at the heart of the service we offer.” The Let’s Encrypt database keeps track of all the certificates and accounts and, Aas explained, is “Write-heavy with plenty of reads as well.”
The previous Let’s Encrypt servers couldn’t have handled a massive re-issue in a single day, he said, so they were replaced with new-generation Dell database servers with “dual AMD EPYC 7542 CPUs, 64 physical cores in total,” the announcement said.
“These machines have 2TB of faster RAM. Much faster CPUs and double the memory is great, but the really interesting thing about these machines is that the EPYC CPUs provide 128 PCIe4 lanes each,” Aas explained. “This means we could pack in 24 6.4TB NVME drives for massive I/O performance. There is no viable hardware RAID for NVME, so we’ve switched to ZFS to provide the data protection we need.”
Let’s Encrypt Now Running on 25G Fiber Network
Let’s Encrypt also upgraded its 1G copper network infrastructure.
“We originally looked into upgrading to 10G but learned that upgrading to 25G fiber wasn’t much more expensive, Aas said. “Cisco ended up generously donating most of the switches and equipment we needed for this upgrade, and after replacing a lot of server network interface cards, Let’s Encrypt is now running on a 25G fiber network!”
Let’s Encrypt Gets HSM Cryptograhic Capacity
On a day Let’s Encrypt would need to re-issue 200 million certificates it would require its pair of Luna Hardware Security Modules (HSMs) at each data center to perform at least 600 million cryptographic signing operations in 24 hours — including an online certificate status protocol (OSCP) response for signature revocation; a certificate signature for replacements; and a response signature for the replacement— for each certificate.
Aas said the previous HSMs that Let’s Encrypt was using could only handle about 190 million signatures in 24 hours, max.
“That isn’t enough,” he wrote. Thales donated new HSMs, giving Let’s Encrypt the capacity to process 864 million signing operations per day, just from one data center.
Let’s Encrypt Boosts Bandwidth, API
The CA also boosted its bandwidth to increase its ability to sync and analyze their databases across data centers and the cloud, according to the announcement. It also enhanced its notification for early renewal with an API extension.
Let’s Encrypt uses the ACME protocol to verify that users control a given domain name and to issue them a certificate. To get a Let’s Encrypt certificate, users need to choose a piece of third-party client software to use.
“In order to get all those certificates replaced, we need an efficient and automated way to notify ACME clients that they should perform early renewal,” Let’s Encrypt’s Aas wrote. “Normally ACME clients renew their certificates when one third of their lifetime is remaining, and don’t contact our servers otherwise. We published a draft extension to ACME last year that describes a way for clients to regularly poll ACME servers to find out about early-renewal events. We plan to polish up that draft, implement and collaborate with clients and large integrators to get it implemented on the client side.”
Critical Libgcrypt Crypto Bug Opens Machines to Arbitrary Code
2.2.2021 Crypto Threatpost
The flaw in the free-source library could have been ported to multiple applications.
The Libgcrypt project has rushed out a fix for a critical bug in version 1.9.0 of the free-source cryptographic library. An exploit would allow an attacker to write arbitrary data to a target machine and execute code.
The security vulnerability is a heap-buffer overflow bug in Libgcrypt 1.9.0 (released on January 19 – previous versions are not affected), which researchers said can be exploited by merely decrypting a block of data. The issue is patched (CVE pending) in Libgcrypt version 1.9.1.
Libgcrypt is a general-purpose cryptographic library for developers to use when building applications, originally based on code from GNU Privacy Guard (GnuPG in turn is a free-software replacement for Symantec’s PGP cryptographic software suite). Libgcrypt is POSIX-compatible, meaning it can be used across Linus, Unix and macOSX applications, and can be enabled using a cross-compiler system for Microsoft Windows.
The bug is “simple to exploit,” according to Google Project Zero researcher Tavis Ormandy, who discovered and reported the issue.
“There is a heap-buffer overflow in Libgcrypt due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker-controlled data, no verification or signature is validated before the vulnerability occurs,” Ormandy explained in his report, published as part of Libgcrypt’s advisory on Friday.
Though the flawed version is no longer available for download, it’s unclear how many developers downloaded it for use in building their applications before it was taken down. Developers should replace the buggy library with the newest version, Libgcrypt authors noted.
Cryptographer Filippo Valsorda noted that Homebrew was affected by the flawed library. Homebrew is an open-source software package management system that simplifies the installation of software on Apple’s macOS operating system and Linux. Homebrew’s managers acknowledged the bug and fixed the issue.
He also tweeted that the fix is problematic on Intel CPU machines.
Third-Party, Open-Source Code: Supply-Chain Problems
Bugs in third-party libraries tend to linger in applications long after patches have been deployed. In fact, a full 70 percent of applications being used today have at least one security flaw stemming from the use of an open-source library, according to Veracode’s latest State of Software Security report.
“Most library-introduced flaws (nearly 75 percent) in applications can be addressed with only a minor version update; major library upgrades are not usually required,” according to the Veracode report. “This data point suggests that this problem is one of discovery and tracking, not huge refactoring of code.”
Cybercriminals also understand that code repositories and third-party libraries represent an attractive avenue for mounting a supply-chain-type attack by seeding them with malicious code. In a recent example from last month, three malicious software packages were published to npm, a code repository for JavaScript developers to share and reuse code blocks.
The packages could have been used as building blocks in various web applications; and any applications corrupted by the code can steal tokens and other information from Discord users, researchers said.
And in December, RubyGems, an open-source package repository and manager for the Ruby web programming language, had to take two of its software packages offline after they were found to be laced with malware.
The gems contained malware that ran itself persistently on infected Windows machines and replaced any Bitcoin or cryptocurrency wallet address it found on the user’s clipboard with the attacker’s.
“We have repeatedly seen…open-source malware striking GitHub, npm and RubyGems, attackers can exploit trust within the open-source community to deliver pretty much anything malicious, from sophisticated spying trojans like njRAT, to…CursedGrabber,” Sonatype researcher Ax Sharma told Threatpost at the time.
Google discloses a severe flaw in widely used Libgcrypt encryption library
2.2.2021 Crypto Securityaffairs
Google discovered a flaw in GNU Privacy Guard (GnuPG)’s Libgcrypt encryption library that could be exploited to get remote code execution.
The popular white hat hacker Tavis Ormandy of Google Project Zero discovered a severe heap buffer overflow flaw in GNU Privacy Guard (GnuPG)’s Libgcrypt encryption software could have allowed a remote attacker to write arbitrary data to the target machine, potentially leading to code execution.
“There is a heap buffer overflow in libgcrypt due to an incorrect assumption in the block buffer management code. Just decrypting some data can overflow a heap buffer with attacker controlled data, no verification or signature is validated before the vulnerability occurs.” reads the advisory published by Ormandy. “This code in _gcry_md_block_write (part of the generic block buffer abstraction code) assumes that the occupied space in a block buffer cannot exceed the blocksize of the algorithm:”
Libgcrypt is a general purpose cryptographic library originally based on code from GnuPG. It provides functions for all cryptographic building blocks and is present in major Linux distributions like Fedora and Gentoo, along with macOS package manager Homebrew. It’s also the crypto library used by systemd for DNSSEC.
The vulnerability was discovered on January 28 and only impacts version 1.9.0 of libgcrypt, the GnuPG team addressed it in less than 24 hours with the release of a new version. The team recommends users to stop using the vulnerable version of the library.
“A severe bug was reported yesterday evening against Libgcrypt 1.9.0 which we released last week. A new version to fix this as weel as a couple of build problems will be released today.” states the advisory published by the GnuPG team. “In the meantime please stop using 1.9.0. It seems that Fedora 34 and Gentoo are already using 1.9.0”
The cryptography engineer Filippo Valsorda analyzed the bug in a Twitter thread and reported that the root cause of the issue is the lack of memory safety in Libgcrypt’s C code.
Valsorda explained that the vulnerability was introduced by the development team to mitigate timing side-channel attacks.
The vulnerability could be exploited by an attacker by sending the library a specially-crafted block of data to decrypt that could trigger the buffer overflow.
“We have to announce the availability of Libgcrypt version 1.9.1. This version fixes a critical security bug in the recently released version 1.9.0. If you are already using 1.9.0 please update immediately to 1.9.1.” wrote Libgcrypt author Werner Koch.
“Exploiting this bug is simple and thus immediate action for 1.9.0 users is required. A CVE-id has not yet been assigned. We track this bug at https://dev.gnupg.org/T5275.“
Encrypted Services Providers Concerned About EU Proposal for Encryption Backdoors
30.1.2021 BigBrothers Crypto Securityweek
European encrypted services providers ProtonMail, Threema, Tresorit and Tutanota on Thursday urged European Union policy makers to rethink plans that would require the implementation of encryption backdoors.
The Council of the European Union in December adopted a resolution on “security through encryption and security despite encryption.” The council said it supports the development and use of strong encryption to protect citizens and organizations, but at the same time it believes law enforcement and judicial authorities need to be able to exercise their legal powers.
There has been a lot of discussion over the past years about finding a balance between providing strong encryption to users while also enabling law enforcement to access encrypted communications and data during their investigations. However, while policymakers around the world are convinced that such a balance can somehow be achieved, tech companies say it’s impossible, as it would require the implementation of encryption backdoors that could be leveraged not only by law enforcement, but also by bad actors.
ProtonMail, Threema, Tresorit and Tutanota say they are concerned about the Council of the EU’s resolution and they have each issued a statement warning that the rights of EU citizens are under threat from these anti-encryption proposals.
“Whilst it’s not explicitly stated in the resolution, it’s widely understood that the proposal seeks to allow law enforcement access to encrypted platforms via backdoors. However, the resolution makes a fundamental misunderstanding: encryption is an absolute, data is either encrypted or it isn’t, users have privacy or they don’t,” said Tresorit, which provides end-to-end encrypted cloud storage for businesses.
Andy Yen, the CEO of encrypted email service ProtonMail, commented, “Put simply, the resolution is no different from the previous proposals which generated a wide backlash from privacy conscious companies, civil society members, experts and MEPs. The difference this time is that the Council has taken a more subtle approach and explicitly avoided using words like ‘ban’ or ‘backdoor’. But make no mistake, this is the intention. It’s important that steps are taken now to prevent these proposals going too far and keep European’s rights to privacy intact.”
Arne Möhle, CEO and founder of Tutanota, a free encrypted email service, warned about the implications for EU citizens.
“With the latest attempt to backdoor encryption, politicians want an easier way to prevent crimes such as terrorist attacks while disregarding an entire range of other crimes that encryption protects us from: End-to-end encryption protects our data and communication against eavesdroppers such as hackers, (foreign) governments, and terrorists. By demanding encryption backdoors, politicians are not asking us to choose between security and privacy. They are asking us to choose no security,” Möhle said.
And Martin Blatter, CEO and founder of secure messaging application Threema, warned about the implications for European businesses.
“Young European companies are now at the forefront of this revolution in technology and data protection. Experience shows that anything that weakens these achievements can and will be abused by third parties and criminals alike thus endangering the security of all of us. With the abundance of uncontrollable open-source alternatives, users would simply move on to those applications if they knew a service was compromised,” said Blatter.
He added, “Forcing European vendors to bypass or deliberately weaken end-to-end encryption would destroy the European IT startup economy without providing even one bit of additional security. Europe would recklessly abandon its unique competitive advantage and become a privacy wasteland, joining the ranks of the most notorious surveillance states in the process.”
While law enforcement agencies have often complained about not being able to conduct their investigations due to strong encryption, there is some evidence suggesting that at least some agencies, such as the FBI, do have the resources needed to access data from encrypted devices.
Firefox Improves Privacy Protections With Encrypted Client Hello
9.1.2021 Crypto Securityweek
Mozilla is strengthening the privacy protections in Firefox with the implementation of Encrypted Client Hello (ECH), an evolutionary step from Encrypted Server Name Indication (ESNI).
In 2018, just after Cloudflare turned on Encrypted SNI, Mozilla added support for encrypting the Transport Layer Security (TLS) SNI extension to Firefox Nightly.
While aiming to better protect against eavesdropping, SNI was found to leak the identity of visited websites during the initial TLS handshake. An extension to TLS 1.3 and above, ESNI was meant to address the data leakage through replacing the SNI extension in Client Hello with an encrypted variant. Client Hello is the first message exchanged in the TLS handshake process.
Only encrypting the SNI extension, however, was found to deliver incomplete protection, while ESNI’s use in the real-world was deemed challenging from both interoperability and deployment perspectives, thus preventing it from being widely adopted.
ECH aims to address the issue with ESNI by encrypting the entire Client Hello message, instead of only the SNI extension. The modification was added to the recent versions of the ESNI specification and was also accompanied by a change in name.
By encrypting the entire handshake, ECH keeps metadata secret, thus protecting the SNI from eavesdroppers on the network. Additionally, it ensures that more security features and improvements can be added to TLS with minimum impact on user privacy, Cloudflare explains.
With the new privacy feature enabled, Firefox ensures that an encrypted “ClientHelloInner” is used for the TLS handshake when connecting to a server that supports ECH. The “ClientHelloInner” is an extension to the unencrypted “ClientHelloOuter.”
While working with Cloudflare to have the ECH specification standardized at the IETF, Mozilla is also moving forth with implementing the feature in its browser. Thus, Firefox 85 will switch from ESNI to ECH draft-08, but users should expect an update to draft-09 soon.
For those who have enabled ESNI in Firefox, the about:config option for ESNI is gone, but they can manually enable ECH before it becomes default, by heading to about:config. ECH, however, will only be used with servers that support it.
“While ECH is under active development, its availability may be intermittent as it requires both the client and server to support the same version. As always, settings exposed only under about:config are considered experimental and subject to change,” Mozilla points out.
Cryptologists Crack Zodiac Killer’s 340 Cipher
18.12.2020 Crypto Threatpost
The Zodiac’s serial killer’s 340 cipher, which couldn’t be solved for 50 years, has been cracked by a remote team of mathematicians.
A remote team of three hobbyist cryptologists have solved one of the Zodiac Killer’s cipher after a half century. And while the name of the elusive serial killer remains hidden, the breakthrough represents a triumph for cryptology and the basic building blocks of cybersecurity — access control and segmentation.
The Zodiac serial killer is believed to have murdered at least five people — and likely more — in and around the Northern California area in the late 1960s and early 1970s. The still-unnamed murderer sent a series of four coded messages to local newspaper outlets, bragging about his crimes and containing cryptic icons, which earned him the moniker “Zodiac”.
The 340 Cipher
The first cipher was quickly decoded. But the second, the 340 Cipher, named after its 340 characters, was trickier to figure out — until this week, almost 50 years later, when an unlikely team of cryptographers broke the code.
This cipher was sent to the offices of the San Francisco Chronicle in in 1969. David Oranchak, a web designer based in Virginia, has been trying to solve it for 14 years — but a breakthrough remote collaboration with other code breakers was the key.
Oranchak made a series of YouTube videos about about the cipher which attracted the others to the project. Building off Oranchak’s work, Australian-based mathematician Sam Blake calculated that there were 650,000 possible ways to read the code, and Jarl Van Eycke, whose day job is as a warehouse operator in Belgium, wrote the code-breaking software, according to a Vice report and interview with Oranchak.
An ‘Algorithmic’ Approach
“When I watched those, I thought ‘This is a really good analytical approach that he’s taken to try to solve this.’ And I sort of saw a couple of things that I thought might be interesting for him to try,” Blake told Vice in a recent interview. “So I reached out to him originally through a YouTube comment, and then we got chatting, and it went from there. I got serious about it in March of this year, and we spent a lot of time on it between March and now, just going through, having no success, no success, no success. And then…we just started to piece it together.”
He explained the appeal of Oranchak’s approach as “algorithmic,” in the interview.
“There’s been a lot of solutions in the past that have required artistic creativity and a lot of bending and massaging of the cipher in order to get it to make a few legible words… then something like a sentence, and often then the name of somebody who could be associated with the case,” Blake said. “What we did was a very different approach to that. We looked at different possible ways you could read the cipher—what other reading directions could they have taken in terms of trying to write it out—and we then ran them through supercomputers and looked for a solution in that direction.”
According to Oranchak and team, the message reads:
“I HOPE YOU ARE HAVING LOTS OF FUN IN TRYING TO CATCH ME THAT WASNT ME ON THE TV SHOW WHICH BRINGS UP A POINT ABOUT ME I AM NOT AFRAID OF THE GAS CHAMBER BECAUSE IT WILL SEND ME TO PARADICE ALL THE SOONER BECAUSE I NOW HAVE ENOUGH SLAVES TO WORK FOR ME WHERE EVERYONE ELSE HAS NOTHING WHEN THEY REACH PARADICE SO THEY ARE AFRAID OF DEATH I AM NOT AFRAID BECAUSE I KNOW THAT MY NEW LIFE IS LIFE WILL BE AN EASY ONE IN PARADICE DEATH”
The group has been officially recognized by the FBI for breaking the cipher.
“The FBI is aware that a cipher attributed to the Zodiac Killer was recently solved by private citizens,” Cameron Polan, spokeswoman for the FBI’s San Francisco office told The Chronicle. “The Zodiac Killer case remains an ongoing investigation for the FBI San Francisco division and our local law-enforcement partners.”
The statement concluded, that “out of respect for the victims and their families, we will not be providing further comment at this time.”
The key, according to Blake was looking at other directions the cipher could be read, and processing those with the 650,000 possibilities through a supercomputer at the University of Melbourne, he added.
The scheme, Blake added, can be found in a 1950s Army cryptography field manual, but Zodiac wrote the code so that it needed to be read diagonally. But what made it nearly impossible to crack was actually an error that he made.
“So he had a pattern in the way in which he was writing out where he would go one row down, two columns across, write a letter; then go one row down, two columns across and write a letter, and so on,” Blake told Vice. “And in that second segment, at some stage—it looks like an accident—instead of going one row down, two columns across he’s just gone one down, one across. And that broke the symmetry.”
Two of Zodiac’s ciphers remain unsolved.
Cybersecurity Implications
Besides the historical break in a 50-year-old murder case, the back-to-basics cryptographic feat serves as a reminder about the importance of tried-and-true fundamentals when it comes to cybersecurity, according to Fortinet CISO Phil Quade.
“The backbone of the science of cybersecurity is built from cryptography, access control and segmentation,” Quade said in his 2019 book, The Digital Big Bang. “As a science, practice and discipline, cybersecurity has only a few silver bullets. For now, cryptography is the rare exception, a simple powerful way to provide substantial protection against the torrential downpour of cyberattacks. But while cryptography remains one of cybersecurity’s most powerful tools today, we must always prepare for the risks we will face tomorrow.”
Every time there’s a new “cipher” (i.e., crytographic algorithm in today’s vernacular), others will try to break it. And vice versa. Earlier in December, researchers claimed a breakthrough in the arms race that cryptography has become.
Researchers from the University of Science and Technology of China explained in the journal Science claimed quantum supremacy: they were able to get a system they named Jiuzhang to perform a calculation in minutes that would have taken a traditional supercomputer an estimated 10,000 years to solve.
The security concern is that quantum computers will be able to crack RSA public key cryptography, used to protect data in transit. That means security teams will have to pivot to new post-quantum cryptography solutions. A conservative estimate from a 2019 DigiCert report said teams will need to have protections from quantum computing breaches in place by 2022.
Seriously, SHA3 where art thou?
27.5.2020 SANS Crypto
A couple weeks ago, Rob wrote a couple of nice diaries. In our private handlers slack channel I was joking after the first one about whether he was going to rewrite CyberChef in PowerShell. After the second I asked what about SHA3? So, he wrote another one (your welcome for the diary ideas, Rob). I was only half joking.
SHA2 (SHA256 --or more accurately SHA2-256-- being the most common version in use) was first adopted in 2001. SHA3 was adopted in 2015. Fortunately, because we've known about the weaknesses in MD5 and SHA1 for years, those have been phased out for integrity purposes over the last decade. And, fortunately, I'm not aware of any weakneses in SHA2, yet, but it is only a matter of time. Having said that, I still see a lot of malware or forensic reports that will include MD5 or SHA1, fortunately usually these days also with SHA256, but I don't believe that even VirusTotal is calculating SHA3 hashes for new samples. I understand the arguments that using both MD5 and SHA1 is probably sufficient for the moment for malware sample identification purposes, but the new standard has been out there for 5 years now and the hash that is being used is almost 20 years old. What is the hold up? In my own personal malware database, I added a column for SHA3 back when NIST first announced that they were going to have a competition to choose the new hash. Python has included SHA3 in hashlib since 3.6 and it was backported to 2.7-3.5 in pysha3. The Perl Digest::SHA3 module has been around since the standard was adopted. I added it to my sigs.py tool more than 3 years ago, more specifically, I use SHA3-384 (as did Jesse Kornblum's beta of sha3deep, though I don't see a final release of that). So, what is the hold up? Why aren't we using the current standard? I, for one, plan to include both SHA2-256 and SHA3-384 hashes in all of my reports going forward. Thoughts?
References:
https://isc.sans.edu/forums/diary/Base+Conversions+and+Creating+GUI+Apps+in+PowerShell/26122/
https://isc.sans.edu/forums/diary/Hashes+in+PowerShell/26128/
https://isc.sans.edu/diary/SHA3+Hashes+%28on+Windows%29+-+Where+Art+Thou%3F/26130
https://isc.sans.edu/diary/SHA1+Phase+Out+Overview/20423
https://isc.sans.edu/diary/New+tool%3A+sigs.py/22181
SHA3 Hashes (on Windows) - Where Art Thou?
No sooner had posted on doing file and string hashes in PowerShell, when I (again) got asked by Jim - "What about SHA3? Shouldn't we be using Quantum Safe algorithms if we have them?"
Looking around, support for SHA3 is pretty sparse no matter what the OS. For Windows there's a decent solution in bouncycastle (https://www.bouncycastle.org/), but the install is likely more than folks want to tackle, especially if it gets rolled into PowerShell at some future date. Similarly, the SCCM ConfigurationManager module does implement them in some fashion, but that's kind of a dead-end for most of us too.
In a pinch, hashify.net has a public API that supports just about any hashing algorithm you'd care to mention:
curl --location --request GET "api.hashify.net/hash/sha3-512/hex?value=CQCQCQ"
{"Digest":"bcc7a070db5dd926bfbef21c6c5e8081402a79e45f96c4cd7fedc405e1a7fcb6b047cff266235f19f0d1219d2f0fd9299b93cd28d69517d7aefec8cf0c9ffdcc","DigestEnc":"hex","Type":"SHA3-512","Key":""}
The problem with that is - if the information you are hashing (presumably to verify against either now or later) is important or sensitive enough to warrant using one of the fancy SHA3 algorithms, it's likely not data that you want sent to a public website in the clear.
I eventually decided to use the functionality in OpenSSL, with the rationale that anyone who needs this function will likely have OpenSSL already installed locally, at most we'd be asking them to upgrade - you'll need OpenSSL 1.1.1 or better for SHA3-xxx hash support. The syntax is:
echo "some string" | openssl dgst -hashalgorithm
or
type "somefilespec" | openssl dgst -hashalgorithm
where "hashalgorithm" is any of:
blake2b512 blake2s256 md4
md5 md5-sha1 mdc2
ripemd ripemd160 rmd160
sha1 sha224 sha256
sha3-224 sha3-256 sha3-384
sha3-512 sha384 sha512
sha512-224 sha512-256 shake128
shake256 sm3 ssl3-md5
ssl3-sha1 whirlpool
So for implementing this in PowerShell, it's as easy as creating the command in a string, then calling it with "Invoke-Expression" (shortened to "iex" in the examples below).
So for now, until Microsoft rolls better support for SHA3 family of hashing algorithms, my quick-and-dirty implementation for the newer, shinier hash algorithms is below. Note that if OpenSSL isn't in the path, I've got a variable pointed to the path to the binary (update this variable to match your install). In any "real" code you would put this in a config file of course (because we all need more config files in our life right?)
$OpenSSLPath = "C:\openssl-1.1.1h\bin\"
function Get-StringHash-OpenSSL ( [String] $InputString, $HashAlgo )
{
$QT = "`""
$cmd = "echo " + $QT + $InputString + $QT + " | " + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo
$callcmd = iex $cmd
$callcmd.split(" ")[1]
}
$hash = get-stringhash-openssl "CQ CQ CQ" "SHA3-256"
$hash
5b960a5284843bb23af5e249c8692bd6d831645cc5070d501b4cef3e94d6983e
$OpenSSLPath = "C:\openssl-1.1.1h\bin\"
function Get-FileHash-OpenSSL ( [String] $InputFileSpec, $HashAlgo )
{
$QT = "`""
$cmd = "type " + $QT + $InputFileSpec + $QT + " | " + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo
$callcmd = iex $cmd
$callcmd.split(" ")[1]
}
$hash = get-FileHash-OpenSSL "c:\windows\system32\cmd.exe" "Sha3-512"
$hash
0cacd8c85b44eed57101fee1431434278319dc441aee26354f811b483a30ff7861ecc88f4c90791e941e49dcb124a975d9eb301
e5d715a4e80ee918ea2f5f844
If you've worked out a way to get these algorithms into PowerShell without IEX or any 3rd party installs, please share using our comment form.
(And yes, I did riff on the title of Mark Baggett's presentation next week - Tech Tuesday Workshop - O Hacker, Where Art Thou?: A Hands-On Python Workshop for Geolocating Attackers https://www.sans.org/webcasts/hacker-art-thou-hands-on-python-workshop-geolocating-attackers-115340 )
Modern crypto standards pave the way to stronger security
15.5.20 Net-security Crypto
Cyberthreats are a ubiquitous concern for organizations operating in the digital world. No company is immune — even large and high-profile organizations like Adobe, Yahoo, LinkedIn, Equifax and others have reported massive data breaches in recent years. Cyberattacks are only growing in frequency, affecting billions of people and threatening businesses.
What’s being done to bolster information security as cyberattacks continue to happen? The National Institute of Standards and Technology (NIST), a non-regulatory agency of the U.S. Department of Commerce, has been at the forefront of guiding cryptographic security programs and standards for more than 20 years. NIST morphed from its original name — the National Bureau of Standards that began at the turn of the 20th century — into its current iteration as the mobile revolution began to take off in the mid ‘90s.
To contend with cyberattacks in the early days, NIST released the Cryptographic Module Validation Program (CMVP) to certify cryptographic modules and the FIPS 140-1 protocol that independent labs use to test cryptographic modules. The program and protocol were right for the time, but times have changed and new validation, testing and certification programs and protocols are needed to keep pace with the proliferation and advancement of technology, as well as growing threats.
A new cryptographic validation protocol
On June 30, 2020, CMVP will be sunsetted and replaced with the Automated Cryptographic Validation Protocol (ACVP). ACVP has been operational since January 2019 and it will become the only protocol available come July 1, 2020.
The ACVP is what the industry needs to secure information in our highly digital world. As the volume of algorithm certification requests continue to soar, NIST’s limited resources couldn’t keep up. ACVP enables testing of cryptographic modules over the internet with a remote testing system. For these purposes, NIST has provided a server to produce test vectors, validate responses and issue certificates. This automation will bring speed and confidence to the cryptographic module validation process.
A timely FIPS update
In conjunction with the ACVP, the current FIPS 140-2 protocol will also be updated to reflect the growing types of technologies that need to be validated — software, hardware, firmware and hybrid systems.
The new FIPS 140-3 standard will be released in September 2020, laying out the security requirements for validating cryptographic modules during the design, implementation and operational deployment phases. FIPS 140-2 only provided security requirements that need to be met once a module is finalized.
FIPS 140-3 implementation schedule. Source: NIST.
The new FIPS 140-3 standard is needed to address issues that didn’t exist 20 years ago when the initial FIPS standard was developed. The updated standard takes into consideration software/firmware security, non-invasive security, sensitive security parameter management and life cycle assurance. In addition, FIPS 140-3 is aligned with the international ISO standard for cryptographic module testing.
Stronger information security with modern crypto standards
All organizations today harbor fears of a potential cyberattack. It’s unavoidable in our digital-centric world that attracts bad actors across the globe who attempt to profit from stolen data. As cyber threats and technology innovation continue to grow, organizations need systems and software that provide better assurance that cyberattacks will be kept at bay.
The shift to ACVP and FIPS 140-3 for testing, validating and certifying cryptographic algorithms and modules is the way forward. With these new cryptographic solutions, organizations will be better prepared to rise to the challenges of the 21st century world.
Microsoft Delays Disabling Insecure TLS in Browsers Until July
4.4.2020 Bleepingcomputer Crypto
Microsoft announced today that it will delay disabling support for the insecure Transport Layer Security (TLS) 1.0 and 1.1 protocols from Microsoft web browsers because of the current global situation until the second half of 2020, with an estimated time of roll out during July.
"For the new Microsoft Edge (based on Chromium), TLS 1.0 and 1.1 are currently planned to be disabled by default no sooner than Microsoft Edge version 84 (currently planned for July 2020)," Kyle Pflug, Microsoft Edge Developer Experience Principal PM Lead, said.
"For all supported versions of Internet Explorer 11 and Microsoft Edge Legacy (EdgeHTML-based), TLS 1.0 and TLS 1.1 will be disabled by default as of September 8, 2020."
Although users will still be able to toggle TLS 1.0 and TLS 1.1 back on even after they will be disabled, Microsoft recommends transitioning from insecure protocols as newer TLS versions come with more modern cryptography and are also broadly supported by modern browsers.
TLS 1.0 and TLS 1.1 will soon be disabled by default in all supported Microsoft browsers, starting with Microsoft Edge version 84.
Learn more on the Microsoft Edge blog: https://t.co/GDvAGofuGK
— Microsoft Edge Dev (@MSEdgeDev) March 31, 2020
TLS retiring plans
Earlier this month, Mozilla said that the support for insecure TLS will be re-enabled in the latest version of Firefox to maintain access to government sites with COVID19 information that haven't yet upgraded to newer TLS versions.
This happened after TLS 1.0 and TLS 1.1 support was dropped with the release of Firefox 74.0 on March 10 to improve the security of website connections.
The retirement of these insecure protocols from the list of supported protocols was announced by all major browser makers including Microsoft, Google, Apple, and Mozilla back in October 2018.
Microsoft said at the time that these outdated protocols will be disabled sometime during the first half of this year in the company's web browsers.
With over 97% of the sites surveyed by Qualys SSL Labs featuring TLS 1.2 or TLS 1.3 support, the vendors' decision to disable the two protocols in favor of newer and better-supported ones is logical as they can provide a more secure path going forward.
97% of surveyed sites support modern TLS (Qualys SSL Labs)
Per usage statistics shared by Microsoft, Google, Apple, and Mozilla when the retirement of TLS 1.0 and TLS 1.1 was announced, the vast majority of their users no longer use these protocols:
Microsoft said that only 0.72% of secure connections made by Edge use TLS 1.0 or 1.1.
Google reported that only 0.5% of HTTPS connections made by Chrome are using TLS 1.0 or TLS 1.1
Apple reported that on their platforms less than 0.36% of HTTPS connections made by Safari are using TLS 1.0 or TLS 1.1.
Firefox had the largest amount of connections, with 1.2% of all connections using TLS 1.0 or 1.1.
Netcraft also reported at the beginning of March that the insecure TLS 1.0 and TLS 1.1 protocols are still in use on more than 850,000 websites, exposing users to a large array of cryptographic attacks (1, 2) that could lead to their web traffic being decrypted by threat actors.
"The use of TLS 1.0 on e-commerce websites as a measure for protecting user data has been forbidden by the Payment Card Industry Data Security Standard since June 2018, and many websites have already migrated," as Netcraft explained.