Category: SSH Security

CVE-2024-6387: RegreSSHion Vulnerability in OpenSSH

Posted on by Srishti Chaubey

Introduction

On July 1, 2024, the cybersecurity community was alerted to a significant vulnerability within OpenSSH, dubbed “regreSSHion” (CVE-2024-6387). This critical flaw, discovered by the Qualys Threat Research Unit (TRU), allows unauthenticated remote code execution (RCE) with root privileges on glibc-based Linux systems. The vulnerability, which affects the default configuration of OpenSSH’s server (sshd), poses a severe security risk due to its potential for complete system compromise without user interaction.

What is regreSSHion?

regreSSHion
Credit: Qualys

RegreSSHion, tracked as CVE-2024-6387, is an unauthenticated RCE vulnerability in OpenSSH’s server (sshd). This flaw grants attackers full root access, making it a high-severity threat with a CVSS score of 8.1. The vulnerability affects versions 8.5p1 to 9.8p1 of OpenSSH, as well as versions earlier than 4.4p1 if not patched for previous vulnerabilities (CVE-2006-5051 and CVE-2008-4109). The issue arises from a signal handler race condition that can be exploited by failing to authenticate within a set time period (LoginGraceTime).

Background and Discovery

The Qualys TRU discovered that this vulnerability is a regression of a previously patched flaw, CVE-2006-5051, reported 18 years ago. A regression in this context means that a previously fixed issue has reappeared in a subsequent software release. This often occurs due to changes that inadvertently reintroduce the problem. The regression was introduced in October 2020 with OpenSSH version 8.5p1, highlighting the importance of thorough regression testing to prevent the reintroduction of known vulnerabilities.

Technical Details

The vulnerability involves a specific sequence of function calls and interactions between the signal handler and the main program logic. Here’s a breakdown of the critical components:

Function Call Chain:

  • __localtime64_r calls __tz_convert.
  • __tz_convert calls tzset_internal.
  • tzset_internal calls __tzfile_read.

Heap Allocation Issues:

  • __tzfile_read involves a call to fopen to read timezone files.
  • fopen allocates a FILE structure on the heap.

Exploit Strategy:

  • The attacker exploits the race condition by manipulating heap memory.
  • By carefully timing the SIGALRM signal, they can interrupt the malloc operation, leaving the heap in an inconsistent state.
  • This allows the attacker to control the FILE structure, leading to arbitrary code execution.

Impact and Exploitation Process

The regreSSHion vulnerability impacts glibc-based Linux systems running vulnerable versions of OpenSSH. Exploitation of this flaw can result in complete system takeover, allowing attackers to execute arbitrary code with root privileges. The attacker leverages the predictable heap layout and timing to achieve arbitrary code execution:

Heap Layout Manipulation:

  • The attacker creates a specific heap layout with controlled memory holes.
  • They send a series of crafted public-key packets to OpenSSH, forcing specific malloc and free operations.

Signal Timing:

  • The attacker sends a SIGALRM signal at a precise moment during the malloc operation.
  • This interrupts the malloc, leaving the heap in a vulnerable state.

Arbitrary Code Execution:

  • By overwriting parts of the FILE structure, the attacker redirects execution to their controlled function pointers.
  • This allows them to execute arbitrary code with the privileges of the OpenSSH process.

While successful exploitation has been demonstrated under lab conditions, it typically requires 6-8 hours of continuous connections. This makes mass exploitation challenging but not impossible.

Affected Versions

The vulnerability affects the following OpenSSH versions:

  • OpenSSH versions earlier than 4.4p1, if not patched for CVE-2006-5051 or CVE-2008-4109
  • OpenSSH versions from 8.5p1 up to, but not including, 9.8p1
Credit – PaloAlto

OpenBSD systems are not vulnerable due to their use of an async-signal-safe version of syslog(), which mitigates the race condition.

Mitigation and Recommendations

To protect against the regreSSHion vulnerability, it is recommended to:

  1. Update OpenSSH: Upgrade to the latest version, which is 9.8p1 or later.
  2. Network Controls: Limit SSH access through network-based controls to restrict unauthorised access.
  3. Micro Segmentation : Products like XShield by ColorTokens help in segmenting critical servers and containing access to them based on policies & detection of anomalies.

