Vulnerabilities in Serv-U 11.1.0.3

2011-12-0700:00:00

vulners.com

JSON

#######################################################################

                         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: [email protected]
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.

#######################################################################