Get Boo Web Vulnerability Assessment

ITM 415
April 11, 2017

Authors:
Grant Heelan
Patrick Walker
Executive Summary

We performed a vulnerability analysis on 192.168.1.248/getboo on April 4th and

April 13th. This paper will go over the different testing strategies employed,
vulnerabilities identified, rank the risk according to our ranking index, and the
recommended fix to resolve the vulnerability. The web application analyzed gives users
the option to create an account and login. Once logged in, the user can create a
bookmark or create a group on the page.

We performed both manual testing and automated tests on the application. For
automated tests, we used fuzzing, spidering, and active scanners within ZAP. Though
the automated tools and manual testing we found multiple vulnerabilities, some a larger
threat than others. One of the vulnerabilities found with a large threat is reflective cross-
site scripting. We could write script on the search bar and the script would be executed
by the server. This vulnerability could be fixed by by the developers by employing
escaping. Utilizing escaping, the script would be taken literally, therefore, not executed
as code. In addition, the developers could also limit the amount of characters that can
be entered by a user into the search bar. With the search field limited, an attacker
couldnt write long, complex code in order to defeat escaping and other protective
measures in place.

Another vulnerability that we found is that the login data is being passed over
HTTP, thus, unencrypted. Even if the usernames and passwords are encrypted or
hashed in the database, an attacker could still intercept the data being passed by the
browser to the database using a sniffer or MITM attack before its encrypted/hashed.
This may not be that harmful to the organization if a general users account is
compromised but if an attacker gain the credentials to a superuser or admin, the effect
could become disastrous.

Scope

The application that we assessed has a URL of 192.168.1.248/getboo. Using

ZAP, we determined that the server is using Microsoft ISS version 8.5. The
programming language being used is PHP as determined with ZAP. The site has basic
functions where users can create an account/login to the site. Once the user is logged
in, they can add bookmarks and create groups within the site. Once a group is created,
the user can specify whether other members can openly enter the group or whether the
other members must be invited to join the group. We reviewed the application on two
occasions. Once on Tuesday, April 4th at 10:00 am and once on Thursday April 13th at
2:30 pm.

Tests Performed

The following automated tests were all completed using ZAP. The first scan we
performed on the website was a spider. The spider can crawl through all possible links
on the site. The spider was launched when the user was logged into the account. This is
so the spider will be able to access more of the page as a logged in user. The next test
that was executed on the site was an active scan with the scope of the scan set for the
URL: 192.168.1.248/getboo. No parameters were set for the active scan. The last
automated test that was performed on the site was a fuzzer. The fuzzer fills the website
with random requests to detect information leaks and establishes how susceptible the
server is to crashing with stack overflow. Fuzzing is used to try to pass untrusted data
as trusted data to a site for processing to see how the site will deal with the information
passed its way. In this regard, fuzzing can be beneficial in identifying a possible cross-
site scripting vulnerability. Initially, we selected all the fuzzing loads to be executed
through the site but we quickly found out that this method returned a great deal of
scripts that were reflected off the web page. Testing the variety of loads from the results
would be a difficult task. Instead, we decided to execute the fuzzer with just cross-site
scripting loads.

Manual testing was also used in addition to automated tools. Although the
scanner and fuzzing results did not return an alert for a SQL Injection vulnerability, we
wanted to run additional manual tests to eliminate the possibility for a false negative.
Our first test was to type in a single () into a search field, trying to generate an error
message with some information. With no success we planned to try again to generate
an error message or to gain access a list of all users username with the tautology
script: SELECT* FROM users WHERE user_id = 1 OR 1=1;#. Both the search bar
field, username field, and password field had a character limit for the input field, making
it difficult to execute an SQL script. We did find two fields that allowed for enough
characters to insert a script into the web page, the email field when registering for an
account and the search field. We were unsuccessful in our attempts to insert an SQL
injection into the page, therefore, the web application passed our SQL injection
assessment.

A possible XSS vulnerability was found through fuzzer; certain XSS script could
be reflected off the webpage. To test for a possible false positive, manual testing was
conducted to attempt to duplicate the results from the scanner/fuzzer. JavaScript was
entered into the search bar in an attempt to create a pop up window appear. The script
that was entered was: <script>alert(hi);</script>. Image 4 shows the screenshot of the
pop-up that was created in the webpage.

Image 2 shows where we checked to see if it would notify us if there is an admin

account. When admin was entered as a username with a random password entered,
the error message stated The password is invalid meaning that the username is
correct.

Vulnerabilities Identified

Risk Index Level of Risk Description

Confidentiality, integrity, availability, and sensitive

High Critical data compromised. High threat to the organization

Confidentiality, integrity, availability compromised

but no sensitive data. Moderate threat to the
High organization

Confidentiality, integrity, availability violated with

Medium Moderate minimal threat to the organization

Confidentiality or integrity or availability violated

Low Low with no impact on the organization
Vulnerability 1a- Application Error Disclosure (image 1)

Classification / High
Severity

Scope This vulnerability affects one page on URL

192.168.1.248/getboo/grades

Detailed The input from the fuzzer caused a stack overflow where
Description information was leaked about a hidden page was revealed.

Recommended Limit the amount of information provided in an error

Fix message.

Vulnerability 2a- Username enumeration (image 2)

Classification / Low
Severity

Scope The vulnerability would affect the whole website

Detailed The attacker can brute force their way through the admin
Description account, then they would have full rights to do just about
anything they want. The reason I pointed it out as mild is
because it may be hard to brute force but the problem
should be adjusted sooner than later to make sure nobody
knows that the only thing incorrect is the password.

Recommended Fix The vulnerability can be eliminated by adjusting the code of

the login page. Making sure the code doesnt loop back to
notify you what part youre missing in the page. For
example, just letting the user know the password or
username are incorrect to make the login more secure for
the users.
Vulnerability 3a- Character Limit (image 3)

Classification / Low
Severity

Scope the vulnerability only affects the login page

Detailed This bug isnt an emergency to be fixed, however having

Description 150 characters for your password limit is high. The limit for
the passwords should normally be around 25-50.

Recommended Fix Limit the amount of characters the user can enter for a max
of 25-50 characters.

Vulnerability 4a- Stored Cross-Site Scripting (image 4)

Classification / High
Severity

Scope The script was executed on one page but it could potentially
affect the entire site.

Detailed Script could be written in a search bar and executed by the

Description server. With this type of an attack, the attacker could gain
access to cookies, change the information/functionality of
the site, or redirect users to another malicious site. XSS can
cause issues with authentication, session management,
stealing user data, website functionality/ loss of operation.

Recommended The web developers could use escaping where the <>
Fix would be taken literally as not as a tag. The developers
could limit the length of the characters in the search field.
Vulnerability 5a- Login Data Passed Over HTTP (image 5)

Classification / High
Severity

Scope Affects just the login in page

Detailed Login data is sent to the server unencrypted. Even if

Description usernames and passwords are encrypted on the database,
an attacker could use a sniffer and intercept the login
information from a user before its encrypted on the
database. This might be not as bad for a general user but
could be catastrophic if the admin username and password
were compromised.

Recommended Fix The login page needs to set up using HTTPS protocol.
Appendix

Image 1

Image 2
Image 3
Image 4

Image 5