DEMO COMPANY

SECURITY AUDIT FINDING REPORT

By

Utsav Chakraboty
REG:D202102282
DEPT:Cyber Forensics & Information Security

Date:July 9th, 2023

Project:DC-001
 Table of Contents
1. Acknowledgement… ......................................................................................... .3
2. Certificate of Approval… .................................................................................. .4
3. Contac Info… ................................................................................................... .5
4. Assessment Overview… .................................................................................. .5
5. Assessment Component… ............................................................................. ..6
6. Severity Ratings……………………………………………………………………...6
7. Scope… ........................................................................................................... ..7
8. Vulnerability Summary & Report Card… .......................................................... .8
9. Technical Findings… ....................................................................................... ..8
Finding 1: SQL Injection Flaws………………………………...…………..… 10
Finding 2: Authorization Bypass …............................................................ 11
Finding 3: Cross-Site Scripting Flaws… ..................................................... 13
Finding 4: Inadequate Security Standards for Password Storage… .......... 14
Finding 5: Weak Password Complexity Requirements… ........................... 14
10. Conclution……………………………………………………………………………18

2
 Acknowledgement

I express to my deep sense of gratitude to my respected Principal Mr. Narendranath

Sinha, HOD Dr. Partha Sarathi Goswami and Departmental Professor Dr. Sudipta Kr.
Ghosal for their valuable help, time and guidance. I am thankful to them for the
encouragement they has given me in completing the audit.

I am also thankful to faculty member and stuff to corporate in the project.

Lastly I would thankful to my parents for their constant and moral support and
encouragement which help me in a successful competition.

————————————
Utsav Chakraborty

3
 Certificate of Approval

The project was undertaken during the 3rd year and involved extensive research, critical
analysis, and practical implementation. The project showcases the student's ability to apply
theoretical knowledge, think independently, and demonstrate problem-solving skills in the
chosen field of study.
The project has been evaluated and assessed by the examination committee, and the student
has demonstrated a high level of competence and understanding of the subject matter. The
committee commends the student's dedication, effort, and commitment to academic
excellence.
We, therefore, hereby confer this Certificate of Approval upon Utsav Chakraborty in
recognition of the successful completion of the college project.

—————————— —————————————-
HOD of the Department Professor of the Department
Dr. Partha kr. Goswami Dr. Sudipta Kr. Ghosal

4
 Contact Information
Name Phone Email Department

Utsav 9748115668 [email protected] Cyber Forensics &

Chakraborty Information Security

Assessment Overview
From June 10th, 2023 to July 7th, 2023, Demo Corp engaged Behala Government
Polytechnic’s CFS Student to evaluate the security posture of its infrastructure compared to
current industry best practices that included an internal network penetration test. All testing
performed is based on the NIST SP 800-115 Technical Guide to Information Security
Testing and Assessment, OWASP Testing Guide (v4), and customised testing frameworks.
Phases of penetration testing activities include the following:
• Planning – Customer goals are gathered and rules of engagement obtained.

• Discovery – Perform scanning and enumeration to identify potential vulnerabilities,

weak areas, and exploits.

• Attack – Confirm potential vulnerabilities through exploitation and perform additional

discovery upon new access.

• Reporting – Document all found vulnerabilities and exploits, failed attempts, and
company strengths and weaknesses.

5
 Assessment Component

• An internal penetration test emulates the role of an attacker from inside the network.
An engineer will scan the network to identify potential host vulnerabilities and
perform common and advanced internal network attacks, such as: LLMNR/NBT-NS
poisoning and other man- in-the-middle attacks, token impersonation, kerberoasting,
pass-the-hash, golden ticket, and more. The engineer will seek to gain access to hosts
through lateral movement, compromise domain user and admin accounts, and
exfiltrate sensitive data.

Severity Ratings
The following table defines levels of severity and corresponding CVSS score range that are
used throughout the document to assess vulnerability and risk impact.

Severity
Severity CVSS V3 Definition
Score
Range
Critical 9.0-10.0 Exploitation is straightforward and usually
results in system-level compromise. It is
advised to form a plan of action and patch
immediately.

High 7.0-8.9 Exploitation is more difficult but could

cause elevated privileges and potentially a
loss of data or downtime. It is advised to
form a plan of action and patch as soon as
possible.

6
 Severity CVSS V3 Definition
Score
Range
MEDIUM 4.0-6.9 Vulnerabilities exist but are not exploitable
or require extra steps such as social
engineering. It is advised to form a plan of
action and patch after high-priority issues
have been resolved.

Low 0.1-3.9 Vulnerabilities are non-exploitable but

would reduce an organization’s attack
surface. It is advised to form a plan of
action and patch during the next
maintenance window.

Informational N/A No vulnerability exists. Additional

information is provided regarding items
noticed during testing, strong controls, and
additional documentation.

Scope
Assessment Details

Machine Penetration Testing 192.168.1.5(DHCP IP)

Scope Exclusions
Per client request, BGPS did not perform any of the following attacks during testing:

• Denial of Service (DoS)

• Phishing/Social Engineering

