ttern - Free Web Hosting with PHP, MySQL and cPanel

Editor in Chief: Grzegorz Tabaka
grzegorz.tabaka@hakin9.org
Managing Editor: Natalia Boniewicz
natalia.boniewicz@hakin9.org
team
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, Aby
Rao, Jason Duke, Carlos Alaya, Joseph Werns, Shane Hartman,
Jose L. Herrera
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.
03/2011 (03)
Dear Readers,
A password is a secret word or string of characters that is used
for authentication, to prove identity or gain access to a resource.
It should be kept in secret from those not allowed access. In spite
of this your computer and files are at risk even if you have a user
account password. In this issue you will learn how to protect your
files.
I greatly encourage you to read A Quick „Hands On” Introduction to
Packing of Alain Schneider. In the fascinating article Direct Object
Reference, or How a Toddler Can Hack Your Web ApplicationIn Nick
Nikiforakis will investigate one type of Web application vulnerability,
namely Direct Object Reference, which occurs when an identifier,
used in the internal implementation of a Web application, is exposed
to users. From the article Malware Analysis for Windows Sostems
Administrators Using Sysinternal Tools you will learn about the two
types of malware analysis, static and dynamic as well as the tools
and processes to perform the analysis. If you want to know how
to deploy software and its payload into target computers running
supported operating systems and understand policies and settings
that already exist to block end users on a corporate, government or
educational network from being able to use this software, read the
article Password, what password? Of Christian Mergiliano. And do
not miss the article The Logic Behind Application. Logic Defects of
Rafal Los, especially if you are curious how the hackers have been
exploiting weaknesses in web applications at an alarmingly high
rate. You will see how a hacker maps out the application flow and
determine vulnerabilities before... he comes to exploit application
logic. You will also understand how logic defects in an application
can cause serious business challenges. And finally, to know why
traditional security projects show a high degree of falling back read
the interview with Jan van Bon.
We wish you nice reading!
Natalia Boniewicz
& Hakin9 Team
4
03/2011

CONTENTS
ATTACK PATTERN
8 Malware Analisys for Windows Systems
Administrators Using Sysinternal Tools
By Dennis Distler
Today administrators deal with malware infections
almost daily. Often malware is customized for specific
organizations, departments in an organization, and even
individuals in the organization.
This type of malware typically is not identified by antivirus
products, and it is up to the administrator to identify
the malware. Locating malware purposely designed not
to be detected is difficult, but detection is not impossible.
To identify malware, systems administrators must be
able to perform malware analysis. To detect malware
administrators should understand the types of analysis,
the process and tools used to accomplish malware
analysis. In this article learn about the two types of
analysis, static and dynamic as well as the tools and
processes to perform the analysis.
14 Direct Object Reference or, How a
Toddler Can Hack Your Web Application
By Nick Nikiforakis
There is no point in denying that everyday software
is steadily moving from desktop applications to Web
applications. When you can check your mail, play games,
create documents and file your tax report without ever
leaving your browser, then you are indeed a citizen of the
Web. In this era, many miscreants have changed their
game. It’s easier for them to impersonate you or steal
your private data from a vulnerable Web application than
to take control of the Extended Instruction Pointer (EIP)
register of your CPU.
In this article we will investigate one type of Web
application vulnerability, namely Direct Object Reference.
A Direct Object Reference occurs when an identifier,
used in the internal implementation of a Web application,
is exposed to users. When this is done insecurely, it can
lead to a lot of trouble...
20 The Logic Behind Application. Logic
Defects.
By Rafal Los
It’s no secret that web applications are at the center of the
ongoing conflict between malicious hackers, and those
defending the applications. As more and more critical
business functions migrate to an Internet presence, web
applications play an extremely vital role in business.
Hackers know this well, and have been exploiting
weaknesses in web applications at an alarmingly high
rate. You will see how a hacker maps out the application
flow and determine vulnerabilities before... he comes
to exploit application logic. You will also understand
how logic defects in an application can cause serious
business challenges.
DEFENSE PATTERN
22 Password, What Password?
By Christian Mergiliano
If you have a computer with a non-encrypted hard drive
and have not disabled other media devices from booting
before your hard drive or have not password protected
your BIOS listen up! Your computer and files are at risk
even if you have a user account password.
Christian explains how to deploy this software and
its payload into target computers running supported
operating systems. You will understand policies and
settings that already exist to block end users on a
corporate, government or educational network from
being able to use this software. And you will see what
you, a home user, can do to keep your computer safe
from this attack.
6 03/2011

CONTENTS
REVERSE ENGINEERING
28 A Quick „Hands On” Introduction to Packing
By Alain Schneider
On Windows systems, programs are usually available in the PE file format
with the EXE extension. Although this file format is quite complex, it is now
well documented, so understanding how it is globally supposed to work is
pretty easy and you can find a lot of programs designed to open/analyze/
modify PE executables.
Those which are designed to modify PE files are often called packers. In
this article we will learn how to write one of them.
INTERVIEW
36 Interview with Jan van Bon
By Exploiting Software Team
Traditional security projects show a high degree of falling back specifically
because they are not embedded in a well-functioning management system
– says Jan van Bon. Creating a solid and practical architecture under your
IT management approach can greatly reduce the cost of improving quality,
and it can speed up your projects. An integrated approach requires a
simple and straightforward method that is easy to understand, supported
by available tools in the market, and accepted by many providers. This
kind of approach requires thorough knowledge and sincere dedication.
As with many other initiatives in the field of IT Service Management,
the Netherlands have again produced a fascinating new approach, with
promising results for IT Security projects. Jan will share his thoughts on
risk managment and IT Security development.
www.hakin9.org/en 7

