Deakin University SIT382 Assignment 2: System Security Exploitation

Verified

Added on  2022/09/16

|17
|3344
|18
Practical Assignment
AI Summary
This assignment solution for SIT382, a System Security course, details the exploitation of web application vulnerabilities using techniques like SQL injection and XXE attacks within the WebGoat environment. The solution covers challenges involving password retrieval, authentication bypass, account creation, and password resets, providing step-by-step explanations and screenshots. The assignment also addresses the use of tools such as BurpSuite and Firefox Developer Tools for intercepting and modifying web requests. Furthermore, the document includes a research component exploring the effectiveness of integrating IDS, IPS, Firewalls, and Honeypots to enhance real-time system security, along with the development of IDS and Honeypots. The solution emphasizes practical application, documentation, and the demonstration of security exploitation and defense strategies.
Document Page
System Security
SIT382
Assignment 2
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
Part A
Challenge 1: Admin lost password
The challenged involved gaining access to the web-goat - without having an administrator’s
username and password; conventionally, such attacks are successful through social
engineering attacks. A common mistake with users is failure to change their credentials from
the default admin/admin. On this task, these credentials did not work and therefore more
analysis was performed. The page was keenly inspected using various web developers’ tools
such as Firebug on Firefox.
Solution
A keen analysis of the .png logo revealed some information that was used to gain access to
the server. I downloaded the logo and inspected the image using a text editor. A search for
Admin yielded the results below.
Figure 2.0 Analysis of the logo using a text editor.
The following credentials were obtained from the image above.
admin:!!webgoat_admin_1234!!
Username: admin
Password: !!webgoat_admin_1234!!
Document Page
Figure 3.0 successfully verified and flag obtained.
Challenge 2: Without Password
This challenge entailed bypassing authentication, to gain access to the server without use of a
password. Traditionally, a common security flaw occurs where software developers fail to put
necessary checks; to avoid SQL injection. With SQL injection, one can easily gain access or
reveal critical information about a software system. SQL injection is effected by carefully
sending data to an SQL database, forcing it to reveal more information.
Crafting the payload
Username: Larry
Password: ' or 1=1 --
The hyphen was meant to terminate any previous sql statement and then a logical evaluation
was put “OR” 1=1 which would evaluate to true.
With this payload, the authentication was successfully bypassed as is evident from the screen
shots below.
Document Page
Flag: 412765f1-ade4-4e64-8cf6-12496a74a6af
Figure 4.0 Bypassing authentication successfully
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
Challenge 3: Creating a new account
The ability to create an account, and give it admin credentials can cause devastating attacks
on various web-based systems. The technique has widely been used in attacking and defacing
websites especially Joomla based websites. Theoretically, such attacks are successful where
vulnerabilities exist, especially regarding SQL injection vulnerabilities. For developers who
fail to put measures to check and eliminate injection attacks on registration forms, put the
systems at risk of such attacks. Theoretically, blind sql injection cannot be detected easily as
normal SQL injection since the SQL Error is not displayed. It however still possesses some
security risks that can be exploited.
On the login page, much information could not provide sufficient information to compromise
the system. However the registration form was exposing some information allowing us to
evaluate and launch more attacks using the payload
tom' AND '1'='1
Figure 6.0 Register form
We were able to know that the username had been taken.
Document Page
Analysis showed that the table for passwords was named password, thus an automated SQL
injection could be attempted using the payload.
tom' AND substring(password,1,1)='t
The response indicated that the username had been taken
The automated bruteforce attack was performed with the payload
tom' AND SUBSTRING(password, 1, 1)='X';--
Where X was replaced with values from the alphabet; abcdefghijklmnupqrstuvxyz
The first character of the password was set to “t” while the rest were randomly fuzzed
resulting in the password; thisisasecretfortomonly
The password was found by use of some python code to run the fuzzing of the password
Figure 8.0 Successful challenges on tom’s password
Document Page
Challenge 4: Admin password reset
Resetting the administrator’s password was very tricky. From research and analysis, I needed
the WebWolf to facilitate the resetting process.
Figure 9.0 Password Reset page and the web wolf page.
On the WebGoat’s password reset page, a reset link was generated; the email was accessed
by use of WebWolf.
Figure 10.0 Received reset email from webgoat
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
Figure 11.0 the reset email with a link for resetting the password.
A click on the link showed an error; indicating that the link was not the reset link for admin
To identify vulnerability on the reset link that I could manipulate, I downloaded WebGoat’s
source code, and searched for PasswordResetLink.java
Figure 11.0 Inspection of the Source code to identify vulnerabilities.
From the analysis of the code, I realized that the reset link was generated by use of the
username; which had to be admin and a secret key. A further analysis of this function
showed that the secret key was not important since the code only used the length of the key
and not the value of the key. For that reason, we could do a trial and error of different lengths
of the key; by repeatedly passing a key of different length and then pasting the generated key
on the reset link.
Figure 12.0 Compiling the MD5.java and PassworResetLink.java
Document Page
Figure 13.0 Continuously generating a reset key by use of username: admin and a key of
different length, the final reset harsh that worked was; 375afe1104f4a487a73823c50a9292a2
The harsh was generated by passing a secret key of length 13; the value of the key was not
important!, what was important was the length of the key.
I pasted the generated harsh on the reset URL until it worked;
Flag: 5e030862-27b5-4952-8553-d27c83003e8d
Document Page
Challenge 5: Without Account
Challenge 5 Default page, trying to vote without an account.
Tying to vote by directly placing the vote as a URL; with this approach we tried to
manipulate the server by user of GET method; by simply calling the URL and passing the
vote value on the URL. This approach failed with the error below.
Checking the request using Chrome Developer tools shows the request was a GET request.
Our intension is to change the request from GET to any other request type such as HEAD
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
To edit and resend the request, I used Firefox Developer tools [which can be opened by
pressing Ctrl + Shift + I] . I then opened the request page to inspect with the developer tools.
The tools allows one to edit and forward a request. As shown below.
I changed the request type from GET to HEAD and send the request.
Document Page
Section 2: XXE vulnerabilities attack
XML External Entity vulnerability (XXE) attacks entails exploiting applications that process
or parse XML inputs. The attack happens when XML input that contains a reference to an
external entity is processed by a weakly configured XML parser. The attack causes unwanted
exposure of confidential data, enables attackers to perform remote port scanning of the
system hosting the parsers, facilitates execution of server side request forgery and can even
facilitate denial of service attacks.
The Extensible Markup Language (XML) 1.1 standard outlines the overall structure of any
given XML document. This standard outlines the concept of an entity; the unit used in the
storage of information within an XML document. Among the various types of entities, one in
particular; the external entity, has the ability to access remote and local contents by use of a
declared system identifier. This particular identifier is in form of a URL, accessible by a
given XML processor while processing an entity. A given XML processor dereferences the
identifier, fetches content from the URL and replaces the instances of the named external
entity with the content obtained through the system identifier.
An attack on the XML parser takes advantage of the fact that the processor dereferences data
referenced by the system identifier. To launch an attack, one would place attack payload as
data referenced by the system identifier; when the XML processor dereferences the attack
payload, it is compromised resulting in disclosure of sensitive and confidential information,
which would ordinarily not be accessible by a given application. This type of attack also
affects external schemas, external styesheets and external DTBs; if these are also included in
an XML document, they easily allow an attack to launch similar attacks.
XXE attacks can cause considerable harm to a system; such as file disclosure, allowing
attackers to infiltrate the system and cause other types of attacks. The attackers mostly use
XXE attack as a pivot to launch other attacks on internal systems. In some cases, an XXE
attack facilitates the planting and execution of arbitrary code, resulting in data breaches and
Denial of Service attacks.
XXE Attack on WebGoat
To demonstrate XXE attack, we launched an attack on local WebGoat installation. The task
here was to try to intercept an XML request, modify the request and then forward it with
different instructions. The attack was performed in three stages;
Intercepting a vulnerable POST request by use of ZAP and Burpsuite
Adding injected ENTITY in the xml request
Forwarding the modified POST request
chevron_up_icon
1 out of 17
circle_padding
hide_on_mobile
zoom_out_icon
[object Object]