[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 2 Feb 2012 10:28:02 +0100
From: Filippo Cavallarin <filippo.cavallarin@...seq.it>
To: Carsten Eiram <che@...unia.com>
Cc: "'oss-security@...ts.openwall.com'" <oss-security@...ts.openwall.com>,
'Henri Salo' <henri@...v.fi>
Subject: Re: XSS hiding CSRF (was: Re: Mibew messenger multiple XSS)
I agree with you, this issues should have been categorized as CSRF. I had this doubt when reporting them and i decide to consider them XSS for one main reason: even with a CSRF protection an operator is still able to inject javascript into visitor's browser (ie an operator sets chat title to XSS and it gets executed when new visitor opens a chat). But propably you are rignt, there is no gain for an admin to exploit this and, for sure you are right, a password reset has a bigger impact.
Regards,
Filippo Cavallarin
On 2 Feb 2012, at 8:25 AM, Carsten Eiram wrote:
> The points made by Steve are why we're spending so much time testing everything we can get our hands on. It's standard operating procedure - and has been for many years - to particularly pay attention to these "XSS hiding CSRF" cases. For that reason you'll often see discrepancies in the original report and the released Secunia advisories.
>
> In the case of Mibew, the functionality is restricted to admins and from an administrator's perspective there is no gain. Therefore, we do not consider it a vulnerability in itself. However, via the CSRF vector it can be exploited by non-admins. This is why the Secunia advisory is rated as CSRF (like the OSVDB advisory) and just mentions XSS as a follow-up impact (along with alternatively just changing the administrator's password and gain full access that way).
>
> I would definitely join Steve in encouraging researchers to keep this trend in mind by considering a) if a discovered issue actually provides a gain compared to legitimately accessible functionality and b) relies on another vulnerability in order to be an issue. We encounter these "XSS hiding CSRF" cases on a weekly basis.
>
>
> --
>
> Med venlig hilsen / Kind regards
>
>
> Carsten H. Eiram
> Chief Security Specialist
>
> Follow us on twitter
> http://twitter.com/secunia
> http://twitter.com/carsteneiram
>
> Secunia
> Mikado House
> Rued Langgaards Vej 8
> 2300 Copenhagen S
> Denmark
>
> Phone +45 7020 5144
> Fax +45 7020 5145
>
>
>> -----Original Message-----
>> From: Steven M. Christey [mailto:coley@...-smtp.mitre.org]
>> Sent: 1. februar 2012 23:24
>> To: oss-security@...ts.openwall.com
>> Cc: Henri Salo; filippo.cavallarin@...seq.it
>> Subject: [oss-security] XSS hiding CSRF (was: Re: [oss-security] Mibew
>> messenger multiple XSS)
>>
>>
>> Funny, the CVE team was discussing this curiosity just today.
>>
>> In the Mibew case, the PoC code has POST forms that invoke scripts like
>> "/operator/ban.php" and "/operator/settings.php". These are almost
>> certainly administrative functions that probably shouldn't be reachable at all.
>> Thus, these might be better identified as CSRF issues at their core, instead of
>> XSS.
>>
>> It seems that some researchers report XSS in administrator modules, but
>> they omit when you need to use CSRF in order to get the administrator to
>> perform the XSS. So, the primary issue is often CSRF, and XSS is only
>> resultant (since, in many cases, the admin already has privileges to edit
>> HTML). The vuln DBs are starting to catch up with this "trend" in vuln
>> reporting, so there is a very slow shift towards identifying CSRF as the core
>> problem. However, CSRF is in the eye of the beholder, in that you often
>> need to know the INTENDED functionality of the application before you can
>> interpret whether things are CSRF versus regular functionality, versus good
>> old XSS.
>>
>> Note that this kind of XSS-hiding-CSRF issue is not necessarily tied to admin
>> functionality, but that's where it's a strong indicator that a researcher might
>> be ignoring CSRF.
>>
>> Sometimes, though, it can be difficult to determine whether XSS or CSRF is at
>> the root, even if you're dealing with admin functionality. For example,
>> maybe an admin program will check for CSRF and fail, but include the original
>> form in its error response, possibly enabling XSS. Or, maybe there are TWO
>> issues at play - maybe a victim can be CSRF'ed to make posts on their behalf,
>> and also a secondary issue where the victim can become an attacker and XSS
>> other people (with or without CSRF).
>>
>> Unfortunately, I strongly suspect that the number of XSS-hiding-CSRF reports
>> will grow :-(
>>
>> For people who investigate vuln reports closely, please keep this trend in
>> mind. If you are a researcher, consider whether XSS or other issues are really
>> legitimate functionality that is only reachable by targeting the victim with
>> CSRF; if that's the case, then the CSRF is "primary" and the XSS is "resultant"
>> and not a separate vulnerability - and if your targeted application has CSRF,
>> then maybe there's a more powerful impact than just XSS. (For example,
>> depending on how settings / configuration is implemented, you might be
>> able to get code execution out of it.)
>>
>> - Steve
>>
>>
>> On Wed, 1 Feb 2012, Kurt Seifried wrote:
>>
>>> On 01/31/2012 08:22 AM, Henri Salo wrote:
>>>> This seems to need 2012 CVE-identifier.
>>>>
>>>> Advisory: http://seclists.org/bugtraq/2012/Jan/177
>>>> Codseq own advisory:
>>>> http://www.codseq.it/advisories/mibew_messenger_multiple_xss
>>>> OSVDB: http://osvdb.org/show/osvdb/78663
>>>> Secunia: http://secunia.com/advisories/47787/
>>>>
>>>> At the moment http://mibew.org/ does not work for me.
>>>>
>>>> - Henri Salo
>>>
>>> Please use CVE-2012-0829 for this issue.
>>>
>>> P.S. for some reason OSVDB lists this as a CSRF issue (?) which is
>>> mentioned in the advisory but not really shown.
>>>
>>> --
>>> Kurt Seifried Red Hat Security Response Team (SRT)
>>>
Filippo Cavallarin
C o d S e q
Development with an eye on security
------------------------------------------------------------------------
Castello 2005, 30122 Venezia
Tel: 041 88 761 58 - Fax: 041 81 064 714 - Cell: 346 66 93 254
c.f. CVLFPP82B27L736J - p.iva 03737650279
http://www.codseq.it - filippo.cavallarin@...seq.it
Le informazioni contenute in questa e-mail e nei suoi eventuali allegati
sono confidenziali e riservate esclusivamente alle persone od enti a cui
sono destinate. Sono proibiti l'utilizzo per qualunque fine del presente
messaggio e di ogni documento ad esso allegato così come la relativa
divulgazione senza l'autorizzazione del mittente. Se avete ricevuto questa
e-mail per errore, vi preghiamo cortesemente di notificarlo (via e-mail,
fax, o telefono) al mittente e di distruggerla.
Tutti i messaggi elettronici sono suscettibili di alterazioni. I dati
personali sono trattati esclusivamente per le finalità della presente
comunicazione in conformità con la legislazione vigente (D.L. 196/2003
"Codice Privacy"). Informazioni: filippo.cavallarin@...seq.it
This message and its attachments are addressed solely to the people or
entity above and may contain confidential information. If you have received
the message in error, be informed that any use of the content herein is
prohibited. Please return it immediately to he sender and delete the
message. E-mails are susceptible to alteration.
Should you have any questions, please contact us by replying to
filippo.cavallarin@...seq.it
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.
