Ldap Injection

HITB Magazine Keeping Knowledge Free Volume 1, Issue 1, January 2010 www.hackinthebox.org Cover Story LDAP Injection 09 Attack and Defence Techniques HITB Magazine Volume 1, Issue 1, January 2010 Editorial Editor Zarul Shahrin Dear Reader, Editorial Advisor Welcome to 2010 and to our newly ‘reborn’ HITB ezine! As Dhillon Andrew Kannabhiran some of you may know, we’ve previously had an ezine that used to be published monthly, however the birth of the HIT- Design BSecConf conference series has kept us too busy to continue working on it. Until now that is... Cognitive Designs As with our conference series, the main purpose of this new [email protected] format ezine is to provide security researchers a technical Contributing Authors outlet for them to share their knowledge with the security community. We want these researchers to gain further recog- Gynvael Coldwind nition for their hard work and we have no doubt the security Christian Wojner community will find the material beneficial to them. Esteban Guillardoy We have decided to make the ezine available for free in the Facundo de Guzman continued spirit of HITB in “Keeping Knowledge Free”. In addi- Hernan Abbamonte tion to the freely available PDF downloads, combined editions Fedor V. Yarochkin of the magazine will be printed in limited quantities for distri- bution at the various HITBSecConf’s around the world - Dubai, Ofir Arkin Amsterdam and Malaysia. We aim to only print somewhere Meder Kydyraliev between 100 or 200 copies (maybe less) per conference so be Shih-Yao Dai sure to grab a copy when they come out! Yennun Huang As always we are constantly looking for new material as well Sy-Yen Kuo as suggestions and ideas on how to improve the ezine, so if Wayne Huang you would like to contribute or if you have a suggestion to send over, we’re all ears :) Aditya K Sood Happy New Year once again and we hope you enjoy the zine! Marc Schönefeld Hack in The Box – Keeping Knowledge Free Zarul Shahrin http://www.hackinthebox.org Editor-in-Chief, http://forum.hackinthebox.org [email protected] http://conference.hackinthebox.org Cover Story Xprobe2-NG LDAP Injection Low Volume Remote Network Information 09 Attack and Defence Techniques 18 Gathering Tool Exception Detection Malware Obfuscation 03 on Windows 25 Tricks and Traps Reconstructing Dalvik Contents 07 The Art of DLL Injection 39 Applications Using UNDX 02 JANUARY 2010 Keeping Knowledge Free HITB Magazine www.hackinthebox.org Exception Detection on Windows By Gynvael Coldwind, HISPASEC ulnerability researchers use various techniques in case the application does not handle the exception for finding vulnerabilities, including source code after having a chance to do so). Vanalysis, machine code reverse engineering and A big advantage of this method, is that it uses the analysis, input data protocol or format analysis, input official API, which makes it compatible with most, if data fuzzing, etc. In case the researcher passes input not all, Windows versions. Additionally, the API is well data to the analyzed product, he needs to observe documented and rather trivial to use - a simple excep- the execution flow in search of potential anomalies. In tion monitor requires only a small debugger loop with some cases, such anomalies can lead to a fault, conse- only a few debug events handled. quently throwing an exception. This makes exceptions However, some closed-source, mostly proprietary, the most observable symptoms of unexpected, caused software contains anti reverse-engineering tricks2, by malformed input, program behavior, especially if which quite often include denial of execution tech- the exception is not handled by the application, and a niques, in case an attached debugger is detected, JIT-debugger or Dr. Watson1 is launched. which makes this approach loose it’s simplicity, Acknowledging this behavior, the researcher might hence anti-debugger-detection methods must be want to monitor exceptions in a given application. implemented. This is easy if the exceptions are not handled, but it Additionally, a debugger is attached to either a run- gets more complicated if the application handles the ning process, or a process that it spawns. To achieve exception quietly, especially if anti-debugging meth- ease of usage, the monitor should probably monitor ods are involved. any spawned process of a given class (that is, from This article covers several possible ways of detect- a given executable file), which requires additional ing exceptions, and briefly describes an open source methods to be implemented to monitor the process kernel-level exception detection tool called ExcpHook. creation3, which decreases the simplicity by yet another degree. Exception detection methods Several exception detection methods are available on Remote exception handler Windows, including the usage of user-mode debug- A more invasive method – however, still using only ger API, as well as some more invasive methods like documented API - is to create an exception handler in registering an exception handler in the context of the the context of the monitored process. The easiest way monitored process, hooking the user-mode exception to achieve this, is loading a DLL into the context of the dispatcher, or using kernel-mode methods, such as monitored process (a common method of doing this interrupt service routine hooks or kernel-mode excep- includes calling OpenProcess and CreateRemoteTh- tion dispatcher hooks. Each method has its pros and read with LoadLibrary as the thread procedure, and cons, and each method is implemented in a different the DLL name, placed in the remote process memory, way. The rest of this article is focused on describing as the thread procedure parameter), and setting up the selected methods. different kind of exception handlers. On Microsoft Windows, there are two different Debugger API exception handling mechanisms: Structured Excep- The most straightforward method of exception de- tion Handling4,5 with the Unhandled Exception Filter6, tection relies on the Windows debugger API and it’s and Vectored Exception Handling7 (introduced in architecture, which ensures that a debugger attached Windows XP). to a process will receive information about every Structured Exception Handling, commonly abbrevi- exception thrown in its context (once or even twice, ated to SEH, is used mostly as a stack-frame member JANUARY 2010 03 HITB Magazine Keeping Knowledge Free www.hackinthebox.org (which makes it a great way to exploit buffer over- routine with an arbitrary jump, and eventually, return- flows by the way8) and if used, is commonly changed ing to the original KiUserExceptionDispatcher (leaving (since every function sets its own exception handler). the environment in an unchanged form, of course). At the architectural level, SEH is an one-way list of This method is quite easy to implement, and quite exception handlers. If non of the exception handlers powerful at the same time. However, it is still easy from the list manages to handle the exception, then to detect, hence inline-hooking leaves a very visible an unhandled exception filter routine (which may be mark. Also, as stated before, creating a remote thread set using the SetUnhandledExceptionFilter function) and loading a DLL is a noisy task, which could alert is called. To allow stack-frame integration, the SEH was anti-debugging mechanisms. designed to be per-thread. Additionally, just like both previous methods, this The other mechanism is Vectored Exception Han- still has to be done per-process, which is not really dling, which is a global (affects all threads present comfortable if one wants to monitor a whole class of in the process) array of exception handlers, always processes. But, if compared to the previous method, called prior to the SEH handlers. When adding a VEH it’s a step forward. handler, the caller can decide whether to add it at the beginning or the end of the vector. Interrupt handler hooking There are two downfalls of this method. First of all, Another approach to exception monitoring is to creating a new thread and loading a new module monitor CPU interrupts in kernel mode. in the context of another application is a very noisy As one may know, after an exception condition event, which is easily detected by the anti-debugging is met, an interrupt is generated, which causes a methods, if such are implied. As for the second thing, handler registered in the Interrupt Descriptor Table keeping the exception handlers both registered and to be called. The handler can be either an interrupt placed first in a row might be a very hard task to gate, trap gate or task gate11, but in case of Windows achieve, especially since SEH handlers are registered exceptions it’s typically an interrupt gate which points per-thread and tend to change quite often, and if a to a specific Interrupt Service Routine, that routes the VEH handler is registered, it could jump in front of the execution to the exception dispatcher. handler registered by the monitor. Additionally, this An exception monitor could hook the exceptions’ may change the flow of the process execution, mak- ISR by overwriting entries in the IDT12. This approach ing the measurements inaccurate. allows the monitor to remain undetected by standard To summarize, this method is neither easy to code, methods used for debugger detection in user land, nor quiet. and at the same time is system-wide, making it possible to monitor all processes of a given class (includ- KiUserExceptionDispatcher ing kernel-mode exceptions, if desired). Additionally, The previous method sounded quite promising, the author can decide which exceptions are worth but the high-level exception API was not good for monitoring, and which not. monitoring purposes. Let’s take a look at a lower, but However, at ISR level, the function does not have still user mode, level of the exception mechanisms on any easily accessible information about the processes Microsoft Windows.

Load more