miércoles, 19 de septiembre de 2012

Hackers and Runners

After a year of full time parenthood, i decided to start working out again. During my younger years I always played team games, and if you know my condition of Argentinian, you will easy deduce that the main sport was Soccer, of course.
I did other sport for short period of times, such as a little bit of Softball, Kendo, Tennis, etc. But of course, my new condition as a father restrict me in different ways: I need a sport that can be done at random times of the day (when my daughter sleeps), that requires basically no preparation (nap only last from 30 minutes to two hours) and that don't require combining with nine other people to play it (Syncing mature people agendas to play a sport is toughest than parenting).
As a consequence of all this requirements, i decided to just hit the gym. Since getting injured and holding a baby doesn't go well alone, I was very cautious and I decide to warm up each time on the treadmill. As time goes by, I slowly find out that I was getting more excited about the running than weightlifting.
Of course, the first reason that start pushing me more into running that weightlifting was the gym itself. It's a very small gym (but very close to my place), and in rush hour is full of people. Sometimes you have to wait to use a machine, and is quite annoying and broke one of the requirements.
The other reason was the people, (and your gym might not be like that), but i found myself surrounded by groups of obnoxious narcissist  behaving like adolescents and even im used it this kind of environment since I work in information security (same behavior, but people probably a little less healthy) the point of working out was to get away for stressful environment.

So i became a runner.

As I said before, it start only two years ago but now I can said that im semi-obsess about it. I try to go out for a run at least three times a week. If I can't find a proper time, i will wake up at insane time or do it extremely late and still enjoy it.
But it's was not until a couple of days ago when I was reading Murakami's "What I talk about when I talk about Running" when I realize Running was there all my life for me, I just never moved my feet together to make it happen.
Murakami on his books started making a comparison line between writing and running, and as  he was getting deep into the similarities I couldn't stop thinking on my career as a Researcher.
He said that the most important quality of a novelist (apart from the talent) it's focus: "the ability to concentrate all your limited talents on whatever's critical at the moment. Without that you can't accomplish anything of value, while, if you can focus effectively, you'll be able to compensate for an erratic talent or even a shortage of it".
After focus, he said that the next quality is endurance: "What’s needed for a writer of fiction—at least one who hopes to write a novel—is the energy to focus every day for half a year, or a year, two years. You can compare it to breathing. If concentration is the process of just holding your breath, endurance is the art of slowly, quietly breathing at the same time you’re storing air in your lungs."
Surprisingly, if you ever find a vulnerability and exploit it from zero on a complex system, you will find Murakami words very familiar.
Talent is really important, but after you go through the roller-coaster of uncertainty during months trying to exploit something that you never know if it will be exploitable you will find out that focusing on new ideas every days is an exhausting task.
I have known many people with talent and a great ability to focus on a problem, but as soon as the problem gets extended for more than two days, they started boycotting themselves.
And this is something you can acquire  and sharpen it with training, exactly the same as distance running. "You’ll naturally learn both concentration and endurance when you sit down every day at your desk and train yourself to focus on one point. This is a lot like the training of muscles I wrote of a moment ago. You have to continually transmit the object of your focus to your entire body, and make sure it thoroughly assimilates the information necessary for you to write every single day and concentrate on the work at hand."
People in general are quite competitive, and you can totally be like that in the infosec scene but when you sit down with a binary for eight hours straight there is no one else rather than you and the computer. This might sound obvious, but there are no opponents or enemy rather than your own ghost  and those will became stronger as time goes by.

Murakami, Haruki (2008-07-29). What I Talk About When I Talk About Running (Kindle Locations 832-834). Random House, Inc.. Kindle Edition.

sábado, 28 de abril de 2012

Three Reasons why you should listen to what Brett Moore has to said...

There are clearly too many conferences and as a result too many material too catch up. But the difficulties as you probably experience is not finding free time to read it, but rather filtering the insightful research among all the noise.
The best way of course is following recommendation from friends (exclude twitter from this equation, giving the tendency to RT information without reading it) or just read the presentation from "respected" researchers but this is a double edge sword, because presenters has the need to be on the media as part of their business model and so the quality usually decrease and at the same time you narrow down your chances to find some fresh material.

