On July 5, after an initial investigation of affected organizations, Truesec contacted Kaseya and provided a detailed technical write-up of these vulnerabilities along with forensic evidence of exploitation. Kaseya released the patch 9.5.7a (9.5.7.2994) that addresses the security issues on July 11.
We strongly believe this information will help the security community in their response to the attack and from a larger perspective it will help the industry understand what happened so we can address the underlying issues, and ultimately increase our capabilities to prevent future breaches.
Overview
The exploit abused four vulnerabilities in the Kaseya application that were chained as visualized in the figure below.
The High-Level Steps of the Exploit
- Obtained an authenticated session by abusing a flaw in the authentication logic [CWE-304] in /dl.asp.
- Uploaded the revil ransomware (agent.crt) through an unrestricted upload vulnerability [CWE-434] while also bypassing the request forgery protection [CWE-352] in /cgi-bin/KUpload.dll.
- Uploaded the ASP payload (screenshot.jpg) in the same fashion as described in 2.
- Invoked the payload in screenshot.jpg through a local code injection vulnerability [CWE-94] in userFilterTableRpt.asp.
- Created Kaseya procedures to copy files and execute the ransomware.
- Executed the procedures.
- Removed logs and other forensic evidence.
Here we will focus on the exploit and describe steps 1 through 4 in detail.
The payloads are not in scope for this article.
Step 1 – Bypassing Authentication [CWE-304]
The threat actor first sent a POST request to the resource /dl.asp with the POST data userAgentGuid=guid.
In dl.asp, userAgentGuid is used in a SELECT query to lookup the database row of the agent. The agentGuid must exist due to the subsequent if statement. The threat actor used the agentGuid of the agent on the VSA server itself (more on this below).
After the lookup, dl.asp tries to see if the provided password matches the values stored in the database for that agent. The provided password is then compared in several different ways. The login flow is illustrated in the pseudo code below:
if password == hash(row[nextAgentPassword] + row[agentGuidStr])
login ok
elseif password == hash(row[curAgentPassword] + row[agentGuidStr])
login ok
elseif password == hash(row[nextAgentPassword] + row[displayName])
login ok
elseif password == hash(row[curAgentPassword] + row[displayName])
login ok
elseif password == row[password]
login failed
else
login ok
The last two statements are where the interesting thing happens. In case the password equals row[password] the login will fail. However, in the case that all checks failed, it would default to an else clause that sets “loginOK” to true.
Because no password was provided in the request, the “password” variable would be NULL and loginOK would end up being true. When loginOK is set to true, the application sends the login session cookie and will eventually (if no other parameters are provided like in the attacker’s request) end up in an if clause that returns 302 redirect to the userPortal.
How Did the Actor Obtain the AgentGuid?
The outstanding question is how the threat actor obtained around 60 (estimated number of VSA victims) unique valid agentGuids. It appears they simply knew the agentGuids before launching the attack.
Truesec has discovered several methods the attack could have been performed without prior knowledge of a valid agentGuid. An example that was also fixed in 9.5.7a is that the userAgentGuid parameter could have been <vsa_server_hostname>.root.kserver instead of an actual agentGuid. Due to what was described as legacy code, in case agentGuid is not a number, it will lookup the agentGuid automatically from the table machNameTab.
Truesec has not found and is not aware of any public evidence that shows exactly how these agentGuids were obtained. Possibly, these random agentGuids might have been what limited the impact of the attack to under 60 out of around 35 000 Kaseya VSA customers.
Steps 2 and 3 – Uploading Files [CWE-434] [CWE-352]
All requests from this point on used the authenticated session obtained in step one.
The threat actor started the upload by sending a GET request to /done.asp without any parameters. When receiving the request, the application creates a row in the tempData table, stages an upload folder, and finally returns a so-called loadKey value. A valid loadkey is required to perform the file upload.
To upload files the threat actor sent a multiform-data POST request to the resource /cgi-bin/KUpload.dll. The request contained the following parameters:
- FileName (name of the file)
- FileData (content of the file to upload)
- LoadKey (the value obtained by GETting done.asp)
- RedirectPath (path that the application will redirect to after successful upload)
- PathData (folder the file will be saved in)
- __RequestValidationToken (bypassable CSRF token)
Bypassing the CSRF Protection
The __RequestValidationToken was not properly validated. For example, the value “xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx” was accepted as a valid token.
Uploading the Ransomware (Agent.crt)
The first upload performed by the threat actor was a file named agent.crt. This file was an encoded version of the ransomware that was later pushed to all agents from the compromised VSA server.
Upon successful upload, the server returns HTTP 200 OK with a body containing a link pointing to /<redirectPath>?FileName=<filename>&PathData=<relative path>&originalName=<filename>&FileSize=<size>&TimeElapsed=<time>.
In this case, as the file upload was successful, the returned link was /done.asp?FileName=agent.crt&PathData=WebPagesManagedFilesVSATicketFiles&originalName=agent.crt&FileSize=1221630&TimeElapsed=00:00:00.828
Uploading the ASP Payload (Screenshot.jpg)
The threat actor uploaded another file named Screenshot.jpg. This was not a jpg file but rather a text file containing ASP code. After obtaining another loadKey value from /done.asp the threat actor uploaded the file. Partial contents of the request can be seen in the figure below (unfortunately only a partial capture was obtained and the middle part of screenshot.jpg was missing).
The response body link in this case was /done.asp?FileName=Screenshot.jpg&PathData=WebPagesManagedFilesVSATicketFiles&originalName=Screenshot.jpg&FileSize=6188&TimeElapsed=00:00:00.016 which indicates that the file was successfully uploaded.
Step 4 – Executing the Payload on the Server [CWE-94]
Finally, the threat actor sent a POST request to /userFilterTableRpt.asp with the pageFilterSQLFile argument.
Due to a flaw in userFilterTableRpt.asp, the contents of the specified file would be interpreted as ASP code as it was passed to the function eval. In this case, ManagedFiles/VSATicketFiles/Screenshot.jpg, the ASP code text file the threat actor just uploaded.
First, userFilterTableRpt.asp sets a variable from the POST parameter. Then it reads the contents of the specified file and passes it to eval, which will by definition interpret the value of the argument as code. The flow is illustrated in the pseudo code below:
f = open (pageFilterSQLFile)
c = read (f)
eval (c)
And that is it. The ASP payload was executed and started pushing out the ransomware, and we all know the story from there.
Final Words
After a patch has been made available to customers of Kaseya VSA, and after we have validated the patch to verify that the attack vector is no longer present, we believe it is time to share these details for the benefit of the community.
We strongly believe this information will help the security community in their response to the attack and from a larger perspective it will help the industry understand what happened so we can address the underlying issues, and ultimately increase our capabilities to prevent future breaches.
Finally, a big thanks to everyone in the security community who shared their findings throughout this incident. We truly appreciate the collaborative spirit that ultimately benefits everyone.
Timeline
[2021-07-02] Threat actor exploited vulnerabilities in the wild to mass-deploy ransomware.
[2021-07-04] Truesec obtained evidence that was helpful to understand the exploit.
[2021-07-05] Truesec sent a detailed write-up of the vulnerabilities along with supporting forensic evidence to Kaseya.
[2021-07-11] Kaseya released a security patch.
[2021-07-12] Truesec validated the patch.
[2021-07-13] Truesec published this article.