Virtual Scripted Attacker (VSA) Datasheet

Client-Side Vulnerability Scanning, Detection

US Patent Application Serial No. 13/545,890

Technical Overview

Dynamic Web Application Security Testing for Web Browsers is an emerging technology that will become a fundamental component of Web Application Security Testing Suites in 2013. Our technology automates the process of identifying Web Browser Exploits at runtime interacting with Web Applications, identifying the optimal payload(s) to trigger an attack.

Current Black-Box Security Scanners mostly target common points of injection contrasted with our technology that is an In-Bowser, DOM-based Scanner utilizing a DOM Inspection Script to analyze element modification(s).

The Virtual Scripted Attacker (VSA) consists of four distinct components, three of which are deployed in an actual browser to provide the desired functionality to test for XSS (Cross Site Scripting). VSA employs an instrumented Mozilla Firefox browser that is remotely controlled with a Selenium Web Driver implementation, running on a Linux Command Line Interface (CLI), utilizing a virtual display driver enabling VSA to run in multiple client environments.

Scans are integrated into existing Continuous Integration (CI) processes to ensure website quality and security. External tools can remotely control VSA and communicate with a JavaScript Object Notation (JSON) API or directly with the logger database connected to the VSA crawler and scanner engines.

VSA Business Logic

  1. HTTP Crawler & Google Module VSA utilizes a classic HTTP as well as a Google Crawler Module. These crawlers are used to spot and log URLs related to a scanned domain. The spotted URLs will be logged to a database. Note that the combination of HTTP and Google-based crawler is unique and allows VSA to identify more potentially vulnerable URLs and resources than other crawler tool.

  1. DOM Crawler The DOM crawler adds yet another layer of visibility for VSA. While the list of URLs found by HTTP and Google-based crawler is extended during the ongoing crawling process, the DOM crawler causes the instrumented Firefox browser to visit the stored URLs and scan the DOM for even more data sources. This way VSA can also spot requests caused by JavaScript actions and Ajax requests.

  1. XHR Scanner The XHR Scanner works similarly to a classic HTTP scanner, but utilizes the XMLHttpRequest Object (XHR). VSA forces all used URLs to be available for Cross-Origin Resource Sharing (CORS), so the XHR scanner can reach and analyze URLs that would otherwise not be available. The scanning process involves a vector-prefix rotation system allowing combining common XSS test vectors with a set of prex-strings to increase the chance of actually triggering vulnerability. A JavaScript system injected into the scanned website ensures that no false positives will be reported.

  1. DOM Scanner The DOM Scanner provides a maliciously prepared DOM, setting all possible sinks for DOMXSS injections to a value allowing clear determination of vulnerabilities. The website is then loaded into this prepared DOM and in case one of the sinks is being activated and code is being executed, vulnerability will be logged. Note that instrumenting a browser allows VSA to log the exact line of code where the vulnerability exists. This enables VSA to automatically feed auto-fix or JSA to patch vulnerabilities after they have been discovered and confirmed.

VSA User Agent Emulation

VSA is currently featuring Mozilla Firefox as the only instrumented user agent. Future development will instrument Internet Explorer, Chrome, Safari and Webkit as well. The system backend is developed in the Python scripting language and MySQL database.

Benefits

Using VSA in a corporate environment yields several benefits for customers and the users of the scanned and guarded websites:

  1. VSA is an automated Dynamic Application Security Testing (DAST) technology designed to detect DOMXSS conditions and confirm security vulnerabilities in web applications during running states.
  2. VSA automatically tests the exposed interfaces of Web-enabled applications using protocols and formats, such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), Extensible Markup Language (XML) and JavaScript Object Notation (JSON). Validating POST-Forms is no problem for VSA based on a value-prediction algorithm.
  3. VSA utilizes experience and knowledge of human pen testers by instrumenting an actual browser, triggering actual DOM events & transactions (clicks, mouseover etc.). While classic scanners work with many HTTP requests and attack-permutations, VSA searches for a vulnerability as a human penetration tester would do
  4. VSA doesn’t “torture” a tested web application, keeps the load-level low by using smart-caching. Why request the whole page over and over again if the DOM scanner can analyze it right in the browser cache?
  5. VSA scales. It works straight from the console and doesn’t require special hardware - or custom compiled kernels. We run VSA for a standard Ubuntu 12 server. The more CPUs VSA gets, the faster it will scan. 100,000 URLs and more are not a problem.

