0

Web Application Security Assessment

ABC Security

1 Rivercourt, #803,
Jersey City, NJ 07310
Contact: (347)-748-4505

WEB APPLICATION SECURITY ASSESSMENT REPORT RAJESH KUMAR

TABLE OF CONTENTS

Report Details 1
Executive Summary 3
Overview 3
Summary of Findings 4
Technical Findings 6
SQL Injection 6
Directory Indexing and Browsing 9
External Redirect 11
Cookie and Session Exploits 13
CSRF 16
Clickjacking 18
Weak Password Complexity, no password aging, password reuse and unencrypted passwords transmitted 20
Missing account lockout 22
Version Disclosure Apache/PHP 23
User Enumeration 25
Appendices 25
Impact Rating and Ease of Exploit classification details: 25
Port Scan Details: 26

REPORT DETAILS

1
 Report Version
Title Version Reviewer Date

Web Application Security Assessment Report V1.0 Rajesh Kumar 3/24/2019

Report Delivery Details

Parameter Details
Web application security testing report
Document Type:
3/24/2019
Date Submitted:
CONFIDENTIAL
Classification:
Doug DePerry
Submitted to:
Douglas.deperry@datadoghq.com
Submission email:

Consultant Details
Name: Rajesh Kumar
ABC Security
Company:
(347)-748-4504
Contact No:
rajeshkumar@nyu.edu
Email:

Copyright
Copyright © 2019 ABC Security. All rights reserved.

2
EXECUTIVE SUMMARY

Overview

ABC security was assigned the task of carrying out Web Application Security Assessment for DataDog. This report details
the scope of testing conducted all significant findings along with detailed remedial advice.

Target and Duration of Engagement:

DataDog defined the following URL as Target:

http://192.168.1.29:5000/login

The web application security assessment was carried out from 03/21/2019 -03/24/2019.

Out of Scope:

▪ Stress testing

▪ Secure transmission testing

▪ Network configuration and vulnerabilities.

Objective:

The purpose of the assessment was to identify and validate various potential security vulnerabilities in the web application
of DemoPasswordManager as defined in scope. Due care was taken not to impact any server availability as agreed upon.

Approach and Framework:

The OWASP Testing Framework was followed as a reference framework that comprises techniques and tasks that are
appropriate at various phases of security testing. Various phases were as listed:

• Perform various scans and information gathering to identify areas of exposure to the internet.
• Perform variously targeted scans to detect various vulnerabilities and manual testing to validate the results.
• Identifying application, objective, core components, areas of risk.
• Inspection of source code to identify other possible vulnerabilities.
• Classify vulnerabilities according to risk and impact.
• Final validation of vulnerabilities along with recommendation strategies for improvement in security posture.
• Responsible disclosure with a confidential report.

The summary below provides a non-technical audience with a summary of the key findings and relates these backs to business
impacts. Section three of this report relates the technical findings where DemoPasswordManager may want to invest further
resources in order to improve the overall security posture of their systems. Section four of this report highlights Appendices
which narrate various rating classifications, other technical details and various tools used during engagement aiming at a
technical audience.

3
Summary of Findings

This section gives an overall summary of key finds during the course of the engagement. The summary is classified according
to vulnerability impact ratings in three categories High, Medium and Low based on overall impact and damage it may cause
to firm. The details of classification are as mentioned in Appendices. Corrective action should be taken immediately according
to classification and response required.

Figure 1 Pie chart: Summary of Findings by Impact ratings

Vulnerability Impact Rating Number of findings

High 1

Medium 6

Low 3

Table: Summary of Findings by Impact Rating

4
The above pie chart shows a summary of findings according to ratings. We found one HIGH rated vulnerability and
significantly high number of MEDIUM rated vulnerabilities which need prioritized attention along with LOW vulnerabilities
which need immediate attention for securing overall security posture of the firm.

The application is not deployed in a consistent format related to best practice guidelines for internet facing web application
deployment. The application is vulnerable to various attacks related to Inadequate Input Validation.