In any case, if there is a researcher that never disappoint is Brett Moore. This guy that came from the further island of New Zeland (country famous for adding fluor on water and as a result breeding  generations of rugby players, hackers and sheep lovers) is one of the big institutions of the antipodes.

There three things that you will always find on a Brett Moore presentation:

  • Brett has a technical standard, and no matter in which conference he is talking, he never lower the quality.
  • He is always as clear as water on his presentation, you will never see him hiding any technical detail. Every piece of the puzzle is always on his slides.
  • Everything he present is based on a real world challenge he had to face at some point. He didn't find a way to bypass SAFESEH because the protection was there, but rather because he had a bug and need to exploit it. This give him an advantage over most of the 90% of the material around, his stuff works. Researchers tend to fall into the Strawberry pudding rule, where requirements to implement their technique are so big that is almost impossible to do so, unless you do it in their own controlled environment. Brett always present a real scenario where the challenge pop up.

If i didn't convince you by now, try reading his new presentation for Syscan 2012 http://www.insomniasec.com/publications/Post%20Exploitation%20Process%20Continuation.pptx on post exploitation process continuation.

PS: Last advice on Mr. Moore, never try to outdrink him or piss him off when he is drunk. You have been warned.

martes, 26 de abril de 2011

Teaching exploit development

Giving a training is one of the hardest thing you will ever experience in a researcher's life (and one of the most rewarding).
Over the 5 days we spent last week giving the Master Class, there were months spent working on the material, preparing exercises, etc.
My first thought when i did my first training back in 2004, was that it was simple. I completely master the subject i was teaching  and the slide deck was pretty solid. But that was just one part of the deal, communicating the knowledge is hard and brain consuming. It's not just "explaining" a subject, but rather transferring the knowledge in such a way that is exciting, mantain the attention of the class for 8 hours a day and it's progressive.
The composition of the class is probably one of the hardest challenge. They are generally very heterogeneous, from super skilled people that should be with you teaching the class  to people that are completely new to the subject. I always tell the story of my experience in Japan, where the first day I make everyone introduce themselves and tell me their experience with the heap, two out of the twenty students have no idea what the heap was, and in fact, their expertise on security was very physical: They work installing security doors.
It's really complex to maintain a balance on a class and make everyone happy, you need to be prepare with a series of exercises and even that won't starve the most hungry for knowledge, whether at the same time you need to have simple exercises and good analogies for the new ones.
The classes on exploitation are a subject by their own. An exploit is something that should not be happening on that machine, you have the whole system against you and now you are not only teaching it but helping 34 people at the same time having all kind of problems. And the worst part, you have 30 seconds to sit on his machine and understand every step of their logic to help them out.
For all of those reasons, is why we try to teach methodology over specific exploitation techniques. Bug Class die, primitive don't. And methodology have a lot to do with primitives, whether is messaging the heap layout to craft a deterministic heap or getting a infoleak out of use-after-free.
If you attend a class, and you think that you are only learning how to use a tool, pack your stuff because you just lost. You lost for one of the two reasons: They are actually just teaching you how to use a tool and nothing more or you didn't understood the concept of the class at ALL.
Tools need to be learned to understand the methodology, not because people randomly want to coopt you on the army of users, but rather because they are providing the tools to move from that point one (Of course, they are classes just focus on tools, try to avoid them). Imagine teaching a class of 34 people with completely different backgrounds about SMT Solvers and symbol execution, using SMT-lib language (lisp alike language) or leaving by themselves and the debugger of choice the hooking of very specific functions to obtain some information (You will be have people using from windbg to the most obscure debugging library, and you will have to support them and actively help them with their mistakes).
I want to share just one last anecdote, that summarize the blog post. We were working on an use-after-free exercise the second day of the class, and i just explained a type of script they had to write to hook on specific functions on mshtml.dll to dynamically find softmemleak on Elements properties. Since we were running out of time, I asked the student what they would prefer: Continue working on exploiting the bug or  write the script? And Halvar answered cleverly as he usually does: "What's the difference?"


lunes, 21 de junio de 2010

The so called Return Oriented Programming...

