Product Lifecycle Management Blogs by SAP
Dive into product lifecycle management news, learn about digitalizing PLM for the digital supply chain, and stay informed with product updates from SAP.
Showing results for 
Search instead for 
Did you mean: 
Former Member

In March 2013, a paper "VERA: A Flexible Model-Based Vulnerability Testing Tool" co-authored by SAP researcher is published in The 6th IEEE International Conference on Software Testing, Verification and Validation (ICST 2013) in Luxembourg.

Usually, in order to state what is meant by the “security” of a system, one defines high-level security requirements, determined by the assets that one wants to protect. The goals are integrity, confidentiality and availability of the resources associated with those assets. The requirements are enforced via mechanisms that provide authentication, authorization, secure channels, etc. As a consequence, secondary goals appear, for instance “only authorized people have access to a certain interface, a directory, or to a certain cookie”. Goals break down into mechanisms plus new more lowerlevel requirements. At the end one may have a goal of the type: “the system must not have cross-site scripting (XSS) vulnerabilities” (shorthand for: the system should not react in a particular way to a particular input), because violating this goal might result in a violation of the higher level security requirements (such as confidentiality or integrity breaches).

In many cases it is not always necessary to find a fullblown attack, but it is enough to find low-level vulnerabilities. This is among others justified by the cost/benefit relation of vulnerability testing: usually the presence of a vulnerability is a pre-requisite to deploy an attack, but to actually exploit a vulnerability is a time-consuming task (if at all possible). Consider the following example: A tester finds that when giving some inputs to a web application, a malformed SQL statement error is reported. This could mean that there is a way to craft the input with malicious SQL Injections, but to find the exact form in which these injections are successful is in general not trivial, in particular if the source code is unknown (as in black-box testing). Preventively fixing the application to eliminate the unwanted behaviour (SQL error) offers a reasonable compromise between security and the testing effort.

Thus, security testing often concentrates on vulnerability testing. As of today, there exist an abundant number of tools for aiding developers and penetration testers to spot common software security vulnerabilities. However, testers are often confronted with situations where existing tools are of little help because a) they do not account for a particular configuration of the SUT or b) they do not include tests for certain vulnerabilities. For instance, the SUT could use a particular authentication mechanism (such as a proprietary protocol) and a recent/rare database version. It is likely that most available tools will not cover the authentication mechanism and might not have information about known vulnerabilities of the database model used by the SUT.

In this situations the tester would benefit from extension mechanisms to the available tools. Some tools (like the nonfree version of Burp and w3af) allow to write such

extension plug-ins. These plug-ins must be written in the programming language of the tool and imply the learning curve of the tool’s API. The alternative consists in directly writing scripts for the task in hand.

In this paper we propose a tool named VERA, standing for “VERA Executes the Right Attacks”, which allows testers to define attacker models by means of extended finite state machines (EFSM). In this way, testers can define new tests where the payloads and the behavior are cleanly separated and that abstract away from low-level implementation details such as HTTP requests.

Although so far we explored primarily vulnerabilities in web applications, our approach is general enough to be applied in other contexts. There are many directions in which our work could be extended. On the one hand it would be interesting to explore a notion of composition in which multiple attacker models are combined to reach a certain goal. On the other hand, it would be interesting to be able to classify and prioritize tests according to the expected skill level of attackers and the expected impact of vulnerabilities. Currently, preliminary validation steps are being made within Siemens and SAP in order to evaluate the benefits of our approach. Those efforts include

using the tool in real-life penetration testing activities.

This paper is a joint work of Abian Blome and Martın Ochoa of Siemens, Germany, Keqin Li of SAP Product Security Research, France, Michele Peroli of University of Verona, Italy, and Mohammad Torabi Dashti of ETH, Switzerland.