KEMBAR78
Penetration Testing Report | PDF | Http Cookie | Password
0% found this document useful (0 votes)
69 views9 pages

Penetration Testing Report

Uploaded by

hopefulvaughan1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
69 views9 pages

Penetration Testing Report

Uploaded by

hopefulvaughan1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

PENETRATION TESTING REPORT

Executive summary
This report details the results of a penetration testing challenge that was completed to
identify vulnerabilities in the "Basic" web challenge from HackThisSite.org -
https://www.hackthissite.org/missions/basic/. It also illustrates how web application
vulnerabilities can be exploited and provides examples of how an attacker might
compromise a web application, potentially leading to a breach of confidentiality,
integrity, and availability that could result in business, financial or reputational loss for
an organisation. The objective of the penetration testing report is to identify
vulnerabilities associated with this web application, attempt to exploit these
vulnerabilities, and provide recommendations for better securing the web application.

Overview of the web application tested


HackThisSite.org is an online platform that provides a legal and safe environment for
individuals to improve their cyber security skills through a variety of challenges and
Capture the Flag (CTF) events. Established in 2003, it is not just a website for hacker
simulations but rather a community of like-minded individuals who are dedicated to
sharing and gaining knowledge in ethical hacking, programming, and technical hobbies.

Key findings of the “Basic” web challenge

Level Vulnerability Findings Recommendation(s)


description

Basic Level 1 Hardcoded The password was hidden Passwords should never
password in plain text in the source be stored in plaintext in
code. the source code, they
should be stored as a
hashed value in a separate
file or if not hashed, it
should be kept in a
properly encrypted file.
Hashing is generally
considered to be a more
secure method of storage.

Basic Level 2 No password file Without the presence of a As a best practice when
password file, there is no testing a web application,
password to verify and it is recommended to
thus, submitting the form always check for
with an empty password vulnerabilities by testing
field will allow for the application using
successful authentication. empty fields, commonly
used credentials and
default login credentials.

Basic Level 3 Location of By exploring the It is recommended to


password hidden directory or file path map out the directory
in source code structure, an attacker can structure of a web
potentially retrieve the application when testing
password. This can be it. This way, you can get a
done by visiting a specific better understanding of
URL, such as how the application
https://www.hackthissite works, and may even
.org/missions/basic/3/p discover interesting or
assword.php, and viewing overlooked elements such
the page source to as login pages.
uncover the location of
the password.

Basic Level 4 & 5 Hardcoded By hardcoding your If the code is carried out
credentials credentials within the on the client-side,
within application, the script for sensitive information
application a web page can be should not be included in
manipulated to redirect a the code to protect it from
password to the desired being accessed by
recipient. When you view unauthorised parties.
the web page source, you
can identify the script
actions and it can be
modified to change the
recipient of the password.

Basic Level 6 Weak encryption An attacker can easily One solution to this
determine the type of vulnerability is to use a
encryption used. This is stronger encryption
because the process method - hashing, and to
involves incrementing the keep changing the
value of each character in encryption key. Another
the string by its position solution is to add
in the string, starting randomness - salt, to the
from 0, and then encryption process,
converting it back to a making it harder for an
human-readable format attacker to break it.
from ASCII decimal. This
predictable pattern can
be easily recognised and
exploited by an attacker.

Basic Level 7 Command After testing the It is crucial to handle all


injection functionality of the information entered by
calendar system, you can users on a web application
see that the web app is with caution, as it should
using a script (Perl) that be considered potentially
takes the number you unsafe until verified. This
input and uses it to show means that the web
a calendar for that year application should check
on the website. The script and sanitise the user input
is using the command "cal before executing it.
-y" followed by the
number you input as the
year. To exploit this, you
can use the “ls” command
which lists out the
current directory as show
in Appendix Basic Level 7.

An attacker can execute


arbitrary commands on
the host system.

Basic Level 8 & 9 Server-side When you input a test To secure against Server
include (SSI) string, it writes it into a Side Include (SSI) injection
injection .shtml file. You can also attacks, user input should
tell that the files are be validated and sanitised,
being stored in the tmp a web application firewall
directory, but the (WAF) can be used, web
password file should be servers and web
located in the directory applications should be
above that. kept up-to-date, web
servers should be
Level 8: By submitting a configured to not allow
command “<!--#exec SSI execution within
cmd="ls ../"-->”, we can user-controlled
see the directories and directories, and proper file
find the file that has the permissions should be set
password. in case of an attacker
gaining access.
Level 9: By submitting
command “<!--#exec
cmd="ls ../../9"-->”, we
can see the directories
for level 9 and also locate
the file with the
password.

Basic Level 10 Incorrect For this level, when you Using yes/no cookies for
implementation check the cookies by authentication is not a
of cookies opening up the “Inspect good method for
Element” you can modify authenticating users as
the cookie information they can be easily stolen
“level10_authorized” or tampered with by
cookie from no to yes as attackers. Cookies are
shown in Appendix Basic best used as a way to
Level 10. maintain a user's
authenticated state after
This vulnerability could the initial authentication
lead to a variety of process has been
security issues such as completed, such as by
session hijacking, using a password or other
cross-site scripting, secure method. The
insecure storage of cookies will store a
sensitive information, and session ID that is
misconfiguration. associated with the
authenticated user on the
server side, allowing the
server to identify and
grant access to the user
without requiring them to
re-enter their password.

Basic Level 11 Unprotected The .htaccess file, which It is recommended to


.htaccess files configures the Apache correct the file
web server, has incorrect permissions on the
file permissions that .htaccess file to prevent
allow it to be read by unauthorised access and
everyone. This poses a to ensure that the
security vulnerability as it “DaAnswer” directory is
may contain sensitive properly protected by
information. Additionally, either removing the
the .htaccess file contains directory or implementing
information about a authentication and access
directory named controls.
"DaAnswer" which should
not be publicly accessible
but can be accessed by
appending it to the
current URL, indicating
that the directory is
inadequately protected
and could be exploited by
attackers to gain
unauthorised access.

Conclusion
In conclusion, the penetration testing report found several vulnerabilities in the "Basic"
web challenge from HackThisSite.org. These vulnerabilities included hardcoded
passwords, no password file, location of the password hidden in the source code,
hardcoded credentials within the application, weak encryption and command injection.
These vulnerabilities could potentially lead to a breach of confidentiality, integrity and
availability that could result in business, financial or reputational loss for an
organisation. The report provided recommendations for better securing the web
application and highlighted the importance of proper web application security. It's
important to note that regular penetration testing and vulnerability assessments can
help you to identify and fix security vulnerabilities before they can be exploited by
attackers.

Appendix
● Basic Level 1

● Basic Level 3

● Basic Level 4 & 5


● Basic Level 7
● Basic Level 8
● Basic Level 9

● Basic Level 10
● Basic Level 11

You might also like