Take a Product Tour Request a Demo Cybersecurity Assessment Contact Us

Blogs

The latest cybersecurity trends, best practices, security vulnerabilities, and more

The Bug Report - June 2024 Edition


Why am I Here

Welcome back to The Bug Report, the "so hot the server fans are sweating" edition! For those who are new to our monthly adventure, every month, our dedicated Advanced Research Center vulnerability research team sifts through a month’s worth of bugs to ensure you are up to date with the most critical. This month, we're bringing you five bugs that could transform your peaceful server farm into a chaotic jungle. Grab a cold drink, sit back, and let’s dive in.

June brings us five bugs worth your attention. Four of these are being actively exploited, and the last one has a publicly available POC code, so the threats are as real as the heatwave outside.


CVE-2024-27348: Gremlin in the Graph!

What is it?

Picture this: Your sleek, powerful Apache HugeGraph-Server is humming along, managing your sprawling data with the grace of a ballet dancer. Suddenly, a mischief-maker sneaks in, transforming your well-behaved server into a wild beast. Enter CVE-2024-27348, a Remote Code Execution (RCE) vulnerability that lets attackers slip through the cracks and wreak havoc.

This vulnerability affects HugeGraph-Server versions across both Java 8 and Java 11 environments. With a CVSS score of 9.8, this bug is no minor glitch. By sending crafted Gremlin queries, attackers can bypass sandbox restrictions and run arbitrary code, seizing full control of your server. Think of it as giving a vagabond DJ access to your playlist—they can play whatever they want, whenever they want, and it’s usually not your favorite tune.

HugeGraph, developed by Baidu, is a high-performance open-source graph database designed to handle massive datasets and complex queries using languages like Gremlin, Cypher, and SPARQL. But with great power comes great responsibility and, sometimes, great vulnerabilities.

A publicly available PoC shows how an attacker can exploit this vulnerability through a specially crafted Gremlin query that abuses the Java reflection mechanism. The PoC scripts show just how easy it is to exploit.

The first PoC demonstrates a reflection attack. The attacker sends a Gremlin query that leverages Java reflection to load the ProcessBuilder class. This class is then used to construct and execute a list of commands on the server:

  • The crafted Gremlin query is designed to bypass the sandbox restrictions by exploiting the reflection API in Java.
  • The query dynamically loads the ProcessBuilder class, constructs a command list, and invokes the start method to execute the command on the server.
  • A simple demonstration might include creating a new directory on the server as proof of successful exploitation, but the real danger lies in executing more harmful commands.

Another PoC demonstrates how changing the thread name can help evade detection by the security manager. This trick allows the attacker to use reflection to execute arbitrary commands. Here’s how it works:

  • The PoC manipulates the thread name to avoid detection by the security manager.
  • The attacker can execute arbitrary commands using Java reflection, bypassing the usual security checks.
  • This technique adds another layer of stealth to the attack, making it even harder to detect and stop.

Who Cares?

Who should be pulling their hair out over this? If you’re running Apache HugeGraph-Server, especially versions between 1.0.0 and 1.2.0, it’s time to sit up and take notice. This bug doesn’t discriminate; it has the potential to wreak havoc across industries relying on HugeGraph for managing their data labyrinths.

Admins, developers, and anyone vested in keeping their data secure and their servers uncompromised—this is your call to action. If your organization relies on HugeGraph for critical operations, you better believe this vulnerability deserves immediate attention.

What Can I Do?

Upgrade to Version 1.3.0

  • The cavalry is here! Upgrade to HugeGraph-Server version 1.3.0 or later, which includes patches to squash this bug. Ensure you’re using Java 11 to bolster your defenses.

Enable Authentication

  • Activate the built-in authentication system to restrict access to the Gremlin server. This adds a critical layer of protection, ensuring that only authorized users can execute queries.

Whitelist IP Addresses

  • Configure the "Whitelist-IP/port" feature to limit access to authorized sources further. This step helps ensure that only trusted IP addresses can connect to your server.


CVE-2024-4577: The Soft Hyphen Snafu

What is it?

Imagine you’re hosting a friendly neighborhood BBQ, and someone slips a note into your invitation stack that changes your "BYOB" event into a full-blown rager. That’s kind of what CVE-2024-4577 does to your PHP setup on Windows. This critical vulnerability lets unauthenticated attackers perform argument injection attacks, leading to remote code execution (RCE). It’s like giving a party crasher the keys to your house while you’re still setting up the snacks.

