MOVEit zero-day exploit used by data breach gangs: The how, the why, and what to do…

Last week, Progress Software Corporation, which sells software and services for user interface development, devops, file management and more, alerted customers of its MOVEit Transfer and related MOVEit Cloud products about a critical vulnerability dubbed CVE-2023-34362.

As the name suggests, MOVEit Transfer is a system that makes it easy to store and share files throughout a team, a department, a company, or even a supply chain.

In its own words, “MOVEit provides secure collaboration and automated file transfers of sensitive data and advanced workflow automation capabilities without the need for scripting.”

Unfortunately, MOVEit’s web-based front end, which makes it easy to share and manage files using just a web browser (a process generally considered less prone to misdirected or “lost” files than sharing them via email), turned out to have a SQL injection vulnerability.

SQL injections explained

Web-based SQL injection bugs arise when an HTTP request that’s submitted to a web server is converted insecurely into a query command that’s then issued by the server itself to do a database lookup in order to work out what HTTP reply to construct.

For example, a database search that’s triggered from a web page might end up as a URL requested by your browser that looks like this:

https://search.example.com/?type=file&name=duck

The query text duck could then be extracted from the name parameter in the URL, converted into database query syntax, and stitched into a command to submit to the database server.

If the backend data is stored in a SQL database, the web server might convert that URL into a SQL command like the one shown below.

The % characters added to the text duck mean that the search term can appear anywhere in the retrieved filename, and the single quote characters at each end are added as markers to denote a SQL text string:

SELECT filename FROM filesdb WHERE name LIKE '%duck%'

The data that comes back from the query could then be formatted nicely, converted to HTML, and sent back as an HTTP reply to your browser, perhaps giving you a clickable list of matching files for you to download.

Of course, the web server needs to be really careful with the search text that it receives, in case a malicious user creates and requests a URL like this:

https://search.example.com/?type=file&name=duck';DROP table filesdb;--

If that search term were blindly converted into a query string, you might be able to trick the web server into sending the SQL server a command like this:

SELECT filename FROM filesdb WHERE name LIKE '%duck';DROP TABLE filesdb;--%'

Because a semicolon (;) acts as a statement separator in SQL, this single-line command is actually the same as sending three consecutive commands:

SELECT filename FROM filesdb WHERE name LIKE '%duck' -- matches names ending duck
DROP TABLE filesdb                                   -- deletes whole table
--%'                                                 -- comment, does nothing

Sneakily, because everyting after -- is discarded by SQL as a programmer’s comment, these three lines are the same as:

SELECT filename FROM filesdb WHERE name LIKE '%duck'
DROP TABLE filesdb

You’ll get back a list of all filenames in the database table that end with the string duck (the special SQL character % at the start of a search term means “match anything up to this point”)…

…but you’ll be the last person to get anything useful out of the filesdb table, because your rogue search term will follow up the search with the SQL command to delete the whole table.

Little Bobby Tables

If you’ve ever heard syadmins or coders making jokes about Little Bobby Tables, that’s because this sort of SQL injection was immortalised in an XKCD cartoon back in 2007:

As the cartoon concludes in the last frame, you really need to sanitise your database inputs, meaning that you need to take great care not to allow the person submitting the search term to control how the search command gets interpreted by the backend servers involved.

You can see why this sort of trick is known as an injection attack: in the examples above, the malicious search terms cause an additional SQL command to be injected into the handling of the request.

In fact, both these examples involve two injected commands, following the sneakily-inserted “close quote” character to finish off the search string early. The first extra command is the destructive DROP TABLE instruction. The second is a “comment command” that causes the rest of the line to be ignored, thus cunningly eating up the trailing %' characters generated by the server’s command generator, which would otherwise have caused a syntax error and prevented the injected DROP TABLE command from working.

Good news and bad news

The good news in this case is that Progress patched all its supported MOVEit versions, along with its cloud-based service, once it became aware of the vulnerability.

So, if you use the cloud version, you’re now automatically up-to-date, and if you are running MOVEit on your own network, we hope you’ve patched by now.

