Pokazywanie postów oznaczonych etykietą bug bounty. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą bug bounty. Pokaż wszystkie posty

środa, 7 stycznia 2015

yammer.com - Same Origin Method Execution

SOME ;-) time ago@BenHayak talked about Same-Origin Method Execution on BlackHat EU. At the time of posting this article, there's no public whitepaper yet (only leaked slides) - that's why I'd love to share one of first posts that show this attack in action.

Yammer.com is part of Microsoft Bug Bounty for Online Services. During some research in used Flash files I found this one: video-js.swf (source).

Take a look to this piece of code:



As far as you probably know - the ExternalInterface is ActionScript class that allows (for example) to communicate Flash object with browser’s Javascript. First parameter is function name, that we want to call. As you can see - it’s readyFunction parameter (from GET), but it’s also sanitized with cleanEIString which looks like this:


So - only chars we are able to use is alphanumeric, underscore and a dot - to prevent Cross-Site Scripting. For example - if we’ll provide readyFunction=alert - our flash file will execute alert function, but we have no control over arguments (because we can't use brackets), so it’s useless for XSS purposes.

...and here is the place where we can start talking about Same-Origin Method Execution :-) Let take evil.com, that have hyperlink to vulnerable videoplayer. After clicking to this link, it opens the flash file in new tab, and next - redirect evil.com to yammer.com (in the same tab). From now on - newly opened tab have access to previous tab by window.opener (because they are both in Same Origin - yammer.com), and it’s also able to access DOM and execute functions in context of opened yammer.com page. 

The goal is to authorize user to some malicious application without his knowledge. Attack scenario will look this way:

1. User is visiting evil PoC site
2. He/she clicks on link which -in the end - redirect user to video player with readyFunction param described later
3. We’re redirecting Poc site to our yammer.com application - all we need to know is client_id - link example here: 


4. We need to wait few seconds to be 100% sure that redirect from point 3 happend (that's why I used proxy.php that sleeps and then returns 30x).
5. Flash Video Player will execute this readyFunction:

window.opener.new_message_popup.nextElementSibling.lastElementChild.firstChild.nextElementSibling.click()

...which is simply the “Allow” button + click() function :->

As you can imagine - this will cause clicking on the button and authorizing application to victim’s account, which is dangerous. :)

Proof of Concept goes here: http://ropchain.org/poc/yammer-some.html

...and demo:


czwartek, 14 lutego 2013

XSS in... Blogger ;-)

Dwa miesiące temu w ramach programu bug bounty Google znalazłem błąd stored XSS w usłudze Blogger, z której właśnie macie przyjemność korzystać :-) Celem wyjaśnienia - bo o tym nie wspomniałem - oczywiście chodzi o modyfikacje nagłówka Referer podczas wejścia na bloga. Poniżej treść oryginalnego zgłoszenia i screenshoty.


Hello there!

I'm happy to tell, that I just found cross-site scripting bug in your blogger service. 

When we put in Referer header something like this:

http://q-x.ath.cx/test'onclick="alert(document.cookie);"

And go to our blog page, our Statistic page will generate this kind of code:

<a target="_blank" href="http://q-x.ath.cx/test" onclick="alert(document.cookie);" '="">http://q-x.ath.cx/test'onclick="alert(document.cookie);"</a>
After clicking - we'll see alert :) You've got some screenshots in attachment.

Waiting for feedback, cheers!
Jakub Żoczek







Błąd oczywiście został błyskawicznie poprawiony.

niedziela, 23 grudnia 2012

Stored XSS in Google Reader

Z racji na datę - chciałbym wszystkim życzyć Wesołych Świąt! ;) 

Poniżej moje zgłoszenie dotyczące błędu w usłudze Google Reader. Zgłoszony przeze mnie 08/10/2012, poprawiony w przeciągu niecałych dwóch dni.

Oryginalna treść zgłoszenia:


Hello there! 

I have just found XSS bug in one of Google Web Applications - Reader (reader.google.com). Here is my proof-of-concept: http://q-x.ath.cx/~zoczus/google-poc.rss

This is how it works - after we subscribe this rss channel we can see it on the list (left one). There's a ability to drag this item and move it in some other place (for example - directory or just position change). After that - we'll get my js code executed.  

Here is decoded payload from title section:

Here we go. I think this title is loooooooooooooooooooooooooong enough to hide THIS evil code my friends: <object width="400" height="400" data="data:text/html;base64,PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPmFsZXJ0KCdCb29tIScpOzwvc2NyaXB0Pgo="></object>

And base64 decoded script (from object section):

<script type="text/javascript">alert('Boom!');</script>