4 02/2011

02/2011 (02)
4
team
Editor in Chief: Grzegorz Tabaka
grzegorz.tabaka@hakin9.org
Managing Editor: Natalia Boniewicz
natalia.boniewicz@hakin9.org
Editorial Advisory Board: Rebecca Wynn, Matt Jonkman,
Donald Iverson, Michael Munt, Gary S. Milefsky, Julian Evans,
Aby Rao
DTP: Ireneusz Pogroszewski
Art Director: Ireneusz Pogroszewski
ireneusz.pogroszewski@hakin9.org
Proofreaders: Michael Munt, Rebecca Wynn, Elliott Bujan, Bob
Folden, Steve Hodge, Jonathan Edwards, Steven Atcheson
Top Betatesters: Nick Baronian, Rebecca Wynn, Rodrigo Rubira
Branco, Chris Brereton, Gerardo Iglesias Galvan, Jeff rey Smith,
Michael Ortega, Aby Rao, Jason Duke, Khashayar Kashani
Special Thanks to the Beta testers and Proofreaders who helped
us with this issue. Without their assistance there would not be a
Hakin9 Expoiting Software magazine.
Senior Consultant/Publisher: Pawe Marciniak
CEO: Ewa Dudzic
ewa.dudzic@hakin9.org
Production Director: Andrzej Kuca
andrzej.kuca@hakin9.org
Publisher: Software Press Sp. z o.o. SK
02-682 Warszawa, ul. Bokserska 1
Phone: 1 917 338 3631
www.hakin9.org/en
Whilst every effort has been made to ensure the high quality of
the magazine, the editors make no warranty, express or implied,
concerning the results of content usage.
All trade marks presented in the magazine were used only for
informative purposes.
All rights to trade marks presented in the magazine are
reserved by the companies which own them.
To create graphs and diagrams we used program
by

