1 - Senior Design - Iowa State University

flameluxuriantData Management

Dec 16, 2012 (4 years and 6 months ago)

275 views

Attack Tool Repository and Player for ISEAGE


Design Report




Team

May06
-
11



Client

Information Assurance Center



Faculty Advisor

Dr. Doug Jacobson



Team Members

Jeremy Brotherton

Timothy Hilby

Brett Mastbergen

Jasen Stoeker




REPORT DISCLAIMER NOTICE

DISCLAIMER: This document was developed as a part of the requirements of an
electrical and computer engineering course at Iowa State University, Ames, Iowa. This
document does not constitute a professional engineering design or a professional land
survey
ing document. Although the information is intended to be accurate, the associated
students, faculty, and Iowa State University make no claims, promises, or guarantees
about the accuracy, completeness, quality, or adequacy of the information. The user of
this document shall ensure that any such use does not violate any laws with regard to
professional licensing and certification requirements. This use includes any work
resulting from this student
-
prepared document that is required to be under the responsib
le
charge of a licensed engineer or surveyor. This document is copyrighted by the students
who produced this document and the associated faculty advisors. No part may be
reproduced without the written permission of the senior design course coordinator.





Date Submitted

December 14
, 2005

i

Table of Contents

List of Tables

…..…..……….…………….…………………………………………………………………
ii

List of Figures
……....……….…………….…………………………………………………………………
iii

List of Definitions

...……….…………….…………………………………………………………………
i
v

1

Introductory Materials

................................
................................
................................

1

1.1

Executive Summary

................................
................................
............................

1

1.2

Acknowledgements

................................
................................
.............................

2

1.3

Problem Statement and Solution

................................
................................
.........

2

1.3.1

Problem Statement

................................
................................
......................

2

1.3.2

Problem Sol
ution

................................
................................
........................

3

1.4

Operating Environment

................................
................................
.......................

3

1.5

Intended Users and Uses

................................
................................
.....................

3

1.5.1

Intended Users

................................
................................
............................

4

1.5.2

Intended Uses

................................
................................
..............................

4

1.6

Assumptions and Limitations

................................
................................
.............

4

1.6.1

Assumptions

................................
................................
................................

4

1.6.2

Limitations

................................
................................
................................
..

4

1.7

Expected End Product and Deliverables

................................
.............................

4

1.7.1

Software Application

................................
................................
..................

4

1.7.2

Documentation

................................
................................
............................

4

2

Approach and Product Design Results

................................
................................
.......

5

2.1

Approach Used
................................
................................
................................
....

5

2.1.1

Design Objectives

................................
................................
.......................

5

2.1.2

Functional R
equirements

................................
................................
............

5

2.1.3

Design Constraints

................................
................................
......................

5

2.1.4

Technical Approach Considerations and Results

................................
.......

5

2.1.5

Testing Requirements Considerations

................................
........................

8

2.1.6

Project Continuation or Modification Recommendations

..........................

9

2.2

Detailed Design

................................
................................
................................
...

9

2.2.1

Database Design
................................
................................
..........................

9

2.2.2

User Interface Design

................................
................................
...............

10

3

Resources and Schedule

................................
................................
............................

15

3.1

Resources

................................
................................
................................
..........

15

3.1.1

Personnel Effort Requirements

................................
................................
.

15

3.1.2

Other Resource Requirements

................................
................................
..

16

3.1.3

Financial Requirements

................................
................................
............

16

3.2

Schedules

................................
................................
................................
..........

17

3.2.1

Project Schedule
................................
................................
........................

17

3.2.2

Deliverables Schedule

................................
................................
...............

18

4

Closur
e Material
................................
................................
................................
........

19

4.1

Project Team Information

................................
................................
.................

19

4.1.1

Client Information

................................
................................
.....................

19

4.1.2

Faculty Advisor Information
................................
................................
.....

19

4.1.3

Team Member Information

................................
................................
.......

19

4.2

Closing Summary
................................
................................
..............................

20

Appendix A

................................
................................
................................
.......................

21

ii

List of Tables

Table 2
-
1. Important Pros and Cons of Databases

................................
..............................

7

Table 2
-
2. Important Pros and Cons of Programming Languages

................................
......

7

Table 3
-
1. Original Personnel Effort Resource Requirements

................................
.........

16

Table 3
-
2. Revised Personnel Effort Resource Requirements

................................
..........

16

Table 3
-
3. Other Resource Requirements

................................
................................
.........

16

Table 3
-
4. Or
iginal Estimated Project Costs
................................
................................
.....

17

Table 3
-
5. Revised Estimated Project Costs

................................
................................
.....

17

iii

List of Figures

Figur
e 1
-
1. Basic solution system architecture

................................
................................
...

3

Figure 2
-
1. Application Sitemap

................................
................................
.......................

10

Figure 2
-
2. Application Homepage
................................
................................
...................

11

Figure 2
-
3. Application Search Page

................................
................................
................

12

Figure 2
-
4. Application Search Results

................................
................................
............

13

Figure 2
-
5. Application Attack Launch Page

................................
................................
...

14

Figure 2
-
6. PHPmyAdmin homepage