All other attacks not specified above were permitted by Demo Corp.

7
FINDINGS SUMMARY

The following table summarizes the findings. Each finding is broken out in detail by risk
immediately after the summary table.

Finding Risk
1. SQL Injection Flaws Critical

2. Authorization Bypass Critical

3. Cross-Site Scripting Flaws High

4. Inadequate Security Standards for Medium

Password Storage
5. Weak Password Complexity Low
Requirements

CVSS SCORING

7.3(high) means- A high CVSS score suggests that immediate action is required to
address and remediate the identified vulnerabilities. It indicates a critical security issue that
should be prioritized and resolved promptly to mitigate the risk of exploitation and protect
the website and its users.

CRITICAL RISK FINDINGS

SQL Injection Flaws

Industry Standards

OWASP Top 10 -------------------------- A1: Injection

NIST 800-53 --------------------------- SI-10: Information Input Validation

Summary

When data enters a web application without being properly sanitized, it may expose the
application to several categories of vulnerabilities. One of these categories is the injection
of Confidential and Proprietary All Rights Reserved Secure Ideas, LLC 8
[email protected] +1 (866) 404-7837 Structured Query Language (SQL) by a third
8
party. This type of attack is commonly referred to as SQL injection.
SQL injection occurs when data is inserted or appended into an application input
parameter, and that input is used to dynamically construct a SQL query. When a web
application fails to properly sanitize data, which is passed on to dynamically create SQL
statements, it is possible for an attacker to alter the construction of back-end SQL
statements.

Some of the potential risks include:

● Loss of sensitive or confidential data

● Altered sensitive or confidential data
● Bypass of authentication
● Bypass of authorization
● Access to underlying Operating System
● Further attacks against users of the application (XSS, CSRF)

Finding

Secure Ideas discovered that the login page of the Juice-shop application is vulnerable to
SQL Injection. This is due to the use of unsanitized user supplied input. Using the
parameters„ = OR 1=1-- , as the username and any password, Secure Ideas was able to
login as the Admin account. Considering Admin was the first user listed in the application,
it was therefore used due to the exploit payload.

As shown in the following screenshots, the admin account was the first account listed in
the application. Additional accounts could be accessed by using ' or 1=1 and email not
like('%admin%');-- and so on.

9
Authorization Bypass
Industry Standards

OWASP Top 10 ------------------------ A5: Broken Access Control

NIST 800-53 ------------------------ AC-3 Access Enforcement

Summary

Authorization bypass is a flaw in software or a hole in security planning where a user or an

attacker is able to access data or functionality for which the user is not authorized. This
vulnerability does not require a malicious attacker to cause increased risk to a business;
the mere fact that unauthorized users have access to a business infrastructure increases
risks to the company. The core issue in authorization bypass is a lack of validation within
the application. When the web application accepts input from a user and uses that input to
retrieve data or provide access, it is critical that the application validate that the user
actually has permission to perform that action. When this validation does not happen, or is
able to be fooled, the application is vulnerable to attack.

Risks businesses face from an authorization bypass include the introduction of bugs to
code via users‟ mistakes, an attacker gaining access to administrative portions of the
application, or loss of important business-related data to a data thief.

Finding

Secure Ideas has found that the Juice shop application contains an authorization bypass
flaw. During the testing Secure Ideas was able to create an admin account with an
unauthenticated session.

In the Juice Shop API, Secure Ideas discovered that an attacker or malicious user could
create a new user with the role of admin.

The following description explains how Secure Ideas was able to perform this attack.

1. Create a Post request in Postman API testing tool to https://juice-shop.wtf/api/Users

2. Add a line in the Body of the request using the following statement
{“email”:”admin”,”password”:”admin”,”role”,”admin”}
3. Send Request to the api endpoint
4. Visit login page to login using new admin account

As shown below, the new user has been created with administrative privileges:

10
HIGH RISK FINDINGS
Cross-Site Scripting Flaws
Industry Standards

OWASP Top 10 ------------- A5: Broken Access Control

NIST 800-53 ------------- AC-3 Access Enforcement

Summary

Not filtering untrusted user-supplied input may expose a web application to several
categories of vulnerabilities. One of these categories is the injection of HTML or JavaScript
code by a third party. This type of attack has been generally referred to as “Cross-Site
Scripting” or XSS.

One common way of exploiting this is with a social-engineering attack vector and a crafted
link. This would exploit a flaw in one or more parameters in the URL and query string.
When the target user follows the link, the malicious code executes in the target‟s browser,
within the context of the vulnerable page.

Cross-site scripting flaws are typically classified by two attributes: whether they are
persisted and whether they are reflected. When a persisted exploit is used, the payload is
stored, and executes again on subsequent visits to the vulnerable page. The classic
example is server-side persistence in the database. Because the data in the database may
be shared between users, it is possible for an attacker to simply add the payload through a
shared data field in order to circumvent the need for social engineering. This is predicated
on the attacker being able to add the payload from either a legitimate account or an
unauthenticated context. Even when social engineering is necessary to introduce the
payload, if it is in shared data it can still reach other users in addition to the original target.
Persistence is not necessarily always on the server, however, and could instead be stored
11
in cookies set by JavaScript. In more modern applications, the local Storage and indexed
DB client-side APIs may be used as well.

