Aspera Under Attack

Vulnerability Patching
Written By Ian Wright

Introduction

It’s another spring morning in Cambridgeshire. It is raining (again) a file sharing vulnerability is being actively exploited (again) and the organisations with vulnerable deployments are taking far too long to apply the patches (again). Let’s take a look at IBM’s Aspera.

A Brief History of Aspera

Aspera Inc. was founded in 2014, they developed a communications protocol (FASP), that was designed for efficient data transfer, along with a related set of products. FASP uses an alternative to TCP’s flow control algorithm to try and make better use of all the available bandwidth, it also has a built in encryption layer that uses an initial SSH connection for key exchange and AES-128 for the encrypted data channel.

IBM Acquired Aspera in 2013 and now offers “IBM Aspera” as a high performance data transfer solution. There are a few key components in a typical IBM Aspera deployment:

  • High Speed Transfer Server (HSTS): These are the server nodes that conduct the actual data transfer. Data transfers can take place between transfer servers or between a client-side component and a transfer server.

  • Aspera Shares: Shares is essentially a web front end for Aspera that allows users to share files using Aspera.

  • Aspera Faspex: Faspex is another web front end for Aspera. Rather than being a general file sharing interface like Shares, Faspex is more oriented towards single point-to-point file sharing tasks.

  • Aspera Connect: Connect is a client-side file transfer component, it includes a browser plugin that enables transfers to be initiated from a web page.

  • Aspera Cargo: Cargo is another client-side component, this is configured to point to an Aspera or Faspex server and can automatically download data to the local host.

Let’s take a look at some recent vulnerabilities.

CVE-2022-47986

This vulnerability allows unauthenticated arbitrary code execution on Aspera Faspex servers. It is a YAML deserialisation flaw that is trivial to exploit and, not surprisingly, unpatched servers are being actively attacked. With a CVSS of 9.8, and an entry on the CISAs Known exploited list, this is clearly a high risk vulnerability.

The vulnerability was disclosed on 2nd February 2023 so, at the time of writing, the vulnerability has been publicly known for over two months. Let’s take a look at some current deployment numbers.

Chart showing the number of IBM Aspera Faspex deployments that are vulnerable to CVE-2022-47986.

Chart showing the number of IP addresses with detected IBM Aspera Faspex versions, as of April 2023.

Out of the 673 detected deployments: 404 (60%) are using patched versions, and 269 (40%) are unpatched and still exposed to a critical vulnerability. It is good to see that we are at least over the 50% mark for patch deployment, but there are a lot of organisations still exposed to CVE-2022-47986.

Exploiting Trust Relationships

Compromising a Faspex server is clearly a problem, but the impact actually extends a bit further than expected. The Aspera Connect client uses a set of “Trusted Hosts” to enable a host to initiate a file transfer without a security prompt. When a server attempts to initiate a file transfer the user is given a security prompt:

IBM Aspera Connect security dialog may expose organisations to CVE-2022-47986.

If the user checks “Remember my choice for this site” then the named server is added to the set of trusted hosts and will be permitted to initiate future file transfers without a security prompt. It seems likely that the majority of users will select this option just to prevent having to click through the warning every time.

This means that, if a Faspex server is compromised, a good proportion of the users of that server may then be exposed to the risk of unauthorised file transfer to and from the client hosts. This essentially means that compromising a single Aspera Faspex server could lead to a wide scale compromise of any data contained on clients that make regular use of that server.

CVE-2023-27284 and
CVE-2023-27286

These two CVEs were published on the 27th March 2023. They both relate to buffer overflows in Aspera Connect 4.2.5 and Aspera Cargo 4.2.5.

One point of interest is that NIST and IBM have used a different CVSS Attack Vector for both CVEs: IBM has assigned a “Local” CVSS Attack Vector to both issues, this implies the vulnerability is not (directly) reachable over a network. NIST has rated both issues has having a “Network” Attack Vector. Due to this difference in vector, the CVEs have a CVSS of 9.8 from NIST and a CVSS of 8.4 from IBM.

Although there are currently no public details on the actual attack vector for these CVEs, it is possible that the issues exist in code that is handling data from a remote Aspera component. This would explain IBM’s “Local” rating as it would mean some user interaction is needed to get the components to initiate an out-bound connection before the issues could be exploited. NIST may have taken the perspective that the Connect browser plugin could be used to initiate a connection to a malicious Aspera component thus enabling a network based attack vector.

Exploit Chain?

While all three of these CVEs are inherently dangerous, combining them into a chained exploit could be devastating. A purely hypothetical attack scenario could unfold like this:

  • Stage 1: Deploy an an automated exploit that scans the Internet for vulnerable Aspera Faspex servers and deploys a payload using the YAML deserialisation vulnerability (CVE-2022-47986).

  • Stage 2: The exploit payload monitors the server for incoming client connections but stays otherwise silent. When a client connects, the payload reaches out to a command and control system with the client details and enables the attacker to quietly initiate an additional file transfer to retrieve any interesting looking files from the client.

  • Stage 3: The compromised Faspex server could also provide a route by which the attacker could attempt to gain control over the client by exploiting one of the buffer overflows covered by CVE-2023-27284 or CVE-2023-27286. This could provide a further foothold in the organisation’s network or may even be used to gain access to the networks of any partner organisations that are using the same Aspera instance to share files.

This is presented as a possible scenario only, I’m not aware of any evidence to suggest such an exploit chain was ever actually carried out. This does serve to illustrate how different vulnerabilities in different components of a system can be combined to significantly extend the scope of a potential attack though.

Conclusion

The number of older versions of Aspera Faspex that are still deployed strongly implies that many instances are installed and then forgotten. At this point it is likely that any remaining vulnerable instances have already been compromised so if you find one in your organisation I would advise treating it as a likely breach rather than a missing patch.

The key message here is that organisations need to keep a close watch on their external attack surface and make sure that issues of this severity are quickly patched. Organisations with more complex infrastructure should now consider an Attack Surface Management solution to be a critical part of their overall security architecture.

The risk that a compromised server could attempt to attack connecting clients, via an attempted exploit of CVE-2023-27284/CVE-2023-27286 or through an unauthorised file transfer, also means there could be some exposure to organisations that are using Aspera deployments belonging to a trusted third party. Even if you don’t have your own Aspera deployment is is worth making sure that any instances in your supply chain have been patched.

We do have a full list of detected vulnerable instances of Aspera Faspex, if you would like to know if any are associated with your organisation then get in touch. We will be happy to cross reference the list against your organisation and let you know if you have any vulnerable instances.

Further Reading

Ian Wright
Previous

MOVEit Transfer
Next

The Importance of Risk Management