Major attacks which could leverage this vulnerability identified were SQL Injection, Cross-Site Scripting and
OS Command Injection. These require immediate attention and should be mitigated with priority.

If web application fails to properly validate and sanitize input field attacker can specify various crafted queries to get
information out of database via SQL Injection. This could lead to exposure of sensitive data like password, usernames, bug
details which in turn can cause extensive damage and financial loses.

Server Misconfiguration is another issue identified. Due to this various directories, files and other sensitive information is
exposed. The server misconfiguration must me identified and remediated. Here we found various default pages, directories,
version of Apache-PHP or even source code in the folder. External redirection validation was done. These issues can lead to
serious exposure of information along with reputation damage.

Session handling mechanism contains various logical vulnerabilities and they do not offer an end-to-end session. They are
vulnerable to Session replay, Man in middle attacks. These issues in combination allow for an attacker to hijack users’ sessions
and gain unauthorized and unauthenticated access to the application and users’ data. Also, cookies are not set to HTTP only
and also could be reused in multiple sessions. These vulnerabilities lead to serious risk scenario when the attacker is motivated
to capture sessions or even attempt to implement malicious activities on behalf of the user.

Username enumeration needs attention. It is recommended to have generic messages instead of specific ones as an attacker
can gather information on user base and can also use this to brute force user accounts password. Also, various policies related
to password need immediate priority and should be set according to standard organization password length, complexity,
and entropy policies.

Various vulnerabilities identified indicate the need for improvement in quality checks and consistent methodology in Software
Development Lifecycle. To remediate risks associated with vulnerabilities re-engineering of application keeping security
principles in mind is required.

5
TECHNICAL FINDINGS

This section records the key technical findings from the assessment along with recommendations on issues identified.

SQL Injection

Vulnerability impact rating: High

Ease of exploitation: Moderate
Description:
The application allows for the injection of arbitrary SQL queries via a number of user-supplied input fields. SQL injection
occurs when user input is not filtered for escape characters and is then passed into a SQL statement. Several functions within
the application dynamically create SQL statements from user input and perform no validation on the user input before doing
so.

Attackers could inject arbitrary SQL statements that modified the execution of the statements. This vulnerability allows an
attacker to get read and write access to any and all of the data stored within the database. An attacker could steal, modify
or destroy any or all of the data using SQL injection.

Affected URLs: http://192.168.1.29:5000/search

Parameters: search=

Payload: ' or '1' = '1' --

Reproduction steps:
1) Open the affected URL in browser: http://192.168.1.29:5000/search
2) Search with given payload.
Impact analysis:
During static code analysis of search page it was identified that search parameter of URL in web application was vulnerable
to SQL injection attacks. As proper input validation was not in place, this parameter could easily be exploited by attacker
to supply custom crafted queries to database to extract important data like tables, users, passwords, bug description.

Figure 1 Source code search page

Such vulnerable SQL injection parameters could be leveraged for exfiltration of sensitive data like
all tables with help of SQL Injection tools like Sqlmap, sqlninja, and also blind sql injection.

6
 Figure 2 List of all password created by all users of password manager

Recommendations:
• Implement data validation routines that contain a default deny policy and restrict character classes to known good
values.
7
 • Single quotes should be escaped to prevent misinterpretation.
• Whitelist acceptable values.
• Re-engineer the application so that it implements the least privilege model, i.e. use different database users to
perform SELECT, UPDATE, INSERT etc. commands. In the event of an attacker injecting code into a vulnerable
statement, the privileges afforded would be minimized. This remediation step does not solve the SQL injection
vulnerability, but it may limit the potential damage.
• Re-code the application so that it uses parameterized stored procedures to prevent variables from being interpreted
as SQL commands.

References:
https://www.owasp.org/index.php/SQL_Injection
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

8
Directory Indexing and Browsing

Vulnerability impact rating: Medium

Ease of exploitation: Easy
Description:
A misconfigured server can show a directory listing, which could potentially yield sensitive information to an attacker. Insecure
indexing is a threat to the data confidentiality of the web-site. Indexing web server contents via a process that has access to
files and directories which are not supposed to be publicly accessible has the potential of leaking information about the
existence of sensitive files, and about their content. In the process of indexing, such information is collected and stored by the
indexing process, which can later be retrieved by a determined attacker.

