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:techops@192.168.1.252:/releases 2. :pserver:ritesh.seth@192.168.1.14:/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.