VULNERABILITY AND

PENETRATION TESTING
REPORT

Jay Soni
UPES Bidholi, Dehradun
Table of Contents

1. Executive Summary
 Summary
 Scope
 Dates of VAPT
 Audit Team
 Restrictions and Assumptions
 Report Presentation

2. Technical / Detailed Summary

 Methodology
 Detailed List of Vulnerabilities
 Proof of Vulnerabilities

3. Conclusion & Strategic Recommendations

Summary
Overview
Coding Networks has assigned the task of carrying out Security Assessment
(Vulnerability Assessment & Penetration Testing) of http://certifiedhacker.com
website to Mr. Jay Soni in reference with the CEH Assignment.
The objective of the test is to identify weaknesses in the security controls implemented
on various perimeter components and to determine the weaknesses in the application
which may be exploited by an outsider/unauthorized user
The tests are carried out assuming the identity of an attacker or a user with malicious
intent. At the same time due care is taken not to harm the infrastructure. This report
details the scope of testing conducted, all significant findings along with detailed
remedial advice. This document summarizes the findings, analysis and
recommendations from the assessment, which was conducted across the Internet from
UPES Dehradun, Bidholi, 278001.

Approach
 Perform broad scans to identify potential areas of exposure and services that may
act as entry points
 Perform targeted scans and manual investigation to validate vulnerabilities
 Test identified components to gain access to the stated scope
 Identify and validate vulnerabilities.
 Rank vulnerabilities based on threat level, loss potential, and likelihood of
exploitation
 Perform supplemental research and development activities to support analysis
 Identify issues of immediate consequence and recommend solutions
 Develop long-term recommendations to enhance security
 Transfer knowledge

Scope
VAPT was done on the http://certifiedhacker.com/ website.
The scope of the security Assessment shall include all components of each Information
System website.
Dates of VAPT
This Vulnerability Assessment & Penetration Testing was performed on 15th, 16th,
20th & 21st March 2019 from UPES, Dehradun, 248001.

Audit Team
The Penetration Testing is done by Jay Soni.

Restrictions and Assumptions

The Penetration tester tried not to cause any wilful disturbance on the stated scope
during the testing.

Report Presentation
 Vulnerability Assessment and Penetration testing Methodology
 Detailed List of Vulnerabilities
 Proof of Vulnerabilities
Technical and Detailed Summary
Methodology
The scope was to finding out the vulnerable areas of http://certifiedhacker.com/ and
exploiting them for the analysis.

1.Reconnaissance
This would involve gathering as much information as possible about the selected target
object. We will attempt to analyse and find out the vulnerabilities as accurately as
possible with minimum breaching of resources.

2. Enumeration
This would involve detailing of the target, including but not limited to:
 Finding open ports and services running on the target
 Finding the common but dangerous vulnerabilities like sqli,xss are tested.

3.Weakness Identification
OWASP ZAP and its components are tested using best in class automated
scanners; this is further supplemented by configuration reviews to ensure the devices
are free from vulnerabilities and are configured securely.
Settings and configurations are analysed for, including but not limited to:

 Cached or default credentials

 Weak password policies
 Sensitive data disclosure
 Missing security patches
 Possible exploitation due to missing patches/ security updates

4.Exploitation
Exploitation of vulnerabilities detected in earlier phases is carried o ut using
exploitation frameworks and scripts, taking a deep dive approach to penetrate as deep
as possible into the setup.
Payloads are deployed to exploit detected vulnerabilities and detect whether it possible
to carry out.
 Privilege escalations
 Backdoor entry
 Man-in-the middle attack
 Eavesdropping/Packet interception
 Unauthorized access
For production setup, penetration testing is done in a safe mode where payloads are
deployed to demonstrate exploitability of vulnerabilities, without actually com
promising sensitive data.

5.Reporting
Based on results of the exercises and risk analysis, protective measures are
recommended as required.
High risk vulnerabilities and remediation measures are reported as soon as they are
identified.
Detailed List of Vulnerabilities Threat Level
Risk Description
Sqli Injection High
Directory Browsing Medium
X-Frame-Options Header Not Set Medium
Password Autocomplete in Browser Low
Web Browser XSS Protection Not Enabled Low
X-Content-Type-Options Header Missing Low

Proof Of Vulnerabilities

Sqli Injection

Vulnerable URL:
http://www.certifiedhacker.com/css/default.css?query=query%27+AND+%271%27%
3D%271%27+--+

Proof of Concept:
The following server-side pseudo-code (attacking script) is used to authenticate users
to the web application-

About this Vulnerability:

