Honeypot for CVE-2020–0618 aka SQL Reporting Services vulnerability
Organizations can use so called Threat Intelligence feeds to purchase lists of IP addresses of potential malicious actors. Commercial parties like FireEye offer them at steep prices, but you could also look at freely available ones through for instance MISP.
These lists consist of millions of IP addresses where at one point in time it was assumed that an adversary was using time. However, often within 72 hours already, this IP address is no longer relevant because the criminal went on to use another IP address.
Due to the large amount of IP addresses it certainly feels like using a ‘hail cannon’ while at conferences such as BlackHat it is already proven that these feeds have less than 3% of usable information.
A better way to collect rogue IP addresses is to use Honeypots. Software that emulates a certain application and vulnerability, which then logs the IP address and the way he or she is trying to abuse the CVE.
By placing these Honeypots in strategic places in your network, you’ll achieve two things:
- Adversaries are trying to hack your honeypot instead of your production server. The honeypot won’t break, just log.
- The collected IP addresses and other information is relevant to your organization. You’ve proven that they are active and targeting your organization.
Wortell Enterprise Security just released a Honeypot for CVE-2020–0618, emulating a SQL Reporting Services server, and logging the source IP addresses and the payload being used.
Vulnerability
MDSec, an UK cybersecurity company, uncovered on Valentine Day 2020 that they had found a vulnerability in SQL Reporting Services.[1]
Because that had disclosed the information to Microsoft ahead of time, Microsoft was able to fix the vulnerability and release it as part of patch tuesday of February 2020.[2]
The only robust way to fix this vulnerability is to patch. The malicious requests containing a payload for unauthed RCE look a lot like regular HTTP requests, therefore a Web Application Firewall (WAF) and/or other network-based solution will likely not provide the right level of security.
After the malicious actors succesfully have abused the vulnerability, they can pretty much run any command on the server. For instance, open up a ‘reverse shell’, getting them access to the network from the outside.
[1] https://www.mdsec.co.uk/2020/02/cve-2020-0618-rce-in-sql-server-reporting-services-ssrs/
[2] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0618
Looking at the MITRE ATT&CK framework, this could be classified as T1190 and the Initial Access tactic.[3]
[3] https://attack.mitre.org/techniques/T1190/
Honeypot
Wortell Enterprise Security shared the code and instructions for their honeypot on Github.
PRO TIP: Wortell is sharing other great projects on its Github repo, such as the powershell module for Azure Sentinel: https://github.com/wortell/AZSentinel
The CVE-2020–0618 honeypot can be found here: https://github.com/wortell/cve-2020-0618
Linux or Docker
The honeypot is written in Go. The easiest way to run it is on a Linux-based OS (like a VM in Microsoft Azure, or on a Raspberry Pi). There is also a Dockerfile in the repository to build your own Docker image, and the Docker container can also be found on DockerHub.
On the Github page you’ll find instructions to generate a self-signed certificate. After that, the Honeypot will listen on ports 80 and 443.
If you visit the IP address of the Honeypot with a regular browser you’ll get a (fake) SQL Reporting Services page. If you try to target the IP address with the known vulnerability, the Honeypot will log your IP address, payload and other relevant information.
HTTP Request
If the malicious actor wants to abuse the vulnerability, they will need to create a specific HTTP request with the payload embedded. Here’s an example:
POST /ReportServer/pages/ReportViewer.aspx
Headers* Host: target* Content-Type: application/x-www-form-urlencoded* Content-Length: X
Body* NavigationCorrector$PageState=NeedsCorrection&NavigationCorrector$ViewState=[PayloadHere]&__VIEWSTATE=
Payload
The payload is base64 encoded and needs a specific contents. With the help of programs such as ysoserial.exe this contents can be created.
The base64 encoded payload will be written to the clipboard:
Simulating an attack
With help of a website such as https://reqbin.com you could tailor the HTTP request and send it to your Honeypot:
Logging
In the folder ‘logs’ you’ll find the honeypot logs. There is an allrequests.log that shows all traffic. And there is a cve.log where only the (potential) attacks are shown that are trying to abuse the vulnerability:
Here’s an example of a log entry from an attempt to use the CVE. You can clearly see the IP address and which payload is being used:
Hunting
If we want to understand what the contents of this payload is, we’ll need to decode it. Here’s decoding the base64 string using Cyberchef:
We find that they’re trying to use a PowerShell command, which is again base64 encoded. If we also decoded this string, we find the real commands:
Conclusion: somebody is trying to establish a reverse shell.
Microsoft Defender ATP
It’s good to know that these Base64 encoded commands and programs such as ysoserial.exe will be detected and blocked by Microsoft Defender ATP.
Is an adversary already present in your network and are they trying to abuse the vulnerability for ‘lateral movement’ then these signals will be shown in the Microsoft Defender ATP console:
Happy hunting!
— Maarten Goet, MVP & RD
