Beruflich Dokumente
Kultur Dokumente
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
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.
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:
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-
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
Proof of Concept:
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
Proof of Concept:
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
Proof of Concept:
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
Proof of Concept:
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
Proof of Concept:
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.