company logo

Product

Our Product

We are Reshaping the way Developers find and fix vulnerabilities before they get exploited.

Solutions

By Industry

BFSI

Healthcare

Education

IT & Telecom

Government

By Role

CISO/CTO

DevOps Engineer

Resources

Resource Library

Get actionable insight straight from our threat Intel lab to keep you informed about the ever-changing Threat landscape.

Subscribe to Our Weekly Threat Digest

Company

Contact Us

Have queries, feedback or prospects? Get in touch and we shall be with you shortly.

loading..
loading..
loading..
Loading...

Authentication Bypass

MoveIt

loading..
loading..
loading..

Critical MOVEit Transfer Authentication Bypass Flaws EXPLOITED

Discover the latest critical vulnerabilities in MOVEit Transfer. Learn about CVE-2024-5806 and CVE-2024-5805, their impact, and essential mitigation steps.

28-Jun-2024
7 min read

Related Articles

loading..

OpenSSH

Linux

A severe OpenSSH vulnerability, regreSSHion, allows unauthenticated RCE, risking...

CVE-2024-6387, identified by the Qualys Threat Research Unit (TRU), marks a significant cybersecurity vulnerability in OpenSSH's server (sshd) on glibc-based Linux systems. This Remote Unauthenticated Code Execution (RCE) vulnerability, labeled "regreSSHion," poses a substantial threat due to its ability to execute arbitrary code as root, compromising system integrity and security. The critical nature of this flaw, a regression from a previously patched issue, demands immediate attention and comprehensive analysis. The issue is a regression of the previously identified CVE-2006-5051 and stems from the asynchronous signal-unsafe functions being called within the `sshd`'s `SIGALRM` handler. ### Overview of the Vulnerability The regreSSHion vulnerability, a signal handler race condition, impacts OpenSSH in its default configuration. This issue allows remote attackers to execute arbitrary code without authentication, potentially compromising millions of systems. Censys and Shodan searches have identified over 14 million potentially vulnerable OpenSSH server instances exposed to the internet. Furthermore, Qualys CSAM 3.0 data indicates that approximately 700,000 external internet-facing instances are vulnerable, representing 31% of the global customer base with OpenSSH. Notably, 0.14% of these instances are running End-Of-Life/End-Of-Support versions of OpenSSH. ### Historical Context and Regression Analysis OpenSSH versions earlier than 4.4p1 were vulnerable to this race condition, which was initially patched but not fully resolved by CVE-2008-4109. This [vulnerability](https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server) is a regression of CVE-2006-5051, initially reported in 2006. A regression in this context implies that a flaw, previously resolved, has reemerged due to subsequent changes in the software. This issue resurfaced in October 2020 with the release of OpenSSH 8.5p1, due to a modification in the logging infrastructure that inadvertently removed critical safeguards, reintroducing the race condition emphasizing the necessity of thorough regression testing to prevent such occurrences. The affected versions are: - **OpenSSH < 4.4p1:** Vulnerable if not patched against CVE-2006-5051 or CVE-2008-4109. - **OpenSSH 4.4p1 to 8.5p1:** Not vulnerable due to the presence of a safeguard. - **OpenSSH 8.5p1 to 9.8p1:** Vulnerable again due to the accidental removal of the safeguard. ### Technical Details and Exploitation The regreSSHion vulnerability is complex and challenging to exploit due to its remote race condition nature. The exploitation process involves interrupting a function call such as free() or malloc() within the sshd's public-key parsing code using SIGALRM, leading to a heap inconsistency. This inconsistent state is exploited in subsequent calls within the SIGALRM handler, enabling remote code execution. The advisory details the step-by-step methodology, including: - **Heap Manipulation:** Interrupting specific memory allocation calls to create a predictable memory state. - **Race Condition Exploitation:** Utilizing SIGALRM to precisely time the interruption and exploit the heap state. - **Remote Code Execution:** Achieving code execution by leveraging the inconsistent memory state to inject and execute malicious payloads. Successful exploitation requires precise timing to induce memory corruption, bypassing security mechanisms such as Address Space Layout Randomization (ASLR). The vulnerability is highly exploitable on glibc-based systems, particularly those without Address Space Layout Randomization (ASLR) and No eXecute (NX) protections, as these mitigations complicate the exploitation process. Despite the complexity, advancements in deep learning could potentially aid attackers in leveraging this vulnerability more effectively. ### Potential Impact Exploitation of this vulnerability could lead to full system compromise. Attackers can execute arbitrary code with root privileges, resulting in complete control over the affected system. This includes installing malware, manipulating data, and creating backdoors for persistent access. Moreover, attackers could bypass critical security mechanisms, leading to significant data breaches and leakage. ### Mitigation Strategies #### Patch Management Immediate patching is crucial. Organizations should apply the latest patches for OpenSSH and prioritize continuous updates. Regular patch management ensures that systems remain protected against known vulnerabilities. #### Enhanced Access Control Restricting SSH access through network-based controls can significantly reduce attack surfaces. Implementing strict access policies ensures that only authorized personnel can access critical systems. #### Network Segmentation and Intrusion Detection Dividing networks into segments restricts unauthorized access and limits lateral movement within critical environments. Deploying intrusion detection systems (IDS) helps monitor and alert on unusual activities indicative of exploitation attempts. ### Detailed Technical Analysis The following sections provide a [comprehensive technical breakdown](https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt) of the regreSSHion vulnerability, including code snippets and contextual examples to illustrate the issue's complexity. #### Signal Handler Race Condition The core of [CVE-2024-6387](https://github.com/xaitax/CVE-2024-6387_Check) lies in a signal handler race condition within sshd. A race condition occurs when the timing of processes influences the system's behavior, potentially leading to unexpected outcomes. ```c void signal_handler(int signo) { // Vulnerable code snippet char buffer[1024]; snprintf(buffer, sizeof(buffer), "Signal %d received", signo); // Race condition occurs here log_message(buffer); } ``` In the above code, the race condition arises from the use of `snprintf` within a signal handler. If the signal handler interrupts a critical section of the code, it can lead to memory corruption and arbitrary code execution. #### Memory Corruption and ASLR Bypass To exploit this vulnerability, attackers must induce memory corruption and bypass ASLR. This requires precise timing and repeated attempts, making the exploitation process challenging but not impossible. ```python import os import time def exploit_race_condition(): for _ in range(1000): os.kill(os.getpid(), signal.SIGUSR1) time.sleep(0.001) if __name__ == "__main__": exploit_race_condition() ``` The Python script above demonstrates a basic approach to exploiting the race condition. By repeatedly sending signals to the process, the attacker increases the chances of successful exploitation. ### Detection and Prevention Qualys provides tools and resources to help organizations detect and mitigate this vulnerability. The following QID (Qualys ID) helps identify affected systems: #### QID 42046: OpenSSH Remote Unauthenticated Code Execution Vulnerability (regreSSHion) ```qql vulnerabilities.vulnerability.cveIds:CVE-2024-6387 ``` ### Secure Blink's Solution #### Automated Detection & Remediation with ThreatSpy ThreatSpy automates both authenticated and unauthenticated scans, identifying a wide range of vulnerabilities, including those within the OWASP Top 10, CWE Top 25, and more. The platform’s heuristic approach prioritizes vulnerabilities based on a custom-built Reachability Framework, offering a Security Posture score derived from contextual analysis. **Key Features of ThreatSpy:** - Automated Scans: Performs extensive scans covering various vulnerabilities and generating detailed reports. - Remediation Playbook and Mitigation Campaign: Provides step-by-step guidance for efficient remediation and automates actions to mitigate identified vulnerabilities. - Security Posture Score: Offers a comprehensive score based on the potential impact and exploitability of vulnerabilities. - ROI Calculation: Evaluates the effectiveness of the platform by calculating the number of manual hours saved. **Addressing the regreSSHion Vulnerability** To mitigate the regreSSHion vulnerability, ThreatSpy can: - **Automated Vulnerability Detection and Remediation:** Quickly identify and apply necessary patches for OpenSSH, ensuring systems are up-to-date and secure. - **Comprehensive Vulnerability Scanning:** Perform both authenticated and unauthenticated scans to cover a wide range of potential vulnerabilities. - **Prioritization and Contextual Analysis:** Use heuristic analysis to prioritize vulnerabilities based on their potential impact and exploitability, providing a Security Posture score. ### Conclusion The [CVE-2024-6387](https://www.qualys.com/regresshion-cve-2024-6387/) regreSSHion vulnerability represents a significant security threat due to its potential for remote code execution as root. Secure Blink’s ThreatSpy offers a robust solution for identifying and mitigating such vulnerabilities through automated detection, prioritization, and remediation processes. By leveraging [ThreatSpy](https://www.secureblink.com/threatspy), organizations can enhance their security posture and effectively safeguard against this critical vulnerability. Try out our [14 day trial for free](https://threatspy.secureblink.com/signup)!

