CVE-2024-6387: RegreSSHion Vulnerability in OpenSSH

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

PuTTY Vulnerability Exposes Private Keys

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

Investigating Fidelity Investments Life Insurance Data Breach: A Closer Look

In recent weeks, Fidelity Investments Life Insurance has come under scrutiny following a significant data breach affecting thousands of customers. Here’s what you need to know about the incident:

1. Data Breach Details:

  • The breach, which occurred between October 29 and November 2, 2023, stemmed from an unauthorised party accessing sensitive consumer data held by Fidelity Investments Life Insurance.
  • Approximately 28,000 customers were impacted by the breach, with their personal information compromised.
  • The breached data includes names, social security numbers, dates of birth, states of residence, and financial information, particularly bank account and routing numbers used for premium payments on life insurance policies.
  • This data can contribute to an increase in phishing attacks, and uplift the risk of identity theft or financial fraud for the customers.

2. Third-Party Involvement:

  • The breach was traced back to Infosys McCamish Systems, a third-party service provider utilised by Fidelity Investments Life Insurance.
  • Infosys McCamish notified Fidelity Investments of the breach in early November, prompting an investigation into the incident.

3. Ongoing Investigation:

  • Infosys McCamish has engaged external experts to conduct a thorough investigation into the breach.
  • While the investigation is ongoing, Fidelity Investments Life Insurance officials believe that a range of sensitive customer data was compromised during the breach.

4. Customer Notifications:

  • Fidelity Investments Life Insurance has begun notifying affected customers about the breach and the potential exposure of their personal information.
  • The company emphasises its commitment to protecting customer data and pledges to take appropriate actions in collaboration with Infosys McCamish.

5. Prior Incidents:

  • This isn’t the first time Infosys McCamish has caused security breaches.
  • In a separate incident, Infosys McCamish notified Bank of America about a breach affecting over 57,000 customers enrolled in deferred compensation plans.

6. Response and Assurance:

  • Fidelity Investments Life Insurance reassures customers that they have not impacted their systems by the breach and that they have detected no related activity within Fidelity’s environment.

7. Legal Investigation:

  • The law firm of Federman & Sherwood has initiated an investigation into the data breach at Fidelity Investments Life Insurance, aiming to assess the impact on affected individuals.

8. Call for Action: Implementing Zero Trust Measures

  • To mitigate the risk of data breaches like this in the future, companies can adopt a zero trust approach.
  • By implementing strict access controls, continuous monitoring, and least privilege access policies, organizations can significantly reduce the likelihood of unauthorised access to sensitive data, hence lowering the risk of data and reputation loss because of a third party vendor breach.

As the investigation unfolds and affected customers are notified, Fidelity Investments Life Insurance remains focused on addressing the breach, safeguarding customer data, and ensuring transparency throughout the process.

Stay tuned for further updates as the situation develops.

#getzerotrust #gopasswordless

Okta Breach Part 2: Unveiling the Full Scope and Impact

Introduction

In late October, Okta, reported a cybersecurity breach that initially appeared to affect less than 1% of its customers. However, recent revelations indicate a far-reaching impact, affecting 99.6% of users in the customer support system. This blog post delves into the broader implications of this

The True Scope Revealed

Contrary to initial estimates downplaying, it has now been disclosed that hackers successfully ran a report on September 28, 2023. It contained sensitive information about all Okta customer support system users. The compromised data had names, email addresses, company names, contact phone numbers, and other details, Impacting 100% of Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers. The only exception being those in highly sensitive environments such as the government.

Financial Impact on Okta

Despite the significant dip in Okta’s stock prices when the breach was first reported in October, resulting in a temporary loss of approximately $2 billion in market capitalisation, the financial fallout seems to be hovering in the single digits. Okta’s latest quarterly financial report indicates a more than 20% increase in revenues for the quarter ending October 31, demonstrating a robust financial performance despite the security incident.

Customer Trust at Stake

The discrepancy between the initially reported 1% impact and the actual 99.6% of affected users reveals a concerning lapse in transparency. Okta customers are now grappling with the realization that threat actors may have access to their names and email addresses, exposing them to the risk of phishing and social engineering attacks. While Okta assures that there is no direct evidence of exploitation, they urge customers to remain vigilant. This stolen information could be weaponized for targeted cyber scams.

Phishing and Social Engineering Threat

With 99.6% of users having their names and email addresses exposed. These stolen data poses a heightened risk of phishing and social engineering attacks.

Okta Phishing

Cyber security experts emphasise the need for Okta customers, especially administrators, to enforce multi-factor authentication (MFA) and consider the use of phishing-resistant authentication. The potential for threat actors to exploit this information for targeted attacks underscores the importance of proactive security measures on the customer’s end.

Conclusion

In the aftermath of the Okta breach, customer trust in identity management systems faces a critical test. As emphasised by the mantra “The ‘S’ in IAM stands for Security”, the true scale of the incident challenges the reliance on auto-saved passwords, demonstrating the vulnerability of conventional systems. We urgently advocate for the adoption of passwordless authentication. For those catching up, our previous post details the Okta breach, highlighting the imperative to #gopasswordless . This approach not only addresses current vulnerabilities but also aligns with the evolving demands of a secure digital landscape.

SUNBURST: A Vital Case Study of Supply Chain Attack

About SolarWinds:

SolarWinds is an American company that provides IT management and administration software that can be used by the Sysadmins and IT administrators in their organization. The reach of the SolarWinds Products is quite high and their products are used by many fortune-500 companies, spreading across the globe.

What is Supply Chain Attack:

Supply Chain Attack is a type of attack in which adversaries can modify the product provided by third-party associates in various ways to compromise multiple targets. The below image provides a visualization of the definition of the supply chain attack.

