44
team
Editor in Chief: Grzegorz Tabaka
Managing Editor: Natalia Boniewicz
Editorial Advisory Board: Daniel Dieterle, Rebecca Wynn, Michael Munt, Aby Rao
Proofreaders: Daniel Dieterle, Nick Baronian, Jeffrey Smith, Robert Wood, Michael Munt, Elliott Bujan, Bob Folden, Steve Hodge, Jonathan Edwards, Steven Atcheson, Mixchal Jahim
Top Betatesters: Nick Baronian, Rebecca Wynn,
Rodrigo Rubira Branco, Chris Brereton, Gerardo Iglesias Galvan, Jeff rey Smith, Robert Wood, Nana Onumah, Rissone Ruggero, Shayne Cardwell, Inaki Rodriguez, Bojan Alikavazovic, Arnoud Tijssen
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: Grzegorz Tabaka
Production Director: Andrzej Kuca
DTP: Ireneusz Pogroszewski Art Director: Ireneusz Pogroszewski
Publisher: Software Press Sp. z o.o. SK 02-682 Warszawa, ul. Bokserska 1 Phone: 1 917 338 3631
www.hakin9.org/en
Whilst every effort has been made to ensure the high quality of the magazine, the editors make no warranty, express or implied, concerning the results of content usage.
All trade marks presented in the magazine were used only for informative purposes.
All rights to trade marks presented in the magazine are reserved by the companies which own them.
To create graphs and diagrams we used program by
Mathematical formulas created by Design Science MathType™
DISCLAIMER!
The techniques described in our articles may only be used in private, local networks. The editors hold no responsibility for misuse of the presented techniques or consequent data loss.
Dear Readers,
It’s been almost one year since the the first issue of Exploiting Software Hakin9 was published. Exploiting Software Bible is the effect of over ten months work and it consists of the best articles of all Exploiting Software Hakin9 issues. It covers a wide range of topics concerning stack overflow, shellcode, stack overflow, reverse engineering, exploiting client software and defense patterns. I would like to express my thanks to all without whose great assistance this issue could not emerge. Special thanks to the authors, editorial advisory board, proof readers, betatesters and graphics. It’s your work and fantastic enthusiasm that made it all possible.
Enjoy the reading, Natalia Boniewicz & Hakin9 Team
4 www.hakin9.org/en 5
CONTENTS
SHELLCODE
10 Shellcode: From a Simple Bug to OS
Control
By Amr Thaber
The secret behind any good exploit is a reliable shellcode. The shellcode is the most important element in your exploit. Generating shellcode with automated tools only helps so much in formulating your exploit. Knowing how to create your own shellcode will help you overcome barriers that lie ahead, and that’s what this article will demonstrate.You will learn how to write a reliable shellcode on the Win32 plaform, how to bypass the obstacles that you will face in writing a win32 shellcode, and how to implement your shellcode into Metasploit.
28 Exploiting Format Strings with Python
By Craig Wright
Format string attacks are not particularly new. Since their widespread public release in 2000, format string vulnerabilities have picked up in intensity as buffer overflows become less common and more widely known. From an unknown start a decade ago, they have become a common means to exploiting system applications. These vulnerabilities remain an issue as we still teach them. It is not uncommon for format string vulnerabilities to allow the attacker to view all the memory contained within a process. This is useful as it aids in locating desired variables or instructions within memory. With this knowledge, an attacker can exploit the vulnerability to successfully exploit code and even bypass control such as Address Space Layout Randomization. In this article Craig will discuss crafting attacks using python in order to attack through DPA (Direct Parameter Access) such that you can enact a 4-byte overwrite in the DTORS and GOT (Global Access Table) and prepares the reader for a follow-up article on exploiting the GOT and injecting shell code.
34 DPA Exploitation and GOTs with
Python
By Craig Wright
If we can write into the GOT, we can effectively redirect the execution flow of a program and allowing ourselves to gain a root shell. This article is a follow-up and second part of a look at format strings in the C and
C++ programming languages; in particular, how these may be abused. The article goes on to discuss crafting attacks using Python in order to attack through DPA (Direct Parameter Access) such that you can enact a 4-byte overwrite in the DTORS and GOT. This time author endeavoured to make the process of exploiting format string vulnerabilities as simple as possible for the inexperienced exploit developer. A basic knowledge of Python has been assumed as well as an understanding of the Linux operating system and how to use gdb. This starts off with detailing the use of Direct Parameter access and how this process works and then describes the Global Offset Tables in detail. You will see that using the exploitation of Direct Parameter Access (DPA) will allow us to write into the address of our choosing.
42 Starting to Write Your Own Linux
Schellcode
By Craig Wright
We have seen more and more people become reliant on tools such as Metasploit in the last decade. This ability to use these tools has empowered many and has created a rise in the number of people who can research software vulnerabilities. It has created more security professionals who cannot only scan a target for vulnerabilities using a tool such as Nessus, but who can complete tests involving system exploitations and hence validate the results presented to them by a scanner. But, this ends when a new application with unexpected calls or controls is found. What do we do when presented with a special case? This makes it extremely difficult for signature based systems to stop or detect shellcode created for a specific purpose and hence more likely that the tester will succeed in testing the vulnerability without other controls interfering. If we remain at this level, we will stop the lower level attacker, but fail in stopping more sophisticated attacks. You will learn how to write your own shellcode, how to fix all the nulls and how to validate your shellcode.
48 Beyond Automated Tools and
Frameworks: the shellcode injection
process
By Craig Wright
Automated frameworks (including Metasploit) have simplified the testing and exploitation process. This of
6 05/2012 www.hakin9.org/en 7
CONTENTS
course comes with a price. Many penetration testers have become tool jockeys with little understanding of just how software functions. This script kiddie approach to code testing does have its place. It has allowed us to drastically increase the number of people working on testing systems for vulnerabilities and in assessing the risks these pose. At the same time, if these individuals do not progress further, simply relying on the ability to leverage the efforts of others, we will hit bottlenecks in the creation of new tests and processes. This article is going to follow from previous articles as well as going into some of the fundamentals that you will need in order to understand the shellcode creation process, how to use Python as a launch platform for your shellcode and that the various system components are.
54 Understanding conditionals in
shellcode
By Craig Wright
This article is going to follow from previous articles as well as going into some of the fundamentals that you will need in order to understand the shellcode creation process. In this article, we are looking at extending our knowledge of assembly and shellcoding. This is a precursor to the actual injection and hooking process to follow. You will investigate how you can determine code loops, the uses of loops as well as acting as an introduction into how you can reverse engineer assembly or shellcode into a higher level language and even pseudo-code, all of which forms an essential component of creating and executing one’s own exploit successfully. By gaining a deep understanding just how code works and to know where to find the fundamentals shellcode programming language we hope to take the reader from a novice to being able to create and deploy their own shellcode and exploits.
62 Taking control, Functions to DLL
injection
By Craig Wright
DLL injection is one of the most common methods used by malware such as a rootkit to load it into the host’s privileged processes. Once injected, code can be inserted into functions being transmitted between the compromised code and a library function. This step is frequently followed with API hooking where the malicious code is used to vary the library function
calls and returns. This article is part of a monthly series designed to take the reader from a novice to being able to create and deploy their own shellcode and exploits. With this knowledge, you will learn just how easy it is for sophisticated attackers to create code that can bypass many security tools. More, armed with this knowledge you will have the ability to reverse engineer attack code and even malware allowing you to determine what the attacker was intending to launch against your system.
BUFFER OVERFLOW
68 Smashing the Stack
By Marco Balduzzi and Mariano Graziano
For decades hackers have discovered and exploited the most concealed programming bugs. But how is it possible to leverage a buffer overflow to compromise software in modern operating systems? Mariano and Marco will introduce us to the basic principles of code exploitation. We will see what happens when a process is executed or terminated, and how a buffer overflow vulnerability can be leveraged to execute malicious code.
80 Smashing the Stack 2
By Marco Balduzzi and Mariano Graziano
Modern operating systems come with sophisticated
protection mechanisms to prevent one-click
exploitations. But, how can attackers bypass such techniques to compromise remote machines all over the world? And downloading PDF documents is always a safe practice?Mariano and Marco will describe the different protection mechanisms that have been introduced in modern operating system to make exploitation more difficult. They will aslo present several popular workarounds used by attacker to bypass such techniques. Finally, they will analyze a real exploit for a Acrobat Reader’s stack-based buffer overflow.
88 Exploit a Software with Buffer
Overflow Vulnerability and Bypassing Aslr
Protection
By Ahmed Sherif El-Demrdash
Buffer overflow is an anomaly where a program while writing data to a buffer overruns the buffer’s boundary and overwrites adjacent memory. This is a special case of violation of memory safety. It is the most dangerous vulnerability in the software world because it could allow
6 05/2012 www.hakin9.org/en 7
CONTENTS
for an exploitation for OS which include this vulnerablesoftware. You will learn how to write your own exploitation with python programming language and bypassing ASLR protection and finally, how to run your own shellcode to control Vulnerable OS.
REVERSE
ENGINEERING
98 Reversing EXE with OllyDbg
By Nilesh Kumar
What is reverse engineering (RE)? Normaly, the source code is in human readable form, object files are binary files with human-readable symbols. Executables are pure binaries. When we attempt to revert a binary executable into its object form, it is called disassembly. Converting an object file into source code is called decompilation. The whole process is called reverse engineering. Nilesh illustrates the reverse engineering of a sample executable file, and how to patch it. You will learn how to reverse engineer an exe. The ultimate goal of RE is to bypass the checks to get the things done your way. The process of RE may differ person to person, and program to program.
102 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.
110 Hacking Applets: A Reverse
Engineering Approach
By Nilesh Kumar and Ronnie Johndas
Ronnie and Nilesh will discuss a technique that can be used to modify the applet’s Java byte code without having to recompile the applet. They will show the process of reverse engineering of an applet which does not have any kind of code obfuscation, string encryption and other code protection techniques employed. You will
learn how to patch byte code and perform other kinds of manipulation in the Java class files of the applet. We will also see how to get a signed applet to run in a standalone manner.
EXPLOITING CLIENT
SOFTWARE
116 Hijacking Software Updates with
Evilgrade
By Mourad Ben Lokhua
Almost every modern application comes with a simple, built-in update mechanism. Usually it is sensible for users to accept updates that improve the security and operation of the program. Mourad shows how to attack usersvia update systems. He also claims that software developers do not spend much time or effort on updates and secure delivery mechanisms, that’s why standard processes for updating applications make many users vulnerable.
122 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…
128 How to Recover Passwords from a
Memory Dump
By Daniel Dieterle
Malware analysis is an amazing field. To be able to grab a memory dump from a live machine and then have the capabilities to pull useful information from it just amazes the
8 05/2012 www.hakin9.org/en 9
CONTENTS
author. Can we find pertinent system settings, and even pull information from them? Were you ever curious about what could be done with a memory dump of an active computer? This article is a short demonstration on how to acquire a memory dump from a running system, and then how to use tools to not only recover the system password hashes from the memory dump, but also how to decode them.
134 Creating a Fake Wi-Fi Hotspot to
Capture Connected Users Information
By Roberto Saia
We can use a standard laptop to create a fake open wireless access point that allows us to capture a large amount of information about connected users; in certain environments, such as airports or meeting areas, this kind of operation can represent an enormous security threat but, on the other hand, the same approach is a powerful way to check the wireless activity in certain areas where the security is very important. An attacker can use his properly configured laptop in a large number of public places, even in an airplane, simulating the Wi-Fi gateway used by airline and capturing personal data of connected passengers. With a little effort, anyone can create a fake Wi-Fi Hotspot and use it to gather precious information about connected users, information such as usernames, passwords, messages and so on. You see how an attacker can deceive a large number of users, and consequently capture information that enables him to commit criminal acts such as identity theft.
142 Deceiving Defenses with Nmap
Camouflaged Scanning
By Roberto Saia
Nmap (contraction of ‘Network Mapper’) is an open-source software designed to rapidly scan both single hosts and large networks. To perform its functionalities Nmap uses particular IP packets (raw-packets) in order to probe what hosts are active on the target network: about these hosts, it is able to discover the running services (type and version), the operating system in use (type and version); it is also able to obtain more advanced information, such as, for example, the type of firewall used on the target network. You will learn how to deceive an IDS/IPS system through a particular feature offered by Nmap software, a simple option able to trick the rules generally used in this kind of systems to detect
any suspect activity inside a medium/large network; the used software is the most famous network scanner in the world and the knowledge of its potentiality is a good way to improve our security policies.
150 Overriding Function Calls in Linux
By Umair Manzoor
Function hooking and overriding plays a vital role in penetration test of thick client application. In this article we will discuss how shared libraries in Linux environment can be overridden with out recompiling the code. By overriding the function calls we can sniff the communication protocol, modify the communication parameters and fuzz the communication protocol.
156 Cracking Java Applications with AOP
exploits (part 1)
By Daniel Drozdzewski
Aspect Oriented Programming is a paradigm that aims to modularise software further by the separation of crosscutting concerns. Daniel will show us the basics of AOP and a simple, yet powerful idea behind the exploit.
160 Cracking Java Applications with AOP
Exploits (part 2)
By Daniel Drozdzewski
AOP has been used in the domain of Software Security before. Its use was mainly for validation, auditing and authorization purposes, which in turn improve software security as a whole. Those crosscutting concerns are being woven into the existing software after the fully functional code has been delivered. Making the process two staged, allows separating the responsibilities.In the second part of the series, Daniel will present the reader with a bit more advanced use of AOP, which will allow us to reverse engineer obfuscated Java applications. On top of that he will show a trick of password post selection, which we use to find parts of the code crucial to password processing, which in turn will allow us to switch the whole password verification off.
166 Cisco IOS Rootkits and Malware: A
practical guide
By Jason Nehrboss
Propagating the worm code into a new router can either be quite easy, difficult, or impossible. There are many
8 05/2012 www.hakin9.org/en 9
CONTENTS
variations of supported IOS code and hardware platforms.The author discusses the use of and demonstrates an IOS Embedded Event Manager rootkit and worm. When a router is infected it can be leveraged into a powerful malware platform. Capabilities demonstrated are network packet captures, reverse shell connections, a spam module, and a mini malware httpd server leveraged with ip address hijacking. In this article you will learn how to exploit critical network devices, network traffic traversing these devices and act as a launch point for further attacks into a network You will also learn about a self replicating IOS worm with stealth features and self defense mechanisms, all with platform independent code.
DEFENSE
180 Easy Network Security Monitoring
with Security Onion
By Daniel Dieterle
Hackers and the malware that they create are getting much better at evading anti-virus programs and firewalls. So how do you detect or even defend against these advanced threats? Intrusion Detection Systems monitor and analyze your network traffic for malicious threats. The problem is that they can be very difficult to configure and time consuming to install. Some take hours, days or even weeks to setup properly. The Security Onion IDS and Network Security Monitoring system changes all of that. Do you have 10 minutes? That is about how long it takes to setup and configure Security Onion – a Linux Security Distribution based on the Ubuntu (Xubuntu 10.04 actually) operating system.
186 Inspecting Https Traffic on Gateways
By Kishin Fatnani
In the past, security devices inspecting application content for attack patterns, misuse or malware, had been blind to encrypted traffic and because of this, encrypted protocols such as Hypertext Transfer Protocol Secure (HTTPS) have been a safe method used by attackers to bypass security inspection. Though reverse proxies and Web Server modules have been there for long, they only inspect incoming traffic e.g. connections made to protected web servers in the organization. Inspecting outgoing traffic or traffic of connections made by users to outside world servers not protected by the device, had been on the wish lists. These days, devices come with the
capability to inspect Secure Sockets Layer (SSL) based outgoing traffic, however there are some concerns by enabling such kind of inspection. In this article we cover some basics of SSL, the challenges in inspecting SSL traffic, and also see how Check Point’s HTTPS Inspection feature is able to inspect HTTPS traffic at the gateway. After reading this article you will know the pros and cons of enabling SSL inspection on a gateway.
192 Detecting Ipv6 Rogue Router
Incidents Using Bro NSM
By Matti Mantere
Internet Protocol version 6 (IPv6) has been a long time coming. As the protocol is making its entrance several security risks of varying criticality are known to exist. However, the amount of skilled personnel needed to assure the security of IPv6 network deployment as well as awareness of the said risks remains woefully low. As IPv6 migration slowly gains momentum, situations where administrators responsible for deployment of network equipment have very poor knowledge and non-existent operational experience of the new protocol are unavoidable. Matti depicts one method for detecting them using open source Bro NSM. Bro Network Security Monitor (Bro NSM) is a flexible open source network analysis framework that is freely distributed under BSD license.
196 The Gentoo Hardened Project:
Or How to Minimize Exploits Risks
By Jesus Rivero
Gentoo’s approach to Linux is evidenced in its Phylosophy1, from there it derives the fact that optimization, flexibility and choices are the keystones of the distribution. Gentoo gives users the tools needed for them to shape their Gentoo installation to their liking and all while building and compiling software especially for their hardware architecture, not relying in pre-built binaries compiled by someone else. That is one of the reasons why you will hear, users and developers, say that Gentoo is a “meta-distribution” because the distribution provides exciting tools that allow users, using the same base system, to build highly secure servers, neat desktops, embedded solutions or even a special VDR system. Jesus will show you how to install a Gentoo Hardened system, how to choose the right profile and kernel and what are the major caveats and potential problems.
10
SHELLCODE
01/2012 www.hakin9.org/en 11
Shellcode: From a Simple Bug to OS Control
I
n this article I’m going to teach you how to write a reliable shellcode on the Win32 plaform, how to bypass the obstacles that you will face in writing a win32 shellcode, and how to implement your shellcode into Metasploit.Part 1: The Basics
What’s Shellcode?Shellcode is simply a portable native code. This code has the ability to run at any place in memory, for example, inside an exploit to connect back to the attacker or do what the attacker needs to do.
The Three Types of Shellcode
Shellcode is classified by the limitations of the environment that you are facing while crafting a program to exploit a specific vulnerability.
Null Byte-Free Shellcode
In this type of shellcode, you are forced to write a shellcode without any null byte. For example, while exploiting a vulnerability in a string manipulation code inside a function, C functions such as strcpy()
or sprintf() work by searching for the null byte in the
string (as strings are null terminated) without checking on the maximum accepted length of this string. A successful byte-free shellcode will make this application
susceptible to the buffer overflow vulnerability. If your shellcode contains a NULL byte, this byte will be interpreted as a string terminator, with the result that the program accepts the shellcode in front of the NULL byte and discards the rest. So you will have to avoid any null-byte inside your shellcode, but you will have the ability to use just one null byte – the last byte.
Alphanumeric Shellcode:
In strings, it’s not common to see strange characters or Latin characters inside. In this case, some IDSs (Intrusion detection systems) detect these strings as malicious especially when they include suspicious sequence of opcodes. These systems could detect the presence of shellcode. Not only that, but also some applications filter the input string and accept only the normal characters and numbers (a-z, A-Z and 0-9).
In this case, you need to write your shellcode in characters. You are forced to use only these characters and only accept bytes from 0x30 to 0x39 and from 0x40 to 0x5A and from 0x60 to 0x7A.
Egg-hunting Shellcode
In some vulnerabilities, you may have a very small buffer to insert your shellcode. With the off-by-one vulnerability, you are restricted to a specific size and you can’t send a shellcode bigger than that.
Alternatively, you could use two buffers to put your shellcode into. One is for your real shellcode and the second is for attacking and searching the first buffer for the eggs.
Part 2: Writing Shellcode
Shellcode SkeletonAny shellcode consists of four parts: Getting the delta, getting the kernel32 imagebase, getting your APIs and the payload.
The secret behind any good exploit is a reliable shellcode. The
shellcode is the most important element in your exploit. Generating
shellcode with automated tools only helps so much in formulating
your exploit. Knowing how to create your own shellcode will help
you overcome barriers that lie ahead, and that’s what this article will
demonstrate.
Shellcode:
From a Simple Bug to OS Control
Figure 1. Shellcode Skeleton
������������������ ������������� ��������������������������
������������ �������
28 01/2012
SHELLCODE
Exploiting Format Strings with Python
www.hakin9.org/en 29
T
he article progresses to discuss crafting attacks using python in order to attack through DPA (Direct Parameter Access) such that you can enact a 4-byte overwrite in the DTORS and GOT (Global Access Table) and prepares the reader for a follow-up article on exploiting the GOT and injecting shell code. We demonstrate how these simple but still often overlooked and even taught vulnerabilities can be used to read arbitrary locations from memory, write to memory and execute commands and finally to gain a shell.Introduction
Format string attacks are not particularly new. Since their widespread public release in 2000, format string vulnerabilities have picked up in intensity as buffer overflows become less common and more widely known. From an unknown start a decade ago, they have become a common means to exploiting system applications. These vulnerabilities (We can see from 2010-06-30: KVIrc DCC Directory Traversal and Multiple Format String Vulnerabilities, that format string vulnerabilities have not disappeared and are still a valid topic today.) remain an issue as we still teach them.
We will start by explaining what a format string actually is and then why they can be exploited.
It is not uncommon for format string vulnerabilities to allow the attacker to view all the memory contained within a process. This is useful as it aids in locating desired variables or instructions within memory. With this knowledge, an attacker can exploit the vulnerability to successfully exploit code and even bypass control such as Address Space Layout Randomization (ASLR).
When a parent process starts, the addressing for that process as well as all subsequent child process in
most implementations will remain static throughout the lifetime of the process. Although an attack may crash a child process, the parent process is often left intact. Consequently, attacks against child processes that cause a crash of the particular thread or fork may return useful information. This is particular true when multiple format string attacks can be leveraged against child processes that respond themselves without crashing the parent application.
Many Linux implementations incorporate a process-limit in order to process-limit the number of re-spawns and this can help minimize the impact of the attack noted above by enforcing an RLIMIT_NPROC rlimit (resource limit) of a
process through the Linux kernel. In this event, where the executable attempts to fork and a greater number of forks would come into existent than are defined by
RLIMIT_NPROC processes, the fork fails. The Linux kernel
module, rexFBD when installed, detects excessive forking
and stops these.
The end result is that memory leaks including format string vulnerabilities can act as a means of locating particular libraries and variables within a running process. The location of both stack and heap variables may be determined. From this, the attacker can discover the structures contained within a program.
What is a Format String?
Not all security people are programmers and consequently we need to start by defining what a format string is. Any format string is basically a set of special parameters that define how to display a variable number of arguments, for instance when sending a string of data to stdout. A format string essentially exists to define a variable length of arguments.
Format strings are primarily known in the C family of languages but are also used by Perl, PHP, and even
In this article we will look at format strings in the C and C++
programming languages. In particular, how these may be abused.
Exploiting format
Strings with Python
34
SHELLCODE
01/2012 www.hakin9.org/en 35
DPA exploitation and GOTs with Python
I
t then continues the attack by exploiting the GOT and injecting shell code. We demonstrate how these simple but still often overlooked and even generally accepted vulnerabilities can be used to read arbitrary locations from memory, write to memory, execute commands, and, finally, to gain a shell.Introduction
In the first part of this article (presented in Hakin9 in Exploiting Software 2/2011), we discussed format string attacks. In this article we are going to extend these, beginning with DPA (Direct Parameter Access) and moving to using the GOT (Global Offset Table) to spawn a root shell. To gain a complete understanding of this process, it is recommended that part one from last month’s issue is read first.
In this paper, we have endeavoured to make the process of exploiting format string vulnerabilities as simple as possible for the inexperienced exploit developer. A basic knowledge of Python has been assumed as well as an understanding of the Linux operating system and how to use gdb. This starts off with detailing the use of Direct Parameter access and how this process works and then describes the Global Offset Tables in detail.
If we can write into the GOT, we can effectively redirect the execution flow of a program and allowing ourselves to gain a root shell. This process will also help when there is some form of stack protection that stops us from altering the address pointed to through EIP and redirecting it to a shellcode address.
In this process, we will inject a reference in place of that which the GOT references for a selected function. Here we want to have a function that can execute system commands as substitutes to overwriting the subsequent instruction with the memory address that
the shellcode we wish to call. The modern protections built into nearly all operating systems have started to load the GOT in a read-only memory area. Where this has occurred, the system avoids the exploitation technique discussed in this paper to a large extent. That being said, it is possible to find systems where these protections have been disabled or older unpatched systems where the complete attacks work natively. At worst, even in a read-only system, the GOT can be read.
Direct Parameter Access
DPA allows an attacker to access arguments through the use of a $ qualifier. Just like we had to learn all
of that difficult math before we moved into formulaic integrals in high school, last lesson we learned the hard way to call arguments using format strings. DPA makes format string attacks simple. It allows us to directly call the location we wish to exploit instead of having to pad attacks using %x%x%x… Basically, as we can address the
argument directly, we do not have to increment the byte count until we find the memory location we wish to exploit.
We showed in the last article how the use of the following syntax will allow us to access the 8th argument from the stack (%8\$x%8\$n) using the $ qualifier. Again,
This article is a follow-up and second part of a look at format strings
in the C and C++ programming languages; in particular, how these
may be abused. The article goes on to discuss crafting attacks using
Python in order to attack through DPA (Direct Parameter Access)
such that you can enact a 4-byte overwrite in the DTORS and GOT
(Global Access Table).
DPA Exploitation
and GOTs with Python
���������������������������������������������������������������������
������������������������������������������������������������������
���������������������������������������������������������������������
������������������������������������������������������������������
���������������������������
�
������������������������������������������������������������������
������������������������������������������������������������������
��������������������������������������������������������������
�������������������������������������������������������������������
��������������������������������������������������������������������
������������������������������������������������������
����������������������
�������������������������
�������������������
�
�������������
��
42
SHELLCODE
01/2012 www.hakin9.org/en 43
Starting to Write Your Own Linux Shellcode
I
t has created more security professionals who cannot only scan a target for vulnerabilities using a tool such as Nessus, but who can complete tests involving system exploitations and hence validate the results presented to them by a scanner. But, this ends when a new application with unexpected calls or controls is found. What do we do when presented with a special case? Here we have to again return to the old art of crafting shellcode. At some stage, if we are to be more than white hat script kiddies and want to come to actually understand the application, we need to learn how to craft our own custom shellcode. In this article, we start to explain the process used to do this.Introduction
We have seen more and more people become reliant on tools such as Metasploit in the last decade. There are valid reasons for this. Simplifying the validation process had made it far easier to check and confirm that vulnerabilities discovered using a scanner such as Nessus can actually be exploited by an attacker and are not simply another false positive. It is far too easy to report on vulnerabilities that do not exist and the ability to verify that holes can actually be exploited is an essential aspect of testing a systems security. To understand risk, we need to know the real level of exploitability. Without this, we are simply guessing.
The capability to use these tools has empowered many professionals and has created a rise in the number of people who can research software vulnerabilities. It has created more security professionals who cannot only scan a target for vulnerabilities using a tool such as Nessus, but who can complete tests involving system exploitations and hence validate the results presented to them by a scanner. It is in effect a leg-up and a means
to quickly gain a foothold into the world of security. What needs to be remembered in this however is that it is just a foothold. To continue to grow in this industry, you need to continuously improve and learn. The ability to gain access and validate simple exploits is important, but it is only the start.
This ends when a new application with unexpected calls or controls is found. What do we do when presented with a special case? Here we have to again return to the old art of crafting shellcode. In this article, we will start to look at how to write effective shellcode. POC (Proof of
Concept) situations frequently require one-off solutions.
In these cases the tester or researcher really needs to be able to create their own shellcode to meet the demands imposed at the time.
Add to this the rapid rate at which shellcode such as that in the Metasploit Project can become obsolete and you start to see the need to create your own custom shellcode. Shellcode you create yourself will not be incorporated into any anti-malware signature databases or IDS (Intrusion detection system. This can incorporate both HIDS (or host based IDS) as well as NIDS (or network based systems)) signature match lists. More importantly, the ability to write your own shellcode allows one to learn the internal functioning of a system and the assembly calls better than any text book could do.
At some stage, if we are to be more than white hat script kiddies and want to come to actually understand the application we need to learn how to craft our own custom shellcode. In this article, we start to explain the process used to do this.
Why Create shellcode?
Shellcode can be complex. To effectively write shellcode, you need to understand what the system
We have seen more and more people become reliant on tools such
as Metasploit in the last decade. This ability to use these tools has
empowered many and has created a rise in the number of people
who can research software vulnerabilities.
Starting to
48
SHELLCODE
01/2012 www.hakin9.org/en 49
Beyond automated tools and Frameworks: the shellcode injection process
T
his is designed as a precursor to the actual injection process where we will in a later article next month introduce the actual injection process and start to move from automatic exploit frameworks (such as Metasploit) into being able to create and execute one’s own exploit successfully. In order to do this, we need to start understanding just how code works and to know where to find the fundamentals of the Python programming language. This article will start a monthly series designed to take the reader from a novice to being able to create and deploy their own shellcode and exploits.Introduction
Automated frameworks (including Metasploit) have simplified the testing and exploitation process. This of course comes with a price. Many penetration testers have become tool jockeys with little understanding of just how software functions. This script kiddie approach to code testing does have its place. It has allowed us to drastically increase the number of people working on testing systems for vulnerabilities and in assessing the risks these pose. At the same time, if these individuals do not progress further, simply relying on the ability to
leverage the efforts of others, we will hit bottlenecks in the creation of new tests and processes.
In previous articles, we have covered a number of topics to do with the creation of shellcode. In this one we shall start to introduce the means that will allow the tester to use that code without having to rely on an external framework. Frameworks do allow for the simpler sharing of code, but also limit us at the same time. They lock the tester into selected platforms. More, attacks in the wild have and are moving further away from the automated framework and the tester needs to be able to anticipate and simulate this to remain as effective.
In subsequent articles this will be expanded into the creation of standalone exploit kits.
In order to do this, we also need to take a step back and explain the system and the tools we will use in more detail. To achieve this, we will start with describing the various components that are used and to providing an introduction to the Python programming language. This will also extend into a simple method to analyse shellcode using GCC such that we can come to understand what the shellcode others have created is designed to do. This is a useful
This article is going to follow from previous articles as well as
going into some of the fundamentals that you will need in order to
understand the shellcode creation process, how to use Python as
a launch platform for your shellcode and that the various system
components are.
Beyond Automated
Tools and Frameworks: the shellcode injection process
Listing 1. Shellcode sample (This sample of shellcode has been taken from Zillion (2002). This page goes into detail as to the operation of the shellcode and the reader is encouraged to step through this. The reader will �nd countless many examples online with a simple Google search and many good examples are also included within the Metasploit framework.)
"\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46" "\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1" "\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x23\x41\x41\x41\x41" "\x42\x42\x42\x42";
Atola Insight
That’s all you need for data recovery.
Atola Technology offers Atola Insight – the only data recovery device that covers
the entire data recovery process: in-depth HDD diagnostics, firmware recovery,
HDD duplication, and file recovery. It is like a whole data recovery Lab in one Tool.
This product is the best choice for seasoned professionals as well as start-up data
recovery companies.
• Case management
• Real time current monitor
• Firmware area backup system
• Serial port and power control
• Write protection switch
62
SHELLCODE
01/2012 www.hakin9.org/en 63
Taking Control, Functions to DLL injection
D
LL injection is one of the most common methods used by malware such as a rootkit to load it into the host’s privileged processes. Once injected, code can be inserted into functions being transmitted between the compromised code and a library function. This step is frequently followed with API hooking where the malicious code is used to vary the library function calls and returns.This article is part of a monthly series designed to take the reader from a novice to being able to create and deploy their own shellcode and exploits.
Introduction
In previous articles, we have covered a number of topics to do with the creation of shellcode and assembly language. We continue with an introduction of one of the primary exploitation processes used against a Windows system. In subsequent articles this will be expanded into the creation of standalone exploit kits and in the deployment of a rootkit.
In this article we look at one of the primary infection steps used to compromise a Windows host, DLL injection. This process is used by attackers and is also incorporated into automated frameworks (including Metasploit) as a part of the testing and exploitation process. DLL injection is one of the more common methods used by malware such as a rootkit to load it into the host’s privileged processes. Once injected, code can be inserted into functions being transmitted between the compromised code and a library function. This step is frequently followed with API hooking where the malicious code is used to vary the library function calls and returns.
In order to do this, we also need to take a step back and explain the system and the tools we will
use in more detail. To achieve this, we will start with describing the various components that are used and to providing an introduction to the Python programming language. This will also extend into a simple method to analyse shellcode using GCC such that we can come to understand what the shellcode others have created is designed to do. This is a useful skill when reversing malware as well as a good way to learn from the existing code base and even to leverage some of the various tools that are freely available already.
What is a DLL?
A DLL is a Dynamically Linked Library of executable code (Shewmaker, 2006). Code libraries are important
as they allow developers to reuse common functions. It is firstly inefficient and not economical to rewrite of the same section of code over and over. More importantly, when the same code is replicated in many blocks it becomes more difficult to patch or update software. In addition, standardized libraries allow developers to reuse set functions rather than having to recode them and hence reinvent the wheel each time they develop a program. It is important to note that the best programmers make mistakes. Whenever they have to recode the same material the chances of an error increase.
A DLL can reference a common function allowing the programmer to just learn the call needed rather than having to rewrite create their own. In this, the code would reference the external function using the DLL which is loaded into memory for use by the program. In this article we will be discussing DLLs are loaded into a running memory process. This is a feature of Windows and not a bug. That said, many features also lead to exploitations.
This article is going to follow from previous articles as well as
going into some of the fundamentals that you will need in order to
understand the code exploitation process. In this article we look at
one of the primary infection steps used to compromise a Windows
host, DLL injection.
Taking Control,
68
BUFFER OVERFLOW
01/2012 www.hakin9.org/en 69
Smashing the Stack
T
his article will introduce the reader to the basic principles of code exploitation. We will see what happens when a process is executed or terminated, and how a buffer overflow vulnerability can be leveraged to execute malicious code. Our analysis has been based on the Intel Architecture 32 bit (IA 32) as it represents the main target for hackers and worms. Our code and tools are made available in a way that the reader can reproduce our attack scenarios. Don’t miss the next Hakin9 issue, where we will analyze real vulnerabilities.Theoretical Background
We start our journey with a small introduction on how processes, memory and registers work.
A program becomes a process when it is loaded by a loader in memory and executed. In this phase, a process identifier, called PID (Process Identifier) is assigned to the process. When the loader loads the executable file, some special information that is contained in its header is read. The executable file is in fact a COFF (Common
Object File Format). The COFF implementation is called Portable Executable (PE) in Windows, and Executable and Linking Format (ELF) on Linux systems. Two main
sections are defined:
• the header permits to load in RAM memory the executable file. It holds the information about the
.text, the .data and the .stack sections (and .bss)
• the payload contains the code
When the executable is loaded, the OS organizes the allocated memory in three areas:
• Text: read only area that contains the program’s code and other read only information. It corresponds to the COFF’s text section.
• Data: region where static variables are saved. It corresponds to the COFF’s data section.
• Stack: region in which local variables, return values and parameters of the function are saved. From the perspective of this article, this is the area of interest. A fourth area is the Heap, in which dynamical variables used by the process are allocated.
In a system, any sort of operation is performed using CPU registers that serve as store units. Intel Architecture 32bit (IA32) defines four register families: • General Purpose Registers (GPRs)
• Segment Registers: CS (Code Segment), DS (Data
Segment), ES (Extra Segment), FS, GS, SS (Stack Segment)
• Control Registers: EIP, CRX, ... • Other: EFLAGS, etc...
The GPRs registers are defined as: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP. The E letter was introduced in the change from 16 to 32 bits. The EAX register is shown in the Figure 1.
Two special registers are the Base Pointer (EBP) and the Stack Pointer (ESP). They are commonly adopted
For decades hackers have discovered and exploited the most
concealed programming bugs. But how is it possible to leverage
a buffer overflow to compromise software in modern operating
systems?
Smashing the Stack
Figure 1. Structure of EAX register ���
��
80
BUFFER OVERFLOW
01/2012 www.hakin9.org/en 81
Smashing the stack 2
W
elcome to this follow-up on our previous article on the exploitation of software vulnerabilities, which we published on Hakin9 ES #1 [0]. This article is made of two chapters: In the first one we describe the different protection mechanisms that have been introduced in modern operating system to make exploitation more difficult. We then present several popular workarounds used by attacker to bypass such techniques. Finally, for the joy of our readers, we analyze a real exploit for a Acrobat Reader’s stack-based buffer overflow (CVE-2010-2883).Protection Mechanisms Against Buffer
Overflow
In this chapter we present the protection mechanisms introduced in Windows 7 and the Visual Studio 2008 suite to enhance the security of their users by preventing
one-click easy exploitations.
At a first glimpse, we can divide these mechanisms in three classes of categories:
• Compiler-based: the /GS flag
• Linker-based: the /SafeSEH flag, ASLR and DEP • Runtime checks
Buffer Security Check – /GS
We start by analyzing the /GS flag provided by the Visual Studio C/C++ compiler. This option tries to prevent stack-based buffer overflow at runtime by adding specific code to the procedure’s prologue and
epilogue. Firstly a random value, called cookie or canary, is stored on the stack, and a sort of variable reordering is done.
Once the program is launched, the cookie is saved in the .data section, then, if necessary, during the procedure prologue is moved on the stack between the local variables and the ret address (the value we are going to protect). In a generic situation the stack appears like in Figure 1.
Figure 2 shows how to enable/disable this flag on Visual Studio 2008.
This is the new prologue using the /GS flag:
vuln!main:
00411260 55 push ebp 00411261 8bec mov ebp,esp 00411263 83ec4c sub esp,4Ch
00411266 a100604100 mov EAX,dword ptr [vuln!__security_ cookie (00416000)]
0041126b 33c5 xor EAX,ebp
0041126d 8945fc mov dword ptr [ebp-4], EAX
As someone can see, the value of the cookie is stored in the EAX register, xored with the base pointer and put on the stack.
Modern operating systems come with sophisticated protection
mechanisms to prevent “one-click” exploitations. But, how can
attackers bypass such techniques to compromise remote machines
all over the world? And downloading PDF documents is always a
safe practice?
Smashing
the Stack 2
Figure 1. /GS stack situation
���� ���� ���� ���� ������ ��� ���
88
BUFFER OVERFLOW
01/2012 www.hakin9.org/en 89
Exploit a software with Buffer overflow vulnerability and bypassing ASLR protection
Y
ou will also learn how to write your own exploitation with python programming language and bypassing ASLR protection and finally, how to run your own shellcode to control Vulnerable OS.What is Buffer overflow
Buffer overflow is an anomaly where a program while writing data to a buffer overruns the buffer’s boundary and overwrites adjacent memory. This is a special case of violation of memory safety. For example: if you have a 2 liter bottle and you tried to fill it with 2.5 liters of water, of course the water will overrun the bottle boundary and 0.5 liter will fall down.
Buffer overflow vulnerability is the most dangerous vulnerability in the software world because it could allow for an exploitation for OS which include this vulnerable software.
You can have a look at Buffer overflow top threats, http://
www.isssource.com/attack-vector-buffer-overflows-top-threat/.
If we looked at buffer overflow in technical view: A buffer overflow occurs when data written to a buffer, due to insufficient bound checking corrupts data values in memory addresses adjacent to the allocated buffer.
For example
Here – a program has defined two data items which are adjacent in memory; an 8-byte long string buffer, A, and a two-byte integer, B. Initially, A contains nothing but zero bytes, and B contains the number 1979; characters that are one-byte wide (Figure 1).
Now, the program attempts to store the null-terminated string “excessive” in the A buffer. By failing to check the length of the string, it overwrites the value of B (Figure 2).
Although the programmer did not intend to change B at all, B’s value has now been replaced by a number formed from part of the character string. In this example, on a big-endian system that uses ASCII, “e” followed by a zero byte would become the number 25856. If B was the only other variable data item defined by the program, writing an even longer string that went past the end of B could cause an error such as a segmentation fault, terminating the process.
And what about ASLR protection?
ASLR refers to address space layout randomization. For example, if you have an instruction like “Call ESP from kernel32.dll“ and this instruction offset location is in 0000001, after rebooting your PC this offset will be changed to another number. This means we can’t
In this article you will find out what the Buffer overflow vulnerability is,
and how you can scan any software for this kind of vulnerability.
Exploit a Software
with Buffer Overflow Vulnerability and Bypassing Aslr
Protection
Figure 2. registers after �lling it Figure 1. Empty registers
98
REVERSE ENGINEERING
01/2012
Reversing EXE with OllyDbg
www.hakin9.org/en 99
S
o what is reverse engineering (RE)? Wikipedia says: Reverse engineering is the process ofdiscovering the technological principles of a device, object, or system through analysis of its structure, function, and operation. Normally, source
code is compiled to one or more object files which are then linked to form an executable. The source code is in human readable form, object files are binary files with human-readable symbols. Executables are pure binaries. When we attempt to revert a binary executable into its object form, it is called disassembly. Converting an object file into source code is called decompilation. The whole process is called reverse engineering (Figure 1).
Goals of RE:
The main goals of RE may include the following: • Security/Vulnerability Research: The most common
aim of doing RE is the discovery of potential flaws in the source code such as buffer overflows or any weak business logics implemented, for example client side validations, weak/homemade
encryptions schemes etc. These can be highlighted and may ultimately determine how how secure or insecure the software is.
• Malware research: Understanding behavior and property of malware is very necessary in order to develop a mitigation plan ... how they behave, how they propagate, what flaws they exploit, etc.
• Writing drivers: Sometimes writing a driver for your hardware requires reverse engineering in order to gain a deep understanding of its operation
• Patch Analysis: Before applying patches they can be reverse engineered to take deep dive into their inner functionalities.
A little Dive Into Assembly and Registers
Knowledge of assembly is required to perform a successful RE of a program. Although study of assembly and instruction sets is a separate topic in
This article is a basic introduction to Reverse Engineering. I have
chosen to illustrate the reverse engineering of a sample executable
file, and how to patch it. The article focuses primarily on a practical
example of reversing.
Reversing EXE with
OllyDbg
Figure 1. RE Process ���������� ���������� ����������� ����������� ������������� ����������� �������������� ������������� ������������������������� Figure 2. Stack ��������� ��� ��� ������� ������� �������� �������� ��������� �������������� ����������� ����������� ����������� ��������� ���������������� ���������������� ���������������� ������������ ������� �������� �102
REVERSE ENGINEERING
01/2012 www.hakin9.org/en 103
A quick “hands on” introduction to packing
T
hose 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.
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.
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.
A Quick „Hands On”
Introduction to Packing
Figure 1. Overview of a PE �le’s structure
Listing 1. pe�le’s basis
>>> import pefile #loading the pefile module
>>> pe = pefile.PE("calc.exe") #we open the well-known ‘calc.exe’ program
>>> for s in pe.sections: ... print s.Name ... .text .data .rsrc