The other attribute used for classification is whether it is a reflected flaw. If it is reflected,
the flaw is in the handling of input that is sent to the server and returns in a response. The
database-persisted example does this, and could therefore be considered both reflected
and persisted. An unpersisted example would be an error message returned from the
server that unsafely includes a value from the input.

In all cases, the malicious scripts are executed in a context that appears to have originated
from the targeted site. This gives the attacker full access to the document retrieved,
providing almost unlimited control over the victim‟s experience using the application. A
wide variety of options are available for crafting an effective exploit, which may incorporate
some of the following:
●Sending application data to a server controlled by the attacker
● Using the victim‟s session to access additional data or functionality
● Stealing cookies that are not protected with the httponly flag
● Manipulating the view presented to the victim for a social engineering purpose, such as
faking a session timeout to prompt for a login or convincing the user to install something
● Stealing data from sensitive input boxes, such as account credentials or credit card
information
● Launching attacks against or harvesting data from other applications open to interaction
with the current domain through a cross-origin resource sharing (CORS) policy, potentially
using the victim‟s cookie-stored credentials
● Changing links on the page to include the cross-site scripting payload in other pages as
the user navigates the site

Finding

Secure Ideas discovered that Juice Shop‟s applications are vulnerable to cross-site
scripting (XSS) due to the application‟s use of input within the response to the user. Many
of the flaws identified were persisted through the database, and many could be exploited
by an unauthenticated attacker without relying on a direct social engineering attack such
as phishing. One example of an XSS flaw is within the user profile page of the Juice Shop
application. An attacker can replace the track-result id with a JavaScript iframe payload.
When a payload, such as is submitted in the browser address bar, it causes the application
to incorporate the attack within the resulting web page. The screenshot below is what the
victim browser would see.

12
MEDIUM RISK FINDINGS
Inadequate Security Standards for Password Storage
Industry Standards

OWASP Top 10 -------------------------- A6: Security Misconfiguration

NIST 800-53 -------------------------- SC-28 Protection of Information at Rest
IA-2 Identification and Authentication

Summary

Password storage is a key point in securing business assets. If passwords are stored or
transmitted via poor algorithms or worse, in clear text, then the business‟s entire software
system is vulnerable to exploitation if the password table is accessed by an attacker.

If passwords are not regularly changed, if the algorithm is not salted (ensuring that no two
encoded passwords are the same), and if the encryption is inadequate, then a business
faces the risk that an attacker will access every account in the database for a period of
time until the attack is discovered.

Finding

Due to the SQL injection flaw above, Secure Ideas found that the Users of the Juice Shop
stores passwords. Analysis of the password table revealed that passwords are stored as a
MD5 hash of the user‟s original password. The following screenshot shows a sample from
the data.

13
MD5 is a hashing algorithm that is known to have problems that allow for cryptographic
collisions, meaning that two different pieces of data can produce the same MD5 hash.
MD5 also lends itself to brute force attacks due to the relatively low computational power it
takes to generate an MD5 hash.

In addition, the MD5 hashes that Secure Ideas found were not salted. This is evident by the
fact that several of the password hashes in the previous screenshot are identical.
Password salts make it much harder for an attacker to crack a password hash as it
requires the attacker to know the salt value in order to start cracking the hashes.

LOW RISK FINDINGS

Weak Password Complexity Requirements

Industry Standards

OWASP Top 10 ---------------------- A6: Security Misconfiguration

A5: Broken Access Control
A2: Broken Authentication

NIST 800-53 ---------------------- AC-3: Access Enforcement

Summary

One of the aspects tested during the penetration test, was the password complexity
requirement of the Juice Shop applications. For most applications, the password is the
single factor of authentication that grants access to all other information. For this reason, it
is imperative that users create strong passwords that are difficult to attack. Unfortunately,
most users do not understand the importance of strong passwords or how to create them.
Application developers must take the responsibility to develop applications in such a way
that requires users to create passwords that can withstand common password-guessing
attacks.

There are three common types of password guessing attacks. The first is a brute-force
attack in which attackers try every combination of every letter in order to eventually find the
correct password. Dictionary attacks utilize a list of common passwords such as
Password1 and abc123. The third type of attack is a hybrid attack in which the attacker
14
uses common passwords that have been mangled with brute-force techniques. For
instance, the attacker might try the word Secret followed by every possible 2-digit numeral
and symbol combination. This can be successful when users tack on numbers and
symbols to the end of their password to comply with password requirements.

Finding

Secure Ideas found that while the application attempts to enforce the use of complex
passwords, the password complexity requirements are weaker than recommended for this
type of application. Secure Ideas found that the application tested allowed passwords such
as admin123 and password123. These types of passwords are commonly found in widely-
accessible dictionaries. As a matter of fact, Secure Ideas commonly uses the
Password123 string against systems that implement account lockout due to it commonly
being found as the password for accounts in web applications.

15
16
17
18
19
20