viernes, 26 de marzo de 2010

(A)leatory (P)ersitent (T)hreat



The Random House Dictionary defines aleatory as:
2. of or pertaining to accidental causes; of luck or chance; unpredictable: an aleatory element.

I will stay with accidental causes, or just plain luck to describe the exploit that was found on the wild for the CVE-2010-0806 vulnerability a couple of weeks ago. The bug is nothing more than 0day found on the wild attached with your favourite trojan (Zeus in this case) that works against Internet Explorer 6-7.

The bug

The bug class is what we known as a use-after-free, that means that at some point some object is freed but we continue use it. A good example of this bug class on a non-browser was the 2001 globbing capabilities bug on wu-ftpd that people cleverly exploit (yes, pretty much everything was done by 2001).
In the case of CVE-2010-0806 (a.k.a. ie_peers), the bug is on an old DHTML featured called behaviours "DHTML behaviors are components that encapsulate specific functionality or behavior on a page".
The bug itself is when trying to persist an object using the setAttribute, which end up calling VariantChangeTypeEx with both the source and the destination being the same variant. So if you send as a variant an IDISPATCH the algorythm will try to do a VariantClear of the destination before using it. This will end up on a call to PlainRelease which decref the reference and clean the object.
VariantChangeTypeEx called with the same source and destination

Mark dowd, the internet security oracle already talk about those kind of potential bugs here: bh2009_dowd_smith_dewey.pdf

Pertaining to accidental causes

When i first read the chinese/russian exploit, i was thrill on how it really works. Specially since my conception of a use-after-free was:
1) free the object
2) allocate memory to fill it
3) Use it

VariantClear will decrement the reference counter or free the object

Well, my conception of a use-after-free remains the same, but the on-the-wild exploit was just relying on the mystery of heap randomness to make this exploit execute shellcode.
The exploit first do a common heap spray with shellcode and later just run the use-after-free trying to free the window object and later just wait the lord to work in mysterious ways and 1/10 times execute shellcode. This is what we called in Immunity: pray-after-free.

Exploiting
The exploitation mechanism of a use-after-free is very simple, everything that was free need to be allocated with something we control. You can use every resource you want, just be sure that whatever you are allocating, it has to be on the exact same heap.
Another important decision is what to free. The public exploit use the window global which to me looks like something that could be potentially use it before we fill it. That's why creating your own element is always recommend it.

var p = document.createElement("BODY");


Creating our own element also gave us a very good idea of the reference count of the object, instead of just looping 10 times, we just call setAttribute on the createdElement.
On the TEAROFF classes, such as the Elements returned by document.createElement it does the decref through the PlainRelease. This function has 2 dword where it cache the thunk before actually free it.
We need to do two more setAttribute, in order to take p out of the cache and call MemFree.
e.setAttribute('s', p);
e.setAttribute('s', t);
e.setAttribute('s', w); // In this VarClear call, is when it actually going to free the chunk.


The Element objects are allocated on the default heap, so our soft-memleak needs to be on the same heap. Strings are allocated through SysAllocateLen which end up on the default heap as explained by Sotirov's Heap Feng Shui but (there is always a but...) jscript String had the length as the first dword, which on our object is a vtable pointer, exactly what we want to control.
Object Chunk that need to be filled (The alerted readers will notice that the chunk is a Low Fragmentation Heap chunk).

In CANVAS exploit, we use XMLHttpRequest.open() but there are many tricks like @WTFuzz document.createElement(‘div’).className
The next step is finding the exact size of the chunk, so we can allocate our object and replace the vtable.

Bypassing DEP
Trigger the bug is trivial. Whatever function we want to call on the free object it will try to do a IDispatch->GetDispID and that will use the modified vtable. The next step for a good boyscout is to transform a function pointer execution into ret2libc. To do that we need to move a buffer we control to ESP.

GetDispID is a very interesting function:

HRESULT GetDispID( BSTR bstrName, DWORD grfdex, DISPID *pid );


As you can see from the msdn description, we have two interesting thing, first the "this" object which is usually the first thing we have pushed on the stack and we also have the bstrName, which is the function name that we want to call. Javascript is flexible enough to allow us to do:
p["CocaCola"]();