Mathematical formulas created by Design Science MathType
DISCLAIMER!
The techniques described in our articles may only
be used in private, local networks. The editors
hold no responsibility for misuse of the presented
techniques or consequent data loss.
Dear Readers,
From an unknown start a decade ago format string vulnerabilities
have become a common means to exploiting system applications.
In this issue you will look at format strings in the C and C++
programming languages. In particular, how these may be abused.
You will also learn how the attackers can bypass sophisticated
protection mechanisms to compromise remote machines all over the
world and how to switch the whole password verification off.
If you are interested how an attacker can exploit the vulnerability
to successfully exploit code and even bypass control such as
Address Space Layout Randomization, read the article Exploiting
Format Strings with Python written by Craig Wright. The author will
demonstrate how the simple but still often overlooked vulnerabilities
can be used to read arbitrary locations from memory, write to memory
and execute commands and finally to gain a shell.
I highly recommend you to read the second part of Smashing the
Stack of Mariano Graziano and Marco Balduzzi. This time the
authors will describe the different protection mechanisms that have
been introduced in modern operating system to make exploitation
more difficult. You will understand popular workarounds used by
attacker to bypass such techniques. You will also analyze a real
exploit for a Acrobat Readers stack-based buffer overflow.
In the article Webapp Exploitation in a Shared Hosting Environment
Richard Cruse will outline an idea on how to gain access into hosting
accounts (via shell injection) on shared hosting services. You will see
how to use common web browser and command line utilities in order
to gain full access to systems running Joomla, and OsCommerce.
If you want to know the pros and cons of enabling SSL inspection
on a gateway read the article Inspecting Https Traffic On Gateways
written by Kishin Fantani.
To learn to bypass the checks to get the things done your way read
Reversing EXE witht OllyDbg written by Nilesh Kumar.
And do not miss the second part of Cracking Java Applications Using
AOP writter by Daniel Drozdzewski who will present the reader with a
bit more advanced use of AOP, which will allow us to reverse engineer
obfuscated Java applications. He will show a trick of password post
selection, and you will gain the knowledge how to switch the whole
password verification off. Enjoy the reading!
Natalia Boniewicz
& Hakin9 Team
6 02/2011
CONTENTS
ATTACK PATTERN
8 Cracking Java Applications Using AOP
Exploits (part 2)
By Daniel Drozdzewski
AOP has been used in the domain of Software Security
before. Its use was mainly for validation, auditing and
authorization purposes, which in turn improve software
security as a whole. Those crosscutting concerns are
being woven into the existing software after the fully
functional code has been delivered. Making the process
two staged, allows separating the responsibilities. In the
second part of the series, Daniel will present the reader
with a bit more advanced use of AOP, which will allow
us to reverse engineer obfuscated Java applications.
On top of that he will show a trick of password post
selection, which we use to find parts of the code crucial
to password processing, which in turn will allow us to
switch the whole password verification off.
14 Exploiting Format Strings with Python
By Craig Wright
Format string attacks are not particularly new. Since
their widespread public release in 2000, format string
vulnerabilities have picked up in intensity as buffer
overflows become less common and more widely known.
From an unknown start a decade ago, they have become
a common means to exploiting system applications.
These vulnerabilities remain an issue as we still teach
them. It is not uncommon for format string vulnerabilities
to allow the attacker to view all the memory contained
within a process. This is useful as it aids in locating
desired variables or instructions within memory. With this
knowledge, an attacker can exploit the vulnerability to
successfully exploit code and even bypass control such
as Address Space Layout Randomization. In this article
Craig will discuss crafting attacks using python in order
to attack through DPA (Direct Parameter Access) such
that you can enact a 4-byte overwrite in the DTORS and
GOT (Global Access Table) and prepares the reader for a
follow-up article on exploiting the GOT and injecting shell
code. Craig demonstrates how these simple but still often
overlooked and even taught vulnerabilities can be used
to read arbitrary locations from memory, write to memory
and execute commands and finally to gain a shell.
20 Smashing the Stack 2
By Mariano Graziano and Marco Balduzzi
Modern operating systems come with sophisticated
protection mechanisms to prevent one-click exploitations.
But, how can attackers bypass such techniques to
compromise remote machines all over the world? And
downloading PDF documents is always a safe practice?
Mariano and Marco will describe the different protection
mechanisms that have been introduced in modern
operating system to make exploitation more difficult.
They will aslo present several popular workarounds used
by attacker to bypass such techniques. Finally, they will
analyze a real exploit for a Acrobat Readers stack-based
buffer overflow.
DEFENSE PATTERN
28 Inspecting Https Traffic On Gateways
By Kishin Fantani
In the past, security devices inspecting application
content for attack patterns, misuse or malware, had been
blind to encrypted traffic and because of this, encrypted
protocols such as Hypertext Transfer Protocol Secure
(HTTPS) have been a safe method used by attackers
to bypass security inspection. Though reverse proxies
and Web Server modules have been there for long, they
only inspect incoming traffic e.g. connections made to
protected web servers in the organization. Inspecting
outgoing traffic or traffic of connections made by users
to outside world servers not protected by the device, had
been on the wish lists. These days, devices come with
the capability to inspect Secure Sockets Layer (SSL)
based outgoing traffic, however there are some concerns
www.hakin9.org/en 7
CONTENTS
by enabling such kind of inspection. In this article we cover some basics
of SSL, the challenges in inspecting SSL traffic, and also see how Check
Points HTTPS Inspection feature is able to inspect HTTPS traffic at the
gateway. After reading this article you will know the pros and cons of
enabling SSL inspection on a gateway.
34 Webapp Exploitation in a Shared Hosting
Environment
By Richard Cruse
Web applications are a concept that is quickly becoming the norm for the
modern individuals online presence. Whether someone is looking for a
full featured E-Commerce solution, or simply wants to be able to post
images and text to a blog when the mood takes them, there is a webapp/
CMS capable of fulfilling that functionality, with little to no background
knowledge required from the user. Richard will outline an idea on how to
gain access into hosting accounts (via shell injection) on shared hosting
services. Exploiting properties of session authentication, unregistered
POSTS and un-sanitized global inputs. You will learn how to use common
web browser and command line utilities in order to gain full access to
systems running Joomla, and OsCommerce.
REVERSE ENGINEERING
38 Reversing EXE witht OllyDbg
By Nilesh Kumar
What is reverse engineering (RE)? Normaly, the source code is in human
readable form, object files are binary files with human-readable symbols.
Executables are pure binaries. When we attempt to revert a binary
executable into its object form, it is called disassembly. Converting an
object file into source code is c alled decompilation. The whole process is
called reverse engineering. Nilesh illustrates the reverse engineering of a
sample executable file, and how to patch it. You will learn how to reverse
engineer an exe. The ultimate goal of RE is to bypass the checks to get the
things done your way. The process of RE may differ person to person, and
program to program.
8
ATTACK PATTERN
02/2011 www.hakin9.org/en 9
Cracking Java Applications Using AOP (Part 2)
I
n the second part of the series, we will present
the reader with a bit more advanced use of AOP,
which will allow us to reverse engineer obfuscated
Java applications. On top of that we will show a trick of
password post selection, which we use to find parts of
the code crucial to password processing, which in turn
will allow us to switch the whole password verification
off.
Introduction
AOP has been used in the domain of Software Security
before. Its use was mainly for validation, auditing and
authorization purposes, which in turn improve software
security as a whole. Those crosscutting concerns are
being woven into the existing software after the fully
functional code has been delivered. Making the process
two staged, allows separating the responsibilities.
Programmers implement the business logic, while
security professionals implement antidotes to known
software vulnerabilities. AOP involvement in improving
of software security goes further, as it also facilitates
clear definition of security concerns as one-time
security policy implementations, rather than security
code scattered and tangled across the whole of
the codebase. Making the actual implementation of
security smaller, means that it is understood better, it
is more transparent and less open for implementation
errors.
We have not found many resources, where AOP
was used to reverse engineer or to compromise
applications. We have certainly not seen the method
of security key post-selection, which we present in this
article, which guides to find the data path in the software
that the crucial security information, like license key or
password, takes. This fact alone does not mean that
such work has not been done before, so if the reader
knows of any similar work, the author would be grateful
for contacting him about it. Also if you could see a way to
improve the presented method or any of the techniques,
the author would also appreciate any pointers in the
direction of improvement.
In the first part of the series (http://hakin9.org/
exploiting-software-12011/), we have introduced the
basic concepts and notions used in AOP. We have also
guided the reader through an example that solidified all
the theory presented there.
In the second part we will continue with the theme
of reverse engineering and modifying software as a
post-production process. The post-production software
modification aspect is very important from a security
point of view. The ability to find the details of inner
workings of an application is a very powerful tool for
many Software Security professionals. The ability to
dynamically modify the behavior of the code (post-
production) is even more powerful tool still. And post-
production in reality means: without an access to the
source code.
Whether through your work or hobby, you wear black
or white hat, we hope you will find the article informative
and educational.
Although the author is a Java programmer by trade,
you dont have to be one in order to successfully follow
the methods, techniques and findings. Please keep in
mind that AOP as a technology is implemented in most
modern programming languages and transplanting our
findings to your favorite technology stack should be a
matter of mere syntax. It is also authors intention to
improve the security and art of secure software delivery
through educating, rather than to cause mayhem
among software industry.
As in part 1, we will use Eclipse + AspectJ
Development Tool.
In the first part, we have introduced the concept of Aspect Oriented
Programming. Through very simple practical example, we have
shown the capability of AOP, its tools and techniques, which could
be used to reverse engineer or even to modify the behavior of a
code.
Cracking Java
Applications using AOP (Part 2)
20
ATTACK PATTERN
02/2011 www.hakin9.org/en 21
Smashing the stack 2
W
elcome to this follow-up on our previous article
on the exploitation of software vulnerabilities,
which we published on Hakin9 ES #1 [0].
This article is made of two chapters: In the first one we
describe the different protection mechanisms that have
been introduced in modern operating system to make
exploitation more difficult. We then present several
popular workarounds used by attacker to bypass
such techniques. Finally, for the joy of our readers, we
analyze a real exploit for a Acrobat Readers stack-
based buffer overflow (CVE-2010-2883).
Protection Mechanisms Against Buffer
Overflow
In this chapter we present the protection mechanisms
introduced in Windows 7 and the Visual Studio 2008
suite to enhance the security of their users by preventing
one-click easy exploitations.
At a first glimpse, we can divide these mechanisms in
three classes of categories:
Compiler-based: the /GS flag
Linker-based: the /SafeSEH flag, ASLR and DEP
Runtime checks
Bufer Security Check /GS
We start by analyzing the /GS flag provided by the
Visual Studio C/C++ compiler. This option tries to
prevent stack-based buffer overflow at runtime by
adding specific code to the procedures prologue and
epilogue. Firstly a random value, called cookie or
canary, is stored on the stack, and a sort of variable
reordering is done.
Once the program is launched, the cookie is saved
in the .data section, then, if necessary, during the
procedure prologue is moved on the stack between
the local variables and the ret address (the value we
are going to protect). In a generic situation the stack
appears like in Figure 1.
Figure 2 shows how to enable/disable this flag on
Visual Studio 2008.
This is the new prologue using the /GS flag:
vuln!main:
00411260 55 push ebp
00411261 8bec mov ebp,esp
00411263 83ec4c sub esp,4Ch
00411266 a100604100 mov EAX,dword ptr [vuln!__security_
cookie (00416000)]
0041126b 33c5 xor EAX,ebp
0041126d 8945fc mov dword ptr [ebp-4], EAX
As someone can see, the value of the cookie is stored
in the EAX register, xored with the base pointer and
put on the stack.
Modern operating systems come with sophisticated protection
mechanisms to prevent one-click exploitations. But, how can
attackers bypass such techniques to compromise remote machines
all over the world? And downloading PDF documents is always a
safe practice?
Smashing
the Stack 2
Figure 1. /GS stack situation