Affected URLs: http://192.168.1.29:5000/passwords/1

Reproduction steps:
1) Open the affected URL in browser: / http://192.168.1.29:5000/passwords/
2) Change index 1 to any other password ID.

Impact analysis:
It was found that directory listing was enabled on affected target URL. Due to this functionality attacker can guess various
directories available and explore them to find crown jewels. Here we found complete source code backed up at
http://192.168.1.29:5000/passwords/1. An attacker can do source code analysis to understand application logic, find
flaws in code and later exploit them with utmost accuracy leaving the application vulnerable to attacks.
Directory Indexing should be terminated as it can lead to information disclosure.

Figure 3 Directory Indexing

Recommendations:

• Disable directory listings in the web- or application-server configuration by default.

• Restrict access to unnecessary directories and files.
• Create an index (default) file for each directory.
9
 • Remove directory listing in robots.txt

References:
http://cwe.mitre.org/data/definitions/548.html
https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Directory_Indexing

10
External Redirect

Vulnerability impact rating: Medium

Ease of exploitation: Easy
Description:
URL redirectors represent common functionality employed by websites to forward an incoming request to an alternate
resource. This can be done for a variety of reasons and is often done to allow resources to be moved within the directory
structure and to avoid breaking functionality for users that request the resource at its previous location. URL redirectors may
also be used to implement load balancing, leveraging abbreviated URLs or recording outgoing links. It is this last
implementation which is often used in phishing attacks as described in the example below.
URL redirectors do not necessarily represent a direct security vulnerability but can be abused by attackers trying to social
engineer victims into a possible phishing campaign believing that they are navigating to a site other than the true destination.

Affected URLs: http://192.168.1.29:5000/login?next=%2F

Payload: ?next=http://www.duckduckgo.com

Reproduction steps:
1) Open the affected URL in browser: http://192.168.1.29:5000/login?next=http://www.duckduckgo.com

Impact analysis:

Get request to http://192.168.1.29:5000/login?next=http://www.duckduckgo.com

GET /login?next=http://www.duckduckgo.com HTTP/1.1

Host: 192.168.1.29:5000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: session=.eJwNjklqBDAMBP_icw6yJWvJZwYtFoRABia5hfw9PlZRNP07Hh813oe0dvg25Zl4xCehWF-
53RLTegpIIC7k2hxNthdcYCwM0BJO5U1NWR09D1yzZopjEfeZfISh0GDiquhbirnOgK7jGjLeRn6_-
vHz_Dxf9w8huG5dtdApiSjubKngoUD3k-5wzPb4-wdrEjam.D3nvXQ.RdBTTpN64fseyvM8gQDVooOOtHk
Upgrade-Insecure-Requests: 1

As we can see attacker can exploit this vulnerability to send victims to a malicious site which they will think is legitimate site
redirected from a trusted site.

Response by 192.168.1.29
HTTP/1.0 302 FOUND
Content-Type: text/html; charset=utf-8
Content-Length: 257
Location: http://www.duckduckgo.com
Vary: Cookie
Set-Cookie: session=.eJwdj8GKwzAMRH-l-NyDHdmWnW_YPyilyJaUls22ECeHpfTfV-
xpmIdmGL3dTVcadxluvrzdaTdxPzIGLeLO7uu1LMKnx_M0jt4N67Guv-
76uZ4tuMm4u3nfDjH3YDc71KKNUi05dBCkEAGrGkxUO_SqAT02gAkyp9w01jR5MxkYmi-
MuZecosbO2jSINzKFjgQcs0rIgtkzVB9g4qZ2iZVKaF5ZqDS0yX1settf3_K0PRE8lVQmnoBijzE2q-
WCILEBkXQiL7Umyx1Dtv8nAiB8_gAdxVN6.D3nvoA.HGCtQrJZ-IqpEdObxWvjsPbS0nY; HttpOnly; Path=/
Server: Werkzeug/0.14.1 Python/3.6.5
Date: Mon, 25 Mar 2019 04:50:40 GMT

