Re: Non-logged Brute Force Attack Vulnerability forFantastico-Created Databases on cPanel Based Hosts
It appears that on my cpanel testbed, 'show databases' privileges are
already revoked.
E.g:
root@<removed> [~]# mysql -u <removed> -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 264567 to server version: 4.0.18-standard
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> show databases;
Empty set (0.04 sec)
This server has several hundred databases on it, none are listed...
Executing this as root gives me a full listing however.
As per http://dev.mysql.com/doc/mysql/en/Show_database_info.html:
"As of MySQL 4.0.2, you will see only those databases for which you have
some kind of privilege, if you don't have the global SHOW DATABASES
privilege."
It appears my chmod solution does work.
NOTE to developers (both cpanel and fantastico):
I have released this information publicly instead of contacting you directly
and not releasing it as this is a immediate problem which can be fixed by
anyone with root ssh access by typing one command.
Also, this problem may be relevant to anyone running a webhosting box with
perl/php support and mysql.
Regards,
Michael Curtis
----- Original Message -----
From: "Kenneth Peiruza" <kenneth@xxxxxxxxxxxxxxxx>
To: "Michael Curtis" <email@xxxxxxxx>
Cc: <bugtraq@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 20, 2004 5:48 AM
Subject: Re: Non-logged Brute Force Attack Vulnerability
forFantastico-Created Databases on cPanel Based Hosts
>
> This method is cool but the solution proposed ( chmod 751
> /var/lib/mysql) has little or no effect 'cause you actually have a mysql
> login & password which can allow you to perform a "Show Databases" SQL
> query.
>
> Another choice is to activate "SQL safe mode" in php.ini, which would
> deny any kind of login attempt into any database, but Perl would still
> be an option :/
>
> The only way to completly close it at one point is to avoid listing the
> available databases at MySQL, but dunno how to do it!
>
> Cheers
>
>
>
> On dc, 2004-05-19 at 19:26, Michael Curtis wrote:
> > Advisory: cPanel/Fantastico/mysql local vulnerability
> > Date: 5/19/04
> > 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
> >
> > Background:
> > 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.
> >
> > Problem Description:
> > 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.
> >
> > Impact:
> > 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.
> >
> > Solution:
> > 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
> > attack.
> >
> >
> > Michael Curtis
> > HostSpace
> >
>
>