Figure 2. /GS on Visual Studio 2008
28
DEFENSE PATTERN
02/2011 www.hakin9.org/en 29
Inspecting Https Traffic On Gateways
T
hough reverse proxies and Web Server modules
have been there for long, they only inspect
incoming traffic e.g. connections made to
protected web servers in the organization. Inspecting
outgoing traffic or traffic of connections made by users
to outside world servers not protected by the device, had
been on the wish lists. These days, devices come with
the capability to inspect Secure Sockets Layer (SSL)
based outgoing traffic, however there are some concerns
by enabling such kind of inspection. In this article we
cover some basics of SSL, the challenges in inspecting
SSL traffic, and also see how Check Points HTTPS
Inspection feature is able to inspect HTTPS traffic at the
gateway. After reading this article you will know the pros
and cons of enabling SSL inspection on a gateway.
Secure Sockets Layer (SSL) Basics
Protocols such as HTTP, SMTP, POP3 are plaintext i.e.
data carried by these protocols can be read by anyone
who is able to intercept the traffic while in transit. Since
these protocols are widely used over the Internet, there
is a need to secure them in order to protect users data.
By protection of data we are looking at confidentiality,
integrity and authentication.
Instead of building security measures in all the application
protocols, the Secure Sockets Layer (SSL) protocol
provides a secure channel below the application layer
thereby making it easier than to make an application
protocol a secure protocol. SSL is prominently used to
protect the HTTP protocol making it HTTPS. Today it is also
used to tunnel an entire network stack, creating a VPN.
The SSL specification was developed by Netscape
communications. After its version 3.0, a new Internet
standard protocol was defined and called Transport
Layer Security (TLS). The first version of TLS, version
1.0, was kind of an upgrade to SSL 3.0 with a few
enhancements. Most web browsers and servers today
support TLS 1.0, though versions 1.1 and 1.2 were
also defined later, many browsers and applications are
yet to support them. Throughout this article, we may
commonly refer to both, SSL and TLS, as SSL.
How SSL/TLS Work
SSL provides:
Confidentiality the data passing through SSL is
encrypted using a symmetric encryption algorithm
like DES, 3DES, RC4, AES etc.
In the past, security devices inspecting application content for
attack patterns, misuse or malware, had been blind to encrypted
traffic and because of this, encrypted protocols such as Hypertext
Transfer Protocol Secure (HTTPS) have been a safe method used by
attackers to bypass security inspection.
Inspecting Https
Traffic On Gateways
Figure 1. SSL providing security below application and above
transport layers