Comparison Chart

To test how VSA performs compared to other commercial and open-source scanner software, a vulnerability-test-course was set up. Note that these vulnerabilities reflect actual website security problems we spotted over the past several years during manual penetration tests and audits.

VSA

SkipFish

‘Snitch

IE-only DOMXSS via document.URL

Yes

No

No

jQuery DOMXSS via location.hash

Yes

No

No

DOMXSS via document.cookie, eval-call on index "dispMonth"

Yes

No

No

XML XSS via GET "mode" inside CDATA/comment

Yes

Yes

Yes

DOM redirect XSS via document.referrer and hidden index

Yes

Yes

Yes

DOMXSS via document.write() and GET parameter "fw" (exposed on other URL)

Yes

No

No

POST XSS via param “city” & “username” when form validates

Yes

Yes

Yes

XSS inside filtered JS string via REQUEST_URI

Yes

Yes

Yes

XSS inside filtered href attribute via GET "locale"

Yes

Yes

Yes

XSS inside filtered href via GET "locale" (variation, different filter)

Yes

No

No

XSS inside filtered href attribute via GET "url"

Yes

Yes

Yes

DOMXSS via document.write() on location.href index "default"

Yes

No

No

Timed DOMXSS via document.referrer, index "sid"

Yes

No

No

DOMXSS via #search-text DOM element value and innerHTML mapping

Yes

No

No

Script XSS via SERVER_URI - reflected inside a JS string

Yes

No

No

Gecko-only Data-URI XSS via partly valid POST email and username + self-redirect

Yes

No

No

XSS inside HTML comment via SERVER_URI

Yes

Yes

Yes

DOMXSS via document.write() on location.search

Yes

Yes

Yes

As can be seen, the classic yet most advanced publicly available XSS scanners have no trouble finding the server-side XSS vulnerabilities. VSA nevertheless manages to spot and confirm server- and client-side XSS problems.

Autofix Feature (Alpha Stadium)

The currently designed Autofix feature will allow VSA to contribute not only to per-user defense and offensive vulnerability testing, but also to a page-specific fix generation allowing website administrators to employ an automated security and quality assurance system. VSA and JSAgent are both capable of logging attacks relating to a resource to a database table. A website using Autofix can now use this database to find out, whether a user is currently visiting one of the potentially affected URLs on that very website. If this is the case, identification happens via hash comparison and the aforementioned page-uniqueness algorithm  Autofix can generate an x and deploy it via JavaScript. Autofix can handle and automatically prevent classic XSS vulnerabilities, injected drive-by-download attacks and DOMXSS attacks. The user experience is not being affected by the minor protective changes Autofix is performing, since only very specific internal browser and DOM properties would be affected by the fix. Autofix will make use of a slim yet significantly important dataset delivered by VSA:

  1. Vulnerable Property Knowing the DOM Property that causes a vulnerability allows Autofix to freeze the affected object and give it protection. Additionally, the object can be set to monitoring mode allowing a website to determine, whether actual attacks are happening and which IP addresses are affected. This significantly eases forensics  which are especially in case of DOMXSS attacks almost impossible to handle for unprepared websites.

  1. Successful Attack Vector(s) Knowing the successful attack vector VSA spotted during scanning allows Autofix to be as precise as possible regarding the necessary filter and fix to be deployed. It further avoids impact on the use experience, since only specific characters and attack vectors need to be ltered. In case VSA is used in a Continuous Integration scenario, Autofix can use the frequently changing data to scale with potentially novel attack vectors and regularly update the code used to fix the vulnerability.

  1. Exact Line of vulnerable Code Knowing the exact line of code where the vulnerability occurs allows Autofix to not only fix the vulnerability, but also to send out a very precise report to the website administrator allowing immediate check if the fix has been applied properly. In complex web applications such as GMail or Google Maps, a small code change might interfere with the user experience despite greatest care. To avoid the improbable, Autofix will notify the website administrator about every employed fix and suggest a manual review before the fix is either left as is or superseded by an actual fix in the website code. Either way, the priority of delivering security without harming user experience is preserved.

