Monday, June 24, 2013

Adobe XFA exploits for all! First Part: The Info-leak

Some notes on exploit development

There are two types of frustration as an exploit developer when you are facing a malware with a zero day or a public proof of concept that generally kick in on the first day or two.

The first one is a classic: spending hours navigating the darkest corners of the Internet, looking for a the right trial version of the vulnerable application. The more obscure the software is, the harder of a time you will have, I know dumb stack overflows that took more time to find the server than to exploit.

Luckily, this was not our case since we are exploiting Adobe Reader and you can easily find all the versions.

The second problem and the most common while reversing Chinese malware is the low percentage of success they often have. You are able to crash the vulnerable software, of course, and this is generally enough in our line of business to demonstrate the weakness. But you also want to understand what techniques they use to gain control and compare them against yours, and this requires their exploit to actually work.

In the case of the Acroform XFA bug, no matter how much we try with different environment and versions, the heap layout was never massaged correctly to allow the exploit to work.

This leaves an open question we generally have (and we have so many theories... yes, some of them involve aliens!). Why are the Chinese offensive teams not investing a couple more weeks on the heap layout, like we did, and to dramatically improve the reliability of their exploits?

In malware design, reliability == more computer owned == more money.

At the same time, from an OPSEC perspective: reliability == stealthiness. And stealthiness means you don't loose your zero day and your investment is worth more over a long term.

Technical description

The vulnerability lies in the AcroForm.api module when handling Adobe XFA Forms in a particular way. The exploit uses an XFA form with 1024 fields like this:

We first need to get UI (user interface) objects from the XFA form, and from within the UI objects the choiceList objects. We need to create 2 arrays with these objects:

These arrays will be used during the whole exploitation process. The code in charge of triggering the vulnerability is:

    var node = xfa.resolveNode

    node.oneOfChild = choiceListNodes.pop();

Everytime the oneOfChild attribute of a node is set with one of the choiceListNodes node, the vulnerability is triggered. When creating a new "XFAObject" of size 0x40, there is an access outside the bounds of the object on "XFAObject"+44, using uninitialized data. At "XFAObject"+44 there is a pointer to some structure we will describe later.  If the pointer is null nothing happens but if we are able to control that uninitialized data after the "XFAObject", we will trigger an info-leak or trigger code execution.

When the pointer is not null, an structure like the following one is accessed:
  ----  0x0 Vtable pointer
  |     0x4 RefCount
  --->  0x8 Destructor's address

This structure is accessed twice during the vulnerability trigger. Since we are in control of the RefCount and the "Vtable", if our RefCount is bigger than two, then we can use the bug as a decrement primitive, otherwise when the RefCount gets to zero, the object's destructor will be called.

We are in control of this memory so we can pretty much control what is going to be executed.
With the right heap layout set, we will a get a string followed by an object object, so with our decrement magic we decrement the null terminator and obtain the vtable address right from our object.
Infoleak running on a Windows 7

Sounds simple right? Wrong.

We can read the vtable, but we can only read it correctly if all bytes of the vtable are below 0x7f. So if any of the bytes is greater than 0x7f, we use the pointer decrement primitive to get that byte below 0x7f.


This gave us the ability to be version agnostic, and follow our mantra "an harcoded-less exploit is a happy exploit".

At this point, it was time to get into the second stage of our exploit which is sandbox bypassing. The Chinese exploit was dropping a DLL with the code. We decided that invading the hard-drive was a bad practice and so with a little help with our Python-based assembler (MOSDEF) embedded in CANVAS we decide it to embed the code into the exploit itself.

And so, we decided it was time to bypass the sandbox. But that my friends, will be for our next blogpost entry.

Keep in touch!
David and Enrique

Tuesday, June 18, 2013

Therapeutic Ramblings of a Hacker

You remember your first hack. So do I. It was in the 7th grade and I used the school's computer in the library to erase a fine I had acquired by returning a high school textbook in late.  At first I tried to reason with the librarian saying "The time allocated to read the book should be relative to the size of the book!  I can't read a psychology textbook in the same amount of time as a Dr. Seuss book!".  That didn't work.  So instead I jumped on the library's network and found a way to erase the 25 cent fine from existence.  After I did that I thought to myself "Wow.  That was actually a lot easier than I thought it would be."

