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 of
vulnerabilities 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

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

-Java applets dont 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 by
knowledgeable 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.

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 all
the 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.

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.

Screen Shots
WebScarab Setup

Fingerprinting