MoveIT Explained - For the Non-Technical Reader

There has been a lot of activity in the media lately about the MoveIT vulnerability. While this information and reporting has been accurate and valuable, I think needs a bit more of an explanation for non-technical audience members to help them understand what it is, how it’s being exploited and how these sorts of attacks really work.

Some background information

MOVEit Transfer Critical Vulnerability (May 2023) (CVE-2023-34362) - Progress Community --> Explains the vulnerability.

Breach Roundup: More MOVEit Victims, Including US Government (databreachtoday.com) --> Explains second vulnerability.

MOVEit Transfer Critical Vulnerability (May 2023) (CVE-2023-34362) - Progress Community --> Disclosure by the vendor.

A vulnerability in MOVEit Transfer Could Allow for Elevated Privileges and Unauthorized Access (cisecurity.org) --> Center for Information Security (CIS) advisory

National Vulnerability Database (NVD) entry NVD - CVE-2023-35708 (nist.gov) – CVE (stands for Common Vulnerabilities and Exposure – the database used to be called CVE, before NIST took it over). --> Provides a common framework for vulnerability identification and tracking.

What is a vulnerability?

              A vulnerability (or a vuln if you want to sound cool) is an error in the code or logic of a program that allows someone to do something that the developers never intended. Some vulns are very simple to identify and exploit, while others are more difficult. The easier ones are typically exploited by less skilled attackers or automation, while the more difficult ones are exploited by skilled attackers, organized cybercriminals or hostile nation state actors.

When vulns are identified, either by the software company themselves, by bug bounties (think the Dog the Bounty Hunter but for vulns), or by an attacker or researcher in what is known as a 0-day (zero day or Oh-day – it just means a previously unidentified vuln), the software vendors are notified and the vulnerability is patched (meaning the code of logic error has been fixed), and the vuln is considered “remediated” or fixed. This is why patch management programs are so important to an organization’s security posture. Without patching, an organization could be susceptible to an attack leveraging a known and remediated vuln.

Vulns are typically human errors that are introduced by the way different aspects code interact with themselves and each other. For example, Microsoft Windows 11 may not be vulnerable to a SQL Injection attack, but if it interacts with a vulnerable version of WordPress, then the third party application will introduce that vuln in to the environment.  

              How many of these vulnerabilities actually exist? Well, in his book Code Complete (quoting from the 2nd Edition), in the chapter "Developer Testing," Steve McConnell cites a handful of studies across a variety of languages: Industry average experience is about 1-25 errors per 1000 lines of code for delivered software.

              To illustrate an example, here are how many lines of code are in the different releases of Microsoft Windows:

              The number of lines of code in Windows operating systems are as follows:

·       Windows NT 4.0 (checked in 1996) – 16 million lines of code

·       Windows 2000 (2000) – 29 million

·       Windows XP (2001) – 35 million

·       Windows Vista (2007) – 45 million

·       Windows 7 (2009) – 42 million

·       Windows 8 (2012) – 50 million

·       Windows 10 (2015) – 55 million

Do the math…that’s a LOT of vulnerabilities! And, since code is constantly being generated by software companies, new vulnerabilities are introduced at a steady clip.

What is SQL Injection?

The MoveIT web transfer application is susceptible to something called a SQL (See-Quel), or Structured Query Language Injection. SQL Injections are a specific type of attack where an attacker takes advantage of something called “improper input validation”, on a webserver, to perform commands. 

