Vulnerabilities in Serv-U 11.1.0.3

2011-12-07T00:00:00
ID SECURITYVULNS:DOC:27416
Type securityvulns
Reporter Securityvulns
Modified 2011-12-07T00:00:00

Description

                         Luigi Auriemma

Application: Serv-U (FTP) http://www.serv-u.com Versions: <= 11.1.0.3 Platforms: Windows, Linux bug B should affect only some Windows versions Bugs: A] sockets and ports consumption B] possible access to the management console Exploitation: remote Date: 03 Dec 2011 Author: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org

1) Introduction 2) Bugs 3) The Code 4) Fix

=============== 1) Introduction ===============

From vendor's homepage: "Serv-U is a powerful, easy-to-use File Server that allows you to securely and efficiently share files across the Internet using 5 industry standard transfer protocols and by employing SSL encryption, powerful managment tools, and more."

======= 2) Bugs =======


A] sockets and ports consumption

The FTP protocol is divided in a main channel called "control" (the connection where are sent the commands) and various "data" channels where are transferred the files and the content of the directories.

For avoiding client-side problems with NAT and firewalls the FTP servers implement also a passive mode where they open one of their TCP ports for transferring the data. This action is available through the PASV and EPSV commands.

The problem in Serv-U is that it opens new ports for each request made by the client without closing the previous ones if unused, which means that two consecutive PASV commands will open two ports on the server and not only one like it should be. The ports opened by the server will remain open forever till the termination of the service.

The effect of this vulnerability is a Denial of Service since it's very quick and easy to saturate all the available sockets and relative ports making the server unavailable:

"425 Unable to set up passive listening socket." "425 Unable to set up extended passive listening socket."

Obviously also the management console will no longer work because it's socket based and so the only way to terminate these problems is stopping and restarting Serv-U manually.

No special privileges are required so even the anonymous account is ok if it's enabled.


B] possible access to the management console

The management console is nothing else than a web server running on localhost (127.0.0.1) on port 43958 with the access granted by the Session value located in the URL (Session plus LocalAdmin=1).

On Windows the Session 64bit value is calculated in this way: - Serv-U-Tray.exe stores the value 5 in a field of the shared memory (function 00406b30) - Serv-U.exe has a loop (10045614) which checks when this value has certain values, 5 in our case, and places the needed session value CRhinoAttr::m_NextID (101e3d60) in the memory through the CServer::GetLocalAdminParams function - this value is stored as current local session number

This number is based on the time elapsed from the starting of the process and incremented after some operations so there are some chances of guessing it in various ways.

The main requirement for testing the vulnerability is that a management console must be already active (LocalAdmin logged in) allowing to scan the session number sequentially till guessing it.

This is enough easy and fast for a local user who wants to escalate privileges because he can see from how many time the Serv-U process was active, and if "Use System Browser" is enabled the session number is visible even from the processes list because it's just the URL passed to the browser.

Instead for a remote attacker the situation is a bit more complex because it's not possible (as far as I know looking both the FTP and HTTP parts) to check from how many time the server is up and obviously he can't reach the localhost directly.

So for accomplishing our target we must send HTTP requests to 127.0.0.1 via the PORT or EPRT commands where is possible to choose an host (yes, 127.0.0.1 is allowed BUT read my final note) and a port (43958) where sending a file located on the same server, just like a classical FTP bounce attack but performed versus itself.

Note that it's necessary to have an account with write permissions for exploiting the vulnerability just because we must write the HTTP request in a file on our folder.

Basicly the attacker performs a loop where he: - builds the HTTP request which does the desired action using an incremental Session value - uploads the file containing this request on his remote folder where he has write access - uses "PORT 127,0,0,1,171,182" or "EPRT |1|127.0.0.1|43958" or "EPRT |2|::1|43958" - uses RETR for sending the uploaded file with the generated HTTP request to the management interface on 127.0.0.1:43958

Not a so quick job but at least it's not so impossible moreover considering that through bug A there is a chance to force the admin to restart the process resetting the counter and maybe forcing him to use the management console (required for the bug).

In case of success it's possible to do some things like creating a global user with full privileges with which is possible to take control of the system.

Important note: The vulnerability has been successfully tested on Windows XP and 2003 Server while on Windows 7 and 2008 (both 32 and 64bit) it did NOT allow the localhost connection returning a "Cannot open data connetion." error. So the possibility of connecting back to 127.0.0.1 is probably a compatibility issue which happens with the old Windows systems.

=========== 3) The Code ===========

A] http://aluigi.org/testz/ftpports.zip

B] http://aluigi.org/poc/servu_1b.zip

====== 4) Fix ======

No fix.


Luigi Auriemma http://aluigi.org