CloudScan Application Management Portal (AMP)

AMP enables staff to create and schedule tasks running on vulnerability detection and network administration tools. AMP manages the dispatch and processing the job results, delivering Proof of Concept execution and Defect Reports into existing log management and product life-cycle management tools. AMP enables enterprises to reduce administration and compliance costs by:

  1. consolidating and automating tool management
  2. freeing senior technical experts from routine tasks
  3. using existing enterprise tools
  4. linking vulnerability detection with product life-cycle management tools

Tool Automation Features

  1. Management of vulnerability discovery tools such as Virtual Scripted Attacker, and Hoyt’s Proxy’Mun and interfaces to CoTS & OS Exploit Tools & Frameworks such as MetaSploit, Canvas, PWNPlug, XSSRIA, SQLSlammer, DOM_KRAKrz and other tools
  2. Unified management via network management and monitoring tools
  1. SNMP, WMI, RADIUS, LDAP, Perl Proxy, SQL, REST, API, CLI and others
  1. Wizard style task creation and scheduling for Point-and-Shoot Exploitation
  2. Customized Attack Platform managed by GreenHat Bug Hunters

Reporting Features

  1. CVSS for standards-based prioritization
  2. 3rd Party Providers – Ads, CDN’s, JS Providers, Analytics and more
  3. Task results transformed into wide range of report formats including: html, pdf, xml, delimited text, SQL, CSV and more
  4. Results formatted for inclusion in common log management and Big Data Mining tools
  5. Issues identified and transformed for automated consumption by other product life-cycle management tools including: JIRA, Bugzilla
  6. Administrative reports including change-logs and resource consumption
  1. Typical Access, Authorization and Accounting model

Work Requests

  1. One-click process for submitting a discovered issue to internal or external operations center for escalated support
  2. Work requests integrate with existing billing systems

User Experience

  1. Engaging and accessible user environments enabling junior and non-technical users
  2. REST-API supports wide range clients including web browsers, iOS and Android mobile devices, Silverlight rich desktop

Big Data Mining

  1. Search and correlate results aggregated from all implemented tools
  2. Discover new vulnerability patterns

Enterprise Integration

  1. Integrates with existing access-controls via Radius
  2. Provides fine-grained role-based access-control configuration
  3. Business logic will run in existing Java application containers
  4. Support for wide range of database systems including: Oracle, DB2, MSSQL, PostgreSQL, MySQL
  5. Support for wide range of proxying HTTP servers including: IIS, Apache, Nginx and Hoyt’s Proxy’Mun
  6. Track usage in existing billing systems and remediation systems (JIRA)

Deployment Options

AMP's modular design enables a wide range of deployment scenarios from wholly outsourced to internal black-box appliance available for immediate deployment.

  1. Outsourced Cloud: HTI will host and maintain your AMP instance while connecting to your enterprise through a private network or the public cloud.

  1. Black-box Appliance: fully configured, rack-mountable appliance loaded with the desired vulnerability detection and network administration tools.

  1. Modular Approach: Any combination of the above deployment options including incorporating existing enterprise resources such as database systems, application server containers, vulnerability detection tools and network administration tools.

  1. Management, Updates and Support included in Click Wrap License Agreement

Pricing

$360/URL/Year

Contact:        CloudScan     xss@xss.cx