................................
................................
...............

15

Figure 3
-
1. Original Project Schedule

................................
................................
..............

18

Figure 3
-
2. Revised Project Schedule

................................
................................
...............

18

Figure 3
-
3. Deliverables Schedule

................................
................................
....................

19

iv

List of Definitions

Attack

-

An assault against a computer system or network that is deliberately executed.


Database



A set of related files and groups of information that are managed by a
database management system.


Database Management System



Software that manages a dat
abase allowing the search
and retrieval of its contents.


Exploit



An attack on a computer system that takes advantage of a particular
vulnerability in the system.


ISEAGE



Internet Scale Event and Attack Generation Environment. A network
d
edicated to c
reating a virtual Internet for the purpose of researching, designing, and
testing cyber defense mechanisms.


Network



A series of computers and devices interconnected by communication paths.
May also include smaller interconnected subnets.


Virus



A pie
ce of software that “infects” a computer by attaching itself to other files on
a system and behaving maliciously.


Vulnerability



This is a weakness in a system due to security procedures,
implementation or other means that could be exploited.


Web Applic
ation



An application interface that resides on a web server, which is
accessed and used through a web browser.


1

1

Introductory Materials

This section includes the executive summary, acknowledgements, problem statement,
operating environment, intended user(
s) and use(s), assumptions and limitations, and
expected end
-
product and deliverables.

1.1

Executive Summary

Today’s world is changing shape as it increases its dependency on computer
technology. As society moves further into the digital world, there has been

growing
concern for the security of the information stored on computers. Finding exploits to
evaluate the security of a given system can be a daunting task. Those individuals
wishing to test system security need a way to quickly locate relevant exploits

and
execute them.


The May06
-
11 team
’s approach

will develop a solution that provides a web
-
based
user interface to a central repository of exploits. This interface will provide users
with
the ability to search for, and then execute, specific exploits
based on their
characteristics.
S
tandardized d
ocumentation about how to use
each
exploit will

also

be made available to the users. In addition, administrators will be provided a means
for maintaining the repository. Finally, this system will be
deployed

for

ISEAGE
(Internet Scale Event and Attack Generation Environment), meaning that users can
evaluate security solutions by carrying out real attacks on real equipment
.



As you can see from the approach just described, the end
-
product will be a web
applic
ation that provides an interface to a database of attacks. The team will also be
developing a set of standardized documentation for using each exploit. Finally, user’s
guides and administrative guides will also be delivered to the client.


The design pro
cess for this project has been fairly straightforward. The team’s first
objective was to gain a solid understanding of the requirements. This was primarily
accomplished through meeting with Dr. Doug Jacobson, the faculty advisor for this
project. A basi
c set of assumptions was also developed during this period. The
requirements and assumptions
agreed upon
became the foundation for the design
process.


The next step in the process was to research existing technologies
to
determine the
best technology
for

this project. The research focused on finding a scalable database
solution, an effective programming language, and a viable
web
server solution. All
feasible options were systematically considered and reviewed before making the final
design decisions.
In some cases, more in
-
depth research was made to ensure the best
decision could be reached given the available information. Ultimately, the group
selected MySQL as the database solution, PHP as the programming language, and
Apache as the
web
server solut
ion. These selections were presented to and approved
by Dr. Jacobson before becoming final.




2

The next step in the process was to determine the layout of the user interface. During
this phase, each team member spent time brainstorming and
developing
basic

sketches. From the ideas presented in these sketches, a more refined series of
screenshots were created. To better capture all the possibilities, the group contacted
graduate students currently working in the ISEAGE environment for their opinion.
As wi
th the technologies, all possibilities were considered before finalizing the
screenshots. The result
ing

screenshots
were then used to develop a well written
description of the overall design
.


As inferred earlier, the overall design of the team’s solution

can be described as a
simple web application. The application will consist of a series of simple web

pages
as the user interface. An overall description of the software and the project objectives
is presented on the homepage. A search page will then be

developed that is populated
with a text box for the search name and a series of drop
-
down menus to select attack
characteristics. Upon conducting a search, the page will be updated with a table of
relevant results. From there the user will be able to cl
ick on an attack to take him/her
to the launch page. At this point, desired attack parameters may be entered into
a

text
box and once the ‘Launch’ button is pressed, the attack will be executed.


The team attempted to keep the database design as simple as

possible. Users will be
able to search for attacks based on the following fields: Name, Target Platform, Type
of Attack, Service Attacked, Documentation Available, Confirmed Exploit
,

and
Runnable Attack.


There are currently no major design issues that n
eed to be resolved. The team will
continue to foll
ow the official project plan
schedule. In the event that a potential
design flaw is discovered, the team will hold a meeting to fully discuss the situation
before making any design changes.

1.2

Acknowledgemen
ts

The team would like to thank Dr. Doug Jacobson, the team’s faculty advisor, for his
time and expertise.

1.3

Problem Statement and Solution

The problem being solved is described in the following two sections. First, the team
describes the general problem ar
ea. Secondly, the team
discusses

the proposed
approach to a solution.

1.3.1

Problem Statement

The team is working to develop a tool that would allow researchers to carry out
specific network attacks against computer hosts. End
-
users need the ability to
locate
and launch relevant attacks as quickly and easily as possible. In addition,
users should also have the ability to search for a specific attack based on a
variety of criteria. They also need to have a way to easily interact with this tool,
such as a web b
ased graphical interface.



3

1.3.2

Problem Solution

To solve this problem, the team is going to develop an application that connects
to a database of network attacks. The application will allow users to search the
database and launch attacks from other dedicated

machines. Administrative
access will be required to update or modify the database in any way. The
solution will allow multiple users access simultaneously. The application will
be a web interface, which allows platform
-
independent access.


The diagram
below depicts the basic system architecture. A user machine will
send a search request to the web server. The web server will execute a PHP
script that connects to the database and performs the desired query. Results
from the query are then returned bac
k to the user’s machine. The attack is
launched in a similar fashion by using another PHP script that will actually
execute the desired attack.


User Machine
Database
Web Server
PHP Script
Windows Attacks
Macintosh Attacks
Linux Attacks
Target Machine

Figure
1
-
1
. Basic solution syste
m architecture


1.4

Operating Environment

This application will run on computers on the ISEAGE network. A temperature
controlled environment of 60
-
90 degrees Fahrenheit is necessary to ensure operation.
High levels of moisture could cause hardware failures,
which could render the
database or other machines inoperable. Computers using the application or those
running the database could be affected by computer viruses.

1.5

Intended Users and Uses

The sections below describe the intended users and uses for the end
-
product.



4

1.5.1

Intended Users

This application is intended for researchers, vendors, and computer
professionals. Most end
-
users will have a strong background in information
technology and familiarity with information security. It may also be used for
training
purposes so it should also cater to those with lesser skills. Most users
will expect to see details about search results to evaluate the threat level and
scope of a particular exploit.

1.5.2

Intended Uses

This application will provide a mechanism to evaluate we
aknesses in computer
systems and network architectures. It will allow users to search and launch
attacks. It may also be used for training purposes. It will not fix vulnerabilities
or pinpoint the cause of failure. This solution will not contain all po
ssible
exploits and its database will rely on administrators for updating its contents.

1.6

Assumptions and Limitations

The assumptions and limitations of this project are listed in the following sections.

1.6.1

Assumptions



Maximum number of simultaneous users is tw
enty



Maximum query response time is two seconds



The application will be coded using PHP and MySQL



Database updates require administrator action



The application will run on any system with a web browser

1.6.2

Limitations



The database will not include all possibl
e attacks or all known attacks

but
will contain as much as time allows



Launching attacks will be done at the click of a button



The application will only be used in the ISEAGE environment



Not all attacks in the repository will be able to be tested and verif
ied



This system will not fix vulnerabilities

or

pinpoint the cause of failure

1.7

Expected End Product and Deliverables

After completing this project the team expects to deliver the end software product and
associated documentation.

1.7.1

Software Application

At the

end of this project, the team expects to provide ISEAGE with a large
database of malicious software from both the past and the present. In addition,
the team will deliver an end
-
product that interfaces to this database.

1.7.2

Documentation

Upon finishing thi
s project, the team will deliver documentation of setup and
software use to the client. A user’s guide and administrator troubleshooting


5

guide will also be developed. In addition, the team will be turning over
commented source code and testing results.

2

A
pproach and Product Design Results

This section includes the approach used for the project and the detailed results of the
design.

2.1

Approach Used

This section details the technical approach the team used for
developing the

design
of the end product.

2.1.1

Design
Objectives

The
design objectives for the project are
:



To develop a web application for searching a repository of attacks
.



To provide a simple, easy to use interface for one
-
click launching of
attacks
.



To populate the database with an initial set of attacks

and provide the ability
to modify its contents in the future
.



To offer the option to download attacks from the repository
.

2.1.2

Functional Requirements

The final product will meet the following requirements:



Provide a web
-
based interface to a searchable databa
se of computer exploits
suitable for users with different technical abilities
.



The d
atabase will be searchable based upon an item name or
specific
characteristics (i.e. version, target platform, type of a
ttack)
.



Allows users to
launch attacks with the clic
k of a button
.



Administrative users will have the ability to add or remove items from the
database
.



Supplies users with standardized documentation about
each
exploit

s usage
.



Ability to download attack code in order to launch an attack manually
.

2.1.3

Design Con
straints

The constraints on the end
-
product are the following:



The software will be platform independent

and web
-
based



The software shall allow users to launch attacks with a single click



The database will contain a variety of attacks



The system will not f
ix vulnerabilities

2.1.4

Technical Approach Considerations and Results

Before deciding on the technologies to use for this project, the team carefully
examined the options currently available. This project require
d

a powerful and
fast database solution. The te
am decided to consider solutions from Oracle,
PostgreSQL, MySQL, and SQL Server 2005
.



6

Table

2
-
1

at the end of this section

highlights the pros and cons the team
considered for database technologies.


Due to comple
xity and lack of

extra features that would benefit this particular
project
, Oracle and PostgreSQL were quickly
removed

from contention.
MySQL and SQL Server 2005 were the two remaining solutions to be
evaluated. Both appeared to have similar feature sets
, and SQL Server 2005
appeared to be the solution that would have been the simplest to learn.
However, several factors contributed to outweigh those advantages.


First,
the team

would have had to
contend with licensing issues that would have
introduced ha
ssle and make the project less economically appealing
. Second,
the release date for SQL Server 2005 was November 7
th
, 2005 (which was still
two weeks into the future at the time the technology was being considered).
The team
did not want to take chances
on the release date being pushed back,
and knew
the
documentation available for the product would be limited due to
its upcoming release
.


The current version of MySQL has a very large user base around the globe, and
is mature and tested, and unlikely to s
uffer from the type of bugs that might
exist

in a newly released product.
Additionally, this solution also provided the
same features and capabilities as SQL Server 2005.
Therefore, it was decided
that MySQL would be the best database solution.


Next, th
e team had to decide on a programming language for creating the web
interface. Our main contenders were PHP and ASP.NET 2005.

Table
2
-
2

at the
end of this section covers

the important pros and cons of each langua
ge.

The
decision was difficult because both languages provided an effective solution
.


PHP
is

a popular option in the global community, and as a result, a large amount
of documentation and open
-
source examples are readily available. On the other
hand, t
he application code may have been easier to write using ASP.NET (due
to the amount of built in functionality provided by Microsoft).


While ASP.NET certainly has the potential to be an incredible product
,

it
was
victim to some of the same issues that were
involved in deciding against SQL
Server 2005. Its release date was also November 7
th
, 2005, and it would have
had the same licensing issues as the server. In addition, while any computer
could view ASP.NET generated web pages,
this would have required th
e use of
a Windows
-
based server
. Using PHP gave more flexibility in choosing
the
platform.


Finally, the team had to decide on a web server. The choices were Apache and
IIS. Given the fact that the team was aiming for platform independence

and had
alread
y decided again
st using Microsoft products
, the decision to use Apache
was a relatively easy one.



7

Table
2
-
1
. Important Pros and Cons of Databases

Products

Pros

Cons

PostgreSQL

-

Relatively Common.

-

Mature a
nd well tested.

-

No licensing issues.

-

More features than MySQL.

-

Complex.

-

Not as intuitive to learn as MySQL or
SQL Server 2005.

-

Smaller user base than other products
listed.

-

Less online examples than other
products listed.

-

Additional features
over MySQL are
not ones
the team

need
s
.

Oracle

-

Heavily used by enterprise.

-

Very large user base.

-

Well established in industry.

-

Lots of documentation.

-

Mature and well tested.

-

Extremely complex, more than any of
the other products.

-

Proprietary

licensing issues.

-

Additional enterprise features are not
ones
the team

would use.

SQL Server
2005

-

Best integration of any solution.

-

Most extensive tools.

-

Fast and scalable.

-

Large amount of prewritten
functions and objects.

-

Interacts well with

the Visual
Studio IDE.

-

Microsoft licensing issues.

-

Future release date.

-

Newness means additional likelihood of
major bugs.

-

Database tied to Microsoft platforms.

MySQL

-

Large amount of online examples
and a large online user community.

-

Current
version mature and well
tested.

-

Open source license will be
easiest to work with.

-

Able to be used on most major
platforms.

-

Relatively easy to learn.

-

Not as much code comes with the
database as with SQL Server 2005.

-

Not as well integrated with oth
er
products as SQL Server 2005 is with .Net
products.


Table
2
-
2
. Important Pros and Cons of Programming Languages

Products

Pros

Cons

ASP .NET
2005

-

Extremely well integrated with SQL
Server 2005.

-

Ability

to drag and drop graphical
web interface.

-

Large MSDN documentation library.

-

Very large amount of built in objects
and functions.

-

Excellent IDE and graphical
debugger.

-

Microsoft licensing issues.

-

Future release date.

-

Newness means additional
li
kelihood of major bugs.

-

A server for ASP .NET would
be tied to Microsoft platforms.

-

A
lready decided against SQL
Server 2005.

PHP

-

Current version well tested.

-

Many online examples.

-

No licensing issues.

-

Cross platform.

-

Fast code execution

-

Ea
sy to learn

-

Not as well integrated as ASP
.NET.

-

No graphical debugger/IDE.

-

No ability to drag and drop
interfaces.




8

2.1.5

Testing Requirements Considerations

The team plans to test the project components as they are created. The plan
includes full statem
ent testing, which will ensure that every statement in the
code is executed at least once. The team also plans to perform integration
testing at each integration point as the system is put together. This will ensure
that new features don’t introduce

any

n
ew bugs.



The final system will be tested by both the team members and several graduate
students working on
other parts of
ISEAGE
,
not directly related to
this

project
.
The tests will take place at the ISU Research Park where the ISEAGE
environment is bei
ng
developed
. This will allow
the

team easy physical access
to all of the machines, and will be convenient for the grad students who can
often be found working there.


The graduate students will perform

the

black box testing of the system, largely
focusin
g on whether or not the system appears to work as expect
ed
. Because
the

team will have a
deeper

knowledge of the software

and
database contents,
team
members

will be performing the white box testing for the system.


The white box testing

will focus not ju
st on the statement testing for the system
itself, but will also heavily test SQL query filtering.
The team wants

to make
certain that the system won’t accept unauthorized
or malicious
queries
. In
addition, the team also needs to be sure

that all correct
results are being
returned.

This means trying multiple methods to return the same results, i.e.
choosing an attack by name, then just platform, etc.


When the system
rejects malicious or malformed
queries and when
the system
returns results known to exist

in the database via multiple methods, white box
testing will be considered successful.



The team’s

testing documentation will record the queries that were
used

as well
as the database results that were returned. Changes to the state of the database
will
also be recorded.

For accountability, the tester’s name and the test date will
also be noted.


In addition to the system and database testing, the client has requested that, if
possible, the team try to test the malicious software being placed in the data
base
to
it actually works properly
. To do this the team will set up a series of systems
and then select a number of attacks to execute. Due to constraints on time and
the availability of target systems and architectures, it will not be possible to
verify

that all malicious software works as it claims. However, the

team
will
attempt to at least show that every piece of software produces network traffic

per the client’s request
. If an attack tool can meet these criteria, then it will be
added to the datab
ase.



9

2.1.6

Project Continuation or Modification
Recommendations

At this time, the team plans to continue the project as initially proposed.
Meetings have been held with the client and all parties

agree with

the decision
to move forward with development.

2.2

Detaile
d Design

This section details the design specifications for the software application the team is
developing. The design is broken down into sections
covering

the database design
and the user interface. Those design aspects are detailed
in the following s
ubsections
.

2.2.1

Database Design

For this project, the database will hold all of the information about each attack
stored in the repository. To keep the database design simple, a single table
will be used to store the information about each item. The fields f
or each item
are described in the list below.



Name

This field contains the name of the exploit.



Target Platform

This field contains the platform that the attack targets, i.e. Windows,
Linux, etc.



Source Platform

This field contains the platform the attack
is launched from, i.e. Windows,
etc.



Type of Attack

This field contains a generalized category for the attack, i.e. DoS, specific
application, man in the middle, etc.



Service Attacked

This field contains the service being attacked if applicable, i.e. ftp,
telnet,
etc.



Documentation

This field will indicate if the team has standardized documentation for
using this tool. If it is available, clicking on the yes link will open the
documentation in a new browser window.



Confirmed Exploit

This field will indicat
e if the attack has been able to be successfully
executed. A successful attack means that the tool was confirmed to work
by the team as documented, i.e. provides root access on a machine, etc.



Runnable Attack

This field will indicate if the attack will ru
n and generates network traffic.
Not all attacks can be tested because of limited availability of time and
properly configured machines (correct vulnerabilities). If this field is a
yes, it means that a user can execute this attack but it is not guarante
ed to
work correctly.



Version



10

This field contains the version number of the exploit stored on the
repository.



Location

This field contains the name of the machine that actually holds the attack
executable.



Homepage

This field will list the homepage of the
attack if applicable.



Execution Command

This field will store the command necessary to launch the attack from one
of the designated attack machines. This field is not displayed to users.


Of the above fields the only user searchable fields are as follows:

Name,
Target Platform, Type of Attack, Service Attacked, Documentation,
Confirmed Exploit and Runnable Attack.

2.2.2

User Interface Design

The team has decided that the best method to interface with the database is
through a dynamic webpage. This solution will

provide access from any
machine with a web browser and also means that user
s

do not
need
to install
separate software. The navigational layout of the website is detailed in
Figure
2
-
1

below. Each
page’s functionalit
y will be described in more detail as the
design is discussed further.



Figure
2
-
1
. Application S
itemap


The first page the user will be brought to is the homepage. The left
side of
this page will provide navigational links to all of the other pages. This
navigational area will remain static throughout the website to avoid confusion
and make navigation
simple
.
The homepage will also contain a brief
description of the project

and the software
’s
capabilities
.

Figure
2
-
2

below
shows
a prototype of the homepage
.




11

Attack Tool Repository and Player
Attack Tool Repository and Player
Welcome to the ISEAGE attack tool repository and player
Today’s world is changing shape as it increases its dependency on computer technology
.
As we move further into the
digital world
,
there has been growing concern for the security of the information stored on computers
.
Finding exploits to
evaluate the security of a given system can be a daunting task
.
Those individuals wishing to test system security need a
way to quickly locate relevant exploits and execute them
.
This web application will provide you with the capabilities to search for attacks based on a number of different criteria
and then provide the ability to launch a particular attack
.
You also have the option of downloading the source
(
if
available
)
and setting up the attack yourself
.
If you have any questions or comments
,
please contact an administrator
through the contact info page
.
Site Navigation
Home
Search
Contact Info
Launch Attack
Admin

Figure
2
-
2
. Application Homepage


When the user deci
des he/she is ready to search for an attack, the search link
on the homepage, or any other page, will bring the user to the search interface.
The user will either be able to enter a name
and/
or choose from a variety of
dropdown menus to select
database
fi
elds as search criteria. Once the user has
clicked on the
’R
un
S
earch


button, all of the information that was selected
will be aggregated into a search query string for the database.
This search
query will be validated by the PHP script and an error mes
sage will be
returned to the user if the query contains invalid characters.
The search page
is depicted
below
in
Figure
2
-
3
.




12

Attack Tool Repository and Player
Attack Tool Repository and Player
Welcome to the ISEAGE attack tool repository and player
Select your search criteria below
Target Platform
Service Attacked
Type of Attack
Doc
.
Avaliable
Confirmed exploit
Runnable
Name search
Run Search
Site Navigation
Home
Search
Contact Info
Launch Attack
Admin

Figure
2
-
3
. A
pplication Search Page


The query string formed above will then be used by a PHP script to query the
database. This script will then transform the results of the query into HTML
and display the results in a table on the search page. Several of the headin
gs
in the
results
table will be hyperlinked. This indicates that the user can sort
the results by simply clicking the desired heading.


The homepage heading will indicate the homepage for the source code if that
information is available. Users will als
o have the option to download the
source code, if available, by clicking on the corresponding link under the
download column. Finally, the names of the attacks are also hyperlinked to
allow quick access to
the application’s
launch capabilities.

Figure
2
-
4

below
illustrates what the search page will look like when the results are returned.
For more information about the meaning of each heading, please refer back to
section
2.2.1
.




13

Attack Tool Repository and Player
Attack Tool Repository and Player
Welcome to the ISEAGE attack tool repository and player
Select your search criteria below
Target Platform
Service Attacked
Type of Attack
Doc
.
Avaliable
Confirmed exploit
Runnable
Name search
Run Search
Home
Search
Contact Info
Site Navigation
Launch Attack
Name
Target
Platform
Doc
.
Avaliable
Service
Attacked
Type of
Attack
Confirmed
exploit
Runnable
Location
(
Machine
)
Source
Homepage
Version
Number
test
2
windows
no
web
DOS
yes
yes
micro
http
://
test
2
.
com
2
.
0
.
2
test
4
unix
no
web
DOS
no
yes
sparky
http
://
test
4
.
com
1
.
0
.
2
test
6
unix
no
web
DOS
no
yes
sparky
http
://
test
6
.
com
1
.
0
.
2
test
8
windows
no
web
DOS
yes
yes
micro
-
1
.
0
.
2
test
10
unix
yes
ftp
app
no
yes
sparky
-
1
.
0
.
27
test
12
unix
yes
web
DOS
no
yes
sparky
http
://
test
12
.
com
2
.
0
test
14
unix
yes
telnet
app
no
yes
sparky
3
.
3
test
16
unix
no
smtp
DOS
no
yes
sparky
-
4
.
1
test
18
bsd
no
icmp
DOS
no
yes
curly
-
1
.
0
.
2
test
1
unix
yes
web
DOS
yes
yes
sparky
-
1
.
0
.
2
test
3
linux
yes
ftp
app
yes
yes
torvi
-
1
.
3
test
5
mac
no
ssh
app
no
yes
darwin
http
://
test
5
.
com
5
.
6
test
7
unix
yes
telnet
app
no
yes
sparky
-
0
.
8
test
9
unix
yes
email
DOS
yes
yes
sparky
http
://
test
9
.
com
1
.
0
.
2
test
11
mac
yes
dns
app
no
yes
darwin
-
1
.
0
.
2
test
13
linux
no
dns
app
no
yes
torvi
http
://
test
13
.
com
1
.
0
.
2
test
15
bsd
yes
email
DOS
yes
yes
curly
1
.
0
.
2
test
17
unix
yes
snmp
DOS
yes
yes
sparky
-
1
.
0
.
2
test
19
unix
yes
ssh
app
yes
yes
sparky
http
://
test
19
.
com
1
.
0
.
2
-
-
Download
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Click here
Admin

Figure
2
-
4
. Application Search Results


Now that the user has conducted a search, he/she will now have the ability to
launch an attack. As hinted at previously, if the u
ser clicks on the hyperlinked
name of an attack he/she will be brought to the attack launch page. If using a
hyperlinked search result, the table displayed on the launch page will contain
the results of all the attacks by the clicked name. Alternatively,

the user can
use the launch attack link in the navigation area to proceed to the launch page
at any time. If the user chooses this option, he/she will have to run a search
from the launch page to display attacks that can be executed

just as described
for

the search page
.


Regardless of the method used
,

the user will be presented with a table

containing a series of radio buttons before the name column. The user can
then select only one button to indicate the attack he/she would like to launch.
At that ti
me, any desired attack parameters can be specified in the text box
above the launch button. If no options are specified, default parameters will
be used.

Attack parameters can be accessed by clicking on the link under the
documentation available heading.

The standardized documentation will
then
be displayed in a new browser window.


Once the user presses the
‘L
aunch


button the attack is then executed. At that
time, the user will be given a prompt indicating if the launch was successful

or


14

indicating
an
y

error
s
. The launch page functionality can be better understood
by examining
Figure
2
-
5
.


Attack Tool Repository and Player
Attack Tool Repository and Player
Welcome to the ISEAGE attack tool repository and player
Site Navigation
Search for the attack you wish to run
Name
Target
Platform
Doc
.
Avaliable
Service
Attacked
Type of
Attack
Confirmed
exploit
Runnable
Location
(
Machine
)
Source
Homepage
Version
Number
test
3
linux
yes
ftp
app
yes
yes
torvi
-
1
.
3
Select the radio button of the attack you would like to launch then press launch to run the attack
.
Note
:
You will only be able to select
1
attack
Launch
Target Platform
Service Attacked
Type of Attack
Doc
.
Avaliable
Confirmed exploit
Runnable
Name search
Run Search
Command line parameters
Enter any command line parameters you wish to use with the attack in the box below
Home
Search
Contact Info
Launch Attack
Admin

Figure
2
-
5
. Application Attack Launch Page


Th
e last aspect of the design is the administration page. The team decided
that the best method to implement simple administration features is through
open source database administration tools.
The faculty advisor also approved
this decision.
PHPmyAdmin,
is the tool that the team has decided to use. It
provides a simple web interface that will allow administrators to login and
modify the contents of the database. Clicking on the administrator link on the
left navigation area will connect to the applicati
on and prompt a user to login.
Once login is successful, administrative features will be available.
Figure
2
-
6

depicts the home screen for database administration.



15


Figure
2
-
6
. PHPmyAdmin homepage

3

Resources and Schedule

This section details the
resources necessary for this project and the schedule associated
with its completion.

3.1

Resources

This section details the personnel effort requirements, other resource require
ments,
and estimated financial requirements.

3.1.1

Personnel Effort Requirements

Table
3
-
1

details the original personnel resource
s

estimations necessary for
this project.
Table
3
-
2

details the revised personnel reso
urces taking into
consideration

the actual time needed to complete Tasks 1 and 2 as well as a
revised estimation for Task 3.
Task definitions can be found in
Appendix A
.


As t
he tables show, Task 1 took approximately half the time that was expected
because the project turned out to be simpler to define than anticipated. Dr.
Jacobson was able to clearly define his requirements which made the task
relatively easy.




16

The origina
l effort estimates also overestimated the time
needed

to complete
Task 3. Since the project definition and required functionality are so clear, the
end
-
product design has proved to be more straight forward than originally
anticipated
. As a result
, the pe
rsonnel effort requirements for this task have
been scaled back considerably.

All other task effort requi
rements have
remained the same.


Table
3
-
1
.
Original Personnel Effort Resource Requirements

Team Members
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Totals
Jeremy Brotherton
9
4
50
31
16
11
16
40
177
Tim Hilby
5
5
42
40
20
14
13
35
174
Brett Mastbergen
8
6
45
37
15
12
11
42
176
Jasen Stoeker
7
3
43
35
22
16
12
45
183
Total
29
18
180
143
73
53
52
162
710
Table 3-1. Original personnel effort resource requirements


Table
3
-
2
.
Revised Personnel Effort Resource Requirements

Team Members
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Totals
Jeremy Brotherton
4
10
17
31
16
11
16
40
145
Tim Hilby
2
7
12
40
20
14
13
35
143
Brett Mastbergen
4
7
9
37
15
12
11
42
137
Jasen Stoeker
2
8
12
35
22
16
12
45
152
Total
12
32
50
143
73
53
52
162
577
Table 3-2. Revised personnel effort resource requirements

3.1.2

Other Resource Requirement
s

There should not be any additional resources necessary to complete this
project
. Our team plans to use open source software, which is freely
available. ISEAGE already has the equipment necessary for the team to use
for testing purposes.

Team costs are depicted in
Table
3
-
3
.

Table
3
-
3
. Other Resource Requirements

Item
Costs
Project Plan Binding
6.00
$

Design Report Binding
6.00
$

Final Report Binding
6.00
$

Total
18.00
$

Table 3-3. Other Resource Requirements

3.1.3

Financial Requirements

This section details the total financial resources necessary to complete this
project.

3.1.3.1

Estimated Costs

Table
3
-
2

above represents the estimated hours spent on all the tasks
necessary to complete the project. Other costs involved in the project are
associated with the project poster and documentation preparation
,

which will
be paid for by team members. The origin
al project
cost

estimates are shown in
Table
3
-
4
, while the revised estimated are shown in
Table
3
-
5
. The revised


17

estimated project cost conveys the cost impact of revisions

made to the
personnel effort resource estimates (
Table
3
-
2
). Table 3
-
4 also includes 4
computers
to be used for the attack repositories that will be provided by the
ISEAGE project.


Table
3
-
4
.
Original Estimated Project Costs

Item
W/O labor
With labor
Donated costs
Project poster
65.00
$

65.00
$

Bound project documentation
20.00
$

20.00
$

4 Donated computers (ISEAGE)
1,600.00
$

Labor at $11.00 per hour:
Jeremy Brotherton
1,947.00
$

Tim Hilby
1,914.00
$

Brett Mastbergen
1,936.00
$

Jasen Stoeker
2,013.00
$

Total costs
85.00
$

7,895.00
$

1,600.00
$

Table 3-3. Original estimated project costs


Table
3
-
5
. Revised Estimated Project Costs

Item
W/O labor
With labor
Donated costs
Project poster
65.00
$

65.00
$

Bound project documentation
18.00
$

18.00
$

4 Donated computers (ISEAGE)
1,600.00
$

Labor at $11.00 per hour:
Jeremy Brotherton
1,595.00
$

Tim Hilby
1,573.00
$

Brett Mastbergen
1,507.00
$

Jasen Stoeker
1,672.00
$

Total costs
83.00
$

6,430.00
$

1,600.00
$

Table 3-4. Original estimated project costs

3.2

Schedules

The sections below represent the schedule
s that have been established to complete
this project on time.

3.2.1

Project Schedule

The figures below show the project time line from start to finish. Figure 3
-
7
shows the original project schedule with the estimated for the tasks in section
3.1.1. Figure 3
-
8 shows the revised project schedule which includes work
completed so far. School breaks are indicated by a series of periods.


The updated time line shows that the group has been able to meet or beat all
deadlines so far. Some of the work such as th
e project definition and user
identification was done in a more parallel fashion than planned, but did not affect
the overall schedule for the project. So far the project remains on schedule.



18


Figure
3
-
1
.
O
riginal Project Schedule



Figure
3
-
2
.
Revised Project Schedule

3.2.2

Deliverables Schedule

The figure below shows the timeline for project deliverables.

The dates for
deliverables have not changed.



19


Figure
3
-
3
.
Deliverables Schedule

4

Closure Material

This section includes team information and the closing summary.

4.1

Project Team Information

Contact information for team members, the client, and faculty advisor are provi
ded in
the following sections.

4.1.1

Client Information

Information Assurance Center

Contact: Doug Jacobson

2419 Coover

Ames, IA 50011
-
3060

Office Phone: 515
-
294
-
8307

Fax: 515
-
294
-
8432

Email:
dougj@iastate.edu

4.1.2

Faculty

Advisor Information

Doug Jacobson

2419 Coover Hall

Ames, IA 50011
-
3060

Office Phone: 515
-
294
-
8307

Fax: 515
-
294
-
8432

Email:
dougj@iastate.edu

4.1.3

Team Member Information

Jeremy Brotherton

Major: Computer Engineering

905 Dickinson #113

Ames, IA 50014

Phone: 515
-
292
-
9704

Email:
bigjermb@iastate.edu


Timothy Hilby

Major: Computer Engineering

252 Barton Anders

Ames, IA 50013

Phone: 515
-
572
-
0890

Email:
steiner@iastate.edu




20

Jasen Stoeker

Major: Computer Engineering

2310 Martin Lovelace

Ames, IA 50012

Phone: 515
-
572
-
6079

Email:
jasen@iastate.edu


Brett Mastbergen

Major: Computer Engineering

451
0 Steinbeck St. #4

Ames, IA 50014

Phone: 515
-
451
-
5700

Email:
siver94@iastate.edu

4.2

Closing Summary

With today’s rapid increase in computer technology the problem of computer security
is rising. The ability to create

defenses against potential security threats begins with
gaining an understanding of how computer networks and computer technologies can
be attacked an exploited. The Attack Tool Repository and Player, in conjunction with
the ISEAGE will provide the abili
ty to quickly, locate and execute a large number of
attacks and exploits. The propo
sed solution will include a web
-
based search engine
capable of searching the attack database. Each attack entry will contain relevant
attack information and documentation
and will be tied to a repository that will allow
all attacks to be executed from their native platform.



21


Appendix A

Task 1


Problem Definition

Subtask 1a


Problem Definition Completion

Subtask 1b


End
-
Users and End
-
Use Identification

Subtask 1c


Const
raint Identification


Task 2


Technology Considerations and Selection

Subtask 2a


Identification of Possible Technologies

Subtask 2b


Identification of Selection Criteria

Subtask 2c


Technology Research

Subtask 2d


Technology Selection


Task 3


End
-
P
roduct Design

Subtask 3a


Identification of Design Requirements

Subtask 3b


Design Process

Subtask 3c


Documentation of Design


Task 4


End
-
Product Prototype Implementation

Subtask 4a


Identification of Prototype Limitations and Substitutions

Subtask
4b


Implementation of Prototype End
-
Product


Task 5


End
-
Product Testing

Subtask 5a


Test Planning

Subtask 5b


Test Development

Subtask 5c


Test Execution

Subtask 5d


Test Evaluation

Subtask 5e


Documentation of Testing


Task 6


End
-
Product Documen
tation

Subtask 6a


Development of End
-
User Documentation

Subtask 6b

Maintenance/Support Documentation


Task 7


End
-
Product Demonstration

Subtask 7a


Demonstration Planning

Subtask 7b


Faculty Advisor Demonstration

Subtask 7c


Client Demonstration

Sub
task 7d


Industrial Review Panel Demonstration


Task 8


Project Reporting

Subtask 8a


Project Plan Development

Subtask 8b


Project Poster Development

Subtask 8c


End
-
Product Design Report Development

Subtask 8d

Development of Project Final Report

Sub
task 8e


Weekly Email Reporting