11
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a
href="http://www.duckduckgo.com">http://www.duckduckgo.com</a>. If not click the link.

Here we managed to redirect from URL in scope to external URL www.duckduckgo.com

Recommendations:

• Use a whitelist of approved URLs or domains to be used for redirection.

• Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving your site.
Implement a long timeout before the redirect occurs or force the user to click on the link. Be careful to avoid XSS
problems when generating the disclaimer page.
• When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of
fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
• Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies,
anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL
components, e-mail, files, databases, and any external systems that provide data to the application. Remember that
such inputs may be obtained indirectly through API calls.
• Many open redirect problems occur because the programmer assumed that certain inputs could not be modified,
such as cookies and hidden form fields.

References:
http://projects.webappsec.org/URL-Redirector-Abuse
http://cwe.mitre.org/data/definitions/601.html

12
Cookie and Session Exploits

Vulnerability impact rating: Medium

Ease of exploitation: Moderate
Description:
Simultaneous Session Logons:
It is the web application design decision to determine if multiple simultaneous logins from the same user are allowed from the
same or from different client IP addresses. If the web application does not want to allow simultaneous session logins, it must
take effective actions after each new authentication event, implicitly terminating the previously available session, or asking
the user (through the old, new or both sessions) about the session that must remain active.
Session Fixation:
It is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web
application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t
assign a new session ID, making it possible to use an existent session ID.
The session fixation attack is a class of Session Hijacking, which steals the established session between the client and the Web
Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the
attack starts before the user logs in.
There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below
are some of the most common techniques:
• Session token in the URL argument.
• Session token in a hidden form field.
• Session ID in a cookie.

Improper Session Termination:

Cookies with valid session IDs can be reused to create sessions even after user is logged out.

No session Idle Timeout:

Authenticated sessions within the application do not appear to time out within a reasonable period of time. We found that
user sessions were still valid after over 2 hours of inactivity. An individual user may be targeted by a deliberate or
opportunistic attempt to 'hijack' an active session either through exploiting an unattended unlocked workstation or through a
session hijacking attack.

Reproduction steps:
1) Send a GET request to the web server, capture the traffic by any proxy tool like Burp.
2) Identify the cookie/session id value
3) Replay with different techniques to achieve session manipulation

13
Impact analysis:

Figure 2 Parallel session of same user in two different browsers

HTTP/1.0 302 FOUND

Content-Type: text/html; charset=utf-8
Content-Length: 209
Location: http://192.168.1.29:5000/
Vary: Cookie
Set-Cookie: session=.eJwdj8GKwzAMRH-l-NyDHdmWnW_YPyilyJaUls22ECeHpfTfV-
xpmIdmGL3dTVcadxluvrzdaTdxPzIGLeLO7uu1LMKnx_M0jt4N67Guv-
76uZ4tuMm4u3nfDjH3YDc71KKNUi05dBCkEAGrGkxUO_SqAT02gAkyp9w01jR5MxkYmi-
MuZecosbO2jSINzKFjgQcs0rIgtkzVB9g4qZ2iZVKaF5ZqDS0yX1settf3_K0PRE8lVQmnoBijzE2q-
WCILEBkXQiL7Umyx1Dtv8nAiB8_gAdxVN6.D3n0dA.0KlWJRjQobx5b7hBByPdoZ-stzI; HttpOnly; Path=/
Server: Werkzeug/0.14.1 Python/3.6.5
Date: Mon, 25 Mar 2019 05:11:16 GMT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/">/</a>. If not click the link.

Figure 5 Session is set with multiple misconfigurations.

During session manipulation, we did not find any session timeout attribute in the GET request, which brings up another
vulnerability of no session timeout. This can be further chained to achieve simultaneous sessions and cookie reuse. In the
session configuration, HSTS, secure, SameSite and Max-Age attributes are missing.

