Saturday, July 7, 2012

Keylogging with Win32 Hooks

Keylogger (from Wikipedia):
Keystroke logging is the action of tracking (or logging) the keys struck on a keyboard, typically in a covert manner so that the person using the keyboard is unaware that their actions are being monitored.

It may seem strange, but there're many keylogging methods. People are getting more inventive as it comes to obtaining other people's secrets.
Protecting your secrets becomes challenging task. Even more than you can think of. Depending on your level of paranoia, perhaps you have to make sure that:
  • you're not using wireless keyboards
  • your keyboard installed directly into computer, and that there's no external device attached in between
  • you're using silent keyboard for preventing acoustic cryptanalysis attacks, and if you don't have one - you have to install random keypress sound generating machine
And I didn't even mention software-based threats!

Typical keylogger paranoid
Read the following excellent article, written by Nikolay Grebennikov, current CTO of Kaspersky Lab, where he outlines keylogger history including several publicized keylogging incidents.

Monday, April 30, 2012

Simple Structured Exception Handling (SEH) Exploit Example

In this post I will demonstrate how to exploit Structured Exception Handling (SEH) buffer overflow vulnerability on x86 systems.

What is Structured Exception Handling and how it works?

Microsoft's Structured Exception Handling is a mechanism for handling hardware and software exceptions (both system and user defined), which allows recovering from errors and perform cleanup if necessary instead of terminating a program immediately.

The SEH represented as a linked list, whose records are stored on the stack. To ease access to this SEH chain, its head pointer maintained in Win32 Thread Information Block (TIB) structure. The TIB structure stores information about currently running thread. On x86 systems, the FS segment register points on TIB structure. SEH chain head located at offset 0x00, and therefore, you can refer to SEH chain head as FS:[0].

Each entry (_EXCEPTION_REGISTRATION_RECORD structure) consists from two 4-byte pointers:
  1. Pointer to the next exception registration record in the chain
  2. Pointer to the exception handling routine
The chain's last record always contains 0xFFFFFFFF value as the "next entry" and pointer to OS default exception handler routine (located in ntdll.dll!FinalExceptionHandler)

Saturday, April 14, 2012

Return-Oriented Programming (ROP) Exploit Example

In this post I will show a simple vulnerability exploitation example using return-oriented programming (ROP) technique.


You found stack buffer overflow vulnerability in a program, but the target environment protected with Hardware-enforced Data Execution Prevention (DEP) mechanism. Briefly speaking, this security feature allows marking certain parts of memory as non-executable, i.e. stack or heap memory pages.

Therefore you can't just overwrite the saved eip address with jmp esp instruction and execute the shellcode from the stack (attempting to run code from the stack will cause a STATUS_ACCESS_VIOLATION exception).

Return-Oriented Programming (ROP) technique

This technique uses existing instruction sequences from loaded modules. No function calls, no any other intentionally placed instructions execution! Because all the executed instructions are located at executable memory pages, this allows us to bypass Hardware-enforced DEP mechanisms.

Shacham et al. state that ROP, given any sufficiently large codebase to draw on, is a Turing-complete exploit language, which means that it can simulate any other language.
More information, including historical facts and detailed explanation, can be found in these slides.

Saturday, February 18, 2012

Understanding the VS C++ Compiler's Buffer Security Check

In this post I will show how VS C++ compiler implements the so called stack canary protection against stack buffer overflows.

Buffer Security Check

This technique is used to detect stack buffer overflow in order to prevent execution of malicious code. It simply places arbitrary value (security cookie) between local variables and return pointer.

Most common attacks overwrite memory starting from addresses referenced by local variables with intent to overwrite return pointer (from lower to higher memory addresses - see Stack representation below). If such attack will take place, security cookie will be overwritten as well.

By simply comparing stored and original values just before exiting the function we ensure return pointer integrity.

Stack representation with security cookie in place (__cdecl convention):

(Lower memory addresses)
Local variable #2
Local variable #1
Security cookie
Base pointer
Return address pointer
Function parameter #1
Function parameter #2
(Higher memory addresses)

Sunday, January 8, 2012

Minesweeper patch: Stop the timer

In this post I will demonstrate how to patch the Minesweeper game: the task will be to stop the timer from incrementing its count.

The task requires some basic assembly language knowledge. If you don't have that knowledge, then Art of Assembly is a great book to start with.

The executable I will be working on is Windows XP version of Minesweeper, called winmine.exe. The file is also available here (MD5=9c45d38b74634c9ded60bec640c5c3ca), download it and rename it to winmine.exe.

The symbols file is required as well. You can download it using symchk command-line tool (which is part of Debugging Tools for Windows), with the below parameters:
symchk /s SRV*c:\symbols* /if winmine.exe
I will use IDA disassembler (freeware version available here) for generating the assembly source code from winmine.exe executable. To simplify the demonstration, I'm loading the symbols file (winmine.pdb) to IDA as well. Otherwise, function names, for example, will have meaningless names in generated code.