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:

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

-----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:

.: [ 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
[B][URL REMOVED BY MIKE*0*, PM ME AND I WILL GIVE YOU IT][/B]

[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

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:

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

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.

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.

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.