crazylazy.info

There’s no Valgrind

One of the particular tools I like on MacOS and Linux to verify an application’s upright memory behavior is Valgrind. On Windows there’s some interesting Microsoft software worth gaining familiarity with. Practically only the Application Verifier is aiming into Valgrinds direction.

Application Verifier

Application Verifier is designed specifically to detect and help debug memory corruptions and critical security vulnerabilities.

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

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.

Malicious Office Documents

On very common entry point these days are malicious office documents. If you've got no idea on how interactive these "documents" can get, take the test at decloak.net (Start button). You'll get a .doc file that's performing network connections and in this case bypassing antonymization technologies.

Great new features

Microsoft designed a powerful Debugging Engine, however the offical frontend lacks the useability ollydbg or Immunity Debugger have.
There're only a few useful extensions I know of.

Byakugan is an awesome set of extensions for WinDBG. It's is based on MS Detours.
And there's msecdbg aka "!exploitable".
Both are interesting to speed up writing exploits. Combining the power of these Debugging extensions with the insights IDA offers seems to be promising: