full-disclosure - Re: Paypal Core Bug Bounty #3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 17 Dec 2012 20:09:27 +0100
From: Krzysztof Kotowicz <kkotowicz+fd@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Paypal Core Bug Bounty #3 - Persistent Web
	Vulnerability

> Successful exploitation of the vulnerability results in persistent session
> hijacking (admin), account steal via persistent phishing or
> persistent search module web context manipulation.
>
>
Exactly how is the session hijacking/phishing/web content manipulation
_persistent_? Just because the payload is _stored_ does not necessarily
mean that is it always running.


> Proof of Concept:
> =================
> The persistent vulnerability can be exploited by remote attackers with
> privileged paypal user account and low required user interaction.
>


> [...]
>


> Manually reproduce ...
>
> 1. Go to the addressbook and switch to add a new contact to adressbook
> 2. Include script code (html/js) as username to the addressbook and save
> the context
> 2. Now, switch to the user search (addressbook) module (other layer) &
> click the user contact search to activate
> 3. Include the exact name of the username (script code (html/js)) from the
> addressbook and press the search button
> 4. The context of the other layer from the addressbook will be executed
> directly out of the results listing page of the exisiting user contacts
> 5. Done! POST REQUEST: method="post" name="searchContact"
>
>
How is THAT a "low user interaction" scenario? IIUC, victim has to manually
(no mention of CSRF here) insert a XSS payload into his address book, then
search for the payload exactly as inserted (is there a antiCSRF token
needed for the search request) and only then is the payload executed.
During this scenario user knowingly sees & uses Javascript code twice -
that's hardly low interaction.

Unless I'm missing something - is there a cross-account action going on
where one user manipulates the address book for a second user (e.g. from
the same organisation?)

Best regards,
Krzysztof Kotowicz

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/