Now of course that took place 142 years ago and we all now that security was a lot more 'relaxed' and arguably non-existent 142 years ago.  But has much changed?  The quick and less eloquent answer is 'no'.  Even after billions of dollars are thrown at security issues there are still unauthorized ways into networks and there are still multiple avenues to gain access to sensitive data.  Many times during penetration tests I am still left with the thought "Wow. That was actually a lot easier than I thought it would be." even 176 years after my first 'hack'.

Anti-virus - doesn't work. It can only protect you against known threats (and by 'known threats' I mean threats that were enjoying high levels of success until anti-virus finally crashed their party - well after the damage has been done).  Anti-virus is just as effective as a man with a shotgun standing in the middle of house with no windows or doors waiting for an intruder - but the shotgun will only fire when a known intruder enters the property - first-time intruders or known intruders that are wearing a different ski mask than the previous robbery get free passes.

Firewalls won't save you.  Sure they have their value and their place but as long as there are computers from the trusted network making requests out into the big bad Interwebs they can't provide the protection you would hope for.  They only reduce the effectiveness of certain types of attacks but do nothing to protect against the type of attack that hackers are using to break in today (and tomorrow, and quite possibly forever).  No software or hardware can stop some humans from being gullible, compassionate or just plain retarded.

There will always be a way in.  There will always be access to your sensitive data.  Think of it this way - can a physical safe ever be 100% burglar proof?  No.  Why?  Because it has to be designed to give someone access.  The only way to keep a physical safe 100% burglar proof would be to design it in such a way that it would never open after it was shut for the first time.  That design can't be applied to us in our society because we want access to our data. Correction, we DEMAND access to our data. If we have pathways to our data then other people have pathways to our data.  As long as you let people through your doors, grant access to anyone on your network or let code run on your devices there will always be a way in.  Our job as security professionals is just to find the pathways and reduce them to a reasonable quantity and find ways to manage risk and in so doing make it really expensive or time consuming for unauthorized persons to traverse those paths.

Everyone is vulnerable. It's rare to find people that aren't broadcasting every second of their lives to the world via social media.  I know what my girlfriend from high school had for breakfast this morning even though I haven't spoken to her in 74 years.  She even posted a picture of it (it looked delicious). Our data is out there and we are trusting it to be stored in databases that we don't control.  The pathway to enumerating corporate passwords can even start from something as innocent as an Instragram post  from a friend of an employee.  Do you know how many entry points there are to your data from the time it starts its journey from your machine (computer, phone, printer, etc) to its final destination? At least 14 trillion.  Well that was a slightly exaggerated but the point is that it's more than you think.  Don't be surprised when you find that someone has access to your data that you have purposefully sent into someone else's void - because the truth is a lot of someones have access to your data (and it's not just the NSA and PRISM).

Your wireless network is not protected very well (for acceptable definitions of 'protect'). If you don't believe me then your wireless sales guy is really, really good.  In fact most of the protocols that the Internet are built upon weren't designed with security in mind, wireless networks are no different.  And as I demonstrated in the latest SILICA video an attacker can trick you into invalidating the "S" in IMAPS/SMTPS/POP3S/HTTPS with a simple click of an innocent "OK" button. If the security of your company lies in the hands of your average employee then you are doomed.  The Internet and its wireless little brother are but a castle built on sand and it's raining really hard outside.

You can't fight hackers without hackers.  It's a frame of mind that you need to protect against - not any one specific action.  Buying shiny new security appliances is equivalent to playing a really expensive and never-ending game of whack-a-mole. (Don't get me wrong - removing attack vector #475 might be a good move but hackers will enumerate and exploit the 475-1 remaining vectors soon enough). Don't make the mistake of having security only be an afterthought.

So with that said I leave you this thought.  Hackers are creative, smart and resourceful.  Stop fearing them and hire them.  They should be included in the design phase, implementation phase, testing phase and deployment stages of your new applications, services and strategies.  So give your local hacker a hug and give him/her a lovely corporate gift basket with an invite to your next meeting.  You won't be disappointed with the results.

Thanks for listening to my therapeutic ramblings.  You can send me your ramblings to Twitter @MarkWuergler