Think of a checkout page for an online merchant. Say you are buying a super sweet Kirk Hammett Signature Baby Wah Pedal so that you can play Enter Sandman like the master and make it sound awesome. You put the pedal in your cart and click the “Check Out Now” button. The checkout page asks for your name, shipping address, credit card number, expiration date, CVV, zip code, phone number and email address – all pretty typical for an online purchase. A standard shopper would just type in the information that’s being requested and expect to complete their purchase (that’s doing what the developers had in mind when they coded the checkout page). A hacker or researcher looking for vulnerabilities would try to put something else in those fields (like 'or 1=1) and see how the webserver responds (to something the developers never intended to process as input). If the page is not performing proper input validation (meaning performing some sort of check to ensure that an address is actually alpha-numeric characters with a limit of say 50 characters or that a US phone number just 10 numbers with some parentheses and a couple of dashes), literally anything can be entered, and the webserver will interpret the whatever that input may be.

This is how the MoveIT vulnerability was likely identified – someone was messing around with the web interface (either manually or programmatically) and saw that it was not performing proper input validation by returning something other than an input error (or nothing) when a SQL string was entered into one of the free form fields. Once they saw that the web interface was accepting SQL strings as input, it was only a matter of time until the target was successfully exploited.

              Having a vulnerable system is not the entirety of what is required for a successful exploitation. It may allow an attacker to compromise (or gain access to) a target, but the attackers still need their bag of tools (so they will need the ability to upload files) to enable them to do things like elevate privileges, execute programs, scan and traverse the network, and harvest and export data. In the MoveIT attacks by the Cl0p cybercrime gang, are leveraging something called remote file inclusion (RFI) to get some variant of a web shell (likely one called LEMURLOOT) onto the target.

What is Remote File Inclusion?

              Remote file inclusion (RFI) basically tells a system where to go and get a dynamic file which can be located locally or remotely. For example, an image file on a web page may be remotely located on another system. If an attacker can modify the request for the remote file, they can point that request to a system they control that contains a file they want to upload. So instead of loading an image, the webserver loads the remote file (which is likely a web shell). This is common for dynamic content that changes regularly (think betting odds, or stock process). Similar to RFI, local file inclusion (LFI) is a vector that involves uploading malicious files to servers via web browsers that is local to that system. The two vectors are often referenced together in the context of file inclusion attacks. In both cases, a successful attack results in malware being uploaded to the targeted server.

What is a Web Shell?

              A web shell is a web-based shell (hence the name). It is a particular variant of malware that provides a web interface to a target system, and runs with the same privileges as the web service. There are heaps of different types of web shells – here are some screenshots to show you what they look like:

These web shells show directory structure, allow users to upload and download files, create files, delete files, traverse directories and more. Some of the more advanced ones have a “nuke” option that allows the user to remove the web shell as well as any evidence of its existence from the logs. Once on a target, they provide attackers with a clean and easy way to execute commands without needing additional credentials or remote access capabilities.

Who is being impacted? --> Ransomware gang lists first victims of MOVEit mass-hacks, including US banks and universities | TechCrunch

Cl0p has also begun posting another tranche of victims today.  

·       1st Source – Financial Services, U.S.

·       First National Bank – Financial Services, U.S.

·       Putnam Investments – Financial Services, U.S.

·       Landal Greenparks – Hospitality, Netherlands

·       Shell – Energy, U.K.

·       Datasite – Technology, U.S.

·       National Student Clearinghouse – Education/Nonprofit, U.S.

·       United Healthcare Student Resources – Insurance, U.S.

·       Leggett & Platt – Manufacturing, U.S.

·       OKK – Insurance, Switzerland

·       University System of Georgia – Education, U.S. (confirmed)

·       Heidelberg – Engineering, Germany (confirmed)

·       John Hopkins University – Education (confirmed)

Many more will likely be announced in the coming days.

ANY company that is running MoveIT is susceptible and needs to ensure that they are running the latest, patched version. If you run MoveIT, I also recommend a threat hunt or compromise assessment to check for the presence of a web shell (unlike Ransomware, the attackers are trying to remain hidden and most shells are typically difficult to detect), or SQL injection. Please note that running an AV scan will likely be insufficient for detection. The bad guys have access to AV applications as well, and regularly change the signature of their code in an effort to avoid detection. The only way you can really be sure you have not been compromised is to have a professional perform an assessment. 

I hope you found this helpful. Please note that this post was meant to be high level, and provide additional detail for a non-technical audience. There are terms and concepts that I intentionally simplified or omitted in an effort to make the subject matter relevant to the largest number of readers.