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...

TIM

Ericsson OSS-RC

RCE

loading..
loading..
loading..

Ericsson OSS-RC reported with two undocumented CVES detected by Red TIM Research

Bug research team of TIM Red Team Research issued two undocumented flaws CVE-2021-32569 and CVE-2021-32571 affecting Ericsson Systems 18B and older...

26-Oct-2021
2 min read

No content available.

Related Articles

loading..

RCE

Firewall

GFI KerioControl vulnerability (CVE-2024-52875) allows 1-click RCE via unauthent...

A critical vulnerability was disclosed in GFI KerioControl, a popular firewall solution used by businesses worldwide. The vulnerability, identified as CVE-2024-52875, affects GFI KerioControl versions 9.2.5 through 9.4.5. This flaw presents a serious security risk, potentially enabling remote code execution (RCE) through a single click by an attacker. The issue has since been actively exploited in the wild, as confirmed by reports of malicious activity associated with the CVE. ### **Overview of CVE-2024-52875** CVE-2024-52875 arises from a failure in properly sanitizing user input in certain URI paths of the KerioControl web interface. These URI paths include: - **/nonauth/addCertException.cs** - **/nonauth/guestConfirm.cs** - **/nonauth/expiration.cs** These endpoints, which are unauthenticated, improperly handle user input passed through the “dest” GET parameter, specifically failing to sanitize linefeed (LF) characters. This vulnerability can be exploited via an **HTTP Response Splitting** attack. This flaw could lead to **reflected cross-site scripting (XSS)**, which in turn could allow attackers to execute a one-click RCE attack. ### **Attack Vector** The vulnerability occurs when input is passed from the user to the web server, specifically in the "dest" parameter. Due to the improper sanitization, attackers can inject malicious linefeed characters into the response headers. This allows the attacker to split the HTTP response and inject arbitrary content, including malicious JavaScript code. A crafted URL, if clicked by an authenticated administrator, can trigger the malicious behavior. The attack works by exploiting KerioControl's firmware upgrade functionality, which allows the attacker to upload a malicious `.img` file. This file, once uploaded, provides the attacker with **root access** to the affected firewall system. Notably, this attack can be carried out using social engineering tactics. By tricking an administrator into clicking a link, an attacker can gain full control of the firewall system without needing to bypass authentication. ### **CVE-2024-52875 Exploitation and Impact** The flaw is especially concerning because it involves unauthenticated endpoints, meaning it can be exploited externally by threat actors. This makes the vulnerability easily accessible to malicious entities, who can leverage this attack vector to compromise the firewall system remotely. Proof-of-concept (PoC) code has already been released by Karma(In)Security, demonstrating the exploitability of the vulnerability. The code shows how an attacker can use the XSS vector to deliver a malicious firmware update, effectively gaining control over the vulnerable system. As of January 5, 2025, there are reports indicating that **CVE-2024-52875** is actively being exploited in the wild, with several malicious IPs linked to the vulnerability observed in the GreyNoise threat intelligence platform. ### **Security Patch and Mitigation** The vulnerability has been addressed by GFI Software in **KerioControl version 9.4.5 Patch 1**, which contains fixes for the issue. Users of vulnerable versions are strongly encouraged to update to this patched version or later to mitigate the risk posed by CVE-2024-52875. ### **Censys Findings: Exposed Devices** At the time of writing, Censys observed over **23,000 exposed instances** of GFI KerioControl, with approximately 17% of these located in Iran. This highlights a significant potential attack surface, as a large number of devices may still be running vulnerable versions of the software. However, it is important to note that not all of these instances are necessarily vulnerable, as specific versions have not been disclosed in Censys' scan results. Censys provided a specific search query that can be used to identify exposed GFI KerioControl instances: ``` services.software: (vendor="GFI" and product="Kerio Control") and not labels: {honeypot, tarpit} ``` This query can help security teams identify exposed instances of GFI KerioControl that may need immediate attention. ### **Best Practices** The discovery of CVE-2024-52875 underscores the importance of timely patching and proper input sanitization in web-facing applications. The ability for attackers to remotely gain root access to firewall systems via social engineering and a single click emphasizes the need for stringent security measures, especially in high-risk environments like firewalls. Organizations using GFI KerioControl should prioritize updating to the latest patched version (9.4.5 Patch 1) to prevent exploitation of this vulnerability. Additionally, security best practices, such as educating administrators on the risks of phishing and social engineering, are crucial in minimizing the risk of exploitation. As always, proactive monitoring for unusual network activity and maintaining a robust security posture are essential to mitigating the risk posed by emerging vulnerabilities like CVE-2024-52875. **References:** - Censys Search Query: services.software: (vendor="GFI" and product="Kerio Control") and not labels: {honeypot, tarpit} - GreyNoise threat intelligence platform: Insights into active exploitation attempts

