Tech Support
Documentation
Login
Contact Us
From Fishy to Formidable: An Updated Look at the Barracuda ESG Zero-Day Vulnerability
Joao Correia
June 28, 2023 - Technical Evangelist
In a recent post entitled “Fishy Zero Day Exploits,” we outlined the discovery of a troubling zero-day exploit of the Barracuda Email Security Gateway (ESG), an appliance designed for email filtering, now recognized as CVE-2023-2868.
Now, with newly released details from an in-depth investigation by Mandiant, we have a fuller picture of this security incident that reveals a sophisticated, global attack with suspected ties to a state-sponsored threat actor.
The Attack Vector
The exploit was initially disclosed on May 23, 2023, with Barracuda advising all ESG users to immediately deploy patches to mitigate the issue.
The vulnerability lies in the ESG’s handling of TAR email attachments, in which unsanitized user-controlled input can trigger a command injection attack. The TAR files get scanned by the ESG through a Perl function, and by naming a file with a controlled payload, the attacker can execute commands with the ESG’s system privileges, effectively gaining root access:
qx{$tarexec -O -xf $tempdir/parts/$part '$f'}
|
Here, $f is the name of a file inside the TAR archive. As you can see, the filename gets passed directly to “qx” and is executed as-is without any filtering. A filename that contains a payload is nothing new in the cybersec field, and it is relatively easy and common to deploy reverse shells as a “one-liner” command that could (and did) fit this file name. We will refrain from directly writing one such example for its malicious uses, but examples are accessible through some google-fu.
The Threat Actor and Their Tactics
Mandiant’s analysis, facilitated by Barracuda’s decisive actions and information sharing, revealed that the first known attack occurred as early as October 2022, some eight months before public acknowledgement.
The attacker, currently tracked as UNC4841, used a clever strategy: they sent emails containing malicious TAR file attachments to ESG appliances. These emails were deliberately crafted to appear as spam, thereby avoiding the attention of both users, by avoiding the inbox as spam, and administrators, who have, over the years, been conditioned to immediately pay no attention to spam emails.
Once the malicious email was scanned by ESG, and the code inside the TAR file was executed, it would download additional executable code from the internet and open a reverse shell to an attacker controlled system. As a reminder, a reverse shell is a connection that, unlike traditional connections where a user connects to a server, the server instead connects to the user system and establishes the connection. This avoids the need for ESG to be directly exposed and reachable to (and from) the Internet, and still allows the attacker to gain entry to it.
Persistence and Evolution
Despite Barracuda’s patch release, the attacker displayed an alarming adaptability by altering their payload and persistence strategy to avoid the fixes and maintain access, even on patched systems. Revised payload code was identified within 2 days of the patches being made available.
In this case, unfortunately, the attacker responded faster than most ESG administrators deployed patches.
Sophistication and Variety of Payloads
The attacker’s methods were notably advanced, including the creation of fully functional plugins to extend ESG’s functionality covertly. Three identified backdoor payloads were SEASPY, SALTWATER, and SEASIDE, each providing unique backdoor access.
Additionally, a rootkit named SANDBAR was used to maintain persistence by hiding the processes of the other modules. This rootkit would remove from process monitoring tools like “ps,” “top,” and similar – any processes spawned by other modules involved in the attack. It operated by forbidding these processes from appearing under “/proc”.
Stealthy Communication and Persistence
The attacker cleverly reused Barracuda’s self-signed certificates to encrypt its communications, further blending into the system. As part of its deployment process, ESG will initially use self-signed certificates, which are left in the deployed system. The attacker would copy and use those certificates for its communications, thus appearing as normal traffic.
Multiple paths were used to persist on a system, including the utilization of cron jobs (with multiple scripts attached), modifying /etc/init.d/rc to start SEASPY upon restart, and deploying SANDBAR as an auto-loading kernel module. Each of these had ways to reestablish persistence in case any of the other modules was missing.
Specific Targets and Attribution
The attacker targeted academics, government, and trade officials across the globe, with a significant focus on regions such as Taiwan, Hong Kong, and Southeast Asia. Multiple specific email addresses were found hardcoded in scripts, considered as interesting targets for exfiltration whenever detected. This was in addition to all other targets caught in the attack that were affected without being specifically targeted.
The target list would be changed to accommodate targets who were officials of countries engaged in high-level diplomatic events with other countries, in the periods leading to, during and in the aftermath of such events.
The pattern of targeted organizations, the utilization of shared IP infrastructure with previously known attackers for command and control, and political motives suggest this campaign is a state-sponsored act by China. This type of attribution is never easy to definitively pinpoint with 100% certainty, but there seems to be an overwhelming number of characteristics that point to this conclusion.
Recommendations Going Forward
In response to the severity and sophistication of this attack, Barracuda now recommends the isolation and replacement of ESGs rather than patching, regardless of what patch level the ESG appliances currently have.
Network activity should be inspected for matching Barracuda certificates.
Over a hundred different IOC’s have been published that help identify C&C ips, suspicious system activities and other telltale signs of compromise, both on ESG and other systems in the infrastructure, as there is some evidence that suggest that reconnaissance and scanning was performed from some ESG appliances, targeted at other internal systems visible to the ESG.
Email logs should be reviewed to identify the initial compromise. Of course, this can be tricky with the ESG itself out of commission as per Barracuda’s recommendations, but this is what centralized logging systems are for.
As always, keeping systems patched as soon as possible, even when those systems are not directly exposed to the Internet, continues to be the most basic and best first step towards achieving some security.
As threats evolve, so does the acceptable time between disclosure and remediation shrink.
[Disclosure: the author acknowledges the use of ChatGPT to assist in the wording of some parts of this article]
