Multiple flaws in VHCS 2.x

Advisory Content :

-----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 (at)
rs-labs (dot) com [email concealed]>
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 (at) molesoftware (dot) com [email
concealed]> 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)

iD8DBQFD7lI85H+KferVZ0IRAhGWAKDV085cjHF+zT6uuzDNKgVHtzveLACgnUSL
/TvzZsIuvjsz5lb+69b7CC8=
=QqT6
-----END PGP SIGNATURE-----

Security

IT News

Search

SecurityAlert Database

About SecurityAlert

ExploitAlert Database

SecurityReason Research

WLB Database

Send to WLB

About WLB

Security Audit

Schedule

Prices of services

Contact

SecurityReason IT News

SecurityAlert

World Laboratory of Bugtraq

ExploitAlert

Apache

PHP

Contact

About SecurityReason