loading..   11-Feb-2025
loading..   4 min read
loading..

APT29

Cozy Bear

HPE confirms Russian hackers stole sensitive employee data in May 2023 breach, i...

**Hewlett Packard Enterprise (HPE)** has confirmed that **Russian state-sponsored hackers** have stolen sensitive employee data in a devastating cyberattack. The breach, which targeted the company’s **Office 365** email environment, transpired in **May 2023** and only recently came to light in official filings and breach notification letters sent to affected individuals. ### **HPE Employees Targeted by Cozy Bear Hackers** The hacking group responsible, **[Cozy Bear](https://www.secureblink.com/cyber-security-news/how-russian-hackers-leveraged-spyware-exploits-from-nso-group-and-intellexa-in-watering-hole-attacks)** (also known as **APT29**, **Midnight Blizzard**, and **Nobelium**), is believed to be linked to Russia’s **Foreign Intelligence Service (SVR)**. This notorious group has previously been involved in **high-profile breaches**, including the infamous **[SolarWinds](https://www.secureblink.com/cyber-security-news/a-second-threat-actor-found-to-attack-solarwinds-system) supply chain attack** in 2020. The breach is a part of a broader campaign by Cozy Bear, which targeted not just **HPE's email environment**, but also its **SharePoint server** in the same timeframe, further compromising confidential data across multiple systems. ### **Sensitive Data Stolen from Employee Mailboxes** According to breach notification letters sent to affected employees, personal data such as **driver’s licenses**, **credit card numbers**, and **Social Security numbers** were stolen. At least **16 employees** were notified of the breach, though the full extent of the breach remains unclear. HPE spokespersons confirmed that it was "a limited group of HPE team member mailboxes that were accessed," and stressed that only the data contained in these mailboxes was impacted. ### **Timeline of Events: The HPE Breach** The breach was first disclosed publicly in an **SEC filing** dated **January 29, 2024**, where **Hewlett Packard Enterprise** revealed that it was notified on **December 12, 2023**, that the **Cozy Bear hackers** had compromised its cloud-based **Office 365 email environment** in May 2023. The hackers exploited a **compromised account**, gaining access to email inboxes of select employees in **cybersecurity**, **go-to-market**, and other critical business sectors. HPE’s official statement confirmed that the hackers began exfiltrating data in **May 2023** and continued until the discovery of the breach. The company stated that the accessed data was **limited to information contained in the mailboxes** of the affected employees. ### **Connection to Other Major Hacks** In the **SEC filing**, HPE indicated that this breach may have been linked to a second breach in **May 2023**, where hackers also targeted the company’s **SharePoint server** and stole files. This came on the heels of Microsoft’s **January 2024** announcement that Cozy Bear hackers had infiltrated their network, accessing both **corporate email accounts** and **source code repositories**. ### **HPE’s History of Security Breaches** This isn’t the first time that **Hewlett Packard Enterprise** has been targeted by cybercriminals. In **2018**, Chinese state-sponsored hackers breached HPE’s network, leading to compromises of its **customer devices**. HPE also reported a significant breach in **2021** when data repositories for its **Aruba Central network** monitoring platform were hacked, exposing sensitive information about monitored devices and their locations. Additionally, in **February 2024** and **January 2025**, HPE launched investigations into potential **new security breaches** after an actor using the **IntelBroker** handle claimed responsibility for stealing **HPE credentials**, **source code**, and other proprietary information. ### **Breach Notification and Employee Impact** Hewlett Packard Enterprise began notifying employees whose personal data had been stolen starting in **January 2025**, following legal requirements to inform affected individuals. The breach notification letters state that the stolen data was "subject to unauthorized access," which HPE is continuing to investigate. In a statement, HPE assured that it was taking steps to strengthen its cybersecurity measures to prevent further attacks. They also emphasized that this breach is being addressed with full compliance to applicable law. ### **What This Means for HPE’s Security Measures** HPE has long been an attractive target for hackers due to its role in providing enterprise-grade IT solutions across sectors. This breach has raised questions about the strength of the company’s internal security measures and its ability to safeguard employee data. The breach also underscores the growing risk of cyberattacks targeting **state-sponsored groups** who possess advanced tools and techniques to infiltrate even the most secure environments. In response, HPE is actively working on bolstering its security framework, with a focus on **enhanced encryption**, better **endpoint protection**, and tighter control over **third-party access** to corporate resources. ### **Conclusion: Cybersecurity Challenges for Enterprises** The HPE breach serves as a stark reminder of the increasing sophistication of cyberattacks targeting major corporations. With **nation-state actors** involved, the risks are far more severe than conventional attacks. The breach highlights the need for all enterprises to continuously update their cybersecurity strategies and adopt **advanced threat detection systems**. **What can we learn from this breach?** The **importance of multi-layered security**, **immediate incident response**, and **employee data protection** cannot be overstated. In the face of evolving threats, companies like HPE must remain vigilant, and more importantly, transparent, in their efforts to protect sensitive data. ### **Key Takeaways:** - **Cozy Bear** (APT29), a **Russian state-sponsored hacker group**, breached **Hewlett Packard Enterprise** in **May 2023**, stealing **personal data** from employee mailboxes. - **16 employees** were notified that **driver’s licenses**, **credit card numbers**, and **Social Security numbers** were among the stolen data. - The breach is connected to a broader campaign, including a **SharePoint server hack** and a larger **cyberattack** on Microsoft. - HPE’s cybersecurity vulnerabilities are under scrutiny, with additional investigations ongoing. - The breach emphasizes the growing threat of **nation-state cyberattacks** and the critical need for companies to enhance their security protocols. This attack should be a wake-up call for all organizations: **cybersecurity is no longer optional**, it’s a necessity. --- **#HPEBreach #CozyBear #APT29 #CyberSecurity #DataBreach #RussianHackers #HewlettPackard #TechSecurity #Office365Breach #DataProtection #SecurityAwareness**

