file access
+ Reply to Thread
Results 1 to 6 of 6

Thread: VHCS exploit - create a full admin acount on a site running vhcs

  1. #1
    Join Date
    Sep 2005
    Posts
    2,050

    VHCS exploit - create a full admin acount on a site running vhcs

    A new exploit from vulnwatch has arrived overnight in my inbox, it is for the popular web hosting management tool vhcs, Virtual Control Hosting System. This exploit is particularly good because it gives you the ability to create a full ADMIN account on any server running the vulnerable vhcs software, which ATM is ALL THE VERSIONS. This would allow full control of the server, and all subdomains etc that are hosted on it, this kind of control could lead to phishing attacks (redirect traffic to spoof site still keeping the url the same), stealing *****, accounts, defacing sites, basically you can do what you want with this sort of control, the news stories of people hacking into major websites is usually done through exploits like this. The full email is in next post:

  2. #2
    Join Date
    Sep 2005
    Posts
    2,050

    next post

    --------------------------------------------------------------------

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA*


    ===============================
    - RS-Labs Security Advisory -
    ===============================

    Tittle: Multiple flaws in VHCS 2.x
    ID: RS-2006-*
    Severity: Critical
    Date: **.Feb.2006
    Author: Román Medina-Heigl Hernández (a.k.a. RoMaNSoFt) <roman@rs-labs.com>
    URL: [url]http://www.rs-labs.com/adv/RS-Labs-Advisory-2006-*.txt[/url]



    .: [ SUMMARY ]

    With about *00.000 installs, VHCS (Virtual Hosting Control System) [*] is
    perhaps the best known professional control panel software being open source
    and an excelent choice for shared, reseller, virtual and dedicated server
    management.

    VHCS team recently released a security patch (dated on Feb, 5th). As I was
    evaluating that software (mainly from a functional perspective) and I care
    about security I decided to download it and have a look at it. Soon I realized
    that the patch was flawed: it was indeed adding a big XSS [5] security hole (by
    removing specific XSS protection which existed in latest VHCS version -
    2.4.7.*). I reported the problem to Alexander Kotov (VHCS project leader,
    hereinafter will be referred as "the vendor"), with ** to Full-Disclosure
    mailing-list [2]. This is bug #* and we will mark the related security patch
    as "v.*". As a bonus, I also reported another bug: #2.

    The vendor issued a new security patch (a.k.a. "v.2"), correcting the XSS
    problems, and refused to explain what the real bug supposedly being fixed was,
    either publicly neither privately. Moreover, they didn't inform its own users
    of the problems with security patch v.* and indeed they simply replaced the
    old patch (v.*) with the new one (v.2), without changing filename nor issuing
    any kind of warning. I'm differentiating them here by adding the "v.#" suffix.

    I quickly researched the new patch. It only introduced one line of code into
    check_login() function. I found a critical bug being partially fixed here.
    Let's name it as bug #*. I also noticed the same function continued being
    b***y (before or after applying patch v.2) and while testing former bugs I
    discovered a new bug (#4). Finally vendor issued a third patch (dated on Feb,
    *th), let's call it v.*. It corrected bug #* but not #4 (which is 0day at the
    time of writing this advisory).



    .: [ BUG #* ]

    Severity: High
    Affected: 2.4.7.* + patch v.*, 2.4.6.2 (and lower)
    Fixed: 2.4.7.* (optionally plus: patch v.2 or patch v.*)
    Summary: "Admin Log" XSS

    VHCS has three different access level interfaces: administrator, reseller
    and domain user. The administrator interface is the more powerful and permits
    full control over the system. One of the tasks of a VHCS administrator is
    reviewing logs and this functionality is integrated on the admin interface.
    You can reach it by logging with an admin account and then clicking: System
    Tools -> Admin log. This dynamic page (and the rest of the GUI) is written in
    PHP. Basically, what it will do is to read logs from MySQL database (in parti-
    cular, table "log" from "vhcs2" database, by default), perform some kind of
    simple parsing (for instance, adding bold style to certain special words) and
    finally print them to the GUI.

    VHCS registers several events in logs, including bad login attempts. In this
    case, a simple entry like this is generated: "john bad password login data".
    As you probably noted, "john" is the username trying to log in. The problem is
    that VHCS takes this username directly from the login page, without any fil-
    tering. So some evil attacker could enter whatever he/she wants -including
    HTML and/or JavaScript code- as username and it will be logged. Next time when
    the VHCS administrator reviews logs using GUI's "Admin log" page, that code
    will be executed in the context of VHCS Admin GUI. This is doubly dangerous:
    the attacker owns victim's browser (which could be used as a new attack vector
    to other known vulnerabilities such as Windows' WMF bug, Internet Explorer or
    Firefox vulns, etc) and he/she also owns VHCS GUI with admin privileges.

    For instance, you can exploit this bug by entering the following string as
    the username in VHCS login page:

    </form><form name="dsr" method="post" action="ch%6*nge_password.php"><input
    name="pass" value="hackme"><input name="pass_rep" value="hackme"><input
    name="uaction" value="updt_pass"></form><script>document.dsr.submit()</script>

    When the administrator reviews the logs, his/her password will be automati-
    cally changed to "hackme".



    .: [ BUG #2 ]

    Severity: Low
    Affected: All versions (tested on: 2.4.7.* w/ or wo/ any patch, 2.4.6.2)
    Fixed: None
    Summary: Weak change password mechanism

    The script "admin/change_password.php" allows to change password without
    asking for the old password. This "feature" was used at exploiting bug #*
    (for fun and profit).



    .: [ BUG #* ]

    Severity: Critical
    Affected: 2.4.7.*, 2.4.6.2 (and lower)
    Fixed: Patch v.*
    Summary: check_login() authentication bypass

    The script "gui/include/login.php" contains the following function (2.4.7.*):

    function check_login () {
    if (isset($_SESSION['user_logged'])) {
    if (!check_user_login($_SESSION['user_logged'], $_SESSION['user_type'],
    $_SESSION['user_id'])) {
    header("Location: ../index.php");
    }
    } else {
    header("Location: ../index.php");
    }
    }

    This function is called from other PHP scripts to perform authentication.
    If the user is authenticated (a valid session should exist containing the
    "user_logged" variable), check_login() function returns without errors (so the
    calling PHP script could continue with its execution). If there is any error,
    the function redirects the browser to the index page. The HTTP redirection is
    implemented via header() PHP function, which sets the appropiate HTTP header
    (Location). But the problem is that the execution flow is not interrumpted, so
    check_login() returns in all cases and the calling script will be completely
    run. When the script finalizes its execution, the browser will jump to login
    page, but it is late: the calling script has already been executed! So we can
    execute every PHP script in VHCS, ever being an unauthenticated user :-) Nasty.
    Some scripts use variables from the PHP session and they may fail (since the
    session is not defined, remember we did not authenticate ourselves). But some
    other could be successfully exploited. For instance, you can take over the
    whole VHCS system by adding a new admin user (abusing "admin/add_user.php"
    script). This is what my simple exploit does.

    The exploit is very basic. See it online:
    [URL REMOVED BY MIKE*0*, PM ME AND I WILL GIVE YOU IT] [*]

    The fix is to add an "exit();" sentence just after each header() line.
    Patches v.* and v.2 did something equivalent (they added "die();") but they
    only fixed the second header() sentence, which was the more dangerous one,
    but still not sufficient to completely fix the bug. Patch v.* is ok.

    -------------------------------------------------------------------

    Ok, the rest of the email is in next post:

  3. #3
    Join Date
    Sep 2005
    Posts
    2,050

    *rd post

    .: [ BUG #4 ]

    Severity: High
    Affected: All versions (tested on: 2.4.7.* w/ or wo/ any patch, 2.4.6.2)
    Fixed: None (0day)
    Summary: Privilege escalation in "admin/add_user.php"

    The script used for adding a new admin user doesn't check whether the logged
    user has the right privileges. Any authenticated user can run this script so
    it may be used to escalate privileges. In other words, a plain domain user
    (which is the VHCS user with lower privileges) could create a new admin user
    (which has full control of VHCS system). The steps are easy:
    *) Log in VHCS as domain user (so you get the right cookie credentials).
    2) Using the same browser window (or any other method to preserve VHCS
    cookie), launch my online exploit (simply replace VHCS URL by the one
    given at [*] and hit enter key :-))

    There is no fix for this vulnerability. Why didn't I reported this bug to
    vendor? Because it demonstrated not to care about security neither having the
    minimum respect to security people like me or even its own users! (see [4] for
    an example of that; also check the "History" section in this advisory).



    .: [ RECOMMENDATIONS ]

    I would NOT recommend VHCS for production environments from a security pers-
    pective. That's why:

    - VHCS is a nice choice if we only attend to its functions but it urgently
    needs a deep security review (please note that I only had a look to very
    few lines of VHCS code... and I found several security issues! VHCS should
    be fully audited).
    - VHCS vendor should reconsider its position regarding security. This implies:

    + Do NOT trust security by obscurity. Do NOT understimate hackers.
    + Always inform your users of new security bugs/patches, stating the risk or
    possible impact, so the user could evaluate the situation and choose to
    apply (or not) the security patch (it is usually a good idea to apply any
    security patch but this is not always possible in production environments,
    can influence any SLA, etc).
    + Always have a security contact, clearly identified in your web page. It is
    also a good idea to have a security section where the vendor clearly states
    and warns about known security issues, advisories, etc.
    + Always have an announce mailing-list where you can inform your users of
    security issues (and other important events, new releases, etc).
    + It is ad****ble to monitorize security mailing-lists such as "Bugtraq" or
    "Full-Disclosure" ;-)
    + Do NOT insult security researchers when they report bugs to you, even if
    they decided to go public at the same time (I hope you have learned the
    lesson, Alex :-)). Instead of that, you should *thank* them, as they are
    working free for you (come on, Alex, it's not so difficult!).
    + Be humble and recognize your own errors (guess it? yeah, this is also for
    you, dear Alex).

    Anyway, if you want to use VHCS, despite my previous comments, take extra
    security measures such as:
    - Protect the whole "/vhcs2/" tree using HTTP Auth (so "strangers" could not
    abuse known or unknown bugs).
    - Only give VHCS accounts to trusted users.
    - Enhance the security of your web server with solutions like Mod-Security [6].
    - Don't forget to update VHCS to 2.4.7.* + Patch v.*.
    - Have a good backup on hand because... you can still be hacked! ;-)



    .: [ HISTORY ]

    * **/Jan/2006: - I discovered bug #* on VHCS 2.4.6.2 while evaluating the
    software.
    - Asked for VHCS security contact.
    - Alexander Kotov <alex@molesoftware.com> contacted.

    * 20/Jan/2006: - I noticed the bug was fixed in 2.4.7.* (although it was hard
    to detect because vendor -one more time- did not clearly
    announce it on its main page).

    * 05/Feb/2006: - VHCS security patch v.* was released.

    * 07/Feb/2006: - I noticed the patch release and reviewed it.
    - Bugs #* and #2 reported to vendor. At the same time, public
    disclosure (because the impact was *minimum*: affected users
    were indeed only the people who installed the b***y security
    patch; furthermore, to be "infected" they first should have
    noticed the patch release and have time to install it. First
    condition is difficult to comply with, given that vendor
    doesn't have any announce mailing-list).
    - Vendor got angry due to public disclosure (it breaks its
    security-by-obscurity policy) and refused to give any detail
    to public mailing-lists neither privately to me.
    - Moreover, vendor began insulting me and other VHCS users who
    asked for clarifications about the security patch.
    - I decided not to talk to that vendor anymore. This includes
    stopping the reporting of security bugs to them. This advi-
    sory will NOT be the exception.

    * 08/Feb/2006: - I found bugs #* and #4. I also built the exploit for them [*].

    * **/Feb/2006: - Advisory released.



    .: [ ACKNOWLEDGEMENTS ]

    Greetings to !dSR [8] ppl for its moral support and funny c0ns. Thanks, guys!

    Lastly, thanks also to Alexander Kotov -the project manager of VHCS- for his
    cooperation and attention payed to this advisory. Ummm, of course I was joking!



    .: [ REFERENCES ]

    [*] VHCS site
    [url]http://www.vhcs.net/[/url]

    [2] First post to Full-Disclosure demonstrating bugs #* and #2
    [url]http://lists.grok.org.uk/pipermail/full-disclosure/2006-February/04**57.html[/url]

    [*] Simple VHCS exploit for bugs #* and #4
    [URL REMOVED BY MIKE*0*, PM ME AND I WILL GIVE YOU IT]

    [4] Funny thread showing security by obscurity position of VHCS vendor
    http://vhcs.net/new/modules/newbb/viewtopic.php?topic_id=480*&forum=*

    [5] Cgisecurity. "The Cross Site Scripting FAQ"
    http://www.cgisecurity.com/articles/xss-faq.shtml

    [6] ModSecurity (Open source web application firewall)
    http://www.modsecurity.org/

    [7] RoMaNSoFt's Research Labs
    http://www.rs-labs.com/

    [8] Digital Security Research - !dSR
    http://www.digitalsec.net/

    -=EOF=-
    --------------------------------------------------------------------

    Continued in next post
    Last edited by Ezekiel; 02-12-2006 at 05:41 AM.

  4. #4
    Join Date
    Sep 2005
    Posts
    2,050

    Final post

    The thing that makes this exploit even more dangerous is the fact that it hasn't been reported, and could last a long time. All you have to do is google for virtual control hosting system and then find a suitable admin login page (not hard) then use the page that was linked to in the message to send the exploit code, then you're in, full admin control over a server. To at least prevent most of the n00bs from following this, I am not writing a tutorial on how to use this, but anyone who can read really should be able to follow that. I might edit out the links to proof of concept page which performs the hack. There are also a few other vulnerabilities shown in this, some as severe as the admin creation exploit. I have just briefly tested this on one server, I think from poland (.pl), it is here:

    [url]http://www.venturi.com.pl[/url]

    I now have total admin control of that site, I could remove it if I wanted, but I am going to do that, only n00bs would just destroy a site. Actually, I am going to edit out the link to proof of concept page. This page makes it so simple to hack a site, all you have to do is fill in the url and it creates a full admin account, you then log in with that and can do what you want with the site. So PM me if you want the link to that site, then I will give it to you, this is just to stop this spreading to every n00b reading this. For anyone who didn't read through all those posts above, this is an exploit for sites running vhcs, which allows you to have total admin control (create an admin account) over the site and any other sites hosted there by simply going to a page, here:

    [LINK REMOVED MY MIKE*0*, PM ME AND I WILL GIVE YOU IT]

    And then fill in the username you want, then it will create an admin account for you. Currently, the site that does this for you forces you to use the password dsrrocks and fills in your email as [email]vhcs-exploit@rs-labs.com[/email], but I am editing the source of the page so the password and email are just random numbers, so they will not discover this exploit. Or, go on undernet on irc and join this channel within * hours of me posting this:

    #allnettoolsforum

    And I will give the link to the PoC exploit. I will give the link to the first 5 to pm me, and the first 5 on the irc channel to prevent every single server vulnerable to this from being hacked. Just by randomly testing this on the first vhcs target I chose from google, I now have control of 6 domains from hacking one vhcs password, all these:

    agromis.pl
    rolpap.pl
    kateso.pl
    peplinski-rolpap.com.pl
    venturi.com.pl
    lampionex.com.pl

    I am probably now going to delete the admin account I created, and delete all the admin logs, but this proves how powerful the exploit is, over *00,000 servers run vhcs.
    Last edited by Ezekiel; 02-12-2006 at 06:19 AM.

  5. #5
    Join Date
    Sep 2005
    Posts
    2,050

    vhcs

    I just want to remind everyone that you should use a proxy when doing stuff like this (use tor), I forgot to use a proxy when testing it out on that polish site, but I haven't actually done anything, if you start defacing sites without covering your *****s, expect to get caught.

  6. #6
    Join Date
    Sep 2005
    Posts
    2,050

    tor

    Download tor from:

    [url]http://tor.eff.org/[/url]

    It's better than any proxy you will find, it uses encryption, is fast, easy to set up and all you have to do is set your browser to use it as a proxy then you are almost totally anonymous for any things you want to do that are not legal.

+ Reply to Thread

Similar Threads

  1. how do you hack a aol acount...or get there password?
    By Edward in forum Internet Privacy
    Replies: 2
    Last Post: 01-31-2007, 01:40 AM
  2. Running on startup no longer works!
    By Goldenclaw in forum Internet Privacy
    Replies: 2
    Last Post: 08-17-2006, 06:42 PM
  3. Help getting admin pass to a site
    By Cyrenius in forum Internet Privacy
    Replies: 4
    Last Post: 03-09-2006, 11:27 AM

Posting Permissions

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