The root cause? A sneaky little thing called the Best-Fit feature of encoding conversion in Windows wasn’t adequately considered during PHP’s implementation. This oversight allows attackers to bypass protections put in place to mitigate an old foe, CVE-2012-1823, by using specific character sequences to inject arbitrary arguments into the PHP CGI execution context. Essentially, attackers can whisper sweet nothings into your server’s ear and get it to do whatever they want.

This vulnerability impacts all versions of PHP on Windows, especially those before PHP 8.3.8, PHP 8.2.20, and PHP 8.1.29. Older branches like PHP 8.0, 7.x, and 5.x are also vulnerable if you’re still running them (pro tip: don’t).

Cybercriminals love exploiting vulnerabilities like CVE-2024-4577 because they offer easy wins. An attacker could craft a malicious HTTP request that injects arguments into PHP’s CGI handler. For example, a POST request might use %AD characters to inject directives like allow_url_include and auto_prepend_file, turning PHP into an unwitting accomplice in running arbitrary code.

Here’s a sample exploit that would make any hacker giddy:

POST /test.php?%ADd+allow_url_include=1+%ADd+auto_prepend_file=php://input HTTP/1.1
Host: vulnerable.host
Content-Type: application/x-www-form-urlencoded
Content-Length: 23
<?php phpinfo(); ?>

The crux of the exploit lies in how PHP and the CGI handler interpret Unicode characters differently—particularly the soft hyphen (0xAD), which can sneak through security checks like a ninja through a laser grid. This simple request could lead to executing a malicious payload, with the implications spanning from unauthorized access to complete system compromise. Think "Mr. Robot" levels of chaos right in your server room.

What's the worst that could happen?
What's the worst that could happen?

Who Cares?

If you’re running PHP on Windows, especially any versions before PHP 8.3.8, PHP 8.2.20, and PHP 8.1.29, it’s time to sit up and take notice. Even more so if you're still holding on to those nostalgic older PHP branches like PHP 8.0, 7.x, or (gasp) 5.x—because those versions are as defenseless as a piñata at a kid’s birthday party, this vulnerability doesn’t discriminate; it affects all PHP versions on Windows, making it a significant threat to a wide range of web applications.

What Can I Do?

  1. Upgrade PHP:Your first line of defense is to upgrade to the latest patched versions:
    • PHP 8.3.8
    • PHP 8.2.20
    • PHP 8.1.29 These versions address the vulnerability and bolster your overall security posture.
  2. Alternative Configurations: Ditch the CGI mode and opt for more secure alternatives:
    • Mod-PHP:
    • FastCGI:
    • PHP-FPM: Tailored for securely handling large volumes of PHP processes.

  3. Temporary Mitigation:

    Apache Rewrite Rules: Block attack vectors with the following rules:
    apache

    RewriteEngine On
    RewriteCond %{QUERY_STRING} ^%ad [NC]
    RewriteRule .? - [F,L]

    XAMPP Users: Comment out the ScriptAlias directive in the Apache configuration:

    # ScriptAlias /php-cgi/ "C:/xampp/php/"
  4. Locale Assessment: Conduct a thorough assessment of your server’s locale settings and review your configurations to pinpoint and mitigate potential risks. Given the diverse nature of PHP deployment environments, ensuring every aspect is locked down is crucial.

Trellix Customers: Trellix has provided a User-Defined Signature (UDS) for the Trellix Intrusion Prevention System (IPS) to cover this vulnerability. Instructions on how to download and apply this UDS are available here.


CVE-2017-3506: Commandeer the Command Line!

What is it?

Ahoy, cyber swashbucklers! CVE-2017-3506 is here to remind you that your WebLogic Server isn’t just a platform for deploying enterprise applications—it’s a potential gateway for digital marauders. This critical vulnerability in Oracle WebLogic Server, an Oracle Fusion Middleware suite component, allows cunning attackers to inject and execute OS commands via malicious HTTP requests embedded with XML trickery.

Picture your WebLogic Server as the captain of a ship. Now imagine if a pirate managed to sneak on board and start issuing commands to the crew. That’s essentially what CVE-2017-3506 does.

Affected versions include WebLogic Server 10.3.6.0, 12.1.3.0, 12.2.1.0, 12.2.1.1, and 12.2.1.2. This vulnerability is a high-severity issue, scoring off the charts on the CVSS scale.

Proof-of-concept (PoC) scripts abound, demonstrating just how attackers can exploit this hole to inject their malicious payloads. It’s like a pirate hijacking your ship and turning it against you.

Special shoutout to the cybersecurity teams who need to fend off threat actors like the infamous China-based Water Sigbin (8220 Gang). In one documented case, the attack payload for CVE-2017-3506 included a base64-encoded PowerShell command designed to download and execute a script from a remote server. This command, once decoded, would download a script named bin.ps1 from the attacker's server and execute it on the compromised WebLogic Server. The bin.ps1 script contained further obfuscated commands and encoded payloads, ultimately leading to the deployment of a cryptocurrency miner. The attackers' use of PowerShell and fileless execution techniques made these attacks particularly stealthy, allowing the malware to run in memory without leaving traditional file-based artifacts—truly the ninja warriors of malware.

Just a little pincushion of malicious code.
Just a little pincushion of malicious code.

Who Cares?

If your enterprise relies on Oracle WebLogic Server for critical operations, this CVE is your digital wake-up call. Whether you’re a small business or a massive corporation, if WebLogic is part of your IT infrastructure, you must be on high alert. Unauthenticated attackers can exploit this flaw to gain control of your server, which could lead to all sorts of mayhem—think data breaches, system takeovers, and even the dreaded ransomware attacks.

What Can I Do?

Apply Patches, Stat!

  • Oracle has released security patches to shore up the defenses against CVE-2017-3506. Make sure your WebLogic Server is upgraded to version 12.2.1.3 or later. This is your first line of defense against potential exploits.

Network Segmentation

  • Divide and conquer! Implement network segmentation to isolate your WebLogic Server from the rest of your network. This limits the damage an attacker can do if they breach the server.

Remove the wls-wsat Component

Not using the wls-wsat component? Get rid of it! Here’s how you can do it:

rm -f /home/WebLogic/Oracle/Middleware/wlserver_10.3/server/lib/wls-wsat.war
rm -f /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/.internal/wls-wsat.war
rm -rf /home/WebLogic/Oracle/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/wls-wsat


After you’ve done that, restart the WebLogic domain controller service to apply the changes:

DOMAIN_NAME/bin/stopWeblogic.sh # Terminates the service.
DOMAIN_NAME/bin/startManagedWebLogic.sh # Starts the service.


Configuration Changes and Workarounds

  • If certain privileges or packages aren’t necessary for your users, consider removing them to reduce the risk of a successful attack. Test these changes on non-production systems first to avoid disrupting your operations.

Trellix Customers: Trellix Intrusion Prevention System (IPS) provides detection for this vulnerability. It contains HTTP response-based signatures. Ensure you have enabled the HTTP Response option and that your solution is updated to the latest version.


CVE-2024-20693: The Privilege Escalation Plot Twist

What is it?

Buckle up, Windows 11 users, because CVE-2024-20693 is the latest plot twist in the ever-evolving drama of cybersecurity. This vulnerability is like finding out your reliable butler has been sneaking into the family vault. It’s an elevation of privilege (EoP) vulnerability that lets local attackers manipulate the cached signature signing level of executables or DLLs, bypassing security restrictions and gaining elevated privileges. Imagine your trustworthy software turning into a Trojan horse, carrying malicious code straight into the heart of your system.

Discovered during a deep dive into Windows internals, CVE-2024-20693 highlights the perils of improperly imposed security restrictions within the Windows Kernel. Inspired by previous vulnerabilities discussed at OffensiveCon 2023, the research reveals how attackers can escalate their system privileges by manipulating NTFS Extended Attributes (EA), specifically the $KERNEL.PURGE.ESBCACHE attribute. This manipulation tricks Windows into treating malicious DLLs or executables as highly trusted, bypassing the usual security checks.

This vulnerability takes advantage of the discrepancy between how the Windows kernel and the NTFS file system handle extended attributes. By exploiting this discrepancy, attackers can make Windows believe that a malicious DLL is actually a benign, fully trusted one.

Who Cares?

If you're running Windows 11, this bug should be on your radar. Whether you’re a casual user or a sysadmin managing a fleet of machines, the implications of this vulnerability are serious. Attackers can exploit this flaw to elevate their privileges, bypass security measures like Windows Defender Application Control (WDAC), and inject malicious code into protected processes. If that doesn’t get your attention, imagine the potential for unauthorized access to sensitive data, system compromise, and a full-scale breach.

