crazylazy.info

COTS - there's a similar German word

The typical Windows scenario, Common Of The Shelf binary, leads to reverse engineering the target application to gain insight. Finding vulnerabilities can be a time-consuming task. Here're some motivating techniques to save tons of time.

Don't give up, just because...

The general methodology is quite self-explaining - similar for every audit process:

1. behavior analysis:
   • how does the target look like,
   • which dialogues occur,
   • which files are required, what are the paths,
   • installer process,
   • uninstall process,

The hardended heap

What a long headline...

The attack surfaces of modern NT 6 systems shifted. Nowadays there's no generic way to bypass heap protection mechanisms. There're many requirements to meet to exploit vulnerabilities with current approaches. In the following this is a about attacking heap data (application specific) and not heap metadata (generic).

The Heap and its Memory API

A non Un-Shakespearian matter

There're mainly two things I wanted to write about regarding Shellcode. However my time is limited... and therefore I kept it short and simple this time.

The two things this mainly is about are:

• dnscat
• (lesser known) Shellcode tools

If your exploit is a rocket, it targets the vulnerable entry point, and the rocket's load is the Shellcode. Normally, when it comes to memory corruptions due exploitation attempts, the program flow alteration directs the EIP into this (pay)load. So instead of crashing your program continues doing what you wanted it to do.
At the point where the EIP doesn't get NOPs e. g. it expects carefully formated instructions (read: Shellcode).

Fix your bugs!

I recently had an interesting discussion with several people involved into software-development of certain product that not the most secure in the planet. In fact it's one these projects whose names regularly pop up in various advisories. What a great popularity push...
It doesn't seem to bother anybody. Because: "Soon Vista will be the standard and that will mitigate these attacks."

Implicit and explicit

Implicit security - let's define that for a moment - is security that is built in into a platform. If you plan to deploy for Windows Vista there're a bunch of security enhancements that come with the newer operating system. Therefore you passively inherit at least some security - as long as you don't run stuff in compatibility mode.

Stack buffer overflows are extinct

Exploiting stack buffer overflows on modern operating systems is harder these days, because lots of mitigations are to overcome.
For example on Windows there's not only /GS - which is activated by default on Visual Studio nowadays - but also nx stack pages, ASLR, DEP and what not. This may lead to return-oriented attacks, but I personally think that even secure programming has improved in case of stack buffer overflows. So they're rare and relatively cumbersome to exploit, because they're understood and mitigated.

Because it's a passion

Soon after I started with writing exploits I found out that I'm copying tutorials and performing attacks that have been created by people whose insight-level is far greater than mine. But I always wanted to at least document a bunch of things that fascinate me regarding the art of exploitation - and contribute at least something to the whole.

Therefore I decided to begin with summing up stuff that matters - to me. For now. This is not a smart-arse competition. I simply have got some time left and this is just another blog that deals with that special computer science topic.

Is everybody being deceptive?

When we're not there, we aren't there to know that we're not there.

I recently listened to the 7th episode of the Social Engineering podcast. - That made me take some notes, and I think I remember some quotes.
In short it was simply about using familiar routines - or those routines which should be familiar - in order to successfully blind somebody else's mind into a routine workflow.