8
ATTACK PATTERN
Malware Analysis
for Widows Systems Administrators Using Sysinternal
Tools
Today administrators deal with malware infections almost daily.
Often malware is customized for specific organizations, departments
in an organization, and even individuals in the organization.
This type of malware typically is not identified by
anti-virus products, and it’s up to the administrator
to identify the malware. Locating malware
purposely designed not to be detected is difficult,
but detection is not impossible. To identify malware,
systems administrators must be able to perform malware
analysis.
Introduction to Behavioral Malware Analysis
for System Administrators
To detect malware administrators should understand
the types of analysis, the process and tools used to
accomplish malware analysis. In this article learn about
the two types of analysis, static and dynamic as well as
the tools and processes to perform the analysis.
Malware analysis is typically performed in a
controlled and isolated lab. In the malware lab,
analysts perform both code and behavioral analysis.
The type of analysis performed first is completely up
to the analyst, and is typically based on the analyst
personal preference.
Code analysis typically starts with looking for
embedded strings in the malware. Next, the malware
is examined with a disassembler, which provides the
analyst with the malwares assembly instructions. The
final stage of code analysis is using a debugger to
analyze the malware as it’s running.
The behavioral analysis process begins by taking
baselines of a system. This baseline can include
services/process’s running on the system, registry
settings (for Microsoft operating systems), users and
groups, file hashes, and network information. After
generating the baseline, the malware is executed on
the system. Once the malware has executed for a while,
the same information is collected again, then compared
to the baseline. After analyzing the differences, its
not uncommon to make changes to the lab to get the
malware to reveal more details about how the malware
functions. These changes can include providing files,
web servers, IRC servers, etc.
However, for administrators responding to a
production system infected with malware often don’t
have the luxury of having baselines to compare against.
Even if the organization has baselines, typically the
baseline is not current, especially with workstations.
Working without current baselines makes it difficult
for the administrator to determine what the malware
installed or what some other software installed. To
assist administrators can use tools such as GMER
(http://www.gmer.net) to assist in help identify malware.
GMER is written to detect rootkits, but can be used
to locate artifacts of malware, but will not locate all
malware. Unfortunately, malware authors use the same
tools as malware analysts to improve the chance their
malware goes undetected. When automated tools fail
to detect, it’s up to the system administrator to detect
the malware.
When analyzing a system infected with malware,
it’s best not to trust the operating system. It’s not
uncommon to have operating systems commands and
tools modified by malware to help evade detection.
It’s best for administrators to bring their own tools
that can’t be modified by malware. The tools used for
analysis can be used to replace most system tools for
live analysis. A word of caution of when performing
behavioral malware analysis, if system is going to have
any forensics performed on the system, the forensics
image acquisition should be performed first.
When forced to manually perform behavioral
analysis there are several helpful tools used to
identify the malware. All tools used in this article
are free of charge and can be downloaded from
03/2011

Malware Analysis for Widows Systems Administrators Using Sysinternal Tools
http://www.sysinternals.com. The following list of tools
will be used to help identify the malware:
• TCPView
• Process Explorer
• Process Monitor
• Handles
• ListDLL
• Autoruns
After downloading the tools, they should be burned
to a CD/DVD or copied to write protected USB drive.
Burning the tools to a CD or using a write protected
USB drive ensures the malware does not modify these
tools.
The behavioral process typically begins by examining
outbound connections from the host. The objective
is to identify which process on the system is actually
generating the outbound traffic. Often times this identified
process is the malicious process, but be aware this could
also just be a proxy for another process or another host.
The next step is to examine the suspicious process.
The examination of this process includes reviewing its
network connections, and strings in the process. The
strings examination includes the process image itself
and strings in memory. Examining strings in memory
can provide more information, especially if the malware
is a packed executable.
Next, any file system or registry changes the malware
makes while running is examined. Additionally any
files, registry keys and dynamic link library (DLL’s) the
malware is using will be examined. When examining
DLL’s it will be critical to being able to identify DLL’s
the malware brought with it or DLL’s already on the
system.
The last stage in the behavioral analysis process is
identifying how the malware loads. It is possible during
this stage to disable malware from running but leaving
Figure 1. TCPView displaying the process generating the traffic
it on the system. Ideally though the malware should be
removed from the system.
For this article a well-known and understood malware
sample known as srvcp.exe was chosen to demonstrate
the behavioral analysis process and tools. For this
article it’s assumed an alert was generated detecting
outbound IRC traffic to irc.mcs.net from a host with the
IP address of 192.168.183.128.
Typically malware is detected by the network traffic
it generates. The level of detail captured will vary
depending on how the information was obtained. The
important information will be the source address and
port, and the destination address and port.
With the system that’s generating the traffic identified
(192.168.183.128), the first tool used will be TCPView
(All tools used in this article should be run with
Administrator privileges). TCPView can be thought of as
a replacement to netstat with a graphical user interface
(GUI). TCPView can be launched using two different
methods. The first method is the standard double click
on the executable and the second method is to run from
the command line. Regardless of which method used
to launch TCPView, the End User License Agreement
(EULA) will be presented.
Running any Microsoft (Sysinternals) tools such as
TCPView from the command line allows the tools to
be scripted to automate data collection. When running
these tools from the command line or in a script, use
the /accepteula flag to suppress the EULA from being
displayed.
After starting TCPView the administrator must
determine if name resolution must be enabled. Some
malware uses host name’s, other malware uses
hardcoded IP addresses. There are two options to
enable or disable name resolution. The first is using
[CTRL-R] keyboard short cut or selecting from the
menu bar Options, Resolve Addresses.
With TCPView started several columns are of interest
to the administrator. The administrator is trying to identify
what is communicating on TCP 6667 to irc.mcs.net. The
first field to examine will be the Remote Address field.
This field will show all remote systems the system is
connected to and on busy systems’ the connection
counts can be in the thousands. After identifying the
Remote Address, look at the Remote Port field to
identify the destination port. Next the administrator will
verify the protocol in use by examining the Protocol
column. Once the remote address, remote port, and
protocol is identified, the two columns labeled Process
and PID (Process Identification) show which process is
generating the network traffic. As seen in Figure 1, the
process generating the traffic is srvcp.exe with a PID of
1024.
In this example the process name looks somewhat
like a legitimate service, but a quick Google search
www.hakin9.org/en 9

10
shows this process is actually malware. However,
often time Google will not be so helpful or the malware
author will infect a windows process such as lsass.exe
or services.exe to hide the malware. When performing
analysis on this type of malware, the same process’s
and tools are used for analysis.
With srvcp.exe process identified, the next steps
will be gathering more information about the malicious
process. The next tool used is Process Explorer, another
tool from Microsoft (Sysinternals). Process Explorer is
a powerful tool that can identify running process and
resources used by that process. Additionally Process
Explorer can be used to identify handles and DLL’s
used by processes, as well as strings in the process
image and in the memory used by the process. Finally
Process Explorer can be used to replace the Windows
task manager. To start Process Explorer double click
processexplorer.exe or on the command line enter in
processexplorer.exe.
With Process Explorer started there are two columns
of interest to the administrator, process and PID. With
the process name and PID identified by TCPView,
locate the process srvcp.exe and it’s corresponding
PID of 1024. With the process identified, right click the
process and click properties. This will bring up a dialog
box with several tabs. Each of these tabs provide a
different piece of information about the process. The
two tabs of interest for behavioral analysis are the TCP/
IP tab and the strings tab.
The first tab to investigate is the TCP/IP tab. When
investigating this tab, the administrator is confirming
ATTACK PATTERN
this is the process to be investigated. Because this
process is talking with irc.mcs.net on TCP 6667, it can
be confirmed this is the correct process as seen in
Figure 2. If the malware is not using name resolution
and only IP address’s are known, uncheck the Resolve
Address’s. Additionally, Process Explorer can be used
without TCPView to identify suspicious traffic, but in
the author’s experience, TCPView speeds the process
up.
After confirmation this is the correct process, next
investigate the strings tab. The strings tab will display
strings found in the process. The strings tab does
have one option of note, the location of which process
to extract the strings from. The options are either
the process image (the executable) or strings from
memory. The administrator should select both options
and making notes about interesting found strings. Items
of interest could include file locations, registry settings,
hostnames, IP addresses, etc. that can provide
more insight into the behavior of malware as seen in
Figure 3.
Next Microsoft (Sysinternals) Process Monitor is
used to identify file, registry, and process/thread
activity. Process Monitor is actually a combination of
two older Sysinternal tools, RegMon and FileMon.
Process Monitor is a very powerful tool, but can lead to
information overload very quickly. With Process Monitor
any type of change will be recorded. This means
anytime a file is read, a registry key is queried, a TCP
packet is sent or many other types operations occurred,
there all captured by Process Monitor.
Figure 2. Process Explorer showing network traffic Figure 3. Strings in Memory identi�ed by Process Explorer
03/2011

Malware Analysis for Widows Systems Administrators Using Sysinternal Tools
Figure 4. Process Monitor displaying network activity
To help with this information overflow, there are two
options that assist. The first is turning Process Monitors
event capture ability on and off. However if this is done
it’s possible to miss critical events. The option is to
use Process Monitors built in filter. The built-in filtering
has many options, but the most common ones used in
malware analysis is Process Name or PID.
During the analysis of srvcp.exe the only activity
identified by Process Monitor is srvcp.exe making a
TCP connection to irc.mcs.net every three seconds as
seen in Figure 4.
In this example only packets sent by srvcp.exe to
irc.mcs.net is captured. However when examining other
malware there will be many different operations. When
seeing these operations, its important to record the
operation type and path it occurred at. This information
can be used to help clean up the malware.
With the process identified, its important to
determine other files and registry keys used by the
malware. There are two excellent tools from Microsoft
(Sysinternals), Handles and ListDLL’s that will be used
by administrators to identify other files, registry keys
and DLL’s used by the malware.
The first tool Handles.exe, a command line only
tool showing any open handle for any process on
the system when Handles.exe is ran. It should be
noted, if the process has opened and closed a handle
before Handles.exe is ran, this handle will not be
seen. Handles.exe is useful when examining malware
that has hooked itself into Windows process such as
services.exe or lsass.exe. When using Handles.exe
Figure 5. Handles.exe ¬–p 1024 –a output showing �les, threads
and registry keys used by srvcp.exe malware
there are two options typically used during malware
analysis. The first option is the –a flag that dumps all
handle information. The second option is the –d PID#
that displays the information for that specific process. If
handles.exe is ran with out any options all files in use by
all process’s will be displayed.
Examining srvcp.exe with handles.exe –a –p 1024
shows a couple of registry keys in use, the directory, the
files and threads used by the malware. The output from
handles.exe –a –p 1024 can be seen in figure 5.
Next the administrator should determine what DLL’s
are in use by the malware. The malware may choose
to use DLL’s on system, or it’s own DLL’s. There are a
few reasons malware install’s it’s own DLL’s, such as no
DLL’s on the system provide the required functionality,
or another reason is because the malware will use
hooked versions of installed DLL’s to hide the malware.
To find the DLL’s used by the malware, Listdlls.exe is
used.
Listdlls.exe has several options, but the two most
common flags are the –v and ¬–d flags. The –v flag is
used to display version detailed information about DLL’s
used by the malware. The –d DLLNAME flag display’s all
process using the specified DLL.
To determine which DLL’s are being used by a
process, run the listdlls.exe #PROCESSNAME, in this example
its srvcp.exe. The output from running listdlls.exe
srvcp.exe is seen in Figure 6.
The output in Figure 6 displays the base address, file
size, and the DLL being used by srvcp.exe.
With a list of DLL’s used by the malware, the
administrator should next run listdlls.exe –d DLLNAME.
This command is used to identify other process using
the same DLL. This is useful to help identify other
process’s using the DLL. For example if malware is
using kernel32.dll its important to determine if the
malware is using a legitimate version or one modified to
help hide the malware from detection.
Next, the administrator should run listdlls.exe –
v srvcp.exe. The output from this command shows
Figure 6. Listdlls.exe output displaying DLL’s used by srvcp.exe
www.hakin9.org/en 11

12
Figure 7. Listdlls.exe –v output
information about the version of the executable as seen
in Figure 7. There are several fields in the output, and
most legitimate DLL’s will have information for each
field. A process that has N/A for most fields should be
considered suspicious, but does not guarantee it’s a
malicious process. In the Verified field, srvcp.exe has
Invalid Signature in it, however this often occurs for
legitimate processes so this field by itself should not be
used as an indicator of malicious software.
With the malicious process identified, files and registry
keys used by the malicious process, the last step is to
identify how the malware start’s up. To find out how the
malware starts Autoruns will be used.
Autoruns, the GUI version or Autorunsc, the
command line version is used to show everything that
starts on the system. Autoruns has multiple tabs, but for
malware analysis the Everything tab as seen in Figure
8 is sufficient. It should be noted the author added
srvcp.exe to startup for this article and is not the normal
behavior of this malware.
Next to each process is a checkbox that determines
if the process will start on the next reboot. If the box is
unchecked, the process will not start when the system
boots. The administrator can reboot the system, and
repeat the analysis to confirm the malware is not
starting on reboot.
With the malware analysis completed the administrator
can use the information to perform several tasks. The
two most critical tasks to performed using the information
collected is to clean the infected systems and use the
Figure 8. Output of Autoruns Everything tab
ATTACK PATTERN
information to detect other systems infected with the
same malware. Another task, depending on the contract
with the organizations Anti-Virus vendor, is submit the
malware for analysis and signature creation.
When performing malware clean up, a systematic
clean up must be performed. The best way to perform
clean up on multiple infected systems is create a script
to clean up. This script can be deployed via Group
Policy or use the Microsoft tool PSExec to run the script
remotely. Before deploying the script, especially scripts
replacing or deleting critical operating system files such
as kernel32.dll, should test the script thoroughly. If the
malware has infected critical OS files it’s recommended
the system be rebuilt.
Additionally using information gathered during the
malware analysis can be used to detect other systems
infected with the same malware. The information to be
used can include the executable, files such as DLL’s,
or registry keys. These can be detected by a systems
management system such as Microsoft Systems
Center Configuration Manager (SCCM), if they are
configured for software inventory. Another option is to
create a script to detect the presence of the malware
and notify the administrator of systems infected with
the malware.
With an understanding the process and tools,
the reader should now be able perform dynamic
malware analysis. Although dynamic analysis is not
comprehensive, it should be sufficient for the reader to
identify malware on infected systems. Administrators
can use the information learned from the dynamic
analysis to clean systems and detect other systems
infected with malware.
DENNIS DISTLER
Dennis Distler (@securitylifer) is an information security
professional with over 10 years experience. In the past
he has held positions in systems administration, network
engineering, network security, security analysis, security
engineering and security consulting in organizations as
small as 6 employees to global enterprises with 70,000 plus
employees. Currently Dennis manages the Information
Security Operations and Engineering Team for a Fortune 500
company. His many responsibilities include forensics, incident
response and malware analysis. Dennis holds multiple
security certi�cations including the GIAC Security Expert
(GSE), the Certi�ed Information Systems Security Professional
(CISSP) and Cisco Certi�ed Security Professional (CSSP).
03/2011

WHAT IS A GOOD FUZZING TOOL?
Fuzz testing is the most efficient method for discovering both known and unknown vulnerabilities in software. It is
based on sending anomalous (invalid or unexpected) data to the test target - the same method that is used by hackers
and security researchers when they look for weaknesses to exploit. There are no false positives, if the anomalous
data causes abnormal reaction such as a crash in the target software, then you have found a critical security flaw.
In this article, we will highlight the most important requirements in a fuzzing tool and also look at the most common
mistakes people make with fuzzing.
PROPERTIES OF A GOOD
FUZZING TOOL
There are abundance of fuzzing tools available. How to distinguish
a good fuzzer, what are the qualities that a fuzzing tool
should have?
Model-based test suites: Random fuzzing will certainly give you
some results, but to really target the areas that are most at risk, the
test cases need to be based on actual protocol models. This results
in huge improvement in test coverage and reduction in test execution
time.
Easy to use: Most fuzzers are built for security experts, but in QA
you cannot expect that all testers understand what buffer
overflows are. Fuzzing tool must come with all the security knowhow
built-in, so that testers only need the domain expertise from
the target system to execute tests.
Automated: Creating fuzz test cases manually is a time-consuming
and difficult task. A good fuzzer will create test cases automatically.
Automation is also critical when integrating fuzzing into regression
testing and bug reporting frameworks.
Test coverage: Better test coverage means more discovered
vulnerabilities. Fuzzer coverage must be measurable in two
aspects: specification coverage and anomaly coverage.
Scalable: Time is almost always an issue when it comes to testing.
User must also have control on the fuzzing parameters such as test
coverage. In QA you rarely have much time for testing, and therefore
need to run tests fast. Sometimes you can use more time in testing,
and can select other test completion criteria.
���������������������
���������������
�������������������������
���������������������
�������������������������
�������������������������������
��������������������
Documented test cases: When a bug is found, it needs to be
documented for your internal developers or for vulnerability
management towards third party developers. When there are
billions of test cases, automated documentation is the only possible
solution.
Remediation: All found issues must be reproduced in order to fix
them. Network recording (PCAP) and automated reproduction
packages help you in delivering the exact test setup to the developers
so that they can start developing a fix to the found issues.
MOST COMMON MISTAKES IN
FUZZING
Not maintaining proprietary test scripts: Proprietary tests
scripts are not rewritten even though the communication interfaces
change or the fuzzing platform becomes outdated and unsupported.
Ticking off the fuzzing check-box: If the requirement for testers
is to do fuzzing, they almost always choose the quick and dirty
solution. This is almost always random fuzzing. Test requirements
should focus on coverage metrics to ensure that testing aims to
find most flaws in software.
Using hardware test beds: Appliance based fuzzing tools
become outdated really fast, and the speed requirements for the
hardware increases each year. Software-based fuzzers are scalable
in performance, and can easily travel with you where testing is
needed, and are not locked to a physical test lab.
Unprepared for cloud: A fixed location for fuzz-testing makes it
hard for people to collaborate and scale the tests. Be prepared for
virtual setups, where you can easily copy the setup to your
colleagues, or upload it to cloud setups.
���������������������������������������
���������������������������

14
Direct Object
Reference or,
In this era, many miscreants have changed their
game. It’s easier for them to impersonate you or steal
your private data from a vulnerable Web application
than to take control of the Extended Instruction Pointer
(EIP) register of your CPU. The reason is simple. As
a software industry, we have more experience writing
native applications in C and C++ than writing Web
applications in PHP and JavaScript. People still write
bugs in their code, but they are definitely harder to find
and exploit than it was 10 years ago.
In this article we will investigate one type of Web
application vulnerability, namely Direct Object
Reference. A Direct Object Reference occurs when
an identifier, used in the internal implementation of
a Web application, is exposed to users. When this is
done insecurely, it can lead to a lot of trouble. This
vulnerability is probably one of the easiest to exploit but
is so deadly and prevalent that it claims the 4th position
in OWASP’s Top 10 Web Application security risks [2].
Many institutions have fallen victim to it, with the most
recent example of an Australian financial company
which was vulnerable in a way that made it possible
for anyone to access other peoples’ private financial
information [1].
Vulnerable Web Application
In order to make explaining easier, we will use as an
example a dummy Web application that allows loggedin
users to send personal messages to each other. All
the messages exchanged between members are stored
in a specific table in an SQL database as follows: see
Table 1.
The message_id column contains auto-incremented
values, unique for every message. The columns to
and from contain the user identifiers of the sender
and recipient of any given message. The title column
ATTACK PATTERN
How a Toddler Can Hack Your Web Application
There is no point in denying that everyday software is steadily moving
from desktop applications to Web applications. When you can check your
mail, play games, create documents and file your tax report without ever
leaving your browser, then you are indeed a citizen of the Web.
contains the title of each message and lastly the
message column contains the actual message
exchanged between two users. Now lets look at some
of the PHP functions used by the Web application to
display a user’s Inbox and allow him to read incoming
messages (Listing 1).
Viewing the INBOX
The function get_message_titles() is responsible for
providing logged-in users an overview of their Inboxes.
The first thing that the function does is to check whether
the user is logged-in. It does this by checking whether
the superglobal $_SESSION array contains a key titled
user_id. This key is set by the Web application when
the user successfully logs in, and is typically a unique
identifier in the Users table of the application much like
the unique identifier of each message in the Messages
table. We will not need that function in our discussion
thus for the sake of brevity, it is not shown in Listing 1.
If that key is not set, then the code redirects the user to
the login page of the Web application and returns.
If the user is indeed logged-in then the user’s
user_id is extracted from his session. Note that the
Figure 1. Table “messages” containing personal messages that
users exchanged with each other
Message_id From To Title Message
... ... ... ... ...
776 23 11 “Hey!” “Hey man!
What news?
777 11 25 “Foo...” “U there?”
778 25 42 “No Title” “Kthnxbye!”
779 23 11 “Welcome” “Welcome to our
site!...”
... ... ... ...
03/2011

Direct Object Reference or, How a Toddler Can Hack Your Web Application
user_id is passed as a parameter to the intval()
function. The intval() function is a built-in function of
PHP that returns the integer value of the parameter
that the programmer passes to it. This function is
very useful for Web application developers since it
allows them to easily filter out erroneous requests
or stop malicious users who attempt SQL injections
or Cross-Site Scripting attacks using fields that the
programmer knows should be integers. Since we will
be incorporating this value to an SQL query we want
to make sure that it is an integer and nothing more
than that.
In the next step, the Web application will query its
database for all messages that have as a recipient the
Listing 1. Code of vulnerable Web application

16
the Web application to call the function read_message().
This function, like get_message_titles() first checks if the
user who is requesting the reading of a message is
logged-in and redirects the user if not. In the next step
the value of the GET parameter named ‘id’ is retrieved
(given that it exists) and filtered through the integer value
function. Thus, continuing with our previous example, if
the user clicks on the following link: http://example.com/
read_message.php?id=776, the $message_id variable of
the read_message function will contain the number 776.
In the next step, the message id is used to retrieve the
full message from the messages table and thus in this
example case the SQL query will be the following:
SELECT from,title,message FROM Messages where message_id = 776;
The Web application uses the data and prints it out as
HTML to the user. The user reads the message and is
happy. Or maybe not ?
Exploiting IT
Those of you who have a security-oriented mindset [4]
may feel a bit uncomfortable with the workings of the
Listing 2. A simple Python script which downloads and saves the �rst 1024 messages from the
import urllib
import os
os.mkdir("./messages")
for i in range(0,1024):
ATTACK PATTERN
previously described Web application. Sure, they check
for SQL injections whenever they use data coming-in
from the user but you feel that something is not quite
right...
Lets look closely at the read_message() function and at
the resulting SQL query. We saw that if a user clicks
on link http://example.com/read_message.php?id=776,
the Web application will use the id parameter to find and
retrieve the appropriate message. In fact, this is exactly
where the vulnerability lies-- the Web application
uses ONLY the id that the user provided as a means
of reading a message. For the user with user_id equal
to 11, the Web programmer assumed that he or she
can click only on the links provided by the get_message_
titles() function, thus only click on one of the following
links:
• http://example.com/read_message.php?id=776
• http://example.com/read_message.php?id=779
While it is true that only the these two links will be
available in his INBOX, nothing is stopping the
user from changing the id parameter to any value
current_message = urllib.urlopen("http://example.com/read_message.php?id=%d" % i)
out_file = open("./messages/%d.txt" % i,"w")
out_file.write(current_message.read())
out_file.close()
Listing 3. Adding authorization checks to the vulnerable SQL query
$result = mysql_query("SELECT * FROM Messages where message_id = {$message_id} and to= {$user_id}");
/* The rest of the code is the same with the original function*/
[...]
03/2011

Direct Object Reference or, How a Toddler Can Hack Your Web Application
at all. Thus, the user with user _ id 11, can ask for
http://example.com/read_message.php?id=778 and start
reading a message that was sent to another user! Once
the malicious user is convinced that the above works then
just 10 lines of Python code obtains the full database of
messages: Listing 2.
And that’s it! So simple, that even a toddler could do
it! The problem in the design of this Web application
is that the user can directly reference messages in
the database. If we generalize this, there is a problem
when a user is allowed to directly reference objects
Listing 4. Adding an extra layer of indirection to defeat DOR attacks
www.hakin9.org/en 17

18
ATTACK PATTERN
References
• “Financial company heavies researcher for reporting vulnerability” http://www.theregister.co.uk/2011/10/14/�rst_state_super_shoots_messenger/
[1]
• OWASP TOP 10, https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project [2]
• Nick Nikiforakis, Marco Balduzzi, Steven Van Acker, Wouter Joosen and Davide Balzarotti, “Exposing the lack of Privacy in File
Hosting Services”, in the Proceedings of the 4th USENIX Workshop of Large-scale Exploits and Emergent Threats, 2011 [3]
• Bruce Schneier, “The Security Mindset”, http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html [4]
Authorization
If a Web application knows which objects can be
accessed by which users then the Web programmer
can straightforwardly integrate this knowledge into
the code. For example, the messages database
table contains a From column (who sent any given
message) and a To column (who is the recipient of any
given message). Thus anytime that a user requests to
read a specific message, the programmer can verify
whether the user was the recipient or the sender of
that message. Since we have limited ourselves in the
above examples to only the user’s Inbox, the SQL
query in function read_message() can be modified as
shown in Listing 3.
As you can see in the modified lines, the SQL query
now asks for all data given a specific message_id and a
specific user_id. The user_id variable is out of the user’s
control thus even if a malicious user changes the
message_id to a different value, the SQL query will not
match any row in the table and thus return no results.
Additional code could be added at this point to warn
the administrator that someone is attempting to access
resources that are owned by another.
Indirection Layer
Another way of tackling this problem is to add an extra
level of indirection between the references that the
user sees (and is in control of) and the references used
in the back-end of the application. This technique is
useful when the Web application programmer wishes
to hide the implementation details from users. It is
best explained with an example. In their vulnerable
implementation, the function get_message_titles()
reads the message identifiers from the database
and gives the appropriate ones to the user. Then the
���
� ���
� ���
�
��
�������������� ��
���
Figure 1. The effects of adding an extra layer of indirection for user
with user_id equal to 11
function read_message() reads the message identifier
from the user and queries the database directly using
the user-provided value. The above protocol could
be modified so that get_message_titles() transforms
the database values before giving them to the user
and then read_message() transforms them back before
querying the database. For instance, get_message_
titles() and read_message() can be re-written as shown
in Listing 4.
Note the changes done to the code. Before querying
the database we create an array that will hold our
future transformations. For every valid message_id
returned by the database, a new row is created in our
array, that connects an incremented counter ($array_
index) with that message_id. Each link given back to the
user, instead of containing the message_id, holds the
array_index with which the message_id was associated.
Finally, the message_array is stored in the user’s session
so that it can be retrieved by read_message(). The read_
message() simply reverses the procedure. What is
interesting now is that the user no longer receives the
actual values that the database contains but rather a
set of values that correspond (at the server-side) with
the actual values. Thus, the user with user_id equal to
11 will see the following links generated by get_message_
titles():
• http://example.com/read_message.php?id=0
• http://example.com/read_message.php?id=1
Even if a user changed the id to a new value, say
id=2, there is no 2 in the $message _ array read by read _
message() thus the query will fail. Figure 1, shows this
procedure graphically.
Randomized identi�ers
There are cases in which for some reason, the Web
application has no knowledge of which resource
belongs to which user. While certainly this is not the
case in our vulnerable Web application, there are
plenty of real-life examples. One of them is a File
Hosting Service (FHS), a Web service which a user
can utilize to exchange large files with friends. In
the usual scenario, the user visits a FHS, uploads a
file and receives a link to the uploaded file. The link
contains a unique identifier that the service generates
03/2011

and associates with that specific file. The FHS user
can then proceed to share this link with any friends
or colleagues. These services typically do not require
users to create accounts, thus they do not have the
means to remember who uploaded a file nor can
they know with whom the user shared the link to
the uploaded file. In these cases, the only protection
available is to use randomized identifiers so that users
can not easily guess the identifiers of other resources.
Thus, a FHS can assume that if one has a valid URL
to a file that they should be given access to it simply
because it should be impossible to recreate it [3]. In
our Web application example where the message_id
is an auto-incrementing number, a user can find the
previous identifier simply by subtracting one from the
current identifier. If instead, each message identifier
was a random identifier, the user could no longer
easily guess the identifiers of other users’ messages.
The only way to figure out other valid identifiers is
through brute-force methods which usually take a
great amount of time, hopefully much greater than the
time resources of the attacker.
Conclusion
The evolution of Web sites, from simple static HTML
pages to full-blown dynamic Web applications marked a
new era, not only for users but also for attackers. Today,
any Web application programmer has to keep in mind
tens of ways that a Web application can fall victim to
attackers and code defensively to avoid exploitations.
In this article, you learned about the Direct Object
Reference vulnerability that’s easy to introduce in
code and even easier to exploit. We saw an example
of this vulnerability, the methods to attack it and finally
three ways that a Web programmer can protect his
applications from it.
NICK NIKIFORAKIS
Nick Nikiforakis is currently a PhD student at the Katholieke
Universiteit of Leuven in Belgium. He is interested in all
aspects of computer security, but he mostly focuses on Web
security and on the protection and exploitation of low-level
vulnerabilities in native applications. In the past, Nick has
presented his work in well-known academic conferences (e.g.
Usenix LEET and EuroSEC), local OWASP chapters, AppSecDev
and BeNeLux OWASP events as well as top European hacking
conferences (CONFidence, BruCON and AthCon). All of his
work can be found online at http://www.securitee.org
www.hakin9.org/en 19

20
ATTACK PATTERN
The Logic Behind
Application
Logic Defects
It’s no secret that web applications are at the center of the ongoing
conflict between malicious hackers, and those defending the
applications.
As more and more critical business functions
migrate to an Internet presence, web applications
play an extremely vital role in business. Hackers
know this well, and have been exploiting weaknesses in
web applications at an alarmingly high rate.
While age-old issues like SQL Injection and
authentication weaknesses continue to plague developers
there is another class of security defects that has been
flying under the radar. Web application logic defects are
not new – in fact, the topic has been covered at great
length by various academic and research organizations;
rather, this class of issues has not received enough
attention due to the prevalence of much simpler attack
vectors. While hackers may not be exploiting this class of
defects in high volume, they are nevertheless extremely
effective and stealthy.
Mapping and Hacking
To attack application logic, a hacker must first understand
the function of the application itself. Although a small
detail, it makes this type of hacking different. While it is an
advantage to know the application when looking for SQL
Injection and like defects, application flow knowledge is
absolutely critical when discovering and exploiting logic
defects. Application flow presents a complex and often
difficult attack surface, but to a hacker looking to remain
undetected, it is the perfect choice.
A hacker who wants to exploit application logic must first
take the time to map out the application flow and determine
vulnerabilities. An experienced hacker would use a visual
graphing tool to draw the application page-flow and workflow
to fully understand the application. As the application is
being mapped, the hacker keeps track of page-state, page
parameters and available actions. Finding logic defects in
applications is painstaking, requiring a hacker to look for
subtle hints inside these tracked components.
For example, hidden variables that only exist on certain
pages within an application, such as the login page or
during privilege elevation, may point to an exploitable
issue in the authentication or authorization service.
Finding such parameters can be tricky, but once they
are identified they can be studied for patterns, or simply
fed to a targeted fuzzer to discover lapses in logic.
There are a number of application logic defects
that are obvious to someone looking for them. For
example, an application that implements a login
lockout mechanism to prevent hackers from guessing
passwords, but stores that information in a cookie, is
easy to manipulate. The hacker simply deletes the
cookie (or never accepts it) and can keep grinding
away at the password mechanism. This is yet another
reason to perform all critical functions away from the
client – in other words, at the back-end server where
the logic and environment is more likely to be under the
control of the developer. Allowing logic to be stored and
executed on the client is like a bank building miniature
cash dispensing machines that customers can take
home with them. It sounds great in theory because it
allows customers to not have to visit a banking center
– but since the bank no longer has direct control over
the physical component given to the customer to take
home – this will ultimately lead to fraud.
Online gaming systems are a particular target for
logic tampering and hacking. An application, such as
an online poker room, which allows re-submission of
an action, in the form of a bet or hand, is vulnerable to
being manipulated. For example, if a player feels he has
a winning hand and places a large bet, then discovers
a sign that their opponent also feels they have a good
hand, they would be able to re-submit a previous
request (typically in the form of an AJAX request) and
make a lower bet. An application that does not have
02/2011

The Logic Behind Application Logic Defects
appropriate logic controls to identify that the player has
already used their turn, can be manipulated, and in fact,
has been in the past.
Picking on Parallel Processes
Turning a developer’s time-optimization technique against
the application is also a great way to exploit application
logic defects. Developers are often trying to speed their
applications and optimize workflow to accomplish multiple
tasks concurrently. An attacker can exploit this type of
optimization by looking for what appear to be parallel
processes that should logically run in serial.
A good example is a business with an online shopping
cart that has also implemented a customer loyalty
system. Once a customer logs in and places their order,
their purchases are converted to points which can be
redeemed for goods or services at a later date. A hacker
can attempt to manipulate this system by placing a small
order, then entering an incorrect payment method to
ensure that the transaction fails. Often, the loyalty points
transaction and payment transaction are conducted in
parallel for speed. However, even though the payment
transaction fails, the loyalty points are still added to the
customer’s account. This type of attack can be repeated,
or even scripted, to obtain a large volume of loyalty points
while not spending any money with the vendor.
Exploiting Numerical Handling Vulnerabilities
It’s important to validate that an application handles
various numeric inputs correctly. Once again, turning to
a shopping cart feature, if a hacker can input a negative
number into an order system various issues can arise,
including something called phantom inventory. If the
application allows a negative number to be used, a
hacker can simply add inventory that doesn’t exist
during the purchase or acquisition process.
For example, a recently discovered and patched
issue in a popular Internet application allowed clientside
validation of input, but if the hacker stripped out
the field validation, which was written in JavaScript, or
intercepted and manipulated the request, a negative
number could be inserted. Inside the application logic
there were immediately two issues. First, someone
could checkout with a negative number prompting a
debit to their account or credit card. This in effect was
stealing money from the vendor. The second issue was
with the back-end inventory management system which
now reflected a discrepancy in available stock.
The Devil is in the Details
Logic defects in an application can cause serious
business challenges. Discovering these types of
issues takes time, and isn’t a simple matter of coding
up a scanner tool. Each issue has a unique method of
discovery, is different from one application to another,
and is often different from one developer to another.
The one thing all logic defects have in common is they
are virtually invisible to modern web attack mitigation
platforms. Whether there is a web application firewall,
an intrusion prevention system, or any combination
thereof – it’s nearly certain that attacking web application
logic will be invisible to the victim –whether that it be an
enterprise, a small business, or a governmental entity.
This is primarily due to the lack of identifiable patterns
such as tell-tale SQL Injection markers. Requests and
responses are often legitimate, and don’t trigger an
alarm or raise suspicion even if the hack is successful.
Remaining undetected makes this type of attack very
attractive to hackers, fraudsters, and others.
Additionally, these types of security defects in applications
often slip past testing teams as scanning tools and formal
logic testing methodologies are still maturing. The best
weapon against these types of security defects is the
Quality Assurance testing organization at each business.
QA testers are well-versed in application logic for the
purposes of functional testing. Rather than developing logic
testing methodology from scratch, security testing teams
should collaborate with their QA organizations to add logic
testing into their already well-adopted methodologies.
It Takes a Village
Logic defects are difficult to avoid in code, difficult to
effectively test for, and nearly impossible to detect. As
hackers exhaust obvious and scriptable defects on the
Internet, web-based applications will likely be their next
attack vector. Rather than waiting for the deluge of
attacks, and for the appearance of scathing headlines,
now is the time for development organizations,
application security teams, and businesses to work
together to fortify their web-based applications against
these attacks. Focus on discussing this with your QA
organization, develop an internal testing methodology
that suits the applications you build, and test your
existing applications. You can then apply these lessons
learned to new applications you design before they are
deployed throughout the organization.
RAFAL LOS
Rafal Los Enterprise and Cloud Security Strategist for Hewlett-
Packard Software, combines over a decade of deep technical
expertise in information security and risk management with
a critical business perspective. From technical research to
building and implementing enterprise application security
programs, Rafal has a proven track record with organizations
of diverse sizes and verticals.
Prior to joining HP, Los de�ned the framework for a software
security program and served as a security lead at a Global
Fortune 100. Los also contributed to the global organization’s
security and risk-management strategy internally and with
their customers.
www.hakin9.org/en 21

22
Password, What
Password?
In this article we will be covering high level
functionality of Kryptos Logic’s Kon Boot v1.1
software. I will explain how to deploy this software
and its payload into target computers running supported
operating systems; policies and settings that already
exist to block end users on a corporate, government
or educational network from being able to use this
software; and what you, a home user, can do to keep
your computer safe from this attack.
Lets start off by imagining that you just returned
home from a summer vacation in Maui – you unpack
your belongings, check your social media sites, and
prepare for the following months work. A couple of
days later you start to notice that your social media
sites have pictures on them that you did not post
as well as other strange anomalies. After you check
your other online accounts, you realize that there is
suspicious activity on all of your web portals including
the loss of $10,000 from your checking account. You
wonder how anything like this could possibly happen.
You have an epiphany that during your flight home you
turned off your laptop and visited the lavatory, leaving
your computer out on your tray table. You returned
and found your computer just as you left it. You were
not suspicious and resumed using your computer for
the duration of your flight. What you did not know
until now is that your fellow passenger had Kon Boot,
broke into your computer, and stole the files off your
desktop. You start to panic because you remember
that you had an extensive password list file of every
password you have as well as your work passwords
in that file. Worst of all the attacker has begun locking
you out of your own website accounts by changing
the passwords and the security questions, because
for convenience you put the questions and answers
in the same file as well. Now you are in an extreme
DEFENSE PATTERN
If you have a computer with a non-encrypted hard drive and have not
disabled other media devices from booting before your hard drive or
have not password protected your BIOS listen up! Your computer and
files are at risk even if you have a user account password.
panic. You have a myriad of questions – the most
daunting how did he gain access to my computer
and password file? You turned off your laptop and
your user account was password protected, so you
believed you were safe. Now you have an enormous
mess of work trying to salvage your online accounts
and personal websites before the attacker finishes
locking you out.
Just for the sake of argument, and to avoid an
onslaught of email, the attack I just mentioned could
also be achieved many other ways including taking
a non-encrypted hard drive out of the computer
hooking it up to your own device using an external
encasement kit, but that takes some time. Imagine
what the passenger might say if they return from the
lavatory and you have their computer half apart, trying
to remove the hard drive and use it as an external
drive on your own computer. The beauty of Kon Boot
is that it is not obvious that you have used it on a
target PC. Kon Boot neither overwrites the SAM nor
makes any modification to the host operating system.
Kon Boot achieves its goal by hooking the kernel
during boot and allows the user to bypass the need
for a password. The added beauty of Kon Boot is the
next time you boot the computer without the Kon Boot
Media the user’s original password will still be on
the system. Unlike other reset tools that completely
remove the password, Kon Boot makes your average
user unaware that you have just broken into their
computer. I have used many other tools that will allow
you to log into another users account or computer but
they, for the most part, modify the operating system or
leave some other kind of obvious trace. If you would
like more information about other reset tools just use a
search engine and search bypass/ reset windows user
passwords.
03/2011

Password, What Password?
Computers that are vulnerable to this attack must
have an Intel Pentium III or greater or another
processor brand that is comparable. The computer
must also run one of the supported Operating
Systems. Vulnerable operating systems that are at risk
for breach include Windows XP Home Edition, 32 and
64 bit editions of Windows Vista Home Basic, Home
Premium, Business, and Enterprise, 32 and 64 bit
editions of Windows 7 Home Premium, Professional,
and Ultimate, 32 and 64 bit editions of Windows
Server 2003 Web Edition, Standard, Enterprise, and
Datacenter, 32 and 64 bit editions of Windows Server
2008 Standard, Enterprise, and Datacenter. This
is the official list of vulnerable operating systems,
though more may exist. One example is windows 7
Starter, normally the OS installed on net books, but
this OS remains untested and unverified. I have also
personally tested some compatible operating systems
using VMware. I was able to boot Kon Boot using the
virtual CD drive and mount the .iso file during boot in
order to hook the kernel. The end result was the same
as running the software on a non virtualized operating
system.
One common question posed to me is how easy is
it for any user to obtain this software. That answer is
fortunately and unfortunately very easy. Anyone who
wKants this software can license and download a copy
from Kyptros Logics’ website. For your honest home
user this is wonderful. He or she can now instantly
download a piece of software that will allow him or her
to bypass a simple windows logon screen and allow
him or her to reset their own password if they have
forgotten it. For the criminal mind, ease of access is
also a beauty. The criminal can download a program
that will allow him or her to gain access to a normal
Figure 1. Using Kon Boot on virtualized operating systems in
VMware
password protected system in about ten seconds.
This allows the criminal to log in as the victim user
and access the computer just as if the legitimate user
successfully authenticated into the desktop with the
password. Something even more worrying is Kon Boot
can be burned on to a flash media device making the
program is extremely portable. You can carry Kon Boot
in your pocket or on a keychain during your every day
life. You no longer have to carry around optical media
that can easily be damaged.
Another use for this program is by parents wanting
to monitor their child’s usage of a computer. When the
child is away at school or unaware of their computer’s
state, you the parent can log onto their computer and
review their files and pictures. A parent might want to
do this in case they suspect that their child is falling
victim to an Internet predator without betraying the
trust of the child. Having the child forcibly log into
their computer and show their parents the contents
may be extremely embarrassing for the child. The
child might also have a file on their desktop that they
delete without you knowing when they log into their
computer.
This would make your average parent (lacking
forensic abilities) computer search moot. Just like
the police of sting operations, you must be subtle and
go under cover by using Kon Boot to find out what
your children are really doing. Personally I do not
recommend this kind of spying for most parents. My
philosophy is unless your child has recently changed
their personality or has become withdrawn from their
friends you should not be like a vulture waiting for
something on their computer to pop up. This type of
parental spying also touches some ethical issues I will
not cover in this article.
On the reverse end of that stick, imagine this
family is like most, more or less computer illiterate.
The children seem to know more about computers
than the parents do. Now just think about what your
children could potentially gain access to by using Kon
Boot on the parents computer. This is a threat that
should be taken seriously. It is incredibly easy to make
a bootable media device with the payload software
on it. Just think what is on your computer right now.
Would you want your children to have access to those
documents?
After I explain all the features and awesomeness of
Kon Boot many people ask me numerous questions. In
this next segment I hope to answer a family of these
questions for example, how long does it take to create
the flash media; how computer savvy do you need to
be in order to create the media; how much time does
it take to create the media; and how likely is it that I, a
simple end user, will be to duplicate all the results and
compromise my own test system.
www.hakin9.org/en 23

24
Ok, lets get started. You are going to make your
own Kon Boot USB flash drive to use on your own test
system. The first thing you will need to do is license
a copy of Kon Boot. You can do this by accessing
www.kryptoslogic.com and navigate to the buy Kon
Boot link. Input all necessary licensing information
and begin downloading the software. It is important
to note that websites other than Kryptos Logic have
Kon Boot version 1.0. Downloading this from a third
party website may be risky because you never know
if someone has injected their own malicious code
on top of Kon Boot. As another note, version 1.0
does not support 64 bit operating systems. Spend
the money and license a legal copy of this software.
Next take a flash drive that does not have any data
saved to it and plug the flash drive into your computer.
I personally used a very simple SanDisk brand flash
drive to accomplish this task. If you use advanced
flash drives like Ironkey or other brands that require
authentication they will not work properly on boot. You
will not be able to access the information contained in
them because they require input that you will not be
able to provide until your operating system has already
loaded. Open the file folder that you downloaded form
Kyptros Logic and click on KONUSB, now navigate
to KonBootInstall.exe and select it. This will open a
command line interface with destination options to
write the program. Choose the correct destination for
your flash drive and select the corresponding letter
drive. Press enter and the program will copy itself to
your flash drive and make itself bootable. Now you
have successfully burned the Kon Boot program onto
your flash media, you can now close your programs
and power off your computer. Now you will need to
gain access to the BIOS. Power on your computer.
When you see the computer manufactures logo press
the corresponding function key to access the settings
of the BIOS. In the Dell laptop I was using the key
was F2. At this point it is important to note if you see a
DEFENSE PATTERN
password screen similar to that of Figure 2, and you do
not know the password, you will not be able to access
the BIOS and make any changes.
There are ways to remove BIOS passwords but this
can be time consuming and cumbersome depending on
your computer manufacturer, model, and ease of access
to the internal components. If you have not previously
set a password this prompt will not appear and will just
go the first page of the BIOS. If you can access the
BIOS you need to navigate to the boot order options.
Now you need to reorder the boot devices to make your
media with Kon Boot boot before the hard drive. For this
demonstration that would be your USB or removable
media drive but, you can also use a Compact Disc or for
legacy systems a floppy drive.
After you have reordered the boot devices save
and exit the BIOS configuration page. Your computer
will restart at this point. If you have completed these
steps correctly and your system board and chipset are
compatible with Kon Boot this should be all you need
to modify in order to use the software. Now, with your
computer powered off plug your USB flash media with
the payload software, Kon Boot, into one of your USB
ports. Next power on your computer. Your computer
should try to boot the removable media device instead
of your hard drive. If your computer successfully boots
off your removable media device and loads Kon Boot,
you will see a screen with this text on it.
Once this screen appears you have successively
hooked the kernel. Now all you have to do is wait for
the supported Operating system to load and choose
an user account to log in with. If the user account is
normally password protected, Windows will prompt
you for a password. This is normal. You may type any
password, gibberish, or just leave the password field
blank. Remember Kon Boot allows you to bypass the
need for an actual password. Lastly press enter and
you should be in the compromised users account, their
desktop should appear, and you may access to their
Figure 2. A password Protected BIOS screen Figure 3. Reordered bootable devices in the BIOS
03/2011

Password, What Password?
files. For those who have been actively following along,
you did it. You have just created a very powerful USB
tool. Use it ethically.
Now that I have sufficiently worried some of you, I
am here to tell you there are very easy ways to prevent
this attack on your computer. First you will need to gain
access to your BIOS using the same steps mentioned
above. Next navigate over to the Boot Order options.
Next depending on your BIOS use the corresponding
key to reorder the boot menu. Have your primary hard
drive boot first and disable the other boot devices, or if
your BIOS will not let you disable the devices, at least
have the other media boot after the primary hard disk
drive. Next navigate to the security tab or comparable
tab. Now highlight Set Supervisor Password and
press enter. A menu should appear like this one. See
Figure 5.
Create an unique password, hopefully not 1234, and
press enter. Lastly you need to exit your BIOS. You will
have several options or prompts when you try to exit.
You want to select the option that says Exit and Save
Changes or a similar choice. If you just exit or say
discard changes all of the settings you just inputted will
be ignored. Your computer will reboot after you exit the
BIOS and will begin booting your operating system.
That’s it. This will protect you from simple, time limited,
and obvious hardware modification Kon Boot attacks,
but will not protect your data if they can reset your
BIOS password or extract the hard drive from your
computer and use it as an external drive to steal your
data off it, much like a criminal would if they just steal
your entire computer. The good news is that there are
more advanced ways of protecting your computer
that are relatively easy. One of the ways to really
lock unwanted users out of your computer, especially
laptops, is with pre-boot authentication software.
This software will completely lock out unauthorized
users and render Kon Boot useless against the target
system. Your system is protected even if you do
not have a BIOS password, even though it is good
practice to set one when you buy a laptop. The preboot
authentication software also encrypts your entire
hard drive, foiling a would be hacker from obtaining
any data off the drive with a hard drive encasement
kit. Some users might feel that this is overkill but if you
are protecting sensitive data like your finances you
want to minimize as many data breach opportunities
as possible.
On most educational, enterprise, and government
networks this attack will not work. On government
networks the workstations are heavily locked down
with enterprise security software. The workstations
are also, depending on base and policy, physically
locked. The computer cases have been locked
controlling access to the physical drives and hardware
inside. Enterprise networks are very secure with
heavy auditing abilities. Some enterprise networks
have fewer restrictions than a government network,
but auditing access keeps snooping eyes at bay.
On educational networks security can be heavy
because of the sensitive information that must be
secured. Usually I have seen deep freeze on most
lab computers as well as BIOS Passwords. Preboot
Authentication is not practical on these types
of computers due to the large number of users. If
the institution uses a BIOS Password this will lock
out the students from being able to use software like
Kon Boot. Security cameras, aware staff, and fellow
students will notice a student taking a computer out of
its enclosure and opening the system during class in
order to reset the BIOS. This human level of security
is not perfect but will usually stop a student when the
threat of expulsion is very real.
Now what happens if for some unforeseen reason a
user is able to use Kon Boot on a network computer
that caches the usernames locally? Unfortunately if
there are not security barriers in place to prevent this
attack the user, will be able to log in as a user that has
Figure 4. Kon Boot successfully hooking the kernel on boot Figure 5. Creation of a BIOS Password
www.hakin9.org/en 25

26
had their usernames cached locally. This part is scary!
That username could be an administrator’s user
name. When the attacker logs in as the victim admin
user, then the attacker has all the normal permissions
of that admin user as set up in your network
environment. This includes access to network drives!
This lack of security can lead to company secrets
being leaked from a rogue employee or spy. This is a
real threat. Can logon auditing help keep an eye out
for this kind of activity? The answer is complicated.
Yes, you can look in logon log file audits and see
when an user has logged on. This previous statement
is also the reason why not. In most environments only
security violations and invalid logons are logged in
your domain controller. Unless the admin user is a
honey pot and you have a global policy red flagging
any activity of this user, you will not know. If you are
able to detect the attacker it will most likely not be in
real time allowing the attacker or spy to slip out with
information and leave the country. If your institution
logs all network logons thinking that you will be able
to detect this, lets be realistic. In a large company with
1,000 employees or more, a normal logon that does
not throw up a security violation will be ignored as just
your average admin user performing maintenance
on a system. Endless what if scenarios arise. I sat
in a server admin class where we were discussing
access violations and logging options. That day most
of the class time was spent trying to capture violation
and event data without filling up the hard drives with
nothing but log files. Other scholars might have the
approach to log everything. This is not necessary in
my mind due to the amount of data you would need
to sift through to find a logon with no violation. In this
economy corporations are cutting back staffing. This
is a perfect scenario for the attacker to go unnoticed
for a while or until they release the stolen data. If you
no longer have many admins to support the users and
network audits, normal activity like correct logons will
probably be ignored due to higher priority tasks. The
massive log files would hinder an investigation plus
you do not know what user you are looking for. No
security violation or excessive use equals, in the real
word, no second thought from a security admin.
Having some level of protection is always a good
plan. I have found in my experience that small mom
and pop businesses usually do not have any kind
of protection on their computers. Most of those
businesses also do not even bother with user account
passwords! I seriously hope this will change due to
the amount of business information usually stored
within the computer systems. On the other extreme
for large enterprise and government systems, I have
seen a tremendous amount of security from heavily
locked down workstations to portable laptops that
DEFENSE PATTERN
had full commercial data encryption protecting the
entire hard drive, pre-boot authentication, and lockout
features. I have found some free products that will
do a pretty good job, but when you are protecting
company proprietary information you take no chances.
This also means IronKeys for all data transfer off a
computer. When it comes to the individual computer I
have found that most attackers are looking for crimes
of opportunity. If someone has stolen your laptop they
might quickly browse for your files and see if there is
anything that catches their eye. If not they just wipe
your computer with a new operating system and sell it.
If you protect your computer with encryption the ease
of browsing through your computer is eliminated and
the attacker might find that they do not have the skills
or time to crack your hard drive, and just move on to
another computer. For most home users True Crypt
is sufficient. This encryption software is free, making
it attractive to many people that want protection but
are constrained by finances. A real life example of
this in laymen’s terms, is when you lock your car in
the parking lot of a grocery store. A criminal might just
go up and down the isle tugging on the door handles
trying to find a car that is not locked. If the car is
locked, there are many ways to break into the cabin
but it might draw some attention and take more effort
than just moving on looking for an unlocked car. If the
thieves want in they can get in – all you are doing is
trying to slow them down. You are just adding levels of
security to make it more difficult and time consuming
to enter your car. This is the same concept that we are
applying to computers.
I hope this article about one very simple program
can help those who do not think much about computer
security to reconsider their position. In less than five
minutes a rogue or curious user can modify the BIOS
and access a vulnerable workstation. It is my goal that
home users will at the very least will set up a BIOS
password to help keep criminals out of their computer
and add one more level of protection to their system. All
trademarks mentioned in this article are the property of
their respective owners.
CHRISTIAN A. MERGLIANO
Graduate of Antelope Valley College
Student at CSU Dominguez Hills
CEO of Surgeradio.org
Computer consultant / Technician
cmergliano@surgeradio.org
03/2011

28
REVERSE ENGINEERING
A Quick „Hands On”
Introduction to Packing
On Windows systems, programs are usually available in the PE file
format with the .EXE extension. Although this file format is quite
complex, it is now well documented, so understanding how it is
globally supposed to work is pretty easy and you can find a lot of
programs designed to open/analyze/modify PE executables.
Those which are designed to modify PE files (for
various purposes) are often called packers. We’ll
learn how to write one of those in this article.
We’ll start by taking a glance at PE file format’s basis;
then we’ll design the principle of a small packer able to
modify our pentest tools in such a way that they are less
detected by AVs; and finally we’ll implement it in Python
using both the good old “pefile” module and the brand
new miasm reverse-engineering framework.
The tools
pe�le
The pefile module is a multi-platform Python module
used to read and work with Portable Executable
(aka PE) files. It can be downloaded here: http://
code.google.com/p/pefile/. We’ll use this specialized
module throughout the article; it is very efficient when
dealing with PE files. The drawback of being specialized
is that some steps of writing our packer can’t be done
with pefile alone.
Figure 1. Overview of a PE �le’s structure
miasm
miasm is a free and open source (GPLv2) reverse
engineering framework for python that can be
downloaded here: http://code.google.com/p/smiasm/.
Being a reverse-engineering framework, it is much more
versatile than pefile, but it is also much younger and still a
bit unstable. Despite its youth we’ll see that it is sufficient
to build a complete tiny packer.
PE format
Overview
In their simplest form PE files can be represented as a
collection of sections and a bunch of metadata. Sections
are blobs that are mapped in memory when the program
starts. These blobs can contain anything useful to the
program: such as the program code itself, constant
values, icons, etc. The metadata (mostly located in
the PE file headers) contains a lot of information; at
the very least the metadata defines where the sections
are located in the file, what their name is, where they
are supposed to be mapped to in memory, and where
the starting point of the program is in memory, once the
sections are mapped.
Listing 1. pe�le’s basis
>>> import pefile #loading the pefile module
>>> pe = pefile.PE("calc.exe") #we open the well-
>>> for s in pe.sections:
... print s.Name
...
.text
.data
.rsrc
known ‘calc.exe’ program
03/2011

A quick “hands on” introduction to packing
Listing 2. smiasm basis
>>> from elfesteem import * #we load the elfesteem module, part of the miasm framework
>>> e = pe_init.PE(open("calc.exe",'rb').read()) #we open the well known ‘calc.exe’ program
# section offset size addr flags rawsize
0 .text 00000400 0126b0 00001000 60000020 00012800
1 .data 00012c00 00101c 00014000 c0000040 00000a00
2 .rsrc 00013600 008a88 00016000 40000040 00008c00
Listing 3. Getting the AddressOfEntryPoint using pe�le
>>> import pefile
>>> pe = pefile.PE("calc.exe")
>>> print "0x%.8X"%pe.OPTIONAL_HEADER.AddressOfEntryPoint # We want the address to be printed in hexa
0x00012475
Sections
Even though there is no written standard about this,
almost every PE file contains a section called .text
and a section called .data. The first one usually holds
the program’s binary code, the second one contains
constants (fixed strings, integer constants, etc.). What
we want to know about those sections is:
• Where it is located within the PE file
• Where it is going to be mapped in memory
• Whether or not it is writable
Either with the pefile module or with the elfesteem
module (which is shipped with miasm) you can answer
those questions in only a couple of lines of python
code: Listing 1.
With miasm, it’s even easier as the sections’ name
and some of their properties are automatically displayed
when you instantiate the corresponding object: Listing 2.
Metadata
PE files have multiple headers stacked one over the
other. The first header, called MZ header, is used when
the programs starts from MS-DOS. We won’t discuss
this header here as we want to pack executables
running under Windows. Following the MZ header is a
DOS stub which is a binary that runs when the program
is launched from MS-DOS. We don’t care about this
stub as this stub generally only displays this program
cannot be run in dos mode and exits. Following the
DOS stub is the real PE header.
Within the PE header are stacked various structures
such as the IMAGE_NT_HEADER, the IMAGE_FILE_HEADER and so
on. The most interesting piece of information that we
can find here is the address where the execution flow
is going to be redirected by Windows just after having
mapped the sections in memory when starting the
program. This option is called AddressOfEntryPoint and is
located in the OPTIONAL_HEADER (which is not optional…).
Using pefile: Listing 3. Using miasm: Listing 4.
If we look back at the sections characteristics showed
by miasm in the previous paragraph we can check that
the “.text” section (which is supposed to hold the binary
executable code of the program) starts at address
0x1000 and has for size: 0x0126b0. This means that
this section goes from memory address 0x1000 to
memory address 0x0136b0, which actually contains
address 0x12475 which is the AddressOfEntryPoint. Until
now everything’s fine and logical!
Packer principle
Now that we’ve learned how to read some characteristics
of PE executable we can start wondering how to take
profit out of it. For the purpose of this article, we’ll focus
on AV detection. Indeed AV software generally loves the
good old way of identifying viruses by finding a fixed
string (called a signature) within raw PE files. Many of
Figure 2. Various headers stacked at the beginning of a PE �le
www.hakin9.org/en 29

30
Listing 4. Getting the AddressOfEntryPoint using smiasm
>>> from elfesteem import *
>>> e = pe_init.PE(open("calc.exe",'rb').read())
(…)
REVERSE ENGINEERING
>>>print "0x%.8X"%e.Opthdr.AddressOfEntryPoint # We want the address to be printed in hexa
0x00012475
Listing 5. Ensuring that the targeted section is writable, using pe�le
>>> import pefile
>>> pe = pefile.PE("calc.exe")
>>> data_section = pe.sections[1] #the ‘.data’ section is usually the second one (just after ‘.text’)
>>> data_section.Characteristics|=0x80000000 #set the writable flag up
Listing 6. Ensuring that the targeted section is writable, using miasm
>>> from elfesteem import *
>>> e = pe_init.PE(open("calc.exe",'rb').read())
(…)
>>> d_section = e.SHList[1] #the ‘.data’ section is usually the second one (just after ‘.text’)
>>> d_section.flag |= 0x80000000 #set the writable flag up
Listing 7. Ciphering a section thanks to pe�le
>>> original = data_section. get_data(text_section.VirtualAddress, length = text_section.SizeOfRawData) # We
read the original content of the ‘.data’ section
>>> ciphered = ‘’ # This variable will hold the ciphered ‘.data’ section
>>> for c in original:
If ord(c)==255:
else:
ciphered+=chr(0)
ciphered+=chr(ord(c)+1)
>>> pe.set_bytes_at_rva(data_section.VirtualAddress, ciphered) # Now we overwrite the ‘.data’ section on disk
with our enciphered version
Figure 3. Taking advantage of on-disk padding to add some code
03/2011

A quick “hands on” introduction to packing
the tools we use during pentests are now identified as
a virus raising alerts in our clients IDS (which is quite
annoying). If we could find ways of modifying our PE
files while preserving their original behavior, we may be
able to bypass AV detection and avoid spamming our
clients with AV alerts during our pentests.
In order to bypass AV detection, we can adopt two
different strategies. The first one consists of identifying
which part of the PE file contains the signature and
modifying it with an equivalent sequences of bytes. The
second one is to modify as much of the PE file as we
can, with the hope that the signature was in what we
modified. The first strategy is very efficient but depends
on both the AV and the PE file we want to pack; the
second strategy is less efficient but does not depend
on the AV software used nor on the PE file we want to
pack. Therefore we’ll write a small packer implementing
the second strategy in this article.
Ciphering
The principle of the packer we write is to encipher the
content of the .data section so that, if the signature is
located within this section, AV software won’t notice
the file anymore. Of course we will also have to add
a decoding stub that will decipher the .data section
when the app starts and redirect the execution flow
to the original starting point once the deciphering is
completed.
For this article we’ll use a very stupid ciphering
algorithm, derived from the Caesar algorithm. We’ll
increment every byte of the .data section by one during
encryption. We will decrement them by one during
decryption. Advanced users can replace this algorithm
with anything else (including xor-based algorithm or
more advanced one such as AES) but this trivial one is
sufficient to play a bit.
Deciphering
Our main concern regards the place we’ll write our
decoding stub into. The easy way would be to add a
new section at the end of the file, write our decoding
stub here, and change the AddressOfEntryPoint to have
it pointing to the beginning of the decoding stub. This
method has two main drawbacks:
• Having a lonely small section with the attribute
executable at the end of a file may ring some bells
in the most advanced AV pieces of software.
• pefile does not handle section adding very well,
and I don’t have this feature of miasm working yet
(although it is supposed to do it gracefully).
So where can we write? The solution lies in some
details of the PE file format standard: sections’ size
on disk have to be a multiple of a certain value (which
www.hakin9.org/en 31

32
is stored in the PE headers). Usually this constraint
causes some garbage to be saved on disk in order to
expand the useful section’s content to the next good
multiple. If we can spot such a garbage place, we
could write our decoding payload there and increase
the section’s size to be mapped in memory (in the PE
header) in order to have the whole section’s disk space
to be mapped in RAM.
Packer’s implementation
Now that the principle is clearly defined, we can
step into the implementation. We’ll start by ciphering
the .data section and modify its attributes to have it
writable in memory (so that our decoding payload can
rewrite it live). The .data section being fully prepared,
we’ll spot the place where we can write our decoding
payload. Finally we’ll write the payload and change the
AddressOfEntryPoint so that it points to the beginning of
Listing 8. Looking for available space using pe�le
>>> import pefile
>>> pe = pefile.PE("calc.exe")
>>> for s in pe.sections:
REVERSE ENGINEERING
the deciphering algorithm. Once all those modifications
are done, our program will be stored on disk with its
.data section ciphered, but will still work as usual as its
new AddressOfEntryPoint will be our additional payload
that re-creates the original .data section and reroute the
execution flow to the original starting point.
Preparing the “.data” section
The preparation of the .data sections needs two steps:
adding the writable flag to its attributes and ciphering
its content. To start up with we’ll change the permission
flags of the .data section to have it writable (so that our
decoding stub can overwrite the ciphered version with
the deciphered one once mapped in memory). Using
pefile: Listing 5. Using miasm: Listing 6.
Now that the section’s writable we just have to
encipher it on disk. Using pefile: Listing 7.
And that’s it. We are done with the .data section!
... print s.Name, '- Bytes of ‘on disk padding’=", s.SizeOfRawData-s.Misc_VirtualSize
...
.text : Bytes of ‘on disk padding’ = 336
.data : Bytes of ‘on disk padding’ = -1564
.rsrc : Bytes of ‘on disk padding’ = 376
Listing 9. Looking for available space using miasm
>>> from elfesteem import *
>>> e = pe_init.PE(open("calc.exe",'rb').read())
(…)
>>> for s in e.SHList:
... print s.name,": Bytes of 'on disk padding'=",s.rawsize-s.size
...
.text : Bytes of 'on disk padding'= 336
.data : Bytes of 'on disk padding'= -1564
.rsrc : Bytes of 'on disk padding'= 376
Listing 10. deciphering code, in ASM
decipher_main:
MOV eax, START_ADDR # We store in EAX the address we are currently deciphering
MOV ebx, END_ADDR # We store in EBX the address at which we shall stop deciphering
decipher_loop:
DEC BYTE [EAX] #We decipher the current byte (which address is stored in EAX)
INC EAX #We move on the the next byte to decipher
CMP EAX, EBX #We compare the address to decipher to our STOP address
JNZ decipher_loop # If we haven’t reached the "STOP address" yet we go back to deciphering
JMP ORIGINAL_AddressOfEntryPoint #Now we jump to the original program’s start
03/2011

A quick “hands on” introduction to packing
Where to add our payload
Now that the .data section is ready we can focus on
adding the decoding stub. Firstly we have to check how
much padding trash space we have for each section.
Ideally we’d love to have enough space within the .text
section but if it’s not the case any other section will be
fine as long as we remember to set its executable flag
on. To check the padding trash quantity we enumerate
each section and compare its size on disk to its size
once mapped in memory. Using pefile: Listing 8. Using
miasm: Listing 9.
You’ll notice that the .data section gives us a negative
result, indeed some sections (especially those holding
data) can have a larger space reserved in memory
than what they have on disk, this is not a bug. Anyway
Listing 11. assembling our deciphering stub using miasm
>>> from miasm.core import parse_asm
>>> from miasm.arch.ia32_arch import x86_mn
>>> from miasm.core.asmbloc import asm_resolve_final
>>>
>>> my_asm+="mov eax,"+hex(Start_Of_Data_Section)+"\n"
>>> my_asm+="mov ebx,"+hex(End_Of_Data_Section)+"\n"
>>> my_asm+="decipher_loop:\n"
>>> my_asm+="dec [eax]\n"
>>> my_asm+="inc eax\n"
>>> my_asm+="cmp eax,ebx\n"
>>> my_asm+="jnz decipher_loop\n"
>>> my_asm+="mov eax,"+old_AddressOfEntryPoint+"\n"
>>> my_asm+="jmp eax\n"
>>>
we figured out that we have 336 bytes available in
the .text section (which holds the main binary code of
the program) to write our decoding stub, that’s good.
We’ll have to write a small decoding stub but it looks
possible.
Writing the decoding part
The decoding stub’s goal is very simple: it loops from
the beginning of the .data section to the end of it,
decrementing each byte by one. Once it has finished
it jumps to the original AddressOfEntryPoint. Sadly we’ll
have to write this part in ASM, leaving python for a few
minutes. In ASM: Listing 10.
Now you should be wondering how we’ll inject this
ASM part, in a compiled form, within our PE file. The
>>> all_blocks, symbol_pool = parse_asm.parse_txt(x86_mn,my_asm) #This one and the 3 followings are used to
assemble our ASM text written in "my_asm"
>>> symbol_pool.add(asmbloc.asm_label('base_address',0))
>>> symbol_pool.getby_name("decipher_main").offset=0
>>> resolved,patches = asm_resolve_final(x86_mn, all_blocks[0], symbol_pool)
>>>
>>> deciphering_stub = ‘’ #This will hold the binary executable of our ASM piece of code
>>> addr = patches.keys()
>>> addr.sort()
>>> for a in addr:
… deciphering_stub += patches[a]
…
Listing 12. �nishing things up with pe�le
>>> pe.OPTIONAL_HEADER.AddressOfEntryPoint = tsection.VirtualAddress+tsection.Misc_VirtualSize-len(stub)
>>> pe.OPTIONAL_HEADER.CheckSum = pe.generate_checksum() #we refresh some checksum in the headers (otherwise the
program will not start due to "corruption")
>>> pe.write("packed.exe") #Finally we write our modified executable on disk !
www.hakin9.org/en 33

34
Table 1. Checking if the �les have been packed
answer is: with Python of course. Indeed miasm is
shipped with disassembling/assembling capabilities that
we’ll use. Sadly there is no way of doing this with pefile
so if you really don’t want to use miasm you’ll have to
consider using a different standalone program (such
as fasm) or another python module with assembling
capabilities (such as MOSDEF). Let’s get the binary
blob corresponding to this ASM text: Listing 11.
With those few lines of python we have the binary
code corresponding to the ASM deciphering stub we
wrote earlier. A quick check let us know that this binary
will fit without any problem within the trash-padded
space we spotted earlier.
>>> len(deciphering_stub)
25
Executable Original MD5 Packed MD5
We now only have to add this small piece of binary
code at the end of the .text section and modify the PE
file header to enlarge the size of this section that has
to be mapped in memory. Using pefile :
>>> pe.set_bytes_at_rva(tsection.VirtualAddress+
tsection.Misc_VirtualSize, stub)
>>> tsection.Misc_VirtualSize+=len(stub)
Now that everything’s ready we still have to change the
AddressOfEntryPoint in order to start the program with
our decoding stub; to update some checksums stored
in the headers, and to save the resulting PE file on disk
(we use only pefile for this point because some kind of
bug currently seems to corrupt the PE files written
from miasm; although this may be corrected once the
article’s published): Listing 12.
Testing and conclusion
Using those few lines of code we packed some usual
Windows binaries, confirmed that they still worked
exactly the way they are supposed to, and compared
their md5 signatures: Table 1.
The signatures are definitely different which proves that
the files are different. Using this packer we may be able to
REVERSE ENGINEERING
Calc.Exe 5911f4ae105c7469636f7adcea35349f 5f8a5cc3e415ae17dc3f3295138172fb
Notepad.exe 2dcc5c800f51d487178814ca9eada181 571299065675826205d78b56d2dd2adf
Winmine.exe ea682c022f7204cc8e8c9ef5dce29356 efa6921d3f123c62735d850b3e087cfd
Table 2. Efficiency measurement of our tiny packer
Executable Percent modi�ed
Calc.Exe 4.7%
Winmine.exe 6.3%
Notepad.exe 1.1%
bypass a couple of AV if we pack our pentest tools! In order
to estimate our chances of bypassing AV we measured
the amount of the file that was changed: Table 2.
These percentages are quite low and you may feel
like ciphering more sections would be a good idea. After
all there is no reason to cipher only the .data section,
you could cipher almost every section this way and
reach percentages around 90%...but there is a trap.
Indeed when Windows loads a PE file it does some
magic BEFORE jumping to the AddressOfEntryPoint. This
magic includes things such as loading some DLL the
program needs to run; and the glitch is that the list of
DLLs can be stored in any section. If you cipher this
list Windows will fail to understand it and will refuse to
launch your program (i.e. your packed version will not
work). There are a couple of traps like those and if you
want to improve your packer you’ll especially have to
worry about the IAT (the Import Address Table, i.e. the
list of DLL needed) and the .rsrc section (the sections
that holds resources …such as the program’s icon).
Once you’ve managed to spot the parts of the program
you don’t want to encipher (such as the IAT) you can
modify the packer to support ciphering of sections that
holds sensitive data that shall be left in the clear (this
is left as an exercise to the reader). And if this is not
sufficient for you, it may be possible to find really nice
ways of finally modifying those parts without ciphering.
As an example the IAT contains, for every DLL-imported
function needed by the program, the offset of the starting
point of the function in the DLL binary. The trick is that if
this offset happened to be wrong Windows will gracefully
search the whole DLL for the good offset and the program
will still work! So a nice and quick way of modifying the
IAT is to fill every offset with random values.
As far as I’ve gone (~200 lines of Python) I usually
modify around 80% of my PE files, which is sufficient
to have gsecdump/cachedump/NameYourFavoritePentestToo
lHere bypass around 60% of AVs! If you still want to
do better you may consider ciphering the whole file,
dynamically decipher it in RAM, and emulate everything
that Windows does when launching a real PE from disk,
but that’s a lot more work!
ALAIN SCHNEIDER
Alain has been a professional pentester for years but also
published a few papers. Those papers focused both on basic
tricks and on-the-edge technics. His favorites subjects are
password cracking and cryptography
03/2011

36
Interview with
Jan van Bon
Creating a solid and practical architecture under your IT management
approach can greatly reduce the cost of improving quality, and it can
speed up your projects. An integrated approach requires a simple
and straightforward method that is easy to understand, supported
by available tools in the market, and accepted by many providers.
This kind of approach requires thorough knowledge and sincere
dedication. As with many other initiatives in the field of IT Service
Management, the Netherlands have again produced a fascinating
new approach, with promising results for IT Security projects.
Traditional security projects show a high degree of falling back
specifically because they are not embedded in a well-functioning
management system – says Jan van Bon.
Exploiting Software: You are the Director at
BHVB – Bureau Hoving & Van Bon. For the
people who are not familiar with your group,
could you tell us a little bit about it?
Jan van Bon: The Bureau Hoving & Van Bon (BHVB)
is a small but highly dedicated team that has focused
on developing a methodological approach to IT Service
Management. It is based in the Netherlands, where
many of the initiatives on IT Service Management have
started. After observing two decades of mostly failing
projects in this field, the team assimilated all available
knowledge in a straightforward aproach, incorporating
existing methods for organizational change and
improvement into one deeply structured new method.
This approach enabled them to create a method that
was both simple and effective, and easy to learn.
Exploiting Software: You are also the Director
at Inform-IT , Knowledge Center for Service
Management. What is its mission?
INTERVIEW
Jan van Bon has been a driving force in the field of IT Service Management for the last 20
years. After a decade of academic research he started his work in IT in the late 1980’s, in the
Netherlands. He has been heavily involved in ITIL, ITSMF, and several innovative projects
ever since. He produced more than 80 books, in up to 14 languages, with thousands of
expert authors and reviewers from all over the world, on a broad range of IT Management
topics. He is the founder and Chief Editor of the ITSM Library, the ITSM Portal, and several
other knowledge portals. As a practitioner he is involved in supporting many organization
improvement projects.
JvB: Inform-IT is the oldest knowledge center on IT
Service Management around. It started in 1996, and
has been responsible for many of the products of
itSMF Netherlands and itSMF International.
Inform-IT’s mission is to develop and distribute
knowledge carriers in the field of IT Service Management.
It produced large numbers of conferences and books,
and is responsible for the first knowledge platform
in the field of IT Service Management – created in
1996, and now still present: the ITSM PORTAL
(www.itsmportal.com).
Inform-IT doesn’t do this on its own – no single
person or team can have all the knowledge it takes.
Therefore Inform-IT works with a huge community of
experts, from all over the world, and from all relevant
disciplines.
Enabling these scattered sources to find eachother
and to co-produce the missing piece of knowledge that
Inform-IT is targeting, has been the core of Inform-IT’s
work of the last 15 years.
03/2011

Interview with Jan van Bon
Exploiting Software: How did Inform-IT start
and how it has evolved to where it is today?
JvB: One of the first assignments of the knowledge
center was to professionalize the itSMF in the
Netherlands, by setting up a chain of events, develop
a magazine, and set up relationships with other
professional bodies in IT in the Netherlands. From 1996
on, Inform-IT started developing annual books on the
state of the discipline of ITSM. Around the turn of the
century Inform-IT delivered a huge book, titled The
Guide to IT Service management. For many people,
this was their entry into the latest developments of
ITSM, beyond ITIL.
Today, Inform-IT is responsible for maintaining its
portfolio of books, for managing the ITSM Portal, and
for developing new titles; titles that are filling in the blank
spots in the ITSM discipline. Some of the books Inform-
IT is now working on, are focusing on the subject of
organizational development and improvement, a topic
that was largely ignored in all ITIL versions.
Exploiting Software: What is your most
interesting and relevant project?
JvB: Inform-IT was involved in many projects, but
the one project that will have most impact of all, is
the ISM Method® (Integrated Service Management:
www.ismportal.nl/en/). Inform-IT contributes heavily to
the development of a method that is commoditizing
the organizational change that is always at the core of
ITIL projects. In the Netherlands the ISM Method has
already been recognized as the next step, that will take
organizations to a much higher level of service delivery,
making much better use of available guidance, like the
practices described in ITIL or COBIT.
Exploiting Software: What is your view
regarding the risk management?
JvB: In the field of IT Service Management, the ITIL
books have been a true hype, for more than a decade
now. Unfortunately, the term risk has been ignored in
ITIL books for a very long time. In all other disciplines,
Risk Management was a logic and basic ingredient.
The ITIL authors however reformatted the risk management
activities in practices like Continual Service
Improvement, Problem Management, The Seven Step
Improvement Process, et cetera. This didn’t help to put
Risk Management in its rightful place.
The ISM Method has put Risk Management at the
heart of the process model, covering all proactive
activities aimed at preventing the agreed service levels
to fail. This way, Risk Management is an integrated
element of the management system.
Exploiting Software: What do you think about
the IT Security developement?
JvB: IT Security Management is one of the first
functions you think of in an organization. Other
examples of core functions are Capacity Management,
Service Management, and Continuity Management. All
of these are not processes but functions: organizational
capabilities using people, processes and products. They
should be based upon the processes that each service
organizations should have in place, but they should
not duplicate these. In practice, the effectiveness and
efficiency of these functions is highly influenced by the
level of integration that has been achieved.
Once you understand that Security Management
doesn’t have to create redundant processes like
Security Incident Management or Security Change
Management or Security Level Management, you can
easily use the available core process to support secure
IT services. Security Management is involved in any
of these core processes: it is activated whenever a
Security Section has to be designed in an SLA, when
a change involves security measures (and when is that
NOT the case?), when there are security incidents, or
security risks, et cetera.
Organizations that have learned to apply an integrated
management system, like the ISM Method, will have a
thorough approach to all their management goals,
whether these apply to speed, capacity, availability,
or security. Having such a system in place will make it
much easier to achieve security goals, e.g. meeting the
requirements of the ISO27000 standard.
In practice, organizations that apply the ISM
Method, can build on the resulting management
system, to achieve any of these goals. Of course the
implementation of the measures that are required will
have to be done in all cases, but the implementation
will now be much more solid (since they are formal
changes to the IT infrastructure), and will be much
more sustainable, since they are built into the regular
management system.
Traditional security projects show a high degree of
falling back specifically because they are not embedded
in a well-functioning management system. Using the
lessons of the ISM Method, new security projects can
now be done at much lower cost, and are much more
effective in the long run.
It has taken us over twenty years to learn this.
But now that the methodology is available, security
management’s future is looking much brighter again.
www.hakin9.org/en 37

Next Issue of
Shellcode: From a Simple Bug to OS
Control
DPA Exploitation and GOTs with Python
And more...
will be available to
download on
November 22 nd
If you would like to contact Hakin9 team, just send an email to
en@hakin9.org. We will reply a.s.a.p.