PCI ASV Scans - Risk Ratings

PCI Scanning stands for 'Payment Card Industry' scanning. As per the standard guidelines It involves having a PCI ASV (Approved Scanning Vendor) perform a vulnerability scan on all vendor IP addresses/devices etc which store, process or transmit credit card data, the scan aims to identify both network and web application vulnerabilities like XSS and SQL, there is lot of guidelines and process involved here as per PCI guidelines, we are not going to discuss that currently.

We are going to discuss how we are going to calculate and rate the risks identified during the scans.

Risk Ratings:

In PCI ASV reports risk for vulnerabilities identified during the ASV scans are calculated based on the CVSS Score. CVSS stands for common vulnerability scoring system which is the scoring standard adopted and well accepted throughout the security domain for calculating the security risk.

More information on CVSS and how to calculate the CVSS scores can be found at:

Refer:
http://www.first.org/cvss/cvss-guide
http://nvd.nist.gov/cvss.cfm?calculator

The basic thumb rule for calculating the risk is
If CVSS score is > = 4.0 then that particular vulnerability will result in non-compliance to PCI, the affected device/IP will be considered as FAIL and CVSS <=3.9 will result in vulnerability as compliant to PCI.

Useful Tips and Suggestion:

1. Most of the vulnerability scanning tools provide CVSS score with vulnerabilities, sometimes few scanners may provide false or inaccurate CVSS scores hence the scores must be reviewed and validated before finalizing the risk.

2. CVSS score if not present for vulnerability, should be calculated manually using the CVSS calculator and appropriate risk should be finalized.

3. Right parameter should be used while calculating the risk, wrong parameters may result in wrong score and wrong compliance status.

4. If to reduce the risk, vendor has a compensatory control for vulnerability then new CVSS score should be calculated considering the compensatory control and risk should be rated accordingly.

5. As per PCI ASV DOS vulnerabilities will be rated as per below rule.

In case of denial-of-service vulnerabilities, where the vulnerability has both a CVSS Confidentiality Impact=none and a CVSS Integrity Impact=none, the vulnerability must be marked as pass and must be rated as low risk.

GWT Penetration Testing

Penetration Testing GWT Application:

One of my recent engagements I have got an opportunity to work on Black box application testing which uses Google’s Web Tool Kit. Initially it was difficult to test as the technology was new and all the parameters were obfuscated, but as we went deeper lot of authorization and other security flaws were unfolded.

Google Web Tool Kit:

A) Boot Strap Loading ->cache/no cache Files

GWT requires no plug-in and has less cross browser headaches. Typically when ever application loads every application has a process called as bootstrap process which is kicked off and initiates application initiation process, where process likes browser detection takes place and appropriate compatible java scripts files are created which are supported by the browser., this is done by files called as gwt.js and .nocache.js where deferred binding occurs which acts as boot strap process and loads appropriate configurations , modules and browser specific classes .

{HEX}.cache.html is browser specific files and it consists of application logic which are generated post authentication. They are named according to the MD5 sum of their contents and consist of RPC methods, other restricted methods and sensitive information.

Sample Cache files looks like:
https://www.xyz.com/testapp/9E871855826913D91F95F8F65F4ED9E3.cache.html https://www.xyz.com/testapp/C2C2D9E9AB0BBFD8B66FD43702FAF3B5.cache.html

Security Issue:
HEX}.cache.html are generated post authentication, the file should be restricted and should not be accessible pre-authentication , if accessible this file can disclose sensitive information.

B) Obfuscated Client Side Code :
Google obfuscates code to save space. In GWT all the client side code is downloaded to browser and consists of RPC methods, other restricted methods and sensitive information. These are often obfuscated by GWT and are hidden.

degwt is a utility that de-obfuscates GWT generated java script code and one such example is present at
http://code.google.com/p/degwt/

Sometimes RPC methods can be enumerated and there are enumeration tools which can be used to enumerate these methods Refer the below link, this may or may not be successful all the time

http://blog.gdssecurity.com/labs/2010/7/20/gwtenum-enumerating-gwt-rpc-method-calls.html

Security Issue:

1. If code can be de-obfuscated using tools like degwt can disclose sensitive information to the user.

2. If RPC method enumerated using gwtenum can disclose sensitive RPC information

C) Authorization:

Authorization testing is much easier when all application functionality is available, this is most common flaw in the GWT application, and most of the time authorization controls are not implemented in GWT applications and in the application, most common authorization check are applicable here .

Security Issues:

1. Low level user can perform unauthorized execute by just replaying the request for recorded from the high level user

2. Low level user can read files available to higher level user by just manipulating the parameters.

D) Cross Site Scripting/CSRF:

Most classis script attacks can work here as GWT is not immune to XSS/CSRF, if the JavaScript is not properly coded it’s always vulnerable to XSS/CSRF.

Security Issues:
Perform a through XSS manual and automated testing to identify any XSS Issues.

E) Other Web Vulnerabilities:
Note that GWT RPC services are vulnerable to the same typical vulnerabilities as typical web apps.

Ex. SQL Injection, XFS, Parameter Tampering etc.

References:
http://blog.gdssecurity.com
http://code.google.com/webtoolkit