SoloriGate/Sunburst: SolarWinds Supply Chain Attack 

SolarWinds supply chain attack first came into the radar of the information security communities when Fireeye was found affected by this supply chain attack. Fireeye was very open & transparent about getting breached in this supply chain attack. Fireeye has been tracking the threat actors behind this global intrusion campaign as UNC2452. There was not much damage done to the organization as only their Red Assessment Tools were leaked in the whole scenario. Fireeye Reported that the tools which were stolen by the attackers did not contain zero-day exploits. Many other big organizations like Microsoft, VMware as well as US Government agencies like the US Department of State, Department of Homeland Security, and many more were found breached by this supply chain attack.

Technical Analysis of the SoloriGate Attack:

SolarWinds was reportedly breached first and the reason was most likely the weak password they were using for one of their access/update servers. The threat actors involved in this global intrusion campaign targeted multiple victims using infected SolarWinds Orion IT management & monitoring software updates. Note that most of the analysis that has been demonstrated in this blog is based on Microsoft’s and Fireeye’s Blog.

Note that most of the analysis that has been demonstrated in this blog is based on Microsoft’s and Fireeye’s Blog.

The infectious update was delivered as a Microsoft standard Windows Installer Patch file (SolarWinds-Core-v2019.4.5220-Hotfix5) which included the malicious DLL (Dynamic Link Library) named as SolarWinds.Orion.Core.BusinessLayer.dll which acts like a backdoor on the Attack Surface. The infected SolarWinds Orion IT management & monitoring software update and DLL was digitally signed and due to which it was highly evasive on the attack surface.

Figure: Digital Signature Details of Patch File

Figure: Digital Signature Details of SolarWinds.Orion.Core.BusinessLayer.dll

In order to know the internal working of the Sunburst/SolariGate Malware let’s decompile the malicious SolarWinds.Orion.Core.BusinessLayer.dll. The Malware samples related to the Sunburst attack can be found here.

In order to analyze the dll, open the file named under the directory APT_Backdoor_SUNBURST “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” (Which is basically named after the SHA256 hash of the SolarWinds.Orion.Core.BusinessLayer.dll) in the dnSpy. The infected code was found under the namespace “SolarWinds.Orion.Core.BusinessLayer.BackgroundInventory” and more specifically in the “InventoryManager” class. 

Image: Decompilation of Malicious DLL.(Identifying the BackgroundInventory Namespace)

Image: Decompilation of Malicious DLL (Going through the InventoryManager Class under the Namespace)

Now this class has a “RefershInternal()” method that creates a new thread which calls the Malicious OrionImprovementBusinessLayer class where all the backdoor magic happens.

Image: Analyzing the RefreshInternal Method

The image below sums up the flow of the infected SolarWinds.Orion.BusinessLayer.dll.

Image: Malicious DLL process flow diagram

To be more evasive on the attack surface the malware code in the DLL runs various checks to make sure that it is not being analyzed using some programs. That is why, hash of the processes, services and drivers on windows is calculated and checked with the blacklisted hashes of the same, and if none of the blacklisted hashes are found on the system then only backdoor code gets activated.

Adversaries in this case used DGA (Domain Generation Algorithms) to dynamically build and resolve the subdomain of avsvmcloud.com. The C2 domain consist of two static and two variable parts which is illustrated in the image below.

Image Source: Microsoft

After the malware has made a successful connection to the C2 server the SoloriGate malware performs the primitive lateral movement, credential abuse, and privilege escalation techniques for further infrastructure exploration. 

The image below from Microsoft illustrates the whole process of SoloriGate Malware infection.

Image Source: Microsoft

According to Microsoft the threat actors are targeting to steal the SAML token signing certificates, using which attackers can easily forge the SAML tokens and access the resources. 

Here is the elaborated descriptive blog post about the SolariGate identity IOC’s.

Defense against SUNBURST/SoloriGate:

  • Fireeye Team uploaded a List of IOC’s and signatures which can be used by organizations for identifying the backdoor.  The GitHub repository of Fireeye countermeasures can be found here.
  • It is also recommended by SolarWinds to go through this advisory page and also upgrade their Orion platform to Orion Platform release 2020.2.1 HF 1.
  • MITRE ATT&CK Techniques related to SolariGate/SUNBURST:
IDDescription
T1012Query Registry
T1027Obfuscated Files or Information
T1057Process Discovery
T1070.004File Deletion
T1071.001Web Protocols
T1071.004Application Layer Protocol: DNS
T1083File and Directory Discovery
T1105Ingress Tool Transfer
T1132.001Standard Encoding
T1195.002Compromise Software Supply Chain
T1518Software Discovery
T1518.001Security Software Discovery
T1543.003Windows Service
T1553.002Code Signing
T1568.002Domain Generation Algorithms
T1569.002Service Execution
T1584Compromise Infrastructure
Table: MITRE ATT&CK Techniques

Conclusion:

This SolarWinds Supply Chain Attack is surely raising the eyebrows of people in the IT industry and also outside the IT industry. Right from STUXNET to NotPetya we have seen many supply chain attacks that were found devastating. In 2017-18 NotPetya was found to have cost  10 Billion Dollars in damages. The evasive Behaviour of the attack made it so hard to be identified in the wild.  Currently, SolarWinds Orion Platform is used by 300,000 customers and out of which 18,000 have downloaded the malicious update.

I hope this blog provided you with a better view of the SoloriGate and SUNBURST attack.

References:

https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/understanding-quot-solorigate-quot-s-identity-iocs-for-identity/bc-p/2009890#M3044

https://labs.sentinelone.com/solarwinds-sunburst-backdoor-inside-the-stealthy-apt-campaign/