SQL injection is a code injection technique, used to attack data-driven applications, in
which nefarious SQL statements are inserted into an entry field for execution (e.g. to
dump the database contents to the attacker).
Impact:
The page results were successfully manipulated using the boolean conditions [query'
AND '1'='1' -- ] and [query' OR '1'='1' -- ]
The parameter value being modified was NOT stripped from the HTML output for the
purposes of the comparison
Data was NOT returned for the original parameter.
The vulnerability was detected by successfully retrieving more data than originally
returned, by manipulating the parameter

Mitigation:

 Do not trust client side input, even if there is client side validation in place.
 In general, type check all data on the server side.
 If the application uses JDBC, use PreparedStatement or CallableStatement, with
parameters passed by '?'
 If the application uses ASP, use ADO Command Objects with strong type
checking and parameterized queries.
 If database Stored Procedures can be used, use them.
 Do *not* concatenate strings into queries in the stored procedure, or use 'exec',
'exec immediate', or equivalent functionality!
 Do not create dynamic SQL queries using simple string concatenation.
 Escape all data received from the client.
 Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters
in user input.
 Apply the principle of least privilege by using the least privileged database user
possible.
 In particular, avoid using the 'sa' or 'db-owner' database users. This does not
eliminate SQL injection, but minimizes its impact.
 Grant the minimum database access that is necessary for the application

References:
https://www.owasp.org/index.php/Top_10_2010-A1
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
Directory Browsing

Vulnerable URL: http://www.certifiedhacker.com/css/

Proof of Concept:

About this Vulnerability:

Properly controlling access to web content is crucial for running a secure web server.
Directory traversal or Path Traversal is an HTTP attack which allows attackers to access
restricted directories and execute commands outside of the web server’s root directory.

Impact:
It is possible to view the directory listing. Directory listing may reveal hidden scripts,
include files , backup source files etc which can be accessed to read sensitive
information

Mitigation:
Disable directory browsing. If this is required, make sure the listed files does not induce
risks.

References:
http://httpd.apache.org/docs/mod/core.html#options
http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html
X-Frame-Options Header Not Set

Vulnerable URL: http: http://www.certifiedhacker.com/

Proof of Concept:

About this Vulnerability:

X-Frame-Options. The X-Frame-Options HTTP response header can be used to indicate
whether or not a browser should be allowed to render a page in a <frame> , <iframe> ,
<embed> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that
their content is not embedded into other sites.

Mitigation:
Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set
on all web pages returned by your site (if you expect the page to be framed only by
pages on your server (e.g. it's part of a FRAMESET) then you'll want to use
SAMEORIGIN, otherwise if you never expect the page to be framed, you should use
DENY. ALLOW-FROM allows specific websites to frame the web page in supported
web browsers).

References:
http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-
x-frame-options.aspx
Password Autocomplete in Browser

Vulnerable URL: http://www.certifiedhacker.com/

Proof of Concept:

About this Vulnerability:

If a site sets autocomplete="off" for a <form> , and the form includes username and
password input fields, then the browser will still offer to remember this login, and if the
user agrees, the browser will autofill those fields the next time the user visits the page.

Impact:
The AUTOCOMPLETE attribute is not disabled on an HTML FORM/INPUT element
containing password type input. Passwords may be stored in browsers and retrieved.

Mitigation:
Turn off the AUTOCOMPLETE attribute in forms or individual input elements
containing password inputs by using AUTOCOMPLETE='OFF'.

References:
http://www.w3schools.com/tags/att_input_autocomplete.asp
https://msdn.microsoft.com/en-us/library/ms533486%28v=vs.85%29.aspx
Web Browser XSS Protection Not Enabled

Vulnerable URL: http://www.certifiedhacker.com/

Proof of Concept:

About this Vulnerability:

Web Browser XSS Protection is not enabled, or is disabled by the configuration of the
'X-XSS-Protection' HTTP response header on the web server

Impact:
The X-XSS-Protection HTTP response header allows the web server to enable or
disable the web browser's XSS protection mechanism. The following values would
attempt to enable it:
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=http://www.example.com/xss
The following values would disable it:
X-XSS-Protection: 0
The X-XSS-Protection HTTP response header is currently supported on Internet
Explorer, Chrome and Safari (WebKit).
Note that this alert is only raised if the response body could potentially contain an XSS
payload (with a text-based content type, with a non-zero length).

Mitigation:
Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection
HTTP response header to '1'.
References:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sh
eet
https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/
X-Content-Type-Options Header Missing

Vulnerable URL: http://www.certifiedhacker.com/

Proof of Concept:

About this Vulnerability:

The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This
allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on
the response body, potentially causing the response body to be interpreted and displayed
as a content type other than the declared content type. Current (early 2014) and legacy
versions of Firefox will use the declared content type (if one is set), rather than
performing MIME-sniffing.

Impact:
This issue still applies to error type pages (401, 403, 500, etc) as those pages are often
still affected by injection issues, in which case there is still concern for browsers sniffing
pages away from their actual content type.
At "High" threshold this scanner will not alert on client or server error responses.

Mitigation:
Ensure that the application/web server sets the Content-Type header appropriately, and
that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.
If possible, ensure that the end user uses a standards-compliant and modern web
browser that does not perform MIME-sniffing at all, or that can be directed by the web
application/web server to not perform MIME-sniffing.
References:
http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Conclusion
Experience has shown that a focused effort is required on the entire environment,
future directions and introduction of security best practices to address the
problems outlined in this report can result in dramatic security improvements.
Also as a strategically level, a Consistent Patch Management Program and
Regular Vulnerability Management is also recommended as new attacks coming
on the scene every day and IT assets become vulnerable even if nothing has
changed since your last assessment. To ensure security system can adequately
protect against the most likely threats, a thorough periodically risk and security
assessment is required.

 Implement a patch management program

Operating a consistent patch management program is an important component in
maintaining good security posture. This will help to limit the attack surface that
results from running un-patched internal services.

 Conduct proactive and regular vulnerability assessments

As part of an effective organizational risk management strategy, vulnerability
assessments should be conducted on a regular basis. Doing so will allow the
organization to determine if the installed security controls are properly installed,
operating as intended, and producing the desired outcome.