Week in Overview(28 May-4 Jun) – 2024
Active network exploitation of CVE-2024-24919 has been detected. This vulnerability, which affects Checkpoint Security Gateways solutions with Remote Access VPN (IPSec) or Mobile Access blade capabilities enabled, could allow a remote malicious user to steal sensitive information and gain access to target accounts. The vendor has already remediated this issue.
Estimated Impact: SERIOUS/RED (78.07/100)
Typology
The CVE-2024-24919 vulnerability exists in Checkpoint Security Gateways solutions with Remote Access VPN or Mobile Access blade functionality enabled. Exploitation of this vulnerability has been detected in the wild, despite the vendor having provided a remediation.
A remote unauthenticated attacker can leverage this vulnerability to:
Affected Products and Versions
The following products and versions are affected:
Mitigation and Recommendations
Additional Resources
The event log system in Windows is crucial for tracking and analyzing various activities within the operating system. Event IDs provide detailed information about specific events, ranging from system startups and shutdowns to potential security threats. For example, Event ID 16 indicates when the registry hive access history is cleared, a potential sign of password dumping activities. Similarly, Event ID 55 highlights NTFS filesystem corruption, which could be indicative of attacks exploiting NTFS vulnerabilities. These events are classified with different levels of importance, from informational to critical, guiding administrators on which events require immediate attention.
In addition to the general system logs, specialized logs like the Application log and the Windows Defender Operational log provide more focused insights. The Application log, despite being noisy, can reveal critical events such as known vulnerability exploit attempts (Event ID 1) and application errors (Event IDs 1000, 1001). The Windows Defender Operational log is essential for monitoring alerts from Windows Defender, including tamper protection activities and the addition of exclusions, which are crucial for identifying and responding to security threats promptly.
Other specialized logs include the Bits-Client Operational log, which can detect misuse of the bitsadmin.exe tool by attackers to download and execute malware, and the Firewall log, which records changes to firewall rules. These logs help identify malicious activities such as the addition of firewall rules to facilitate communication with command-and-control servers. The NTLM Operational log is particularly important for environments looking to phase out NTLM authentication, as it allows administrators to monitor and gradually disable NTLM usage.
Logs such as the Security-Mitigations KernelMode and UserMode logs, PrintService logs, and SMBClient Security logs provide additional layers of security monitoring. For instance, the PrintService logs are useful for detecting Print Spooler attacks, while the SMBClient Security log helps identify suspicious SMB activities, such as rejected guest logons. The AppLocker logs and CodeIntegrity Operational logs are vital for enforcing application whitelisting and detecting malicious drivers, respectively. Collectively, these logs create a comprehensive system for monitoring, detecting, and responding to a wide range of security threats and system anomalies in a Windows environment.
In recent weeks, Snowflake, a prominent cloud-based data storage and analytics provider, has been embroiled in a cybersecurity incident. Reports indicate that unauthorized access to its systems may have compromised sensitive data from high-profile clients, including Santander Bank and Ticketmaster. Snowflake, known for its robust data storage, processing, and analytics capabilities, is a key player in data-driven applications. This blog post will explore the details of the Snowflake breach, drawing on disclosures from Snowflake, news reports, and insights from cybersecurity researchers.
Snowflake first detected unusual activity in its systems around mid-April 2024 and officially acknowledged potential unauthorized access on May 23, 2024. The company has been investigating the situation and communicating with affected customers, providing Indicators of Compromise (IoCs) and recommended actions to secure their accounts. Despite allegations of a widespread breach, Snowflake asserts that the incidents were due to compromised user credentials rather than vulnerabilities in its product. The company emphasized that there was no misconfiguration or malicious activities within Snowflake’s products, urging customers to review their security configurations.
Investigations into the breach suggest that it was facilitated by a compromised machine used by a Snowflake sales engineer, infected with Lumma Stealer malware. This malware logs keystrokes and other activities, likely serving as the initial access point for the attackers. The threat actor responsible claimed to have extracted sensitive data from major entities like Santander Bank and Ticketmaster. Following the breach, Santander Bank and Live Nation Entertainment (Ticketmaster’s parent company) confirmed unauthorized access to databases hosted by a third-party provider, later linked to Snowflake’s compromised environments. Cybersecurity firms conducted detailed analyses, revealing over 500 demo environment instances detected in the stealer logs related to the breach.
The threat actor behind the breach, known as “Whitewarlock,” surfaced on a Russian dark web forum on May 23, 2024. They posted data allegedly obtained from the breach, including customers’ data, account numbers and balances, credit card numbers, and HR employee lists from Santander Group. Whitewarlock claimed responsibility for the breach and demanded $2 million from Snowflake to return the stolen data. ShinyHunters, another threat actor group, also shared the same data to attract attention and further promote the Snowflake breach. Whitewarlock’s sudden appearance and specific demands suggest an opportunistic attack rather than a coordinated campaign.
The broader impact of the breach is significant, with reports indicating that six major organizations have experienced cybersecurity issues related to their use of Snowflake. Security researcher Kevin Beaumont highlighted this on Mastodon, noting the extent of the breach’s repercussions. Snowflake’s proactive measures, including detailed communications with affected customers and ongoing investigations, aim to mitigate the breach’s impact. The incident underscores the importance of stringent security practices and vigilant monitoring in safeguarding cloud-based environments from sophisticated cyber threats.
An insecure deserialization vulnerability has been identified in Progress® Telerik® Report Server versions prior to 2024 Q1 (10.0.24.130). This vulnerability can be exploited to execute remote code on the affected server.
The vulnerability arises from the insecure handling of serialized data in Report Server, allowing attackers to inject and execute arbitrary code remotely.
Updating to Report Server 2024 Q1 (10.0.24.305) or higher is the only way to eliminate this vulnerability.
CVE-2024-27348 is a critical remote code execution (RCE) vulnerability in Apache HugeGraph-Server. This flaw allows unauthorized users to execute arbitrary commands on the server through Groovy injection. The vulnerability affects versions of HugeGraph-Server from 1.0.0 to versions before 1.3.0. To mitigate this issue, users are advised to upgrade to version 1.3.0 or later.
A Python scanner has been developed to exploit this vulnerability, enabling ethical security professionals to test their systems for this specific issue. The scanner, available on GitHub (An insecure deserialization vulnerability has been identified in Progress® Telerik® Report Server versions prior to 2024 Q1 (10.0.24.130). This vulnerability can be exploited to execute remote code on the affected server.
), runs four commands (host, ping, curl, wget) on the target server to identify if the utilities are present and if the system is vulnerable. The scanner collects ping logs and DNS lookup/web request logs from the targets, which helps in determining if the commands were executed successfully.
The usage of the scanner is straightforward. It supports both single target and multiple target scanning modes. For single target scanning, the command is:
python3 CVE-2024-27348_Scanner.py -t http(s)://target_address -p port -d your_domain/ip
For scanning multiple targets listed in a file, the command is:
python3 CVE-2024-27348_Scanner.py -f targets_file -d your_domain/ip
The file should contain target addresses and ports in the format:
http://target,port
Security professionals can utilize this scanner to verify if their Apache HugeGraph-Server instances are vulnerable to CVE-2024-27348. Promptly upgrading to version 1.3.0 or later is essential to protect systems from potential exploitation. As with any security tool, it is crucial to ensure it is used responsibly and within legal and ethical boundaries.
Two years ago, while working from my home network, I encountered a strange and alarming incident. During an exploit of a blind XXE vulnerability, I set up an AWS server to receive traffic and noticed an unknown IP address replaying my HTTP requests. To ensure this wasn’t an anomaly, I repeated the test with different devices and new servers on AWS and GCP, all showing the same behavior. This led me to suspect that my modem or ISP had been compromised, although the unknown IP address was traced back to DigitalOcean.
Further investigation into the DigitalOcean IP revealed it had a history of being used for phishing and malicious activities, including targeting a South American cybersecurity company. The repeated interception and replay of my HTTP requests suggested a sophisticated level of network monitoring, likely through my ISP or modem. Despite reaching out to threat intelligence contacts and examining the data, the exact method of compromise remained unclear. The incident underscored the vulnerabilities inherent in the trust relationship between ISPs and customer devices.
In a related incident, I discovered significant vulnerabilities in Cox Communications’ APIs, which allowed unauthorized access to customer PII and device control. After reporting these findings, Cox patched the vulnerabilities and began a comprehensive security review. However, they confirmed that my initial device compromise was unrelated to these newly found vulnerabilities. The exact mechanism of my modem’s compromise remains a mystery, but the experience highlights the critical need for robust security measures and vigilant monitoring in protecting network infrastructures.
