[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 10 Oct 2011 23:58:43 +0300
From: "MustLive" <mustlive@...security.com.ua>
To: "Petr Lautrbach" <plautrba@...hat.com>
Cc: <jlieskov@...hat.com>,
<oss-security@...ts.openwall.com>
Subject: Re: CVE Request -- Multiple security issues in various versions of AWStats
Hello Petr!
> According to mentioned CVE, there is vulnerability in awredir.pl in
> AWStats before 6.95.
> This vulnerability was fixed in 6.95 by adding key parameter which is
> generated from secret
> $KEYFORMD5 and url so that awredir.pl is not open redirector by default
> any more.
It's still open (hardly open, but open), because destination URL is set in
URL of the script (it's one of peculiarities of open redirectors). And as I
wrote in my advisory, this protection measure can be bypassed.
> Do you find the problem that key is md5 hash so that it might be somehow
> vulnerable to dictionary attack? Or that administrator can blank
> $KEYFORMD5 and create open redirector?
Here is a quote from my advisory: "And in version 1.2 the protection was
added - parameter key. Which can even be not used (if $KEYFORMD5 is empty),
or it can be revealed by picking up.".
First, the empty value of secret key will be used quite often, because the
software requires that admin should compute value of
md5(YOURKEYFORMD5.url) - the software itself doesn't give such instrument.
And because admins mostly lazy or busy, they will not be wasting their time
for computing of this value and will use blank $KEYFORMD5 instead.
Second, the key value can be picked up (if it's not empty) - the easier the
key, the quicker it can be pickup. It's not dictionary attack, not rainbow
tables (variation of dictionary attack), but exactly brute force. Because
there are not dictionaries with "random word" + "random URL". So it's
needed to take URL and hash (value of key) and make simple algorithm for
brute forcing of the key. You can look at my example of URL Redirector Abuse
for awredir.pl version 1.2:
http://site/awredir.pl?key=0f3830803a70cc1636af3548b66ed978&url=http://websecurity.com.ua
If you'll make a small program for bruteforcing (or even manually) you can
quickly pick up the key - because I've used simple value of key for this
example (to show how this protection is vulnerable).
Best wishes & regards,
Eugene Dokukin aka MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
----- Original Message -----
From: "Petr Lautrbach" <plautrba@...hat.com>
To: "MustLive" <mustlive@...security.com.ua>
Cc: <jlieskov@...hat.com>; <oss-security@...ts.openwall.com>
Sent: Monday, October 10, 2011 6:17 PM
Subject: Re: [oss-security] CVE Request -- Multiple security issues in
various versions of AWStats
> On 10/08/2011 12:53 AM, MustLive wrote:
>> Jan!
>>
>> Petr was not right :-). And I CCed this letter, to let him know about it.
>>
>> 1. As I wrote in my previous letter there is CVE entry already for
>> Redirector vulnerability - Open redirect vulnerability
>> (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-5020). And as I
>> showed in my advisory in case of #2, this fix can be bypassed, so there
>> can
>> be made update for this CVE entry or made new entry.
>>
>> So CVE, Mitre and all others, who made such entries in their
>> vulnerability
>> databases (including developer, who tried to fix it, but incorrectly and
>> it
>> can be bypassed) already recognized it as vulnerability.
>>
>
> According to mentioned CVE, there is vulnerability in awredir.pl in
> AWStats before 6.95.
> This vulnerability was fixed in 6.95 by adding key parameter which is
> generated from secret
> $KEYFORMD5 and url so that awredir.pl is not open redirector by default
> any more.
>
> Do you find the problem that key is md5 hash so that it might be somehow
> vulnerable
> to dictionary attack? Or that administrator can blank $KEYFORMD5 and
> create open redirector?
>
>
> Thanks,
>
> Petr
>
>> 2. Yes, awredir.pl is url redirector and it's only one thing that it
>> should
>> do, but in result we have 7 holes: 3 XSS, 1 SQLi, 1 HTTPRS, 1 CLRFi and
>> one
>> Redirector hole (even redirecting should be done flawless). To which
>> holes
>> redirectors can lead I wrote in my article Redirectors: the phantom
>> menace.
>>
>> 3. Petr and everyone who don't know about Redirector vulnerabilities
>> should
>> read articles about this type of holes:
>>
>> URL Redirector Abuse (WASC-38) in WASC 2.0
>> http://projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
>>
>> And my articles (first one on Ukrainian and others are on English):
>>
>> Redirectors (I wrote this article, with few examples of redirectors,
>> before
>> I posted multiple redirector vulnerabilities in search engines in my
>> 2007's
>> project Month of Search Engines Bugs)
>> http://websecurity.com.ua/987/
>>
>> Redirectors: the phantom menace
>> http://websecurity.com.ua/3495/
>>
>> Attacks via closed redirectors
>> http://websecurity.com.ua/3531/
>>
>> P.S.
>>
>> Since you wrote me, then you can listen my music.
>>
>> In September I've released my first commercial album Originality
>> (http://soundcloud.com/mustlive/sets/originality). And soon I'll release
>> my new single. So you can listen these and other my compositions ;-). I
>> hope you'll enjoy my music.
>>
>> Best wishes & regards,
>> Eugene Dokukin aka MustLive
>> Administrator of Websecurity web site
>> http://websecurity.com.ua
>>
>> ----- Original Message ----- From: "Jan Lieskovsky" <jlieskov@...hat.com>
>> To: "Steven M. Christey" <coley@...us.mitre.org>; "Petr Lautrbach"
>> <plautrba@...hat.com>
>> Cc: <oss-security@...ts.openwall.com>; "MustLive"
>> <mustlive@...security.com.ua>
>> Sent: Friday, October 07, 2011 12:33 PM
>> Subject: Re: [oss-security] CVE Request -- Multiple security issues in
>> various versions of AWStats
>>
>>
>>>
>>> And one correction yet.
>>>
>>> Petr Lautrbach (Cc-ed) commented on Red Hat Bugzilla
>>> bug [1], that:
>>>
>>> <quote>
>>> > URL redirection abuse:
>>> >
>>> >
>>> http://site/awredir.pl?key=0f3830803a70cc1636af3548b66ed978&url=http://websecurity.com.ua
>>>
>>> awredir.pl is url redirector so this is its main/only feature and it
>>> is/can be secured by $KEYFORMD5. So I don't think this is flaw.
>>> </quote>
>>>
>>> Thus explicitly mentioning it here too, so this would not fall out
>>> of the radar and just five CVE ids would be assigned.
>>>
>>> Thank you && Regards, Jan.
>>> --
>>> Jan iankko Lieskovsky / Red Hat Security Response Team
>>>
>>> P.S.: Petr, if you have more comments on the rest of the issues,
>>> feel free to do so in order to proper set of CVE ids would
>>> be assigned to these. Thanks, Jan.
>>>
>>> On 10/07/2011 10:17 AM, Jan Lieskovsky wrote:
>>>> Hello Josh, Steve, vendors,
>>>>
>>>> these doesn't look like CVE ids have been already assigned for:
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=740926#c0
>>>> [2] http://secunia.com/advisories/46160/
>>>> [3] http://seclists.org/fulldisclosure/2011/Sep/234
>>>> [4] http://websecurity.com.ua/5380/
>>>>
>>>> If I counted correctly, six CVE ids should be assigned for these
>>>> (since different versions are listed as vulnerable):
>>>>
>>>> 1) XSS (WASC-08) (in versions <=1.1):
>>>> http://site/awredir.pl?url=javascript:alert(document.cookie)
>>>>
>>>> 2) Redirector (URL Redirector Abuse in WASC 2.0) (WASC-38):
>>>> http://site/awredir.pl?url=http://websecurity.com.ua
>>>>
>>>> 3) SQL Injection (WASC-19): (version 1.2)
>>>> http://site/awredir.pl?url='%20and%20benchmark(10000,md5(now()))/*
>>>>
>>>> 4) XSS (WASC-08) (in version 1.2):
>>>>
>>>> http://site/awredir.pl?url=%3Cscript%3Ealert(document.cookie)%3C
>>>> /script%3E
>>>>
>>>> http://site/awredir.pl?key=%3Cscript%3Ealert(document.cookie)%3C
>>>> /script%3E
>>>>
>>>> 5) HTTP Response Splitting (WASC-25):
>>>>
>>>> http://site/awredir.pl?key=04ed5362e853c72ca275818a7c0c5857&
>>>> url=%0AHeader:1
>>>>
>>>> 6) CRLF Injection (Improper Input Handling in WASC 2.0) (WASC-20):
>>>>
>>>> http://site/awredir.pl?key=4b9faa91e2529400c4f3c70833b4e4a5&
>>>> url=%0AText
>>>>
>>>> Could you allocate CVE identifiers for these? (let me know
>>>> if further description of each of the issues is necessary prior
>>>> assignment).
>>>>
>>>> Thank you && Regards, Jan.
>>>> --
>>>> Jan iankko Lieskovsky / Red Hat Security Response Team
>>
>>
>
>
> --
> Petr Lautrbach, Red Hat, Inc.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