Recommendations:
Session IDs are attacked by guessing, capturing or setting the id. You can protect against this in your own applications by
…
• Securing the cookie to make stealing the ID harder
• Limiting the session to a specific host to make attacks more difficult
• Changing the ID when escalating privileges and throughout the session life.
• Set Cookie with industry standard recommendations to protect against reuse and manipulation.

References:
14
https://blog.teamtreehouse.com/how-to-create-bulletproof-sessions
https://stackoverflow.com/questions/964071/correct-way-to-manage-sessions-in-php
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md

15
CSRF

Vulnerability impact rating: Medium

Ease of exploitation: Moderate
Description:
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in
which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data since the
attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link
via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's cho osing. If
the victim is a normal user, a successful CSRF attack can force the user to perform state-changing requests like transferring
funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire
web application.

Affected URLS: http://192.168.1.29:5000/

Reproduction steps:
1) Save the Html source code as any test page and run it in browser.
2) To change any user’s password, change the csrf token in the source code.

Source code
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.1.29:5000/edit" method="POST">
<input type="hidden" name="csrf&#95;token"
value="IjQzMGE4NTgyZDIzYTRjNDQ0YmZiZmQ4NzNlNGIzYWFlY2FhMGU5OTUi&#46;D3n2hw&#46;LEY2FTyfIAoWJ1c9h1V10k9t9
ns" />
<input type="hidden" name="new&#95;password" value="R&#64;j09esh" />
<input type="hidden" name="new&#95;password1" value="R&#64;j09esh" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>

Impact analysis:
Here we have tricked administrator into changing password of another user.

Figure 3 CSRF – Password change for any user

Recommendation:

16
 • The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append CSRF tokens to each
request and associate them with the user’s session. Such tokens should at a minimum be unique per user session but
can also be unique per request. By including a challenge token with each request, the developer can ensure that
the request is valid and not coming from a source other than the user.
• CSRF attacks are only possible since Cookies are always sent with any requests that are sent to a particular origin,
which is related to that Cookie. Due to the nature of a CSRF attack, a flag can be set against a Cookie, turning it
into a same-site Cookie. A same-site Cookie is a Cookie which can only be sent if the request is being made from
the same origin that is related to the Cookie being sent. The Cookie and the page from where the request is being
made, are considered to have the same origin if the protocol, port (if applicable) and the host is the same for both.

References:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
https://www.veracode.com/security/csrf
https://www.acunetix.com/websitesecurity/csrf-attacks/

17
Clickjacking

Vulnerability impact rating: Medium

Ease of exploitation: Moderate
Description:
Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a
user into clicking on a button or link on another page when they were intending to click on the top-level page. Thus, the
attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application,
domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and
text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead
typing into an invisible frame controlled by the attacker.

Affected URLS: /poc.html

Payload:

<style>
iframe { /* iframe from the victim site */
width: 800px;
height: 500px;
position: absolute;
top:0; left:0px;
opacity: 0.5; /* in real opacity:0 */
z-index: 2;
}
</style>
<div>Click to get 1 month free subscription</div>

<!-- The url from the victim site -->

<iframe src="http://192.168.1.29:5000/register"></iframe>

<button>Click here!</button>

<div>...And you're cool (I'm a cool hacker actually)!</div>

Reproduction steps:
1) Save the above source code as any HTML webpage
2) Open the above-generated webpage in the browser

Impact analysis:
Here is a POC with HTML and iframe where we managed to get the server page to be loaded in the sample HTML code,
this could be heavily exploited in tricking the user to get user activity details. In the source code above, we have redirected
the visitor to the DemoPasswordManager register page, which is loaded every time user visits our sample page.

18
 Figure 4 Clickjacking demo with a login screen

Recommendation:

1. Send the content as an HTTP Header – the directive is ignored if specified in a META tag
2. Use X-Frame-Options on critical configuration pages or other pages that require an “authentic user click”
3. Don’t use “sameorigin” if you have any page on your domain which accepts an arbitrary URL to frame