Client-Side Vulnerability Scanning, Detection | US Patent Application Serial No. 13/545,890


Cross Site Scripting

Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application's immediate response in an unsafe way.

An attacker can use the vulnerability to construct a request which, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes.

Users can be induced to issue the attacker's crafted request in various ways.

For example, the attacker can send a victim a link containing a malicious URL in an email or instant message. They can submit the link to popular web sites that allow content authoring, for example in blog comments. And they can create an innocuous looking web site which causes anyone viewing it to make arbitrary cross-domain requests to the vulnerable application (using either the GET or the POST method).

The security impact of cross-site scripting vulnerabilities is dependent upon the nature of the vulnerable application, the kinds of data and functionality which it contains, and the other applications which belong to the same domain and organisation.

Cross Site Scripting Reflection Remediation

In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defences:

Input should be validated as strictly as possible on arrival, given the kind of content which it is expected to contain.

For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression.


XSS (Cross-site Scripting) allows an attacker to execute a dynamic script (Javascript, VbScript) in the context of the application. This allows several different attack opportunities, mostly hijacking the current session of the user or changing the look of the page by changing the HTML on the fly to steal the user's credentials. This happens because the input entered by a user has been interpreted as HTML/Javascript/VbScript by the browser.

XSS targets the users of the application instead of the server. Although this is a limitation, since it allows attackers to hijack other users' session, an attacker might attack an administrator to gain full control over the application.

Impact

Permanent XSS is a dangerous issue that has many exploitation vectors, some of which includes:
  • User session sensitive information such as cookies can be stolen.
  • XSS can enable client-side worms which could modify, delete or steal other users' data within the application.
  • The website can be redirected to a new location, defaced or used as a phishing site.

Remedy

The issue occurs because the browser interprets the input as active HTML, Javascript or VbScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically the output location is HTML. Where the output is HTML ensure that all active content is removed prior to its presentation to the server.

Prior to sanitizing user input, ensure you have a pre-defined list of both expected and acceptable characters with which you populate a white-list. This list needs only be defined once and should be used to sanitize and validate all subsequent input.

There are a number of pre-defined, well structured white-list libraries available for many different environments, good examples of these include, OWASP Reform and Microsoft Anti Cross-site Scripting libraries are good examples.

Remedy References

External References


XML Injection

Certain parameters are vulnerable to XML external entity injection. The tag ]> was injected into the XML sent to the server. This tag defines an external entity, xxe31071, which references a file on the XML parser's filesystem.

This entity was then used within a data field in the XML document. The server's response contains the contents of the specified file, indicating that the parser processed the injected external entity.

XML external entity injection vulnerabilities arise because the XML specification allows XML documents to define entities which reference resources external to the document. XML parsers typically support this feature by default, even though it is rarely required by applications during normal usage. External entities can reference files on the parser's filesystem; exploiting this feature may allow retrieval of arbitrary files, or denial of service by causing the server to read from a file such as /dev/random. They can also reference URLs; exploiting this feature may allow port scanning from the XML parser's host, or the retrieval of sensitive web content.

XML Injection Remediation

XML external entity injection makes use of the DOCTYPE tag to define the injected entity.

XML parsers can usually be configured to disable support for this tag.

You should consult the documentation for your XML parsing library to determine how to disable this feature.

It may also be possible to use input validation to block input containing a DOCTYPE tag.


Operating System Command Injection

Operating system command injection vulnerabilities arise when an application incorporates user-controllable data into a command that is processed by a shell command interpreter.

If the user data is not strictly validated, an attacker can use shell metacharacters to modify the command to be executed, and inject arbitrary further commands that will be executed by the server.

OS command injection vulnerabilities are usually very serious and may lead to compromise of the server hosting the application, or of the application's own data and functionality. The exact potential for exploitation may depend upon the security context in which the command is executed, and the privileges which this context has regarding sensitive resources on the server.

OS Command Injection Remediation