The bad news is that this vulnerability was a zero-day, meaning that Progress found out about it because the Bad Guys had already been exploiting it, rather than before they figured out how to do so.

In other words, by the time you patched your own servers (or Progress patched its cloud service), crooks might already have injected rogue commands into your MOVEit SQL backend databases, with a range of possible outcomes:

• Deletion of existing data. As shown above, the classic example of a SQL injection attack is large-scale data destruction.
• Exfiltration of existing data. Instead of dropping SQL tables, attackers could inject queries of their own, thus learning not only the structure of your internal databases, but also extracting and stealing their juiciest parts.
• Modification of existing data. More subtle attackers might decide to corrupt or disrupt your data instead of (or as well as) stealing it.
• Implantation of new files, including malware. Attackers could inject SQL commands that in turn launched external system commands, thus achieving arbitrary remote code execution inside your network.

One group of attackers, alleged by Microsoft to be (or to be connected with) the infamous Clop ransomware gang, have apparently been using this vulnerability to implant what are known as webshells on affected servers.

If you’re not familiar with webshells, read our plain-English explainer that we published at the time of the troublesome HAFNIUM attacks back in March 2021:

Webshell danger

Simply put, webshells provide a way for attackers who can add new files to your web server to come back later, break in at their leisure, and parlay that write-only access into complete remote control.

Webshells work because many web servers treat certain files (usually determined by the directory they’re in, or by the extension that they have) as executable scripts used to generate the page to send back, rather than as the actual content to use in the reply.

For example, Microsoft’s IIS (Internet Information Services) is usually configured so that if a web browser requests a file called, say, hello.html, then the raw, unmodified content of that file will be read in and sent back to the browser.

So, if there is any malware in that hello.html file, then it will affect the person browsing to the server, not the server itself.

But if the file is called, say, hello.aspx (where ASP is short for the self-descriptive phrase Active Server Pages), then that file is treated as a script program for the server to execute.

Running that file as a program, instead of simply reading it in as data, will generate the output to be sent in reply.

In other words, if there is any malware in that hello.aspx file, then it will directly affect the server itself, not the person browsing to it.

In short, dropping a webshell file as the side-effect of a command injection attack means that the attackers can come back later, and by visiting the URL corresponding to that webshell’s filename…

…they can run their malware right inside your network, using nothing more suspicious than an unassuming HTTP request made by an everyday web browser.

Indeed, some webshells consist of just one line of malicious script, for example, a single command that says “get text from a specific HTTP header in the request and run it as a system command”.

This gives general-purpose command-and-control access to any attacker who knows the right URL to visit, and the right HTTP header to use for delivering the rogue command.

What to do?

• If you’re a MOVEit user, make sure all instances of the software on your network are patched.
• If you can’t patch right now, turn off the web-based (HTTP and HTTPS) interfaces to your MOVEit servers until you can. Apparently this vulnerability is exposed only via MOVEit’s web interface, not via other access paths such as SFTP.
• Search your logs for newly-added web server files, newly created user accounts, and unexpectedly large data downloads. Progress has a list of places to search, along with filenames and URLs to search for.
• If you’re a programmer, sanitise thine inputs.
• If you’re a SQL programmer, use parameterised queries, rather than generating query commands containing characters controlled by the person sending the request.

In many, if not most, webshell-based attacks investigated so far, Progress suggests that you’ll probably find a rogue webshell file named human2.aspx, perhaps along with newly-created malicious files with a .cmdline extension.

(Sophos products will detect and block known webshell files as Troj/WebShel-GO, whether they are called human2.aspx or not.)

Remember, however, that if other attackers knew about this zero-day before the patch came out, they may have injected different, and perhaps more subtle, commands that can’t now be detected by scanning for malware that was left behind, or searching for known filenames that might show up in logs.

Don’t forget to review your access logs in general, and if you don’t have time to do it yourself, don’t be afraid to ask for help!

Learn more about Sophos Managed Detection and Response:
24/7 threat hunting, detection, and response  ▶

Short of time or expertise to take care of cybersecurity threat response? Worried that cybersecurity will end up distracting you from all the other things you need to do?