What Can I Do?

  1. Apply Patches: Microsoft has your back with the April 2024 Patch Tuesday update. This update addresses CVE-2024-20693 by disabling cached signature levels for DLLs loaded into protected processes and when WDAC is enabled. Update your systems immediately to close this security gap.
  2. Network Restrictions: Block outgoing SMB traffic to the internet. This step prevents attackers from leveraging malicious SMB servers to exploit the vulnerability. It’s like locking the doors to stop the bad guys from sneaking in.
  3. Disable New SMB Shares: Restrict users from mounting new SMB shares. By doing so, you reduce the attack surface without disrupting legitimate network operations. Think of it as putting up additional barriers to keep the intruders out.
  4. Monitor and Filter SMB Traffic: Deploy network monitoring solutions to detect and filter responses to specific ioctl requests (like 0x90390) and the presence of $KERNEL.PURGE.ESBCACHE extended attributes in SMB traffic. This proactive step helps you catch potential attacks before they escalate.

CVE-2024-30080: The Queuing Catastrophe

What is it?

Imagine this: you’re peacefully managing your network, enjoying a quiet day with everything running smoothly. Suddenly, out of nowhere, CVE-2024-30080 bursts onto the scene like a rogue wave in a calm sea. This isn't just any security vulnerability—it's a critical storm brewing in the depths of Microsoft Message Queuing (MSMQ). Found in the mqise.dll executable within the RPCToServer function, this flaw results from a race condition that leads to a use-after-free error. With a CVSS score of 9.8, it’s like finding a crack in your fortress wall that's wide enough for an entire army to march through.

An attacker could craft a malicious MSMQ packet and send it to your vulnerable server. Here’s a simplified scenario:

POST /msmq HTTP/1.1
Host: vulnerable.server
Content-Type: application/x-msmq
Content-Length: 64

<evil-payload-here>

Successful exploitation could result in the attacker gaining complete control over the system, spreading malware, stealing data, or using the compromised server to launch further attacks.

Who Cares?

Anyone with a Windows system should pay attention, especially if you’re running a server with MSMQ enabled. While MSMQ isn’t enabled by default, there are still thousands of servers out there with this service quietly running in the background. A quick Shodan search revealed around 256,000 potentially vulnerable internet-facing MSMQ servers. So, if you’re responsible for keeping a network safe and sound, this one’s for you.

The severity here is twofold: first, an attacker can exploit this vulnerability remotely without needing to authenticate—yes, they can just waltz right in. Second, this flaw is wormable, meaning it can spread from server to server where MSMQ is enabled, and network traffic on TCP port 1801 is allowed. Imagine a digital plague sweeping through your servers—that’s the potential we're discussing.

This can get bad really fast
This can get bad really fast

What Can I Do?

  1. Apply Patches: Microsoft has released updates to tackle this beast. Make sure your systems are running the latest versions:
    • Windows 11 versions before 23H2 10.0.22631.3737
    • Windows Server versions before 2022 10.0.20348.2527 These patches are part of the June Patch Tuesday updates. So, hop on that update train and keep your systems safe.
  2. Disable MSMQ: If you can’t patch it immediately, disable the MSMQ service. Here’s how you can do it:
    • Go to Control Panel.
    • Check if the "Message Queuing" service is running.
    • Stop the service. Disabling MSMQ is like locking that front door and putting up a “Do Not Disturb” sign.
  3. Network Configuration: Block inbound traffic on TCP port 1801. This can be configured using your firewall rules. Doing this cuts off the exploit’s entry point, making it much harder for attackers to sneak in.
  4. Monitor and Audit: Regularly audit your systems to check for the presence of the MSMQ service. Make sure unnecessary services are disabled to minimize your attack surface. Think of it as regular housekeeping—dust off those unused services and keep everything neat and tidy.

Trellix Customers: Trellix Intrusion Prevention System (IPS) provides detection for this vulnerability. Ensure you have enabled the HTTP Response option and that your solution is updated to the latest version.

This document and the information contained herein describe computer security research for educational purposes only and for the convenience of Trellix customers.

This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers.

Get the latest

Stay up to date with the latest cybersecurity trends, best practices, security vulnerabilities, and so much more.
Please enter a valid email address.

Zero spam. Unsubscribe at any time.