-----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: Romn Medina-Heigl Hernndez (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-----