This document discusses structured exception handling (SEH) and exploitation techniques. It provides background on SEH, how it is used to handle exceptions in Windows, and protections like SafeSEH. It then describes exploiting a vulnerability found through fuzzing the BigAnt Messenger Server application by overwriting SEH pointers and injecting shellcode. Exploitation steps include understanding the application, finding a crash through fuzzing, removing bad characters, and developing an exploit to gain control.

1. SEH Based
Exploitation
By
Karun

2. Who am i
 An avid security enthusiast and holding
4+years of experience in the field of
information security. Currently working for
ADP into network forensics.

3. Basics
 Vulnerability
 Exploit
 Payload(Shell code)
 CPU registers(X86 CISC)
 SEH(Structured Exception Handling)
 SafeSEH
 Ollydbg
 Back|track

4. Wat is SEH
structured exception handling is a uniform way of handling all exceptions
that occur during the normal course of process execution. In this context,
an exception is defined as an event that occurs during execution that
necessitates some form of extended handling.
Hardware exception:
This is used to categorize exceptions that originate from hardware. For
example, when a program makes reference to an invalid memory address,
the processor will raise an exception through an interrupt that gives the
operating system an opportunity to handle the error. Other examples of
hardware exceptions include illegal instructions, alignment faults, and other
architecture specific issues.
Software Exception:
The second type of exception is known as a software exception.
A software exception, as one might expect, originates from software rather
than from the hardware. For example, in the event that a process attempts
to close an invalid handle, the operating system may generate an
exception.

5. SafeSEH
In Windows XP SP2 and Windows Server 2003 the windows
exception handler makes use of a new protection feature
called SafeSEH. Essentially SafeSEH is a linker option can be
used when compiling a executable module. When this
option is enabled in a module, only addresses listed as on a
registered SEH handlers list can be used as SEH Handlers
within that module. This means that if you try to use address
that isn't on the registered handlers list, from a module
compiled with /SafeSEH ON, the SEH address will not be
used by the windows exception handler and the SEH
overwrite will fail.
In addition, there is also a
IMAGE_DLLCHARACTERISTICS_NO_SEH flag, which when set
on a DLL prevents any addresses from that DLL being used
as SEH Handlers.
Both of these DLL flags constrain the potential locations in
which we can look for SEH overwrite addresses.

6. Required Software on
Attacking and Victim Systems
The attacking system requires the following software:
Perl interpreter
 Python interpreter
 Metasploit 3.x
 Netcat
 generatecodes.pl
 comparememory.pl
The victim system requires the following software:
 BigAnt Server 2.52 SP5
 OllyDbg 1.10

7. BigAnt Application
 BigAnt Messenger Server is a secure and
stable messaging application designed to
provide efficient and private
communication over networks of any size.

8. Ways of Finding a vulnerability
 Source Code Review
 Reverse Engineering
 Fuzzing
Fuzzing:
Fuzz testing or fuzzing is a software testing
technique used to discover coding errors and
security loopholes in software, operating
systems or networks by inputting massive
amounts of random data, called fuzz, to the
system in an attempt to make it crash.
The fuzzer code we are going to use if a simple
fuzzer written by Aaron Conole .

9. Procedural Flow
 Understand the application completely.
 Fuzz all the fields unless you create a crash in
the program.
 Confirm the Fuzz value by double check, for
that you need to create the crash for couple
of time.
 Once your are done with the crash value, its
time to develop the exploit by which we can
take control of the crash and make our
payload run.

10. Procedural Flow
 One important point is to find the bad
characters in our code and remove them.
 Known bad characters.
 Characters that application treats in entirely
different way.
 Remove both the above characters and
make you payload stable and tight.

12. Other security measures.
 Stack cookies (GS Switch cookie)
 SEHOP
 Data Execution Prevention (DEP)
(software and hardware based)
 Address Space Layout Randomization
(ASLR)

13. References
 Corelan.be
 Uniformed.org

14. Any Questions?
Thank You…
Karun
Karun.guduru@gmail.com
+91-90001-41621