Workarounds

If you cannot apply the patch immediately, consider the following workarounds:

  1. Configuration Change:
    • Set LoginGraceTime to 0 in the OpenSSH configuration file. This eliminates the vulnerable window but may lead to denial of service by exhausting all available connections.
  2. Code Modification:
    • Temporarily comment out or remove the async-signal-unsafe code from the sshsigdie function in OpenSSH source code and recompile.

Current Status and Observations

As of July 2, 2024, there is no known activity in the wild exploiting this vulnerability. While proof-of-concept (PoC) code exists, it has not been successfully used to achieve remote code execution in testing environments. However, the potential for targeted attacks remains, and organizations are urged to apply patches and implement mitigation promptly.

Conclusion

The regreSSHion vulnerability in OpenSSH (CVE-2024-6387) underscores the critical need for rigorous regression testing and prompt security updates. By understanding the nature of this threat and taking proactive measures, organizations can mitigate the risks associated with this severe vulnerability and protect their systems from potential exploitation.

Stay informed and vigilant, and ensure your systems are updated to safeguard against this and other emerging cybersecurity threats.

Read More

Qualys Technical Paper

New York Times Source Code Leak

Posted on by Srishti Chaubey

Introduction

The New York Times recently experienced a significant security breach, leading to the leak of their source code. This breach was initiated through an exposed GitHub token, allowing unauthorised access to their repositories

How It Happened

An anonymous hacker posted the New York Times’ source code on 4chan. The breach occurred due to an exposed GitHub token, which provided access to over 5,000 repositories, totalling 270 GB of data. The stolen data included sensitive and proprietary information.

Response from The New York Times

The New York Times confirmed the breach and revealed that a credential was inadvertently exposed in January 2024. They quickly addressed the issue, emphasising that their systems remained non-compromised and their operations unaffected. However, this incident highlights the critical need for stringent security measures.

Implications of the Leak

The breach exposed vast amounts of data, including source code for various projects. This poses significant risks for the New York Times, including potential security vulnerabilities and intellectual property theft. The leaked data also included uncompressed tar files, with the hacker urging users to seed due to potentially insufficient seed-boxes. Reactions ranged from disbelief at the volume of repositories to jokes about the newspaper’s digital complexity.

Connection to Disney Leak

Just days before, another breach occurred involving Disney’s internal servers. A hacker associated with the defunct game Club Penguin leaked 2.5 GB of sensitive data, including corporate strategies and internal emails. This shows a disturbing trend of high-profile data breaches. The Disney breach exploited Confluence servers via exposed credentials, further emphasising the need for robust security practices.

Conclusion

This incident underscores the critical importance of securing access tokens and implementing robust security measures to prevent unauthorised access to sensitive information. As cyber threats evolve, organizations must remain vigilant and proactive in safeguarding their digital assets. Securing the CI/CD Pipeline should be a priority for every organization and PureID’s CASPR can be a game-changer.

Okta Warns Customers of Credential Stuffing Attacks

Posted on by Srishti Chaubey

In a recent advisory, Okta, a leading identity and access management services provider, sounded the alarm over a rise in credential stuffing attacks targeting online services. Let’s delve into the details of this warning and understand the implications.

Overview of the Threat

Okta reported a significant increase in the frequency and scale of credential stuffing attacks against online services in recent weeks. These attacks have been fuelled by the widespread availability of residential proxy services, lists of previously stolen credentials, and automation tools. The surge in attacks poses a severe threat to the security of user accounts and sensitive data.

Observations by Security Experts

Duo Security and Cisco Talos also observed large-scale brute-force attacks against various targets, including VPN services, web application authentication interfaces, and SSH services. The attacks, originating from TOR exit nodes and other anonymizing tunnels and proxies, targeted VPN appliances and routers from multiple vendors.

Modus Operandi of Credential Stuffing Attacks

Credential stuffing attacks involve the automated trial of username and password combinations obtained from previous data breaches or phishing campaigns. Threat actors exploit the reuse of login credentials across multiple accounts, attempting to gain unauthorised access to compromised accounts.

Recommendations for Organisations

  • Enable ThreatInsight in Log and Enforce Mode for proactive IP address blocking.
  • Deny access from anonymizing proxies to prevent attacks from dubious sources.
  • Switch to Okta Identity Engine for enhanced security features.
  • Utilize CAPTCHA challenges and passwordless authentication with Okta FastPass.
  • Implement Dynamic Zones to manage access based on geo-location and other criteria.
Okta's Warning on Credential Stuffing Attacks
Blocking anonymized requests from Admin Console > Settings > Features
Okta

Implementing these recommendations can fortify an organisation’s defence against credential stuffing attacks, ensuring a safer online environment for users and stakeholders.

Conclusion

Credential stuffing attacks pose a significant threat to the security of online services and user accounts. By heeding Okta’s warning and implementing robust security measures, Okta customers can better protect themselves against these malicious activities and safeguard their sensitive data.

Another approach to create a safer cyber world is to not use the typical password based authentication. By eliminating passwords, organizations can improve their defences, increase security and reduce the risk of future incidents. Typical cyber attacks such as Credential Stuffing are not applicable to Passwordless authentication, so the best way to move forward is to #gopasswordless

Read Also

Unpacking Okta’s Recent Security Breach

Okta Breach Part 2: Unveiling the Full Scope and Impact

PuTTY Vulnerability Exposes Private Keys

Posted on by Srishti Chaubey

Introduction: Understanding the PuTTY Vulnerability

PuTTY, a widely-used SSH and Telnet client, contains a critical vulnerability, tracked as CVE-2024-31497, affecting versions 0.68 through 0.80. This flaw allows threat actors to potentially recover private keys used for cryptographic signatures, posing significant security risks. 

Exploring the Vulnerability: How Attackers Exploit PuTTY

The vulnerability arises from the biased generation of ECDSA nonces for the NIST P-521 curve, used in SSH authentication. Attackers can leverage this flaw to recover private keys by collecting cryptographic signatures, enabling unauthorised access to SSH servers or the ability to sign commits masquerading as legitimate users.

PuTTY Vulnerability Exposes Private Keys

Expert’s Insights

“PuTTY’s technique worked by making a SHA-512 hash and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY’s technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later), it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.”

“In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.”

-PuTTY security advisory.

Impact and Implications: Risks Posed by the Flaw

The exploitation of this vulnerability can lead to severe consequences, including unauthorised access to sensitive systems, data breaches, and potential supply chain attacks. Affected software includes FileZilla, WinSCP, TortoiseGit, and TortoiseSVN, urging users to take immediate action.

The following software that uses the vulnerable PuTTY is confirmed as impacted:

  • FileZilla 3.24.1 – 3.66.5 (fixed in 3.67.0)
  • WinSCP 5.9.5 – 6.3.2 (fixed in 6.3.3)
  • TortoiseGit 2.4.0.2 – 2.15.0 (fixed in 2.15.0.1)
  • TortoiseSVN 1.10.0 – 1.14.6 (mitigation possible by configuring TortoiseSVN to use Plink from the latest PuTTY 0.81 release)

Mitigation and Resolution: Steps to Address the Vulnerability

In light of the vulnurability, users are advised do the following:

  1. Improved Randomness: Enhance the randomness of nonce generation by integrating a more robust cryptographic random number generator (RNG). This ensures nonces with sufficient entropy to prevent bias and enhances overall security.
  2. Different Hashing Algorithm: Consider utilising a different hashing algorithm or a combination of algorithms suitable for the NIST P-521 curve. Selecting a hash function compatible with curve parameters can mitigate bias introduced by modulo “q” reduction.
  3. Nonce Generation Scheme: Implement a nonce generation scheme independent of reducing the hash value modulo “q.” Develop a method to directly produce nonces within the defined range of “q” to preserve randomness and prevent bias.
  4. Comprehensive Review: Conduct a thorough review of the nonce generation process and cryptographic operations in PuTTY. Collaborate with security experts to identify and address any additional vulnerabilities or weaknesses, ensuring the fix is robust and effective.
  5. Update and Patch: Once a fix is developed, PuTTY would release a patch. Encourage users to upgrade to the latest version promptly to mitigate the vulnerability and enhance the security of their SSH connections.