loading..   08-Feb-2025
loading..   5 min read
loading..

Outage

Cloud

Cloudflare R2 crash causes a 59-minute outage, affecting services and leading to...

Cloudflare faced a significant service disruption affecting multiple platforms, including its R2 Object Storage service. The outage lasted for 59 minutes and caused a complete failure of operations against R2, along with widespread disruption to several Cloudflare services that depend on R2, including Stream, Images, Cache Reserve, Vectorize, and Log Delivery. This Threatfeed delves deep into the technical details surrounding the incident, its impact on users, and Cloudflare's efforts to mitigate similar events in the future. ### Incident Overview **Date of Incident:** February 6, 2025 **Duration:** 59 minutes **Primary Cause:** Human error during abuse remediation **Root Cause:** Insufficient validation safeguards during routine phishing site remediation **Impacted Services:** R2, Stream, Images, Cache Reserve, Vectorize, Log Delivery, Durable Objects, Cache Purge, Key Transparency Auditor, Workers & Pages At approximately 08:12 UTC, the R2 Gateway service was inadvertently disabled during the routine remediation of a phishing site complaint. The action, intended to target a specific phishing URL hosted on R2, mistakenly disabled the entire R2 Gateway service responsible for authenticating and serving requests. As a result, all operations against R2 failed during the initial 59-minute incident window. ### What Was Impacted? **R2:** - **Full Outage:** 100% failure rate of operations (uploads, downloads, metadata operations) during the incident. - **Secondary Impact:** From 09:13 UTC to 09:36 UTC, client reconnection and subsequent backlog caused load issues, resulting in a <1% increase in error rates. **Stream, Images, and Cache Reserve:** - **Stream:** 100% failure of upload and streaming delivery operations. - **Images:** 100% failure of upload and download operations, although image delivery experienced a minimal drop in success rate to 97%. - **Cache Reserve:** Increased requests to origins, leading to minimal impact on cacheable requests (<0.049%). **Log Delivery:** - **R2-dependent logs:** Up to 13.6% data loss in R2 delivery jobs. - **Non-R2 logs:** Up to 4.5% data loss, with some delays in log processing. **Vectorize:** - 75% of queries failed, and 100% of insert, upsert, and delete operations failed due to reliance on R2 for persistent storage. No corruption was observed. **Durable Objects:** - Observed a minor 0.09% increase in error rates due to a spike in reconnecting clients. **Cache Purge and Key Transparency Auditor:** - Cache Purge API saw a 1.8% increase in error rates and a significant latency spike. - 100% failure in signature publish & read operations for the Key Transparency Auditor. **Workers & Pages:** - A minimal 0.002% of deployments failed, limited to services with bindings to R2. ### Incident Timeline | **Time (UTC)** | **Event** | |-----------------------|----------------------------------------------------------------| | **08:12** | R2 Gateway service disabled during phishing remediation. | | **08:14** | Impact begins: R2 operations fail. | | **08:18** | Critical R2 alerts triggered due to service failure. | | **08:23** | Sales engineering escalates issue to R2 engineering. | | **08:33** | Internal incident declared. | | **08:42** | Root cause identified: R2 Gateway service disabled by error. | | **08:46** | Attempts to re-enable R2 Gateway service using internal tooling fail. | | **08:57** | Operations team escalated and begins service restoration. | | **09:09** | R2 Gateway service redeployed, recovery begins. | | **09:13** | Impact ends; R2 service begins recovery. | | **09:36** | Durable Objects error rate returns to normal. | | **10:29** | Incident closed after monitoring confirms error rates return to normal. | ### Root Cause Analysis The root cause of the incident was human error during a routine abuse remediation. Cloudflare’s system mistakenly allowed the operator to disable the entire R2 Gateway service instead of the specific phishing endpoint. This issue was compounded by insufficient safeguards in the abuse processing system, which failed to distinguish between internal accounts and customer-facing resources. The R2 service architecture is built on a separation of concerns, where the Gateway service handles authentication and request routing, while the underlying infrastructure (including the distributed storage subsystem) remains unaffected during failures. However, with the Gateway service down, all operations against R2 were halted. Notably, there was no data loss or corruption during the incident, as the infrastructure components remained intact. ### Recovery Process Once the root cause was identified, Cloudflare faced challenges in restoring the R2 Gateway service due to the lack of direct rollback functionality for the product disablement action. The R2 team was forced to engage an operations team with lower-level system access to restore service. After redeploying the R2 Gateway service, client operations were restored, and error rates for dependent services began to normalize. ### Post-Incident Actions and Remediation Cloudflare has committed to a thorough review and improvement of its internal controls to prevent a recurrence of this incident. The company has outlined several key remediation efforts: 1. **Guardrails for Internal Accounts:** Cloudflare has implemented stricter validation safeguards to prevent disabling production services running on internal accounts. 2. **UI Changes for Abuse Reviews:** Product disablement actions in the abuse remediation interface have been temporarily disabled while more robust safeguards are added. 3. **Account Provisioning:** Cloudflare is revising how internal accounts are provisioned to ensure they are properly tagged and protected from accidental disablement. 4. **Restricting Access to Critical Actions:** Access to product-disablement actions will be limited to a smaller group of senior operators, with two-party approval required for any ad-hoc disablement requests. 5. **Expanded Abuse Checks:** New abuse checks will be added to prevent accidental blocking of internal Cloudflare hostnames and prevent disablement of services linked to internal accounts. ### Impact Assessment While the February 6th outage lasted less than an hour, its impact was significant, affecting key Cloudflare services relied upon by millions of users. However, the swift recovery, the lack of data loss, and Cloudflare’s immediate commitment to fixing systemic issues demonstrate the company’s dedication to preventing similar incidents in the future. Cloudflare [acknowledges](https://blog.cloudflare.com/cloudflare-incident-on-february-6-2025/) the severity of the incident and is deeply sorry for the inconvenience caused to its customers. The company’s commitment to improving its systems and reducing human error remains a top priority. As Cloudflare continues to enhance its internal controls, users can expect more resilient and reliable services moving forward.

loading..   07-Feb-2025
loading..   5 min read