The "this" object is also under our control since it's the buffer that we use on the use-after-free.
Triggering the vulnerability. In this case, i set the bstrName as "getElement" but could be transformed into whatever we want.

Now is just a matter of finding the correct piece of code in order to pop the first or the 2nd dword from the stack.
Some ideas:
XCHG/POP/RETN
POP/POP ESP/RETN
POP ESP/POP/RETN
POP EBP/POP/LEAVE/RETN


If you are precise enough, you will have defeat randomess and will have a proper shell:

sábado, 20 de marzo de 2010

BlueHat Security Forum 2010 - Argentina



Dear diary,
I'm finally back into blog writing. The main reason why I stop is pretty much everyone else reason: lack of time. Although time is still a precious asset, i found some time to write this entry.
Two days ago, Microsoft finally made BlueHat for the very first time in Argentina. It is a great honour as an Argentinian still living in the country, to have Microsoft decide that we are a strategic point to extend the conference outside the US. Andrew Cushman told me its the second time they do it outside Redmond, they have a first experience in Brussels which was a bittersweet experience, but he said they learn from that experience and they renew the hopes in Argentina.
Their strategy this time was to blend the latinamerican CSO/CTO with the researchers community. Spotting who was who, was just a simple visual exercise: Suits vs tshirt.

The kicking point to archive this almost impossible objective (The Microsoft Security team has a past of choosing high objective that they commonly archive) was a round table lead by Andrew which a bunch of well-known researchers (FX, Damian Hasse, Manuel Caballero, Rodrigo Rubira Branco, Ivan Arce, Luiz Eduardo and me) with the title "Hackers and You". The idea was great, sadly, we run out of time to discuss and expose all the different flavours from such a broad topic.
I believe there are four main points made, not only in the round table but in BlueHat in general.

o Offensive security is a key part of enterprise security. Microsoft understood this looong time ago and act greatly upon it. No matter the size of your bussiness, If you ever stop considering the offensive part of the security, you will end up without strategy and simply relying on your IDS/IPS/Firewall/AV devices, that quoting FX presentation "its a very very very *bad* idea".
o Security needs to be consider in every step of your business cycle. The Microsoft presentation were very clear on that subject.
o Hire researchers for your team and make them happy. Certifying them with theoretical exams (study/take the test/immediately forget) won't make them either happy or help them secure your network. Talk to them, research on practical training and let their creative spirit fly a bit (on controlled environments).
o Prevention is prediction. This subject briefly came from a very smart question of a conference attendee to the panel, she said "having all this new technique and tricks, seems that prevention gets old". Ivan have enough time to reply saying that prevention models can be correctly designed, which i totally agree. Prevention models became prediction models. Prediction needs not to be understand as the result of a lucky cookie but rather how the philosopher Ricoeur understand the term futurology (bad translation of the term from my part): Understanding and trying to win yards on randomness. And this is where in my opinion, offensive security help you go the extra mile along with the great researchers we have on that area, they know how to hack and help you understand current and future out of the box risks.

Finally, there was an interesting presentation by Kristen Dennesen and Anchises de Paula on the Latin American vulnerability market. I had high expectation about this presentation, because i want to see how they focus this subject having to face a more executive crowd (Pedram did a great job at the ekoparty, but that was more focused on researchers).
They did a very nice job, i have the feeling that they have at least three presentations in one, so as an attendee i was thirsty for more information on the each of them but due the lack of time they couldn't go where i want. But again, this was an executive crowd. The subject in my understanding of their presentation were: Vulnerability Market in Latin America, New security legislation and their impact on the security scene and the security threats in latinamerica.
Luckily Bluehat encourage the corridor and bar discussion, which usually allows you to talk with the presenters, exchange opinion and get the backstage information.

In summary, great conference, glad too get together with old and new friends. Kudos to Celene, Katie, Mike, Mark, Damian and Andrew for putting together such a great conference. I'll be looking for more next year.


PS: My favourite presentation was Hernan Ochoas "5 minutes to explain the 14-year old unpatched SMB bug", which was fast, fun and with great content.

PS2: Fede present a very nice draft of what is going to be our future Hackerspace in Buenos Aires, i'm in the group that is trying to push this project and we hope we can gave the big news soon.