Results 1 to 1 of 1
  1. #1
    Join Date
    Sep 2003
    Location
    Canton, NY
    Posts
    214

    Exclamation Non-logged Brute Force Attack Vulnerability for Fantastico-Created Databases

    For those of you not subscribed to BugTRAQ, here's a message which I submitted earlier today. I also posted it on the cpanel forums and it was swiftly deleted by their moderators and I was sent a abrupt email which I have attached at the end of this post.
    This has been sent to the fantastico developers.

    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.


    Email received from <email removed>:
    Your post on our forums about a vulnerability in Fantastico would be
    better suited as a vulnerability report to the Fantastico producers. You
    can contact them at any of the addresses here:
    http://www.cpanelthemes.com/contact.php

    --
    Joshua P Shaffer
    Technical Liaison, cPanel Inc
    <email removed>
    (570) 443-7700
    Last edited by alpha; 04-01-2005 at 08:05 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •