8/19/2019 Project10_Team2Project 1

1/9

Assignment 10: Security Testing

Part 1:

Research the major security vulnerabilities of the ATM Simulation. Develop a strategy and plan for testing

security with these vulnerabilities in mind. Describe the most likely methods of attack, changes to the design

that might be made to make the system more secure, and tools that may be used to attack the system. 

Part 2:

Run the web crawler tool from the OWASP Live CD and describe the tools purpose and usefulness.

Author(s)

William Rozzo and Jonathan Wesel

Summary

Java was found to be fairly secure as far as languages go. The interpreted method of execution prevents the

code from accessing other parts of the system. Several of the security flaws can be overcome with careful

programming such as data members incorrectly declared as public and unhandled exceptions. Some

vulnerabilities arise when the program is run as a web applet, such as a failure to use certificates and the

default behavior of trusting certificates.

Using a web crawler, we found that there was much more to the ATM java applet that one could gather from

the site itself. The spider was able to find all paths through the individual classes in the program. It was nice

to see that no possible injection points were found. However, the ATM example is pretty simple and a real

ATM would have many more dependencies such as databases that would increase the number of attack

surfaces.

Using fingerprinting, we found information about the website such as the web server type, version, and OS it

is being run on. Though the ATM example was a simple website with a small fingerprint, more complex sites

would have much more information that may be unique. This information can be used to find holes and weak

points that are common to the versions or types of servers or software being run on the system.

The Open Web Application Security Project (OWASP) provided us with a wide array of tools that could poke

and prod at a given website in an attempt to discover possible vulnerabilities. WebScarab and Nikto proved

to be the most powerful and user friendly applications for this purpose. WebScarab included a great

spidering tool, while Nikto turned out to be a great fingerprinting utility. Nikto discovered a number ofvulnerabilities such as the potential weakness against cross-site scripting and the fact that the site had no

disallows within the robots.txt.

Significant Findings or Learning

We learned that details we once thought were very minor and insignificant, such as what type of web server

you have running, can actually be used by attackers. It turns out that there are many free tools that can be

8/19/2019 Project10_Team2Project 1

2/9

used to discover application vulnerabilities. Once vulnerabilities are discovered, one can use this knowledge

to attack the systems weaknesses. OWASP was completely new to the team. We found the tools OWASP

provides to be extremely useful in vulnerability discovery. In particular, we found Nikto to be a neat little tool

that can scan a given host searching for different weaknesses. As Nikto discovers vulnerabilities, it displays

them to the user along with some advice regarding the vulnerability found.

Honor pledge

I pledge on my honor that I have not given or received any unauthorized assistance on this

assignment/examination. I further pledge that I have not copied any material from a book, article, the

Internet or any other source except where I have expressly cited the source.

Detailed Analysis

PART 1

The ATM Simulation is a java-based application; therefore the vulnerabilities of this application are based

mostly on its Java foundation. Since Java is platform independent and runs on a virtual machine, platform

vulnerabilities vary. However, the virtual machine nature provides a sandboxed environment protecting the

platform from attacks.

Based on our research, it turns out that Java is mostly considered one of the safest languages. No language is

perfect however, below are the main security vulnerabilities of interest.

Type confusion

- In the Java language you can explicitly declare class data members as public, private, or protected. This type

safety feature can be compromised if the Java code has two classes that point to the same memory, but have

different type protections.

Public types

- In Java any class data member declared as public can be modified externally by anyone at any time. This is

an obvious security problem if any type of critical data is stored in a public data member.

Unhandled Exceptions

- Java has the ability to handle exceptions, but it is up to the developer to ensure handlers are in place to

catch exceptions. An attacker could look for ways to generate exceptions to cause the system to crash or

become unstable.

Trusted Certificates- The java implementation of running signed applets also poses security risks. Running an applet with a signed

certificate will request permission, but the default behavior is to “always trust content from the source”. If

one applet from a certified vendor is allowed with this default value, all future applets from the same vendor

will run automatically without warning.

Vulnerable Applets

8/19/2019 Project10_Team2Project 1

3/9

-Java applets don’t have a “kill bit” so a vendor can disable applets found to be harmful. If an applet contains

a security hole that is known, an attacker can host a copy of the applet and anyone trusting the certificate

would be at risk.

Testing Strategy

The system should be tested directly against the vulnerabilities that exist. Test cases should be developed

that attempt to exploit all of the various security weaknesses of the application. All testing should be

thoroughly documented. Test procedures and test description documentation should be established before

any testing begins. The goal of creating and maintaining test procedure documentation is to ensure that the

entire testing process can be repeated any number of times without any question as to whether it was done

the same each and every time. Since we know we have a small budget, free and open source tools should be

considered before purchasing any commercial tools or creating tools in house. Since we have access to the

source code, we are not limited to black box testing. For Java security weaknesses such as type confusion and

public types we can write test programs that use some of the ATM systems classes. These tests can run

alongside the ATM system and should be able to determine whether the system has the potential to fall

victim to such security issues. Testing should not be limited to automated scripts and tools. It would be

advantageous to consider conducting manual detailed analysis of the code. Code inspections completed byknowledgeable personnel may potentially find security vulnerabilities that automated tools might miss.

Testing would begin by focusing on the known security vulnerabilities, one at a time. Next, tests can be

written that simulate likely attacks to the system. If time permits, further research should be done in an

attempt to identify any additional vulnerabilities of the system. If additional vulnerabilities are discovered,

corresponding tests should be written and executed.

Most Likely Attacks

As a web applet, this online ATM is does not use trusted certificates, which means that the site could be

hijacked or spoofed and anyone using it may willingly give up their card number and password.

Assuming the ATM application was a real ATM, the most likely attacks would have to do with attempts to

steal money or hijack customer information. Since the system does not use a SQL database, SQL injection

attacks would be of no use. All customer data happens to be stored locally on the system, this is a poor

design. It is likely that this was done just for the example application to drive some sort of simulation. We

would hope that some actual database would be used in a real ATM.

Expected Attacks:

- Attacker accesses customer data stored on the system

- Attacker steals customer authentication information, attempts to gain access to system

- Attacker obtains customers ATM card, attempts to gain access to system

- Attacker attempts a brute force attack on system with a stolen ATM card

Design Changes

A change that could be made to this ATM program would be to require permission by the user though a

trusted certificate. In order to overcome the security risk associate with this, we could urge the user to

uncheck the box granting permission to all applications from the source, as it is checked by default.

8/19/2019 Project10_Team2Project 1

4/9

Another change would be to create external databases that hold the customer, card, and account

information. Though this would increase the number of attack surfaces, the system as a whole would be

more secure due to the separation of sensitive data from the control logic of the program.

PART 2

To run the OWASP tools, the OWASP Live CD had to be downloaded and run. The Live CD consists of Ubuntu

with various OWASP tools installed. For the purposes of this assignment, the main tool used was the OWASP

WebScarab. WebScarab contains built in features similar to what you might see in an application like

Wireshark, yet it also has the capability to run other cool features such as a web spider and a fuzzer. To run

the live CD, we mounted the ISO image to a virtual machine.

Spidering/Web Crawling

From the point of view of a tester, spidering is a great way of being able to visually picture the entire layout

of a web site. There may be places that the developer did not intend to make publicly visible, or it could assist

the tester in finding key areas of the web site to test for vulnerabilities. As a tester, you want to be able to

ensure you test as thoroughly as possible. By spidering the web site under test, you can effectively gather allthe different parts of the site to be sure it is completely tested. Below, the results of running the spider on

the ATM example applet showed no possible injection points.

8/19/2019 Project10_Team2Project 1

5/9

8/19/2019 Project10_Team2Project 1

6/9

Fingerprinting

Fingerprinting is a very useful tool for attackers and testers. By learning as much as possible about the site,

one can better test or attack the site. The ATM web site didn't really give us much as far as fingerprinting

goes. The entire site is plain old HTML. The web server the site is running on is Apache 2.2.10 (Linux/SUSE).

Although the gathered fingerprints are minimal here, this information is a goldmine for testers and attackers.

As an example, an attacker could do research to determine what kind of security holes exist in the specified

version of Apache. Once known, the attacker can aim his or her attacks specifically at these weaknesses.

We decided to play around with a few of the other tools included on the Live CD and came across Nikto.

Nikto is a command line tool that basically automates the fingerprinting process for you. Nikto was able to

discover much more than we could manually using WebScarab, additionally it ran very quickly. We like the

fact that Nikto is automated, but for each vulnerability it finds it gives a brief description. This is a very

powerful tool that could be used by attackers and testers alike. Here are the results of the Nikto scan.

8/19/2019 Project10_Team2Project 1

7/9

 

Screen Shots

WebScarab Setup

8/19/2019 Project10_Team2Project 1

8/9

 

8/19/2019 Project10_Team2Project 1

9/9

 

Fingerprinting