MOVEit Transfer breaches are a perfect storm of application security risks

Since the initial SQL injection covered in our June 8th post, the MOVEit Transfer saga has sprouted multiple other vulnerabilities allowing for eventual remote code execution – and all are still under active exploitation. While already noteworthy for its sheer scale, the MOVEit crisis stands out among recent cybersecurity scares for its combination of multiple application security concerns into a perfect storm that will rage on for months.

Invicti does not use any MOVEit products and is not affected by the ongoing attacks. If your organization uses software from the MOVEit family, please follow the vendor’s official remediation guidance.

From SQL injection to full RCE: The MOVEit story so far

While the initial vulnerability reports mentioned only SQL injection (CVE-2023-34362), proof-of-concept attacks were soon published that showed the SQLi was only one step in a far more complex attack chain that allowed for remote code execution (RCE) and culminated in the installation of a web shell (see the earlier post for details). Even as the vendor, Progress Software, published patches to address the first CVE, two more SQL injection vulnerabilities were reported as CVE-2023-35036 and CVE-2023-35708. While both have also been patched now, the window of opportunity for attackers spanned at least several weeks, with organizations worldwide suffering data breaches.

The attacks are attributed to the financially-motivated cybercrime group Cl0p (codenamed Lace Tempest) and lead to ransom demands against selected organizations. Unlike more traditional ransomware attacks, sensitive data is exfiltrated rather than encrypted, with the attackers threatening to reveal it publicly unless ransom is paid. Affected organizations were given until June 14th to pay up or be publicly named and later have their data revealed on Cl0p’s leak site. As of this writing, the cybercriminals have already named over 90 organizations and claim to have leaked data for at least one global company.

For many of the organizations affected, the stolen data includes customer information, leading to fears of identity theft and other forms of abuse if those details fall into the wrong hands. A number of US government agencies have also confirmed breaches, and while Cl0p have repeatedly claimed they will only target commercial organizations and delete data obtained from any other sources, there is obviously no guarantee this is true. It is also highly likely that other threat actors have been performing similar attacks for weeks, if not months. This widespread risk to data privacy has even resulted in a class-action lawsuit being filed against Progress Software for alleged failures in data security practices and monitoring.

How top application security risks were combined into one devastating attack

Data breaches are a dime a dozen these days, but the MOVEit crisis is especially notable because it touches so many of the year’s headline topics and trends in cybersecurity. It also provides a veritable A–Z of web application security risks and their real-life consequences, so let’s run through a few of the big ones.

Relentless probing for web application weaknesses

Attacks against web applications continue to be a major source of data breaches, with Verizon’s DBIR for 2023 listing web apps as the direct breach vector in 25% of incidents overall and over 30% of system intrusion incidents, which is where the MOVEit attacks would fall. Far from being an ancient and long-gone threat, SQL injection is still among the top vulnerabilities in such malicious probes and attacks. In fact, Cloudflare’s 2023 report on application security shows that SQLi is the most common identifiable attack method detected in API traffic. The brutal truth is that every single web application and API out there will at some point be probed for vulnerabilities, starting with SQL injection.

Real-life attacks combine multiple vulnerabilities

While the simplest form of SQL injection is somebody hacking your database to directly access your data, real-life attacks by organized threat actors typically chain multiple vulnerabilities to achieve their goal. Taking the MOVEit Transfer attacks as an example, SQLi was used to escalate access rather than to extract data directly. If you go through one of the early proofs of concept, you can see multiple vulnerabilities being exploited, with each providing a stepping stone to the next stage. Here’s the simplified sequence:

1. As a prerequisite, session variables are set using request headers to establish a valid application session as a guest user, which should not be possible for a secure application.
2. SQL injection into an email field allows the attacker to create an admin user in the MOVEit Transfer database and grant that user all the necessary privileges.
3. A JSON Web Token (JWT) is generated to authorize admin-level API access in the next step.
4. Using the JWT, an API endpoint for file access is used to put a Base64-encoded payload on the server, resulting in insecure file upload. The PoC payload only opens a command line window and prints a message, but the real one deploys a web shell.
5. More SQL statements are injected to clean up evidence of the attack by deleting the previous database modifications needed to get access tokens.
6. Another SQL injection records the payload in the MOVEit database as a regular file upload from the application.
7. The payload is triggered with another API call, with code being executed on the server due to insecure deserialization. This is remote code execution (RCE).

As you can see, this wasn’t a “left the door open” type of attack but a carefully crafted chain, where each step has to succeed before the next can begin. This is typical of such tailor-made attacks, where a determined threat actor combines multiple vulnerabilities that might individually be low-risk or hard to exploit and assembles a complex attack package.

APIs are routinely targeted

Cyberattack stories related to APIs are mostly of the “unauthenticated API access” variety (as in the Optus hack), where the API is the primary or only target and the actual attack is fairly simple. Yet in modern application architectures, APIs are the main way to access data and functionality, so it’s likely that any multi-stage attack will hit an API endpoint sooner or later. For MOVEit Transfer, the application API might not be directly vulnerable to external attacks but is called many times once the attacker has escalated to admin privileges and generated a valid access token.

It only takes one weak link in the software supply chain

Supply-chain security has been a buzzword ever since the SolarWinds crisis and comes in two distinct flavors: securing the components used for building software and securing all the third-party software an organization relies on. For the MOVEit attacks, it’s the second meaning that’s on everybody’s lips now, with one vulnerable product affecting hundreds if not thousands of organizations that use it to manage their data. The sobering fact is that any modern business relies on dozens of third-party applications, and you can never be sure if every single one is secure, even though each is a target in its own right and could be the gateway to your systems and data.

You don’t matter – your data is the target

The opportunistic and indiscriminate nature of the MOVEit attacks should (hopefully) put an end to the “we’re not worth attacking” mentality that undermines security at so many organizations. Year after year, research shows that the vast majority (well over 90%) of all data breaches are financially motivated. Highly organized cybercrime actors use stolen sensitive data as their source of revenue, so it makes perfect (if ruthless) sense that they would go after a file management application used by thousands of organizations. As the current crisis shows, instead of hacking each organization separately, it’s far easier to spend extra time and resources compromising a popular third-party tool that is then used to hit everyone. The data is the real target – anything along the way is merely a means to get at it.

The lessons are there, but are we learning fast enough?

In a display of morbid humor, Cl0p’s message to MOVEit victims states that they offer a “penetration testing service after the fact.” Mocking aside, it’s clear that while the MOVEit Transfer application did have several vulnerabilities, they were not easy to exploit and required a long and determined effort to build a working attack. The usual reminders that any web application should go through multiple levels of security testing apply at this stage – putting software through static and dynamic automated testing, manual penetration testing, and regular vulnerability scanning is the best way to reduce risk.

While hardly revolutionary, the big lesson here is “protect your data no matter where it lives and what products can access it.” This means knowing and classifying all the different types of information in the organization, knowing all the software that can access it at rest or in transfer, and (this is the tricky bit) defining and enforcing security requirements for both your own applications and third-party products. In addition to any formal compliance, these should include both defensive and offensive security measures with regular testing, following the old principle of “trust, but verify.” Considering that US agencies were on the list of affected organizations and zero-trust guidance has been trickling down already, we can also expect regulatory steps for tighter control of third-party software in government systems.

For this security crisis, there were no gaping holes or head-slapping mistakes, only small everyday risks that conspired to whip up a perfect storm. There is no easy fix – only hard work to secure data and continuously test application and API security. Starting now.

Read the free Invicti white papers to learn how to use DAST in your SDLC and make API security part of your AppSec program.