-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===============================
- RS-Labs Security Advisory -
===============================
Tittle: Multiple flaws in VHCS 2.x
ID: RS-2006-1
Severity: Critical
Date: 11.Feb.2006
Author: Román Medina-Heigl Hernández (a.k.a. RoMaNSoFt) <roman@rs-labs.com>
URL: http://www.rs-labs.com/adv/RS-Labs-Advisory-2006-1.txt
.: [ SUMMARY ]
With about 100.000 installs, VHCS (Virtual Hosting Control System) [1] 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.1). I reported the problem to Alexander Kotov (VHCS project leader,
hereinafter will be referred as "the vendor"), with cc to Full-Disclosure
mailing-list [2]. This is bug #1 and we will mark the related security patch
as "v.1". 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.1 and indeed they simply replaced the
old patch (v.1) 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 #3. I also noticed the same function continued being
buggy (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,
9th), let's call it v.3. It corrected bug #3 but not #4 (which is 0day at the
time of writing this advisory).
.: [ BUG #1 ]
Severity: High
Affected: 2.4.7.1 + patch v.1, 2.4.6.2 (and lower)
Fixed: 2.4.7.1 (optionally plus: patch v.2 or patch v.3)
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%61nge_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.1 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 #1
(for fun and profit).
.: [ BUG #3 ]
Severity: Critical
Affected: 2.4.7.1, 2.4.6.2 (and lower)
Fixed: Patch v.3
Summary: check_login() authentication bypass
The script "gui/include/login.php" contains the following function (2.4.7.1):
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:
http://www.rs-labs.com/exploitsntools/rs_vhcs_simple_poc.html [3]
The fix is to add an "exit();" sentence just after each header() line.
Patches v.1 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.3 is ok.
.: [ BUG #4 ]
Severity: High
Affected: All versions (tested on: 2.4.7.1 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:
1) 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 [3] 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 advisable 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.1 + Patch v.3.
- Have a good backup on hand because... you can still be hacked! ;-)
.: [ HISTORY ]
* 19/Jan/2006: - I discovered bug #1 on VHCS 2.4.6.2 while evaluating the
software.
- Asked for VHCS security contact.
- Alexander Kotov <alex@private> contacted.
* 20/Jan/2006: - I noticed the bug was fixed in 2.4.7.1 (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.1 was released.
* 07/Feb/2006: - I noticed the patch release and reviewed it.
- Bugs #1 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 buggy 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 #3 and #4. I also built the exploit for them [3].
* 11/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 ]
[1] VHCS site
http://www.vhcs.net/
[2] First post to Full-Disclosure demonstrating bugs #1 and #2
http://lists.grok.org.uk/pipermail/full-disclosure/2006-February/041957.html
[3] Simple VHCS exploit for bugs #3 and #4
http://www.rs-labs.com/exploitsntools/rs_vhcs_simple_poc.html
[4] Funny thread showing security by obscurity position of VHCS vendor
http://vhcs.net/new/modules/newbb/viewtopic.php?topic_id=4801&forum=1
[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=-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
iD8DBQFD7oQI5H+KferVZ0IRAtY2AKCk++08ILjoLagGUKzU+QSPPPFfOwCfYUHM
5U7wIaUMr/3hPtm0ocp21zs=
=KT6T
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2.1.3 : Sat Feb 11 2006 - 20:27:59 PST