References:
https://www.owasp.org/index.php/Clickjacking
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
https://blogs.msdn.microsoft.com/ieinternals/2010/03/30/combating-clickjacking-with-x-frame-options/

19
Weak Password Complexity, no password aging, password reuse and unencrypted passwords transmitted

Vulnerability impact rating: Medium

Ease of exploitation: Easy
Description:
There is no minimum threshold of password complexity. So even administrator passwords or other user passwords could be
as simple as ‘123’. Due to this attacker can easily guess passwords if they are simple and imitate that user in the application.

Also, the application did not support a password aging policy, allowing users to keep the same password indefinitely. This
vulnerability greatly increases the chances of compromise of a user’s password through either unintentional disclosure by a
user or through other electronic compromise.

Passwords for users of the application are transmitted unencrypted to the server. An attacker can leverage SQL injection
vulnerability in order to extract user credentials and password values. An attacker could use the same vector to impersonate
authorized users and gain access to potentially sensitive information.

Impact analysis:
The application allows for the use of weak passwords; depending on the strength of the user's chosen password, brute force
guessing could take an unskilled attacker as little as a few seconds to guess.
Moreover, an attacker with access to a user's credentials would be able to indefinitely compromise an account as there
doesn’t exist any password aging policy.

An external attacker would need the ability to query the backend database, via an attack vector such as SQL Injection or
access to unencrypted database backup media. Here we managed to get user passwords and information from the database.

Figure 5 Password reuse

Recommendation:
1) Re-engineer the application to user's chosen password, brute force guessing could take an unskilled attacker as
little as a few seconds to guess. introduce functionality that allows the implementation of a minimum password
strength that can be set in line with corporate security policy and best practice.

20
 2) The accounts should be routinely audited in order to prevent and detect the use of weak passwords. Passwords
should be set to expire on a regular basis and the application should maintain a history of at least the last 3
passwords to prevent password repetition.

3) Use a one-way cryptographic hash function to store passwords in the database rather than using plain text
4) Implement a password aging policy that requires users to change their passwords at least every 90 days.
5) Password reuse should not be allowed, it helps in protecting users in case of an attack and breach of passwords.

References:
https://www.resolver.com/trust/policies/corporate-password-policy/
https://www.sans.org/security-awareness-training/blog/time-password-expiration-die
https://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database

21
Missing account lockout

Vulnerability impact rating: Low

Ease of exploitation: Easy
Description:
The application does not impose an account lockout threshold. An attacker could perform unlimited login attempts. An attacker
able to successfully brute force entry into an account would be able to masquerade as that user within the application.

Affected URLs: 192.168.1.29:5000/login

Impact analysis:
Without an account lockout mechanism to restrict the number of authentication attempts, an attacker would have an unlimited
number of attempts to guess the configured password and unless their brute force attempt was discovered they would
eventually guess even a strong password.

Figure 9 Password brute force successful

Recommendation:
Implement an account lockout mechanism that restricts the number of login attempts. Industry best practice suggests a maximum
figure of failed login attempts to be between 3 and 5 attempts.

The account lockout should either be implemented as a random period of time i.e. between 1 and 5 minutes to defeat
automated brute force tools or should remain locked until unlocked by an administrator or through an account reset process
that can be initiated by a user the implementation of which is subject to security policy requirements. All unsuccessful login
attempts should be tracked in a database or other stateful component and should not be tracked in a session variable.

References:
https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003)

22
Version Disclosure Apache/PHP

Vulnerability impact rating: Low

Ease of exploitation: Easy
Description:
Information disclosure in banner grab reveals sensitive data, such as technical details of the web server, environment, or user-
specific data. Sensitive data may be used by an attacker to exploit the target web application, its hosting network, or its
users. This helps an attacker to launch target specific attacks.

Impact analysis:
Information disclosure in banner grab reveals sensitive data, such as technical details of the web server, environment, or user-
specific data. Sensitive data may be used by an attacker to exploit the target web application, its hosting network, or its
users. This helps an attacker to launch target specific attacks.