Dear Diary,
I always hate the name Returned Oriented Programming, not because it might be an accurate name but just cause it sounds like they are reinventing the wheel once again. Paraphrasing aeschylus sometimes i think the offensive security is just bread crumbs from the great banquet of the end of the 90's hackers.
Anyway, recently I have to teach a class in Norway, the group of students was very smart which always help you push further and further. The last day, as part of our advance stack overflow class, we teach them how to write a ROP shellcode and go the next step and write their automatically tool.
Obviously, one day is not much to write your own tool, but was enough to write their shellcode which I'm proud to said it was half the size of the public exploit I saw.
Since the term start getting over-hyped, I think in a way it make it look far and harder. But thinkings of way to teach it in a class, makes me realize how simple it is. You see some exploits going for the most complicated solutions while the simple ones are shorter and more accurate sometimes.
So let me give you some hints, which are part of the Advance Stack Overflow class at Immunity:

The first step before start writing a ROP shellcode is to plan the strategy ahead, else you will be improvising in the middle of your shellcode and the consequences are going to be just ugly.

Here are some bulletpoints of what you should be thinking ahead before starting your shellcode:

  1. Restriction Bypass
    As we know, the trick behind ROP is that you are basing all your return values on one or two dlls whose base is known by you, either by an infoleak or just lack of REBASE flag.
    With that in mind, you need to find out which API functions are being imported (statically or dinamically) in order to find out how you are going to bypass it.

    There are probably a bunch more, you just need to use your imagination. A recently paper from Brett Moore, make me realize you can use the same trick too.
    Let said you don't have access to any of those API functions, so as you see, the field to play with is very small, an interesting way to potentially bypass it will be by using GlobalAlloc, or any kind of heap wrapper.
    When we call any of those functions with normal size, it will returns us a memory chunk. With the address of the memory chunk we can easily obtain the Heap Segment http://www.nirsoft.net/kernel_struct/vista/HEAP_SEGMENT.html (usually the LSB are zero). Once you get the Heap Segment, you can grab the address of the PHEAP from it and change the permission flag into EXECUTABLE HEAP. Then the next step will be to force a second allocation of a big size such as it's going to use VirtualAlloc and make it Executable. Voila!
  2. Which registers we control?
    a) Can we control the content to all the registers (In Immunity Debugger a good way to check it, is just to get a POP R32/RETN)
    b) Exchange / Move between registers: All kind of combinations and flavour, whether is just a “MOV RA, RB” , “OR RA, RB” or “XCHG RA, RB”. And so on... Swapping with ESP is always important.
    c) Register logic: Look for different types of register logic, this will allow you to later bypass bad characters restrictions. (NEG R32, etc)
  3. Memory Access Instruction
    You most likely will be doing a lot of READ / WRITE operations, thats the main point of the so called ROP.
    MOV [R32], R32
    MOV R32, [R32]
  4. CPU Context
    Very important to reduce the amount of dwords used, always check if there is more than just ESP pointing to the controlled buffer.

Exploiting 101

The main trick to make ROP very simple (if we can really called it a trick), is just generate a parallel stack for calling functions. The parallel stack if needs to be created on a known address (if possible, which most of the time it is, else we can use ESP itself), if you know the base address of your dll, you most of the times can calculate the address of the .data (RW) section. That's a good spot to start creating your parallel stack (There are static RW pages at the same address along all version of Windows, but that is an exercise for the readers).

In the exercise we were exploiting on class, we were able to respond to all of the questions in the strategy, we have VirtualProtect imported, all the registers could be written with whatever we want, we were able to xchg with the stack , all kind of combinations of memory READ and WRITE and finally EBP was pointing to our stack.

pop R32/ ret // All the registers
mov [ecx], eax / ret // Write to ECX
mov eax, [ecx] / ret // Read from ECX
mov [eax], ebp / ret // Write to EAX content of EBP
xchg eax, esp // Exchange eax with ESP
neg eax // To bypass character restrictions

With that combination, creating the parallel stack to call VirtualProtect on our stack was trivial:
We just need to get the address of VirtualProtect, copy into the parallel stack and start writing all the arguments of VirtualProtect in the parallel stack, for the address to “unprotect” we used the stack itself taken from EBP, the other arguments were just trivial to craft. At the end, you xchg ESP with your parallel stack that will execute VirtualProtect (with the same ret2libc trick you were using) and later jump back to the stack, this time to actually execute your shellcode.


MOV EAX, [ECX] // EAX now holds the address of VirtualProtect
MOV [ECX], EAX // Paralel Stack : 0: [ VirtualProtect ]
MOV [EAX], EBP // Paralel Stack: 8 [ Address of Stack ]
NEG EAX // EAX= 0x2000 Bypassing bad characters
DATA + 0xC // ECX = DATA + 0xC
MOV [ECX], EAX // Paralel Stack : C: [ Size: 0x2000 ]
-0x40 // EAX = -0x40
NEG EAX // EAX = 0x40
DATA + 0xC // ECX = DATA+0xC
MOV [ECX], EAX // Paralel Stack : 0x10: [ Flag: 0x40 ]
DATA + 0x10 // ecx = data+0x10
DATA + 0x60 // eax = data+0x60
MOV [ECX], EAX // Paralel Stack : 0x14: [ OldProtect: Writeable addres in data ]
DATA // eax = data

At this point in code, where we change switch to a parallel stack that it will look like:

[ VirtualProtect ]
[ XXXXXXXX      ]
[ Stack addr      ]
[ 0x2000            ]
[ 0x40                ]
[ DATA +0x60   ]

When the new parallel stack get executed, it will call VirtualProtect on our stack address and later return to XXXXX (I didn't set it, but that should be your stack :)


Once you get shellcode execution, you should go back to your very simple primitives and try to sequence of opcode that do what you one in less step, like a combination of POP or multiple memory access. Always keep in mind that the less return addresses you have, the easy to port and make universal (?).
The lesson learned is that a rop shellcode can easily be understood and written as a series of calls, read and writes instructions. 
At the end, this is nothing more than the old school return to libc, I recommend to read Pablo's 2008 presentation about DEPLIB  for ideas on how to write your own ROP tool.
Sorry for the lack of images or screenshot, but i'm actually should be spending all my free time getting my research done for Blackhat.

The picture on this post was taken by Igor Siwanowicz

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.

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:

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:

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.

jueves, 24 de septiembre de 2009

Ekoparty 2009 was a total blast!!

When i decide to write this review I know it was going to be hard to be impartial on this, but the heck with it!

Ekoparty 2009 was a total blast!! Around 500 people got together on the 17 and 18th of September in the cultural center Konex to merry, learn and party a little bit.

The conference has a really interesting line-up, some of the most respected researchers around the globe such as Moxie Morlinspike, Luis Miras, Charlie Miller, Cesar Cerrudo were given insightful and original presentations.

But that's doesn't make a conference good. What it makes this conference the best one in latin america was the venue, the people that came from different part and the level of detail and effort that the organizers invested on every single spot of the conference in order to mix the best of the two worlds: a little bit of business, a little bit of underground.

I gave a turbo talk presentation on the infamous FreeListInUse technique, explaining where it original came from, how was developed and what was the original concept behind it. But sadly it was too much information in such a small amount of time that people not familiar with exploitation couldn't get the real juice about it. Next time (H2HC), i will try to overuse metaphors to explain how things works. (I will post the slides soon)

The great privilege as a speaker, was to use the Juan Pablo's masterpiece the WOPR. He made a replica of the Wargames WOPR, which leds and the corresponding counter and on the back you had a place to set your laptop.

We set a nice stand where we had the chance to gave NOP Certifications, sadly nobody pass this time, we hope that next year we had more people playing! Also some people get to the stand to get a demo of the new internet hype, the SMBv2 exploit which we successfully gave.

As an Argentinian i couldn't be more proud for having a conference such as the Ekoparty to respresent us. It was a really nice time to get together with old friends and met new people.

From this spot, i just want to thanks Fede, Fran, Leo, Jero and Juan Pablo for the great conference they made this year!!

See you next year.
PS: You can find more pictures at: http://picasaweb.google.com/nicowow/EkoParty2009