Figure 2. Browsers display company name in green for Extended

Validation certicates
34
DEFENSE PATTERN
02/2011 www.hakin9.org/en 35
Webapp Exploitation in a Shared Hosting Environment
W
e will learn how to use common web browser
and command line utilities in order to gain
full access to systems running Joomla, and
OsCommerce. The author assumes prior knowledge of
POST/GET methods and a basic working knowledge
of the Joomla, Wordpress, and Oscommerce content
management systems, and an understanding of SQLi
processes.
Introduction
Web applications are a concept that is quickly becoming
the norm for the modern individuals online presence.
Whether someone is looking for a full featured
E-Commerce solution, or simply wants to be able to
post images and text to a blog when the mood takes
them, there is a webapp/CMS capable of fulfilling that
functionality, with little to no background knowledge
required from the user. Long since gone is the days
of html based websites written in notepad, or badly
developed pages made in FrontPage, web2.0 is here
and people are making full use of it.
By the end of this article, one will have a basic
fundamental understanding of the practices used for the
exploitation of common content management systems
and webapps live on the internet today.
At the time of the writing of this article, the current
versions of the analyzed webapps are as follows:
Joomla: 1.5.23/1.7
OsCommerce: 2.31
Of these platforms, the only one which has current
generation exploits is osCommerce; Joomla has
vulnerabilities up to one revision prior to current
release. While this may seem like a halting point for
this article, in my experiences, I have found far more
outdated instances of these softwares in a 1000+
server farm environment, then current versions.
Users appear to be blissfully unaware of what security
patches are, or just dont seem to be overly worried
about keeping their programs current. This is much
the same way that many modern OS level exploits still
remain dangerous, such as the holes leveraged by
confcker.b or quakbot.a.
Body
And now its time to roll up our sleeves, and dive into
this face-first. For the sake of this article, we will be
using a shared hosting server, running UNIX, with PHP
5.2 and MySQL 5. We need to first start by identifying
the characteristics we need for our exploits to work
successfully. Be this via versioning, or via guesswork
and fuzzing to see whats installed on a box.
In this article we will outline an idea on how to gain access into
hosting accounts (via shell injection) on shared hosting services.
Exploiting properties of session authentication, unregistered POSTS
and un-sanitized global inputs.
Webapp Exploitation
in a Shared Hosting Environment
Figure 1. Password reset window with the token as Figure 2. Successful XXS example
REVERSE ENGINEERING
38 02/2011
Reversing EXE with OllyDbg
www.hakin9.org/en 39
S
o what is reverse engineering (RE)? Wikipedia
says: Reverse engineering is the process of
discovering the technological principles of
a device, object, or system through analysis of its
structure, function, and operation. Normally, source
code is compiled to one or more object files which are
then linked to form an executable. The source code is
in human readable form, object files are binary files
with human-readable symbols. Executables are pure
binaries. When we attempt to revert a binary executable
into its object form, it is called disassembly. Converting
an object file into source code is called decompilation.
The whole process is called reverse engineering
(Figure 1).
Goals of RE:
The main goals of RE may include the following:
Security/Vulnerability Research: The most common
aim of doing RE is the discovery of potential
flaws in the source code such as buffer overflows
or any weak business logics implemented, for
example client side validations, weak/homemade
encryptions schemes etc. These can be highlighted
and may ultimately determine how how secure or
insecure the software is.
Malware research: Understanding behavior and
property of malware is very necessary in order to
develop a mitigation plan ... how they behave, how
they propagate, what flaws they exploit, etc.
Writing drivers: Sometimes writing a driver for your
hardware requires reverse engineering in order to
gain a deep understanding of its operation
Patch Analysis: Before applying patches they can
be reverse engineered to take deep dive into their
inner functionalities.
A little Dive Into Assembly and Registers
Knowledge of assembly is required to perform a
successful RE of a program. Although study of
assembly and instruction sets is a separate topic in
This article is a basic introduction to Reverse Engineering. I have
chosen to illustrate the reverse engineering of a sample executable
file, and how to patch it. The article focuses primarily on a practical
example of reversing.
Reversing EXE with
OllyDbg
Figure 1. RE Process

Figure 2. Stack

Next Issue of
If you would like to contact Hakin9 team, just send an email to
en@hakin9.org. We will reply a.s.a.p.
will be available to
download on
November 22
nd
A Quick hands on Introduction to
Packing
DPA Exploitation and GOTs with Python
The Logic Behind Application
And much more...