The web server HTTP header responses displayed the type and version of software running on the server. Knowledge of the
specific web server version allows an attacker to quickly identify known vulnerabilities that may be present in that particular
server. This vulnerability constituted information leakage and did not directly impact the security posture of the server
however it is useful and time-saving to the attacker.

Figure 6 Version Disclosure

Recommendation:
• If possible, configure the server to provide false or no information. Remove all default content from
the system in order to reduce its known signature footprint.
• Edit your Apache configuration file and Add/Edit following variables. After making changes restart your Apache
service.
ServerTokens Prod
ServerSignature Off
• In order to prevent PHP from exposing the fact that it is installed on the server, by adding its signature to the web
server header we need to locate in php.ini the variable expose_php and turn it off. _ By default expose_php is
23
 set to On. In your php.ini (based on your Linux distribution this can be found in various places, like /etc/php.ini,
/etc/php5/apache2/php.ini, etc.) locate the line containing “expose_php On”_and set it to Off:

References:
https://www.tecmint.com/hide-apache-web-server-version-information/
http://www.ducea.com/2006/06/16/apache-tips-tricks-hide-php-version-x-powered-by/

24
User Enumeration

Vulnerability impact rating: Low

Ease of exploitation: Easy
Description:
User enumeration is when a malicious actor can use brute-force to either guess or confirm valid users in a system. User
enumeration is often a web application vulnerability, though it can also be found in any system that requires user
authentication.

Affected URLS: http://192.168.1.29:5000/login

Reproduction:
1) Open the following URL in browser: http://192.168.1.29:5000/login
2) Change the user name to any random value in the user field and click sign in.
3) Repeat the request by correct user name and incorrect password and observe the differences.
Impact analysis:
The malicious actor is looking for differences in the server's response based on the validity of submitted credentials. Here we
try to look out for a number of users in-app with various user ids. We can go on incrementing until we know an exact number
of users. Here we found there are 5 users as id=6 showed user not found.

Figure 11 User Enumeration

Recommendation:
Send generic error messages instead of specific “Username is invalid”.

References:
https://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/
https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

APPENDICES

Impact Rating and Ease of Exploit classification details:

25
Vulnerability Impact Ratings:

Impact rating represents the rating of web application vulnerabilities that could lead to a serious impact on the firm.
Depending on environment and vulnerability in context, this rating is computed keeping in mind the financial, reputation,
availability and relationship impacts.
In usual case it is, Vulnerability impact rating= Base impact rating + Environmental impact rating.

Impact ratings are classified as follows:

High:
The high rating is reserved for vulnerabilities which have a very high impact and could lead to a major loss if exploited. This
rating must be interpreted as immediate attention should be taken to mitigate the vulnerability.
Examples of such vulnerabilities are:
SQL Injection.
Remote OS command Injection.
Backdoors and Trojans.
Dos attacks.

Medium:
Medium rating is reserved for vulnerabilities which have a very moderate impact but could lead to a loss if exploited. This
rating must be interpreted as attention should be taken to mitigate the vulnerability.
Examples of such vulnerabilities are:
Application Errors.
External Redirects.
Session management.
CSRF

Low:
Low rating is reserved for vulnerabilities which have very low security impact but could lead to information disclosure or loss
if exploited. Usually, these vulnerabilities are chained with others to form complex attack cases.
Examples of such vulnerabilities are:
Information Disclosure
Directory Browsing
Enumeration errors.

Ease of Exploit Ratings:

Depending on factors of influence in the specific environment the Ease of exploit ratings is calculated.

Difficult:
This type of vulnerabilities requires advanced attacker skills and are very difficult to exploit or require special knowledge.
Moderate:
This type of vulnerabilities requires normal attacker skills and are moderately difficult to exploit. Usually, such moderate
exploitation techniques combine the use of information and specialized tool set.

Easy:
This type of vulnerabilities requires no attacker skills and could be exploited by anyone based on information obtained. Such
vulnerabilities are easily exploitable.

Port Scan Details:

Here are details of Nmap post-scan and service discovery:

Port Service
22 SSH-OpenSSH 7.6p1
26
5000 Werkzeug httpd 0.141

27