loading..   02-Jul-2024
loading..   7 min read
loading..

Supply Chain Attack

CDN

Polyfill.io relaunches on a new domain after being accused of delivering malicio...

Polyfill.io, a widely used JavaScript CDN service, has been at the center of a significant cybersecurity dispute. Following the discovery of malicious code being delivered to over 100,000 websites, the service has been relaunched on a new domain. This [Threatfeed](https://www.secureblink.com/cyber-security-news) analyzes the underlying nuances of this supply chain attack. #### Background & Initial Discovery Polyfill.io was designed to [help](https://github.com/polyfillpolyfill/polyfill-service) developers add modern JavaScript functionality to older browsers. However, in February 2024, a Chinese entity named 'Funnull' acquired the polyfill.io domain and inserted malicious code into the scripts delivered by its CDN. This malicious code primarily targeted mobile devices, redirecting users to undesirable sites. Researchers from Sansec [identified](https://sansec.io/research/polyfill-supply-chain-attack) the attack, noting that the compromised scripts affected more than 100,000 websites. The malicious code injected by polyfill.io's CDN was designed to hijack mobile devices visiting websites embedding the CDN's scripts. #### Analysis of the Malicious Code The inserted malicious code was sophisticated and strategically designed to evade detection. It redirected users to sports betting sites using a typosquatted domain name (google-anaiytics[.]com), an intentional misspelling of Google Analytics. This kind of attack highlights the potential risks of supply chain vulnerabilities, where third-party code can compromise entire networks. Here is an instance of how such malicious code might look: ![MaliCode1.jpg](https://sb-cms.s3.ap-south-1.amazonaws.com/Mali_Code1_44df6760eb.jpg) This script deceptively loads from a malicious domain, mimicking a legitimate service to avoid immediate suspicion. #### Response and Mitigation Measures Following the [exposure](https://twitter.com/Polyfill_Global/status/1805707089672815039), the polyfill.io domain was shut down by its registrar, Namecheap. The service owners swiftly relaunched it on a new domain, polyfill.com, and asserted there were "no supply chain risks." They claimed all services were cached in Cloudflare, ensuring static content delivery without third-party interference. Despite these assurances, security experts remain skeptical. Cloudflare, a prominent cloud security company, noted unauthorized use of its name and logo by polyfill.io, further eroding trust in the service. Cloudflare's CEO, Matthew Prince, highlighted the scale of the impact, revealing that tens of millions of websites had used polyfill.io, underscoring the seriousness of the breach. #### Technical Deep Dive: Supply Chain Risks Supply chain attacks like the one involving polyfill.io underscore the critical need for robust security practices. When third-party services are integrated into web applications, they become potential vectors for attacks. This incident demonstrates several key vulnerabilities: 1. **Third-Party Code Injection**: The compromised polyfill.io CDN served as an entry point for malicious code. Developers must thoroughly vet third-party services and ensure they are secure. 2. **Domain Trust and Verification**: The use of typosquatted domains (e.g., google-anaiytics[.]com) highlights the importance of domain verification. Implementing strict domain whitelisting can mitigate such risks. 3. **Content Caching and Delivery**: While caching content in services like Cloudflare can reduce risk, it is not foolproof. Continuous monitoring and verification of cached content are essential. #### Recommendations for Developers To safeguard against similar supply chain attacks, developers should consider the following practices: 1. **Self-Hosting Critical Libraries**: Instead of relying on third-party CDNs, host critical libraries on your servers. This ensures direct control over the content delivered to users. 2. **Implementing Subresource Integrity (SRI)**: SRI allows browsers to verify that resources fetched from a CDN have not been tampered with. This can prevent malicious modifications to scripts. ![MaliCode2.jpg](https://sb-cms.s3.ap-south-1.amazonaws.com/Mali_Code2_b60b6b11c2.jpg) 3. **Regular Security Audits**: Conducting periodic security audits of third-party services and dependencies can identify potential vulnerabilities before they are exploited. #### Role of Media and Public Perception Polyfill.io's response to the allegations, particularly their claims of being "maliciously defamed," underscores the challenges companies face in managing public perception during a security crisis. The service's owners have actively defended their integrity, emphasizing the use of Cloudflare caching to mitigate risks. However, trust once lost is difficult to regain, especially when authoritative entities like Cloudflare contradict the company's claims. #### Legal Implications The legal ramifications of such a breach are significant. Companies affected by the malicious code injected through polyfill.io's CDN could potentially seek legal recourse. Additionally, ethical considerations come into play, as the responsibility to protect user data and ensure secure services is paramount. The incident highlights the ethical duty of service providers to maintain the highest standards of security and transparency. #### Future Outlook and Industry Impact This incident is likely to influence future industry practices regarding the use of third-party CDNs. Developers and organizations might shift towards more secure, self-hosted solutions or rely on reputable, audited CDNs with stringent security measures. The focus on supply chain security will intensify, driving innovation in tools and practices designed to detect and prevent such attacks. #### Comparative Analysis Comparing the Polyfill.io incident with other notable supply chain attacks, such as the SolarWinds breach, provides valuable insights into common tactics and mitigation strategies. Both cases involved the compromise of trusted third-party services, highlighting the need for comprehensive security frameworks that encompass all aspects of the supply chain.

loading..   29-Jun-2024
loading..   5 min read
loading..

AWS

Coinstats

Cryptotheft

CoinStats breach exposes 1,590 crypto wallets via alleged social engineering att...

On June 22, 2024, CoinStats, a popular cryptocurrency portfolio management app, faced a significant security breach compromising 1,590 crypto wallets. This incident not only disrupted services temporarily but also raised serious questions about the security measures of cryptocurrency platforms. The following [Threatfeed](https://www.secureblink.com/cyber-security-news) analysis will meticulously dissect the critical nuances of this cryptocurrency breach of this year, its technical aspects, and the broader implications --- #### Incident Overview **CoinStats Breach** The breach initially surfaced on June 22, leading to the temporary suspension of CoinStats services. The [attack](https://x.com/CoinStats/status/1804633869372559788) was limited to 1.3% of all wallets, resulting in a loss of approximately $2 million. A detailed investigation revealed that the attack was orchestrated by compromising an employee's computer through social engineering, which led to the infiltration of their AWS infrastructure. CoinStats shared a list of [impacted wallets](https://docs.google.com/spreadsheets/d/1Lwxpy2T6W7aptjBJUio0Z01zihsqknXn6KPhzawQLVI/edit?gid=1914313472#gid=1914313472), but some [users reported](http://x.com/ArturJaro/status/1804803184872820899) thefts from wallets not on the list. Thus, the breach's scope might be larger than verified. **Technical Details of the Breach** The attack exploited social engineering tactics to install malicious software on an employee's computer. This allegedly allowed the attacker to obtain unauthorized access to the AWS environment where CoinStats' wallet data was stored. Despite prompt action to limit the breach, the attacker managed to access a significant number of wallets . ![4676c939-a8fa-4f1c-84b6-2e3888c0f346.png](https://sb-cms.s3.ap-south-1.amazonaws.com/4676c939_a8fa_4f1c_84b6_2e3888c0f346_cc4767d05a.png) ***CoinStats Post Attack' Status*** **Response and Mitigation** CoinStats' response involved immediate shutdown and isolation of affected systems. They published a list of compromised wallets and urged users to transfer their funds to secure external wallets. The company is conducting a thorough post-mortem analysis to refine its security measures and prevent future breaches . --- #### Social Engineering: A Critical Weakness **Understanding Social Engineering** Social engineering involves manipulating individuals into performing actions or divulging confidential information. This tactic exploits human psychology rather than technical vulnerabilities, making it a potent weapon for attackers . **Case Study: CoinStats Incident** In the CoinStats breach, the attacker used social engineering to trick an employee into downloading malware according to what was understood on June 26, [Narek Gevorgyan](https://x.com/narek_gevorgyan/status/1805873896836440411), CEO of CoinStats, via there findings of an [internal investigation](https://www.reddit.com/r/CoinStats/comments/1doubje/an_update_from_coinstats_ceo/): _“Our AWS infrastructure was hacked, with strong evidence suggesting it was done through one of our employees who was socially engineered into downloading malicious software onto his work computer.”_ This malware then facilitated unauthorized access to the company's AWS infrastructure. The specifics of the malware used remain unclear, but its impact underscores the effectiveness of social engineering in bypassing technical defenses . Gevorgyan’s message refrained from promising refunds for all victims, instead indicating that the company will outline a detailed action plan following a comprehensive post-mortem analysis. _"I empathize with those who lost money; I understand their hardship. CoinStats will support the victims of the hack, and we’ve been exploring various options internally."_ Some community members have reported even more substantial losses. For example, Blurr.eth’s wallet allegedly lost 3,657 Maker tokens, valued at approximately $8.7 million. --- #### Broader Implications for Cryptocurrency Platforms **Increasing Trend of Security Breaches** The CoinStats incident is not isolated. Other platforms, such as CoinGecko, have also faced security breaches recently. CoinGecko's breach on June 5 involved a compromised employee account on a third-party email management platform, leading to the exposure of user data . **Impact on User Trust and Platform Security** These incidents erode user trust and highlight the need for robust security practices. Users are now more cautious, emphasizing the need for platforms to adopt stringent security protocols, including multi-factor authentication and regular security audits . **Role of Employee Training and Awareness** Educating employees about social engineering tactics is crucial. Regular training sessions and simulated phishing attacks can help build a security-conscious workforce, reducing the risk of similar breaches in the future . --- #### Technical Analysis of the CoinStats Breach **AWS Infrastructure Vulnerabilities** The breach highlighted vulnerabilities in CoinStats' AWS setup. While AWS provides robust security features, improper configuration and inadequate monitoring can lead to significant risks. In this case, the compromised employee credentials allowed the attacker to navigate the AWS environment undetected initially . **Malware and Exploitation Tactics** The malware used in the CoinStats breach was likely designed to evade detection and exfiltrate data stealthily. Analyzing the malware's code and behavior can provide insights into its mechanisms and help develop countermeasures. For instance, using endpoint detection and response (EDR) tools could have potentially identified the unusual activity early . **Mitigation Strategies** Post-breach, CoinStats needs to implement several mitigation strategies: - **Enhanced Access Controls:** Implementing stricter access controls and limiting permissions can reduce the impact of compromised credentials. - **Regular Security Audits:** Conducting frequent audits of infrastructure and codebases helps identify and rectify vulnerabilities. - **Incident Response Plan:** Developing a comprehensive incident response plan ensures swift and coordinated action during future breaches . ---

loading..   28-Jun-2024
loading..   5 min read