Vulnerability Assessment
Report
Technical Report
No part of this publication, in whole or in part, may be reproduced, copied, transferred or any other right
reserved to its copyright owner, including photocopying and all other copying, any transfer or transmission
using any network or other means of communication, any broadcast for distant learning, in any form or by
any means such as any information storage, transmission or retrieval system, without prior written
permission from Avenging Security Pvt Ltd.
Table of Contents
EXECUTIVE SUMMARY
o Summary of Result
Scan Detail
Vulnerability
XSS (Cross Site Scripting)
HTML Form Without CSRF Protection
Session Cookie Without HTTP Only Flag
Session Cookie Without Secure Flag Set
Password Type Input With Auto Complete
Missconfiguration :UnencryptedApi
Quickjacking/Clickjacking
Unencrypted View State parameter
CVS web repository
XML external injection
Conclusion
EXECUTIVE SUMMARY
Avenging Security Pvt Ltd was contracted by Example Media PVT LTD to
conduct a Vulnerability Assessment in order to determine its exposure to a
targeted attack. All activities were conducted in a manner that simulated a
malicious act or engaged in a targeted attack against Example Media Pvt Ltd
with the goals of:
White Box Web Application Penetration Testing for
http://api.xxxxxxx.com/psms/
Efforts were placed on the identification and exploitation of security
weaknesses that could allow a remote attacker to gain unauthorized access to
organizational web application. The attacks were conducted with the level of
access that a general user would have.
The assessment was conducted in accordance with the recommendations
outlined by the company with all tests and actions being conducted under
controlled conditions.
SUMMARY OF RESULT
Initial reconnaissance of the Example Media Pvt Ltd during the network level
Security checks we tried to probe the ports present on the various points and
detect the services running on them with the existing security holes, if any. At
the web application level (http://api.xxxxxxx.com/psms/)we checked the web
server's configuration issues, and more importantly the logical errors in the
web application itself.
Scan Detail
Start Date 15th January 2018
Finish Date 27th January 2018 Scan Time 13 days Technology SSID Name http://api.xxxxxxxx.com/psms/
Credentials User id: xxxxxxx Password: xxxxxx
Scope White-Box
Vulnerabilities
S.no
Alert Summary Threat No. of Url’s
Url’s
1.
XSS (Cross Site Scripting)
High 1 http://api.xxxxxxx.com/psms/customer/message.jsp?message=
2. HTML Form Without CSRF Protection
Low 1 http://api.xxxxxxx.com/psms/
3. Session Cookie Without HTTP Only Flag
Low 1 http://api.xxxxxxx.com/psms/
4. Session Cookie Without Secure Flag Set
Low 1 http://api.xxxxxxxxx.com/psms/
5. Password Type Input With Auto Complete
Low 1 http://api. xxxxxxxxx.com/psms/
6 Missconfiguration :UnencryptedApi
High http://api. xxxxxxxxx.com/psms/
7. Quickjacking/Clickjacking
High 1 http://api. xxxxxxxxx.com/psms/
8 Unencrypted View State parameter
Low 1 http://api. xxxxxxxxx.com/psms/
9. CVS web repository High 1 http://api. xxxxxxxxx.com/psms/
10. XML external injection High 1 http://api. xxxxxxxxx.com/psms/
1. XSS (Cross Site Scripting)
Issue: XSS (Cross Site Scripting)
Threat: High
Host : http://api. xxxxxxxxx.com/psms/customer/message.jsp?message=
Issue Detail:
Overview:
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
XSS attacks can generally be categorized into two categories: stored and reflected.
Reflected XSS Attacks
Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site. When a user is tricked into clicking
on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.
Proof Of Concept:
Step1:
Open the following link
http://api. xxxxxxxxx.com/psms/customer/message.jsp?message=
And enter the following script after the url .
<script>alert(‘CC’)</script>
Step2
That confirms XSS Vulnerability.
2. HTML Form Without CSRF Protection:
Issue: HTML Form Without CSRF Protection.
Threat: Medium
Host : http:// xxxxxxxxx.com/ campaigns/forgot_password
Issue Detail:
An attacker may force the users of a web application to execute actions of
the attacker’s choosing. A successful CSRF exploit can compromise end
user data and operation in case of normal user. If the targeted end user is
the administrator account, this can compromise the entire web application.
3. Session Cookie Without HTTP Only Flag
Issue: Session Cookie without Http Only Flag
Threat: Low
Host : http://api. xxxxxxxxx.com/psms/
Issue Detail:
This cookie does not have the HTTP Only flag set. When a cookie is set
with the HTTP Only flag, it instructs the browser that the cookie can
only be accessed by the server and not by client-side scripts. This is an
important security protection for session cookies.
4. Session Cookie Without Secure Flag Set
Issue: Session Cookie without Secure Flag set
Threat: Low
Host : http://api. xxxxxxxxx.com/psms/
Issue Detail:
This cookie does not have the Secure flag set. When a cookie is set with the
Secure flag, it instructs the browser that the cookie can only be accessed over
secure SSL channels. This is an important security protection for session
cookies.
5. Password Type Input With Auto Complete
Issue: Password Type Input With Auto Complete
Threat: Informational
Host : http://api. xxxxxxxxx.com/psms/
Issue Detail:
When a new name and password is entered in a form and the form is
submitted, the browser asks if the password should be saved. Thereafter
when the form is displayed, the name and password are filled in automatically
or are completed as the name is entered. An attacker with local access could
obtain the clear text password from the browser cache.
Possible sensitive information disclosure.
6. Missconfiguration :UnencryptedApi
Issue: Unencrypted api
Threat: High
Host : http://api. xxxxxxxxx.com/psms/
Issue Detail:
This web security vulnerability is about crypto and resource protection.
Sensitive data should be encrypted at all times, including in transit and at rest.
No exceptions. Credit card information and user passwords should never
travel or be stored unencrypted, and passwords should always be hashed. Use
AES (256 bits and up) and RSA (2048 bits and up).
And while it goes without saying that session IDs and sensitive data should
not be traveling in the URLs and sensitive cookies should have the secure flag
on, this is very important and cannot be over-emphasized.
The following details in clear text, when check the request and response from
the server:
Username: xxxxxx
Password: xxxxxx123
Hence, anyone can perform MITM (man in the middle attack) to obtain the
information of user, running on the same network.
7. Quickjacking/Clickjacking:
Issue: Quickjacking/Clickjacking
Threat: Low
Host : http://api. xxxxxxxxx.com/psms/
Issue Detail:
Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is
a malicious technique of tricking a Web user into clicking on something
different from what the user perceives they are clicking on, thus potentially
revealing confidential information or taking control of their computer while
clicking on seemingly innocuous web pages.
Prevention:
There are two main ways to prevent clickjacking:
1. Sending the proper Content Security Policy (CSP) frame-ancestors directive response headers that instruct the browser to not allow framing from other domains. (This replaces the older X-Frame-Options HTTP headers.)
2. Employing defensive code in the UI to ensure that the current frame is the most top level window
8. Unencrypted View State parameter :
Issue: Unencrypted View State parameter :
Threat: High
Host : http://api. xxxxxxxxx.com/psms/
Issue Detail:
This web security vulnerability is about crypto and resource protection.
Sensitive data should be encrypted at all times, including in transit and at rest.
No exceptions. Credit card information and user passwords should never
travel or be stored unencrypted, and passwords should always be hashed. use
AES (256 bits and up) and RSA (2048 bits and up).
And while it goes without saying that session IDs and sensitive data should
not be traveling in the URLs and sensitive cookies should have the secure flag
on, this is very important and cannot be over-emphasized.
Impact:
Anyone can perform MITM (man in the middle attack) to obtain the
information of user, running on the same network.
Proof Of Concept:
Prevention:
In transit: Use HTTPS with a proper certificate and PFS (Perfect
Forward Secrecy). Do not accept anything over non-HTTPS connections.
Have the secure flag on cookies. Make the parameter encrypted and
pass that encrypted data on the url’s.
9. CVS Web Repository :
CVS Web Repository was found on this webpage. The CVS directory is a
special directory. CVS/Entries lists files and subdirectories registered into the
server. CVS/Repository contains the path to the corresponding directory in
the repository. CVS/Root contains the path to the repository.
Impact:
These files may expose sensitive information that may help an malicious user
to prepare more advanced attacks.
Proof of Concept
http://api. xxxxxxxxx.com/psms/CVS/Root
http://api. xxxxxxxxx.com/psms/customer/CVS/Root
Data Found:
1.: :pserver:[email protected]:/releases 2. :pserver:[email protected]:/cvs
Prevention:
Remove the file from production systems.
10. CVS Web Repository :
XML supports a facility known as "external entities", which instruct an XML
processor to retrieve and perform an inline include of XML located at a
particular URI. An external XML entity can be used to append or modify the
document type declaration (DTD) associated with an XML document. An
external XML entity can also be used to include XML within the content of
an XML document.
Now assume that the XML processor parses data originating from a source
under attacker control. Most of the time the processor will not be
validating, but it MAY include the replacement text thus initiating an
unexpected file open operation, or HTTP transfer, or whatever system ids
the XML processor knows how to access.
below is a sample XML document that will use this functionality to include
the contents of a local file (/etc/passwd)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE acunetix [
<!ENTITY acunetixent SYSTEM "file:///etc/passwd">
]>
<xxx>&acunetixent;</xxx>
Impact:
Attacks can include disclosing local files, which may contain sensitive data
such as passwords or private user data, using file: schemes or relative
paths in the system identifier. Since the attack occurs relative to the
application processing the XML document, an attacker may use this trusted
application to pivot to other internal systems, possibly disclosing other
internal content via http(s) requests.
Proof of concept:
URL encoded POST input data was set to <?xml version="1.0"
encoding="utf-8"?> <!DOCTYPE roottag PUBLIC "-//VSR//PENTEST//EN"
"http://hitWC91ccmRpy.bxss.me/"> <roottag>not an entity
attack!</roottag>
An HTTP request was initiated for the domain hitWC91ccmRpy.bxss.me
which indicates that this script is vulnerable to XXE injection.
HTTP request details:
IP address: 23.212.70.59
User agent: Java/1.6.0_34
Prevention:
If possible it's recommended to disable parsing of XML external entities.
Conclusion:
These failures would have had a dramatic effect on Avenging Security Pvt Ltd
operations if malicious party had exploited them. Experience has shown that a
focused effort to address the problems outlined in this report can result in
dramatic security improvements. Most of the identified problems do not
require high-tech solutions, just knowledge of and commitment to good
practices. For systems to remain secure, however, security posture must be
evaluated and improved continuously. Establishing the organizational
structure that will support these ongoing improvements is essential in order
to maintain control of corporate information systems. We conclude that the
overall security needs to improve. We hope that the issues cited in this report
will be addressed.
Top Related