If possible, applications should avoid incorporating user-controllable data into operating system commands.

In almost every situation, there are safer alternative methods of performing server-level tasks, which cannot be manipulated to perform additional commands than the one intended.

If it is considered unavoidable to incorporate user-supplied data into operating system commands, the following two layers of defence should be used to prevent attacks: The user data should be strictly validated. Ideally, a whitelist of specific accepted values should be used.

Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable shell metacharacter or whitespace, should be rejected.

The application should use command APIs that launch a specific process via its name and command-line parameters, rather than passing a command string to a shell interpreter that supports command chaining and redirection. For example, the Java API Runtime.exec and the ASP.NET API Process.Start do not support shell metacharacters. This defence can mitigate the impact of an attack even in the event that an attacker circumvents the input validation defences.


LDAP Injection

LDAP injection arises when user-controllable data is copied in an unsafe way into an LDAP query that is performed by the application.

If an attacker can inject LDAP metacharacters into the query, then they can interfere with the query's logic. Depending on the function for which the query is used, the attacker may be able to retrieve sensitive data to which they are not authorised, or subvert the application's logic to perform some unauthorised action.

Note that automated difference-based tests for LDAP injection flaws can often be unreliable and are prone to false positive results. You should manually review the reported requests and responses to confirm whether a vulnerability is actually present.

LDAP Injection Remediation

If possible, applications should avoid copying user-controllable data into LDAP queries.

If this is unavoidable, then the data should be strictly validated to prevent LDAP injection attacks.

If it is considered unavoidable to incorporate user-supplied data into operating system commands, the following two layers of defence should be used to prevent attacks: The user data should be strictly validated. Ideally, a whitelist of specific accepted values should be used.

Otherwise, only short alphanumeric strings should be accepted. Input containing any other data, including any conceivable shell metacharacter or whitespace, should be rejected.

In most situations, it will be appropriate to allow only short alphanumeric strings to be copied into queries, and any other input should be rejected.

At a minimum, input containing any LDAP metacharacters should be rejected; characters that should be blocked include ( ) ; , * | & = and whitespace.


SQL Injection

SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner.


An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.

Various attacks can be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and executing operating system commands.

Attack Possibilities... Blind SQL Injection Attack | Boolean SQL Injection | Command Injection | HTTP Header Injection | Local File Inclusion | Open Redirection | Remote Code Evaluation | Remote File Inclusion | SQL Injection | Cross-site Scripting | Total Attack Possibilities = UNLIMITED

Impact

Depending on the backend database, database connection settings and the operating system, an attacker can mount one or more of the following type of attacks successfully:
  • Reading, Updating and Deleting arbitrary data from the database
  • Executing commands on the underlying operating system
  • Reading, Updating and Deleting arbitrary tables from the database

Actions to Take

  1. See the remedy for solution.
  2. If you are not using a database access layer (DAL) within the architecture consider its benefits and implement if appropriate. As a minimum the use of s DAL will help centralize the issue and its resolution. You can also use an ORM (object relational mapping). Most ORM systems use parameterized queries and this can solve many if not all SQL Injection based problems.
  3. Locate all of the dynamically generated SQL queries and convert them to parameterised queries. (If you decide to use a DAL/ORM, change all legacy code to use these new libraries)
  4. Monitor and review weblogs and application logs in order to uncover active or previous exploitation attempts.

Remedy

A very robust method for mitigating the threat of SQL Injection based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built in libraries for this. Wherever possible do not create dynamic SQL queries or SQL queries with string concatenation.

Required Skills for Successful Exploitation

There are numerous freely available tools to test for SQL Injection vulnerabilities. This is a complex area with many dependencies, however it should be noted that the numerous resources available in this area have raised both attacker awareness of the issues and their ability to discover and leverage them. SQL Injection is one of the most common web application vulnerabilities.

External References

Remedy References


What's the Risk?



CloudScan Navigation Map

What is your CVSS Number?