Non-logged Brute Force Attack Vulnerability for Fantastico-Created Databases on cPanel Based Hosts
From: Michael Curtis (email_at_curto.us)
To: <firstname.lastname@example.org> Date: Wed, 19 May 2004 13:26:08 -0400
Advisory: cPanel/Fantastico/mysql local vulnerability
By: Michael Curtis (email [at] curto [dot] us)
System: Redhat Enterprise 3 ES / cPanel 9.3.0-R5 (most likely all redhat
versions with all cpanel versions)
Severity: High, full compromise of local databases, password retrieval
cPanel is one of the leading and most feature filled scripted webhosting
systems for Linux and bsd platforms. It is a add on installed on top of a
existing operating system installation which adds multiple features for
management and use of webhosting/email/ftp/database accounts.
Fantastico is a add on for cPanel to automate installation of website
scripts such as Invision Power Board, PHP-Nuke, OS Commerce, CubeCart and
phpCOIN to name just a few.
Due to relaxed logging, insecure chmod permissions on /var/lib/mysql and
predictable usernames for mysql databases it is possible for a malicious
user (with a existing account) to upload a php or Perl script which can be
used to enact a brute force attack on mysql databases on the server.
Full compromise of all databases on server (with time), may lead to
deduction of passwords for other accounts.
Theoretical Proof of Concept:
All users have read access to the directory /var/lib/mysql which contains
folders with the same names as databases hosted on the server. At this point
a brute force attack could be staged, but the username is not necessarily
the same as the database name.
However, when databases are created through fantastico... the database name
and username ARE the same.
E.g. When you install invision board (first install) it creates both a
database and username in the format [username]_ibrd1
The optimal form of attack would be to target the fantastico created
databases as the username can be determined from the database name. A script
could easily ls/grep/sed this list from /var/lib/mysql. Then it would merely
be a case of a standard brute force attack against those databases using
those usernames. The attack could be dictionary based or sequential.
As there is no logging of incorrect mysql logins (AFAIK) this could not be
detected other than the massive load it would generate. On a host without
suexec/phpsuexec this load would not be traceable (other than the
apache-status page, but the url can be obfuscated by using ~username
somewhat). Also, the bandwidth generated between mysql and apache is not
logged or measured.
Due to the ease of exploit of this vulnerability no proof of concept code
will be released.
On our test bed (Redhat Enterprise 3 ES / cPanel 9.3.0-R5) /var/lib/mysql is
owned by mysql.mysql but is chmod 755. By simply changing that to 751 the
directory listing is disabled and all databases continue to work.
There are still other ways for users to obtain listings of usernames, but at
least this blocks the database names making it a little more difficult to