Conclusion: Ensuring Security in SSH Environments

The PuTTY vulnerability underscores the importance of robust security measures in SSH environments. By staying informed and implementing necessary updates and precautions, organizations can bolster their defence against potential threats.

Read Also

Unveiling Terrapin: A New Threat to SSH Security

Unveiling Terrapin: A New Threat to SSH Security

Posted on by Srishti Chaubey

SSH (Secure Shell) has long been hailed as a reliable protocol for secure network access, widely used for remote terminal logins and file transfers. However, the fortress of secure online connections now faces a dilemma – the Terrapin attack. In this blog, we delve into the intricacies of Terrapin, its potential impact on existing password-based authentication systems, and how organizations can safeguard against this insidious attack. Ready to plunge into the chaos? Buckle up, and let’s explore!

Understanding Terrapin

Terrapin is not your average security vulnerability; it’s a prefix truncation attack specifically designed to exploit weaknesses in the SSH protocol. By manipulating sequence numbers during the handshake process, an attacker can selectively remove messages from the beginning of the secure channel without detection. Imagine a hacker manipulating the building blocks of your messages, pulling them out one by one without you even batting an eye!

Working of Terrapin the SSH Vulnurability
Image Source: https://terrapin-attack.com/

The Attack in Action

The Terrapin attack is not just theoretical; it has real-world implications. Attackers can downgrade connection security by truncating essential messages, such as the extension negotiation message (RFC8308). This truncation can lead to the use of less secure client authentication algorithms and the deactivation of specific countermeasures in OpenSSH 9.5.

The vulnerability has been assigned following CVEs

  • CVE-2023-48795 (CVSSv3 : 5.9 MEDIUM) – General Protocol Flaw
  • CVE-2023-46445 (CVSSv3 : 5.9 MEDIUM) – Rogue Extension Negotiation Attack in AsyncSSH
  • CVE-2023-46446 (CVSSv3 : 6.8 MEDIUM) – Rogue Session Attack in AsyncSSH

Downsides for Password-Based Authentication

Password-based authentication systems are particularly vulnerable to the Terrapin attack. The attack allows an adversary to compromise the integrity of the secure channel, potentially leading to unauthorized access and exploitation of implementation flaws. Picture this: attackers downgrade your connection security by snipping crucial messages. Your passwords might be waltzing into the wrong hands. This could result in attackers signing victims into other accounts without detection, paving the way for sophisticated phishing attacks. Just beware that Terrapin’s not a party crasher; it’s the DJ changing the beats!

Mitigating the Threat

To perform the Terrapin attack, a Man-in-the-Middle attacker is required, along with a cozy spot in local networks, making it challenging on the open internet. However, within local networks, where MITM attacks are plausible, the threat becomes more significant. Furthermore, the attack focuses on SSH connections that use widely adopted encryption modes like ChaCha20-Poly1305 or CBC with Encrypt-then-MAC.

Vulnerability Scanner

To assist organizations in determining vulnerability, a simple console application is developed in Go. This tool helps identify if an SSH server or client is susceptible to the Terrapin attack based on the offered encryption modes and support for strict key exchange countermeasures.

Conclusion: A Safer Alternative at PureID

With Certificate-based authentication, the risk of MITM is mitigated as certificates are bound with IP addresses. Any man-in-the middle will not be able to replay the client certificate, manipulate the handshake & successfully establish TLS connection.

PureID’s ZITA (Just in Time Access) fully eliminates the risk of Terrapin along with any MITM attack. This approach, unlike outdated password-based systems, stands resilient against Terrapin. As the threat landscape evolves, prioritizing advanced authentication mechanisms becomes paramount for ensuring a secure network environment. Forget passwords; they’re so yesterday! Join the secure squad – it’s the future!

© 2024 | PureID. All Rights Reserved

Privacy & Terms | Licenses