Davide Caputo

Luca Verderame

Simone Aonzo

Alessio Merlo

Droids in Disarray: Detecting Frame Confusion in Hybrid Android Apps

Keywords: Frame Confusion, Android Security, Static Analysis, Dynamic Analysis 2

Frame Confusion is a vulnerability affecting hybrid applications which allows circumventing the isolation granted by the Same-Origin Policy. The detection of such vulnerability is still carried out manually by application developers, but the process is error-prone and often underestimated. In this paper, we propose a sound and complete methodology to detect the Frame Confusion on Android as well as a publicly-released tool (i.e., FCDroid) which implements such methodology and allows to detect the Frame Confusion in hybrid applications, automatically. We also discuss an empirical assessment carried out on a set of 50K applications using FCDroid, which revealed that a lot of hybrid applications suffer from Frame Confusion. Finally, we show how to exploit Frame Confusion on a news application to steal the user's credentials.

Introduction

Nowadays, the landscape of mobile devices is mostly divided between Android and iOS, with a market share of 74% and 23%, respectively 1 . From a technical standpoint, Android and iOS have remarkable differences both in terms of OS architecture and Software Development Kit (SDK). Such heterogeneity negatively impacts the application (hereafter, app) development process, as companies must rely on different developer teams (be them internal or outsourced) for each platform, thereby increasing the costs of both app development and maintenance. A promising way to overcome the limitation posed by such multi-platform development process is a cross-platform framework, which allows to implement an app using a unique programming language and automatically generate a corresponding Android and iOS version. Cross-platform frameworks based on web technologies (i.e., HTML, CSS, and JavaScript), like Cordova [START_REF] Cordova | [END_REF] or PhoneGap [26], allow for the development of the so-called hybrid applications, which combine elements of both native (i.e., OS-specific) and web apps. Hybrid apps allow developers to write code based on platform-neutral web technologies and wrap them into a single native app that can render HTML/CSS content and execute JavaScript -like a standard web browser -through a component called WebView on Android, and WKWebView in iOS. Such component acts as a bridge between the web (i.e., the JavaScript code) and the native world (i.e., the Java or Swift code) through the definition of ad-hoc interfaces. Such interfaces (called JavaScriptInterfaces in Android or WKScriptMessageHandlers in iOS) allow the developer to define a set of function calls that can be mutually invoked by the two worlds using asynchronous callbacks. As a result, they grant access to the complete set of OS functionality to hybrid apps, thereby making them equivalent to native apps. However, from a security standpoint, the interaction between the native and the web worlds -which rely on different security models and requirements -can expose hybrid apps to ad-hoc and complex vulnerabilities, like those described in [START_REF] Hu | A Tale of Two Cities : How WebView Induces Bugs to Android Applications[END_REF]22,[START_REF] Neugschwandtner | A View to a Kill: WebView Exploitation[END_REF][START_REF] Chin | Bifocals: Analyzing WebView Vulnerabilities in Android Applications[END_REF][START_REF] Li | Unleashing the Walking Dead : Understanding Cross-App Remote Infections on Mobile WebViews[END_REF]. Among them, the Frame Confusion vulnerability [22] in hybrid apps has been discovered some years ago and it has been fixed on iOS 2 but not on Android (neither in the latest version, i.e., Android Pie 9.0). To this regard, we argue that a lot of hybrid apps still suffer from such vulnerability and that there is still a lack of i) an extensive analysis of Frame Confusion, ii) a methodology to automatically detect Frame Confusion in hybrid apps, and iii) a reliable solution to mitigate the problem. Frame Confusion is basically due to the ability of JavaScript code to invoke Android native code through web pages containing at least an Iframe element. Such element allows loading external contents (e.g., advertisements, video and payment systems) from domains which differ from the domain of the hybrid app. For this reason, any Iframe is in charge of containerizing the rendered sub-page, and should execute content only within the scope of its own domain, as prescribed by the Same-Origin Policy (SOP). However, in case of web pages with multiple Iframes, the WebView is unable to identify the Iframe that invokes a function in the native code, and thus the result of the invocation is always executed in the main app page, thereby inducing the confusion problem. Such misbehavior occurs as the JavaScriptInterface is bound by the OS to the entire WebView element, without any distinction among the domains (and thus the Iframes) that invoke the function calls. Therefore, the Frame Confusion vulnerability allows to bypass the isolation granted by the Iframe security model and to build a communication channel between web pages belonging to different domains, (i.e., the main app page and the inner Iframes). As a consequence, such vulnerability can affect the confidentiality and the integrity of hybrid apps: a malicious Iframe can, for instance, force the main app to expose private information (like session cookies or internal app files) or mount sophisticated phishing attacks.

Contribution of the paper. In this work, we focus on the Frame Confusion vulnerability on Android. Therefore, hereafter we refer specifically to the Android OS. Our contribution is three-fold. First, we propose a methodology for systematically detecting the Frame Confusion vulnerability in hybrid apps on Android. Then, we present FCDroid, a tool that implements such methodology to automatically identify hybrid apps on Android that suffer from the Frame Confusion vulnerability. FCDroid combines static and dynamic analysis techniques in order to reduce false positive and false negative rates. Finally, we discuss the results of an extensive analysis carried out through FCDroid on a set of 50, 000 apps downloaded from the Google Play Store. The experimental results indicate that the 49.35% of the analyzed apps are hybrid, as they use the WebView component and enable JavaScript execution, while about 6.63% of them (i.e., 1637 apps) were found to be vulnerable to Frame Confusion for a total of more than 250.000.000 app installations worldwide. To further validate the proposed methodology, we have manually analyzed some of these vulnerable apps to find out possible attacks exploiting the Frame Confusion vulnerability. To this regard, we were able to exploit Frame Confusion in an Asian news application that has more than 1M users worldwide; such attack allows to steal the user's credential of the primary social media website.

Organization of the paper. The rest of the paper is organized as follows: Section 2 introduces some technical background on hybrid apps and the Frame Confusion, while Section 3 discusses the detection methodology. Section 4 presents FCDroid, while Section 5 shows the experimental results. Section 6 discusses the exploitation of the Frame Confusion on an actual news app, and Section 7 presents some related work. Finally, Section 8 concludes the paper.

Technical Background

Landscape of Mobile Apps. Mobile apps can be divided into three categories, namely, i) native, ii) web, and iii) hybrid apps. Native apps are binary, platform-specific files which are installed on the device and execute by interacting with a set of API calls exposed by the mobile OS. As a consequence, they must be developed in the OS-specific language (i.e., Java/Kotlin for Android and Objective-C/Swift for iOS), and they have full and direct access to the OS API. On one hand, native apps exhibit the best performance for CPU-intensive workloads, while, on the other hand, they need to be re-implemented to execute on a different mobile OS. As this is a daunting task mostly for small-medium enterprises, there is a growing trend towards web or hybrid apps. Web apps render HTML5 and execute Javascript code within the device browser (which is a native app). For this reason, they are highly portable and platform-independent, but the interaction with the underlying OS is limited to the API accessible by the browser itself. Consequently, they have restricted functionalities and, in general, limited performance. Hybrid apps have been proposed to overcome the limitations of both native and web apps, namely granting i) portability over platforms, ii) access to the whole OS API and, iii) reasonable performance. Hybrid apps are programmed once in cross-platform web technologies (i.e., HTML, CSS, and JavaScript) as web apps, and then wrapped into a platform-specific native container, i.e., the WebView. The WebView may also allow the interaction between the web and the native part, acting like a bridge between the web code and the host OS API, thereby allowing to render HTML/CSS content, execute JavaScript code, and get access to the full OS API.

WebView. The WebView is an Android app component which embeds a mini-browser for rendering HTML/web pages and execute JavaScript code in mobile apps. The WebView allows defining ad-hoc interfaces, called JavascriptInterfaces, that enable to invoke Java methods from the JavaScript code. This feature allows crossplatform frameworks (e.g., Cordova, PhoneGap) to design a set of plugins that can be embedded in apps and offer platform-specific functionality, such as the API for the filesystem or the GPS location. To enable JavaScript interfaces, the developer needs to bind a set of Java methods to a WebView component using the addJavascriptInterface method. The communication between the JavaScript and the Java code is handled by the WebView using asynchronous callbacks. In detail, when some JavaScript code invokes Java code through an interface bounded to the WebView, it does not wait for the result: instead, when the result is ready, the Java code outside the WebView invokes a JavaScript callback function, passing the result back to the web page. This mechanism provides improved app performance and responsiveness, particularly in the case of long-running operations that would block the UI.

WebView Security Mechanisms. As the WebView deals with web content that can include untrusted HTML and JavaScript code, it can suffer from well-known web security vulnerabilities such as cross-site scripting [START_REF] Bhavani | Cross-Site Scripting attacks on Android webView[END_REF][START_REF] Jin | Code Injection Attacks on HTML5based Mobile Apps[END_REF][START_REF] Bao | Cross-site Scripting Attacks on Android Hybrid Applications[END_REF] or file-based cross-zone scripting [START_REF] Chin | Bifocals: Analyzing WebView Vulnerabilities in Android Applications[END_REF]. As countermeasures, the Android OS includes a set of mechanisms aimed at limiting the capability of the WebView to the minimum functionality required by hybrid apps. By default, the WebView does not execute JavaScript, thus requiring developers to enable this feature using the setJavascriptEnabled method. Besides, the application can either enable or disable the access of the WebView to specific resources like files, databases or geolocation [30] through the WebSettings object. Since API 17, the Java methods -which are exposed through a JavaScript interfaceneed to be explicitly annotated with the @JavascriptInterface [16]. The aim is to restrict the access to the OS API, in order to prevent the invocation of any public Java method through code reflection [START_REF]The Lifetime of Android API Vulnerabilities: Case Study on the JavaScript-to-Java Interface[END_REF]. To further increase the resilience of the WebView component against untrusted contents, since API level 21 the Android OS implements the WebView as an independent app, thus offering a centralized update mechanism that relieves the developer from the burden of manually updating each hybrid app [START_REF]WebView[END_REF]. Moreover, since API Level 26 the WebView renderer executes in a separate process [33]. Finally, since Android 8, the WebView incorporates Google's Safe Browsing protections to detect and warn users about potentially dangerous websites. Unfortunately, this option needs to be explicitly enabled by the developer through a specific tag in the Android Manifest [32].

Frame Confusion

Frame Confusion is a vulnerability affecting hybrid apps that allows malicious interactions among the main web page (hereafter, main frame) and different web domains hosted in inner Iframe elements (hereafter, child frames) through the asynchronous bridge between the Java and the JavaScript code, granted by the WebView. To this aim, the WebView maintains a map that links the WebView instance with a list of function calls in the native code registered to the JavascriptInterface. However, such a map does not include any restriction on web domains (and thus web pages) that can access the attached interfaces. Thus, if the main frame contains multiple child frames, each of them can independently and asynchronously access all the interfaces bound to the WebView component, in order to interact with the Java code. For this reason, the WebView is forced to return the results of each native method invocation to the main frame and not to the actual caller, be it the main frame or a child frame, thereby causing potentially unintended interactions between different frames, i.e., the Frame Confusion. Such interaction between the native and the web worlds allows bypassing the Same Origin Policy (SOP), which -in a standard web browser -completely isolates the contents of the main frame from the child frames, since they belong to different domains.

Attacking and exploiting the Frame Confusion. The Frame Confusion vulnerability can be exploited either by using a compromised child frame or the main frame, as shown in Figure 1 (taken from [22]). In detail, if an attacker is able to compromise a child frame (Fig. 1a), he triggers the invocation of native function calls through the WebView App (step 1), which computes the result (step 2) and sends the callback to the main frame (step 3). For instance, a malicious advertisement campaign -embedded in a child frame -can exploit this attack and affects the main frame, by, e.g., inducing an unwanted phone call or force the sending of an SMS. On the other hand, in case of a compromised main frame (Fig. 1b), the attacker is able to intercept all the callbacks triggered by the child frames, thus leading to possible information leaks. As an example, a benign child frame could inadvertently expose sensitive information like, e.g., the GPS location or the result of a SQL query, to the main frame in control of the attacker, through a native method invocation. The exploitation of the Frame Confusion vulnerability requires the attacker to affect any web domain in the main or a child Iframes that has access to the JavaScript interfaces. This condition is achieved through:

-The direct control of a web page. In such a scenario, the attacker can be able either to take control over an existing web domain or to create an ad-hoc website, e.g., a malicious advertisement campaign. -The injection of malicious code in an existing web page. In this case, the attacker can exploit a weakness in the communication protocol of the hybrid app, e.g., a

clear-text communication or a misconfigured SSL connection, to mount a Man-In-The-Middle attack 3 and inject malicious code in the loaded web pages.

It is worth noticing that the presence of other vulnerabilities in the JavaScript code, e.g., the adoption of JavaScript libraries with known vulnerabilities [START_REF]OWASP: Using components with known vulnerabilities[END_REF] or the presence of XSS vulnerabilities [START_REF] Sedol | Survey of Cross-site Scripting Attack in Android Apps[END_REF][START_REF] Backes | A Local Cross-Site Scripting Attack against Android Phones[END_REF][START_REF] Bao | Cross-site Scripting Attacks on Android Hybrid Applications[END_REF], further boosts the exploiting capabilities of the attacker. the Iframe sandbox attribute [START_REF]w3: Sandbox attribute[END_REF], which enables a set of extra restrictions on any content hosted by an Iframe and, among them, it allows blocking the execution of JavaScript code. Although effective in principle, this mechanism completely prevents the execution of any JavaScript code, thus limiting the functionalities of the web page. the Content Security Policy (CSP) [START_REF]Content Security Policy: Content security policy[END_REF] that allows for the definition of fine-grained restrictions on the execution of JavaScript code, including the possibility to define a set of trusted domains that are able to execute JavaScript, in a white-listing fashion. Although effective against the loading of an undesired web domain, the CSP cannot prevent the injection of the malicious code in a white-listed domain, thereby resulting ineffective against the Frame Confusion.

Mitigations

Furthermore, previous security mechanisms are not enabled by default, thus leaving the burden of their configuration to the developer. All in all, at the current state of the art, none of the existing security mechanisms are able to effectively prevent the Frame Confusion.

A Frame Confusion Detection Methodology

The lack of a solution for preventing the Frame Confusion asks for -at least -a methodology to automatically detect such vulnerability. Unfortunately, at the current state of the art, the only way to detect Frame Confusion is through manual source-code inspection, mostly carried out by app developers. Such activity is error-prone and requires good skills in security analysis by the developing team. Furthermore, the complexity of Frame Confusion leads developers to false positives/negatives or, in the worst case, to underestimate or ignore the problem. To overcome this limitation, we propose a novel methodology for the automatic identification of the Frame Confusion in Android. To achieve such result, we first define a blueprint of the Frame Confusion vulnerability, and then we build an analysis flow that is able to detect it automatically, by exploiting a fruitful combination of static and dynamic analysis techniques.

Vulnerability Blueprint

The design of an automatic and rigorous analysis flow for the Frame Confusion vulnerability demands for the selection of a set of features that enable the vulnerability. To this aim, we argue that a minimal set of such features is the following:

1. the app requires the Internet permission in order to access web domains using a WebView component; 2. the app uses at least a WebView (W) that is configured to execute JavaScript code; 3. W sets at least a JavascriptInterface (JI); 4. JI injects at least a public Java method (m) that can be accessed from the JavaScript code; 5. in case of an app targeted to API level 17 or higher, m needs to be further annotated with the @javascriptinterface tag; 6. W loads at least a web page (WP) that contains one or more Iframe elements; 7. WP does not enforce any mitigation technique among those described in the previous section.

Detection Algorithm

The Frame Confusion detection methodology can be summarized by the pseudocode listed in Algorithm 1. Given a generic Android app in .apk format, the algorithm begins by retrieving a list of the Android permissions used by the app (row 1). If the list does not include the Internet permission, then the app cannot use the WebView component, and therefore it is marked as not vulnerable (rows 2-4). Otherwise, the algorithm computes the list of all the invoked methods of the app (row 5) in order to locate the presence of setJavaScriptEnabled, and addJavascriptInterface APIs. If a setJavaScriptEnabled invocation (row 9) is recognized, the algorithm further investigates the flag parameter of the call (rows 10-14). A True value indicates that the WebView enables the execution of JavaScript and thus its object reference is retrieved (row 12) and included in the list of those that enable JavaScript (row 13).

Instead, the presence of a addJavascriptInterface indicates that a WebView component is configured to expose a bridge between Java and JavaScript. If this is the case, the algorithm extracts i) the WebView object from which the addJavascriptInterface method is invoked (row 17), and ii) the Java object injected in the JavascriptInterface (row 18). After that, the algorithm needs to detect if the Java object injected in the interface contains public methods that can potentially be accessed from JavaScript code (rows [START_REF] Li | Static analysis of android apps: A systematic literature review[END_REF][START_REF] Li | Unleashing the Walking Dead : Understanding Cross-App Remote Infections on Mobile WebViews[END_REF][START_REF] Li | DroidBot: A lightweight UI-guided test input generator for android[END_REF][22][START_REF] Neugschwandtner | A View to a Kill: WebView Exploitation[END_REF][START_REF] Das Patnaik | [END_REF][START_REF]OWASP: Using components with known vulnerabilities[END_REF][26][START_REF] Rizzo | BabelView: Evaluating the Impact of Code Injection Attacks in Mobile Webviews[END_REF]. Moreover, in case of apps targeted to API level 17 or above, the public methods of the object need to be further annotated with the @javascriptinterface tag (rows [START_REF] Li | Static analysis of android apps: A systematic literature review[END_REF][START_REF] Li | Unleashing the Walking Dead : Understanding Cross-App Remote Infections on Mobile WebViews[END_REF][START_REF] Li | DroidBot: A lightweight UI-guided test input generator for android[END_REF][22]. If the injected Java object contains methods accessible from JavaScript, then the corresponding WebView instance can be added to the list of those that expose potentially vulnerable interfaces (row 21 or row 25). Next, if the analysis is not able to find at least a WebView -with JavaScript enabledthat contains a JavaScript interface with exposed Java methods, then the app is marked as not vulnerable (rows 29-34). Otherwise, the analysis collects from the Website collector module all the website pages accessed by the WebView that are i) included in the resources of the .apk package (row 35), ii) statically invoked by loadURL methods (row 36), and iii) dynamically reached during the execution of the app (row 37). Thereafter, the algorithm collects every website that uses at least an Iframe element that loads an external page (either embedded in HTML pages or generated JavaScript) and that does not enforce any of the mitigation techniques discussed in the previous section (rows 40-48). Finally, if the app loads at least one vulnerable website, it is marked as vulnerable. On the contrary, if the app uses the appropriate security mechanisms or does not use any Iframe is marked as non vulnerable.

The FCDroid tool

FCDroid 4 implements the proposed detection methodology to automatically identify the presence of the Frame Confusion vulnerability in Android apps. The rest of the section discusses i) the implementation challenges addressed by FC-Droid and ii) its architecture, emphasizing the underlying tools and technologies.

Implementation Challenges

The Frame Confusion detection methodology poses several challenges in terms of implementation. Indeed, an automatic detection tool needs to:

1. achieve maximum coverage, i.e., by detecting all possible app execution paths that may lead to the vulnerability; 2. recognize the actual configuration of WebView components, which may dynamically enable JavaScript or define new interfaces; 3. analyze all the web pages loaded inside some potentially vulnerable WebViews, by also considering those loaded according to i) the user's input, and ii) the value of runtime variables.

To address such challenges, an automatic tool can rely on static and dynamic analysis techniques. Static analysis techniques can examine all possible execution paths and variable values, not just those invoked during execution. However, static approaches can i) introduce false positives and ii) be unable to detect complex scenario, like, e.g., values provided by the user or resources loaded at runtime. On the other hand, dynamic analysis techniques allow to detect the actual behavior of the app, but it is limited by i) the coverage of the analysis and ii) the time required for the analysis, thus producing potential false negatives.

To this aim, FCDroid combines static and dynamic analysis techniques to overcome the limitations of both techniques and achieve more accurate detection results.

FCDroid Architecture

The FCDroid architecture, depicted in Fig. 2, is composed by five main building blocks: the Static Analysis Module (SAM), the Dynamic Analysis Module (DAM), the WebSite Dumper (WD), the Frame Confusion Detector (FCD), and the Exploitation Checker (EC).

Fig. 2: The FCDroid Architecture.

Static Analysis Module (SAM).

The Static Analysis Module relies on Apktool [START_REF] Winiewski | Apktool A tool for reverse engineering Android apk files[END_REF] to disassemble the app package (in the .apk format) and translate the Dalvik bytecode contained in the app into Smali [START_REF] Gruver | Smali -Assembler/Disassembler for the dex format[END_REF] language. In addition to that, SAM brings the resources contained in the app back to their original form, e.g., from binary compiled XML files into textual XML files. Then, the module extracts the list of permissions requested by the app and the target Android API level according to the content of the AndroidManifest.xml file. Finally, the SAM inspects each extracted Smali file in order to locate all the API invocations related to the WebView component. In detail, the module detects:

-setJavaScriptEnabled that enables the JavaScript code in a WebView object. If found, the SAM also extracts the variable containing the boolean flag passed as an argument; -addJavascriptInterface, that creates a JavaScript interface object. In this case, the SAM retrieves the Java class of the injected object and the name assigned to the interface; -loadUrl and evaluateJavaScript, that allows the loading of specific URLs or JavaScript code inside the WebView. In case, the module also extracts the URL address or the script code, if statically defined;

The collected pieces of information are then sent to the WebSite Dumper and the Frame Confusion Detector to continue the analysis.

Dynamic Analysis Module (DAM).

The Dynamic Analysis Module is in charge of executing the app into a controlled testing environment in order to monitor the stimulation of the WebView components at runtime. To this aim, it installs the app into an Android Emulator and stimulates the app automatically, trying to explore its possible execution states. This allows the DAM to i) monitor the invocations of WebView-related API along with their execution parameters, and ii) intercept all the network traffic generated by the app. In order to stimulate the app automatically, the DAM relies on Droid-Bot [START_REF] Li | DroidBot: A lightweight UI-guided test input generator for android[END_REF], an open-source tool that can automatically explore the app UI and mimic the interaction with a user. Unlike many existing input generators that rely on static analysis and instrumentation of the app to generate inputs, DroidBot works in black-box mode, i.e., it does not need to know in advance the structure of the app, and it is resilient to obfuscation techniques. In order to keep track of API invocations, the DAM module provides the Android emulator with an ApiMonitor module. ApiMonitor, based on the Xposed5 framework, allows the DAM to intercept and collect each method executed by the app during the analysis, saving its invocation and the value of parameters on a JSON file. Furthermore, the DAM module intercepts and stores all the network traffic generated by the app using the HTTP/HTTPs proxy mitmproxy [START_REF] Cortesi | contributors: mitmproxy: A free and open source interactive HTTPS proxy[END_REF].

WebSite Dumper (WD). The WebSite Dumper module aims at extracting and retrieving all the websites invoked by the WebView components. To do that, it retrieves from the SAM and DAM modules the list of URLs accessed by app WebView components.

For each identified URL, the WebSite Dumper determines whether it refers to a local or a remote resource. In the first case, it collects and stores the static resource obtained by the app package. In the latter case, the WD module dumps the content of the remote website by downloading the web pages recursively, up to a maximum of 3 levels deep, by using the wget tool 6 . Finally, the module polishes the results and maintains only HTML and JavaScript files that will be inspected by both the FCD and the EC module.

Frame Confusion Detector (FCD). The Frame Confusion Detector module implements the core logic of FCDroid for the detection of the vulnerability. At first, FCD collects from the SAM the list of permissions of the app and verifies that the app requires the Internet permission. If so, the module analyzes the list of invoked APIs (both those statically extracted by the SAM module and those evaluated at runtime by the DAM) to verify the existence of at least a WebView instance that enables JavaScript and exposes a JavaScript interface. Furthermore, if an exposed interface is found, the FCD parses the class of the injected Java object to determine the existence of methods that can be accessed from JavaScript. Finally, the FCD also needs to detect the amount of potentially-vulnerable webpages.

To this aim, the module collects the websites dumped by the WD and checks whether a page contains at least an Iframe element and does not enforce any mitigation techniques (i.e., the Content-Security-Policy meta tag in the HTML header or the sandbox attribute). At the end of the analysis, the FCD module marks the application as vulnerable or not vulnerable.

Exploitation Checker (EC). The Exploitation Checker is the module responsible for the detection of app configurations that can boost the exploitation of the Frame Confusion Vulnerability. In details, the EC can identify:

-The adoption of unencrypted communication channels, by analyzing the network traffic generated by the DAM module and by extracting the list of URLs that are accessed in plain HTTP.

-The presence of buggy/vulnerable Javascript libraries by relying on the RetireJS [START_REF] Erlend | RetireJS -Scanner detecting the use of JavaScript libraries with known vulnerabilities[END_REF] tool, which allows obtaining a list of known-to-be-vulnerable JavaScript libraries that are executed within the WebView. -The presence of JavaScript code vulnerable to DOM-XSS attacks 7 , by including a customized implementation of JSPrime [START_REF] Das Patnaik | [END_REF]. Such tool inspects the JavaScript code in order to detect unsanitized input variables that could allow an attacker to execute arbitrary JavaScript code in the victim's WebView.

Experimental Results

We empirically assessed the reliability of the proposed methodology, by systematically analyzing 50.000 apps with FCDroid8 . Such apps have been downloaded from the Google Play Store in December 2018, and they are the top free Android apps ranked by the number of installations and average ratings according to Androidrank [START_REF] Androidrank | Androidrank market data[END_REF]. Our experiments were conducted using an Intel Xeon 3106@1.70 GHz, with 32GB RAM, running Ubuntu 18.04.

Frame Confusion Identification. The FCDroid tool discovered that 49.35% of apps (i.e., 24675 out of 50000) are hybrid, since they use at least a WebView component, thereby highlighting the wide adoption of such component in the Android ecosystem.

As shown in Table 1, all the apps with at least one WebView component enable the execution of JavaScript, while 44.84% also attach (at least) a JavaScript interface, which contains properly annotated methods. Such methods can be invoked from the websites loaded inside the apps. Furthermore, FCDroid inspected all the websites accessed by the hybrid apps obtaining the results described in Table 2. In detail, 1.2% (87k/6.7M) of websites contain at least an Iframe element; among those pages, the 27.96% include CPS policies while none of the visited pages enforces the sandbox attribute. Therefore, such findings indicate that most of the web pages that use Iframe elements are potentially vulnerable to Frame Confusion. Finally, our analysis identifies that 6.63% (i.e., 1637) of hybrid apps are potentially vulnerable to Frame Confusion. To estimate the impact of such results on the Android users' community, we cross-referenced our findings with the Google Play Store meta-data, obtaining that the total sum of official installations for vulnerable apps is greater than 250.000.000.

Exploitation Conditions. We further inspected the vulnerable apps with FCDroid, in order to detect the presence of other vulnerabilities in the app configuration that can make easier the exploitation of the Frame Confusion. As shown in Table 3, 59.98% of vulnerable apps access websites using an insecure connection, i.e., plain HTTP, while 27.48% contain code vulnerable to XSS attacks. Finally, 79.96% of vulnerable apps include JavaScript libraries with known security vulnerabilities. Advantages and Limitations of FCDroid. FCDroid combines static and dynamic analysis techniques to maximize the detection accuracy. To prove that, we compared the analysis results obtained by the static and the dynamic analysis with the hybrid approach of FCDroid, as shown in Fig. 3. In detail, the static analysis allows to identify 12.43% of apps as potentially vulnerable to Frame Confusion. Unluckily, such amount contains both true and false positives. To discriminate, each app should be manually inspected, through a time-consuming and error-prone process. On the contrary, the dynamic analysis is not exhaustive, i.e., it may be unable to reach statically defined web pages, like those hardcoded in the app package, that are loaded in WebView components. Therefore, only 4.69% of apps are successfully detected as vulnerable (true positives) through dynamic analysis. To overcome such limitations, the mixed approach (i.e., static and dynamic analysis) adopted by FCDroid detected 6.63% of (true positive) vulnerable apps automatically. Indeed, FCDroid allowed to automatically validate more than half of the potentially positive results detected by the static analysis. Furthermore, FCDroid increased the detection rate of the dynamic analysis by 1.94%. Nonetheless, the experimental results also unveiled some limitations of the current FC-Droid implementation. First, the dynamic analysis is limited to the public surface of the app (i.e., the one that does not require any user authentication) and executes in a predefined time-frame (i.e., 60 seconds). Furthermore, the implementation of FCDroid does not detect dynamically-generated Iframe elements, like, i.e., those created at runtime by the JavaScript code. In this section, we discuss the impact of a successful exploitation of Frame Confusion by attacking a news app (i.e., YTN News9 ) which has been found vulnerable by FC-Droid. At the moment of writing, YTN is available on the Google Play Store and has more than 1M downloads. We manually reverse-engineered and analyzed the app: it uses the WebView component to load a home page with several Iframes. The Iframe at the bottom of the web page loads an advertisement (step 1 in Fig. 4). Our manual investigation confirms the FCDroid findings: the WebView uses HTTP, JavaScript is enabled, and there is an interface exposed through addJavascriptInterface. The interface exposes different methods that are able to get some information about the device. One of these exposed methods is named liveLogin. This method has three parameters of type string, the first two are converted into integers and used to customize the WebView, while the last one is passed as a parameter to the loadUrl method without any kind of sanitization. Therefore, an attacker can easily inject arbitrary JavaScript code or a web page that will be loaded in the main frame. In order to exploit the vulnerability, the attacker must control an Iframe. There exist two approaches to achieve such result: 1) if the attacker and the mobile device belong to the same network, the attacker can carry out a Man-inthe-Middle (MitM) attack, otherwise, 2) the attacker can create an ad-hoc advertising campaign. In our use case, we carried out a MitM attack, and we were able to control the advertisement (steps 2, 3 and 4 in Fig. 4). For the sake of precision, since the Web-View uses HTTP, the attacker can also target the main frame; however, in this example, Fig. 4: YTN News: Flow of the attack. we focused on a child frame, since we only aim to prove the exploitability of Frame Confusion. Thus, given the absence of any security mechanisms, we can access the exposed interface and exploit the Frame Confusion by invoking the liveLogin method with a URL pointing to our malicious web page (step 5 in Fig. 4) containing a fake Twitter login page. It is worth pointing out that the WebView is a promising vector attack for phishing, as there are no GUI components that prompt the actual URL and the transport protocol (e.g., HTTP/HTTPS), thereby making hard to distinguish between the legitimate Twitter website and a well-crafted phishing site [START_REF] Aonzo | Phishing attacks on modern android[END_REF]. As a final remark, it is worth noticing that this is just one among a set of potential exploitation of Frame Confusion under such specific app settings. For instance, it is possible to download a large file (since the app has the WRITE EXTERNAL STORAGE permission) or continue to load the same pages within the WebView to carry out simple Denial-of-Service attacks.

Related Work

The steady growth of hybrid apps has attracted the attention of both academic and industrial security research communities. The main approaches for the security analysis of hybrid apps can be divided into static and dynamic. In static analysis methodologies, the hybrid app is analyzed according to its source (or binary) code without being executed. For instance, Lee at al. proposed HybriDroid [START_REF] Lee | HybriDroid: static analysis framework for Android hybrid applications[END_REF], a static analysis framework that examines the inter-communication between the native and the web counterpart of the app to identify development bugs or potential leaks of sensitive information. Other works, like [START_REF] Rizzo | BabelView: Evaluating the Impact of Code Injection Attacks in Mobile Webviews[END_REF], [START_REF] Chen | DroidCIA: A novel detection method of code injection attacks on HTML5-based mobile apps[END_REF], and [START_REF] Yan | New deep learning method to detect code injection attacks on hybrid applications[END_REF] propose some detection methodologies for code injection attacks based on app-instrumentation or machine learning techniques. However, any of the proposed static analysis techniques suffer from the over-approximation of the app execution paths which drastically reduce the accuracy due to a high rate of false positives [START_REF] Li | Static analysis of android apps: A systematic literature review[END_REF]. On the other hand, dynamic analysis techniques aim at analyzing the security of the app runtime behavior in a controlled environment. The sole work based on dynamic analysis techniques for hybrid apps is BridgeTaint, proposed by Bai et al. [START_REF] Bai | BridgeTaint: A Bi-Directional Dynamic Taint Tracking Method for JavaScript Bridges in Android Hybrid Applications[END_REF]. BridgeTaint tracks sensitive data exchanged through the bridge and uses a cross-language taint mapping method to perform the taint analysis in both domains. Although dealing with the dynamic monitoring the bridge between the Java and the JavaScript worlds, BridgeTaint is only focused on data analysis aimed at the identification of data leaks. Anyway, none of the approaches mentioned above is either able to identify the Frame Confusion vulnerability. The work proposed by Luo et al. [22] is the only research paper that explicitly discusses this vulnerability. Indeed, the authors -who also coined the term "Frame Confusion" -have also studied the security implications of the two-way interaction between the native and the web code in hybrid apps. Anyway, they focus only on detecting the security weaknesses of the WebView component and the JavaScript interfaces, as well as some statistics on the usage of the WebView API and JavaScript interfaces. Furthermore, their analysis is manual, and it has been carried out on a reduced dataset made by only 132 apps. To the best of our knowledge, our methodology is the first approach allowing us to systematically detect the Frame Confusion vulnerability. Furthermore, the adoption of both static and dynamic analysis techniques allows overcoming the limitations of both approaches.

Conclusion

In this work, we have proposed a methodology for systematically detecting the Frame Confusion vulnerability in hybrid Android apps. Then, we have implemented a tool, FCDroid, based on our methodology, which combines static and dynamic analysis techniques to reduce false positive and false negative rates. The results obtained with FC-Droid show that Frame Confusion is a concrete problem: among the top 50.000 apps by installations on the Google Play Store, 24675 use the WebView component and we find that 1637 apps (i.e., about the 6.63% among the ones with at least a WebView component) are vulnerable. Although we took into consideration only the top apps, the Frame Confusion already affects more than 250.000.000 installations. Moreover, we have also discovered that about 59.98% of such vulnerable apps load the page within the Web-View using a clear-text connection thereby easing phishing attacks. Future extension of this research will be the study of proper remediations that could prevent the Frame Confusion without disabling the execution of JavaScript inside Iframes in hybrid apps. As a final remark, our attack to the YTN news app 10 suggests that the WebView is a promising vector for phishing attacks, as the user has no way to discriminate whether she is interacting with the legitimate website or a well-crafted phishing one.

Fig. 1 :

 1 Fig. 1: Exploitation of Frame Confusion from (a) the child frame and (b) the main frame.

Fig. 3 :

 3 Fig. 3: FCDroid vs Static and Dynamic Analysis

  . As described above, the Frame Confusion allows violating the SOP by circumventing the sandbox of Iframes. Unfortunately, despite the recent security mechanisms added in the WebView component, the Frame Confusion is still unfixed at any Android API level. Still, the web world offers an extra set of security mechanisms that are able to restrict the communication among the main frame and the child frames, thus preventing the Frame Confusion vulnerability, i.e.:

  Algorithm 1: Frame Confusion Detection

	Input : APK Package
	Output: vulnerable, notVulnerable
	1 listPermissions = getPermissionFromApk(app);
	2 if "android.permission.INTERNET" not in listPermissions then 3 return notVulnerable;
	4 end
	5 methodsList = getAllInvMet(app);
	6 JSWebView = list();
	7 IWebView = list();
	8 foreach method in methodsList do 9 if method.getName == "setJavaScriptEnabled" then 10 flagParam = getFlagParam(method);
	11	if flagParam == True then
	12	webViewObj = getInvObj(method);
	13	JSWebView.add (webViewObj);
	14	end
	15	end
	16	else if method.getName == "addJavascriptInterface" then
	17	webViewObj = getInvObj(method);
	22	end
	23	end
	24	else if containPubMet(interface) then
	25	IWebView.add (webViewObj);
	26	end
	27	end
	28 end
	29 if len (JSWebView) == 0 or len (IWebView) == 0 then 30 return notVulnerable;
	31 end
	32 if len (IWebView ∩ JSWebView) == 0 then 33 return notVulnerable;
	34 end
	35 resourceFiles = getAllResourceApk(app);
	36 dumpWebStat = getStaticUrl(methodsList);
	37 dumpWebDyn = getDynamicUrl(app);
	38 filesToCheck = dumpWebDyn union resourceFiles union dumpWebStat;
	39 vulnerablePages = list();
	40 foreach file in filesToCheck do
	41	if isHTMLfile( f ile) or isJSfile( f ile) then
	42	if containIframe( f ile) then
	43	if not containCSP( f ile) and not containSandboxAtt( f ile) then
	44	vulnerablePages.add (file);
	45	end
	46	end
	47	end
	48 end
	49 if len (vulnerablePages) > 0 then 50 return vulnerable;
	51 end
	52 return notVulnerable;

18 interface = getInterfaceObj(method); 19 if getSDK(app) > 17 then 20 if containAnnotatedPubMet (interface) then 21 IWebView.add (webViewObj);

Table 1 :

 1 Statistics on the Frame Confusion blueprint.

		Percentage Ratio
	Internet Permission 96.45% 48226/50k
	Use WebView	49.35% 24675/50k
	JavaScript Enabled 49.35% 24675/50k
	JavaScript Interface 44.84% 22420/50k

Table 2 :

 2 Statistics on the web pages accessed by hybrid apps.

		Percentage Ratio
	Web pages with Iframes	1.2%	87k/6.7M
	Web pages with Iframes and CSP	27.96% 24108/87k
	Web pages with Iframes and sandbox attribute	0%	0/87k

Table 3 :

 3 Statistics on the exploiting conditions of vulnerable apps.

		Percentage Ratio
	Insecure connections 59.98% 982/1637
	XSS vulnerabilities	27.48% 450/1637
	Vulnerable JS libraries 79.96% 1309/1637

http://gs.statcounter.com/os-market-share/mobile/worldwide

https://www.owasp.org/index.php/Man-in-the-middle_attack

FCDroid is available at https://www.fcdroid.com.

https://repo.xposed.info/

https://www.gnu.org/software/wget/

https://www.owasp.org/index.php/DOM_Based_XSS

The complete list of experimental results is available at https://www.fcdroid.com/ results.

https://play.google.com/store/apps/details?id=com.estsoft.android.ytn

https://cordova.apache.org/docs/en/latest/guide/appdev/security/index. html#iframes


Bruhadeshwar Bezawada

Indrajit Ray

Kushagra Tiwary
email: kushagra.tiwary@colostate.edu

AGBuilder: An AI Tool for Automated Attack Graph Building, Analysis, and Refinement

Keywords: Attack graphs, Planning Domain Definition Language (PDDL), AI Planning, CVE, NVD

Attack graphs are widely used for modeling attack scenarios that exploit vulnerabilities in computer systems and networked infrastructures. Essentially, an attack graph illustrates a what-if analysis, thereby, helping the network administrator to plan for potential security threats. However, current attack graph representations not only suffer from scaling issues, but also are difficult to generate. Despite efforts from the research community there are no automated tools for generating attack graphs from textual descriptions of vulnerabilities such as those from the Common Vulnerabilities and Exposures (CVE) in the National Vulnerability Database (NVD). Additionally, there is little support for incremental updates and refinements to an attack graph model. This is needed to reflect changes to an attack graph that arise because of changes to the vulnerability state of the underlying system being modeled. In this work, we present an artificial intelligence (AI) based planning tool, AG-Builder -Attack Graph Builder, for automatically generating, updating and refining attack graphs. A key contribution of AGBuilder is that it uses textual descriptions of vulnerabilities to automatically generate attack graphs. Another significant contribution is that, using AGBuilder, we describe a methodology to incrementally update attack graphs when the system changes. This aspect has not been addressed in prior research and is a crucial step for achieving resiliency in the face of evolving adversarial strategies. Finally, AGBuilder has the ability to reuse smaller attack graphs, e.g., when building a network of networks, and join them together to create larger attack graphs.

Introduction

Cyber-attacks against safety critical and mission critical systems such as nuclear power plants are rising alarmingly. It is no longer a question of "if" but "when" a system will be attacked. Thus, in order to be adequately prepared for such an eventuality, there is a need to better understand how the system can be attacked so that provisions for defense deployment can be made or, perhaps, provisions for the graceful degradation of mission services can be instantiated when all defenses have failed. Information security planning and management traditionally begins with risk assessment with the help of system mapping and dependency analysis. The outcome of this process is an identification of vulnerabilities in the system, an enumeration of the threats to critical resources arising from these vulnerabilities, and the corresponding loss expectancy. The analysis allows one to determine appropriate security controls to protect resources and minimize their susceptibility to cyber attacks.

Attack trees [START_REF] Ray | Using attack trees to identify malicious attacks from authorized insiders[END_REF][START_REF] Jhawar | Attack trees with sequential conjunction[END_REF][START_REF] Audinot | Guided design of attack trees: a systembased approach[END_REF] and attack graphs [START_REF] Ammann | Scalable, graph-based network vulnerability analysis[END_REF][START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF][START_REF] Ou | A scalable approach to attack graph generation[END_REF][START_REF] Poolsappasit | Dynamic security risk management using bayesian attack graphs[END_REF][START_REF] Sun | Using bayesian networks for probabilistic identification of zero-day attack paths[END_REF][START_REF] Wang | Measuring the overall security of network configurations using attack graphs[END_REF] are two systematic computer security models that represent a networked system's vulnerability to malicious attacks by enumerating known vulnerabilities in the hosts or applications. They capture cause-consequence relationships between system configuration and the vulnerabilities in the form of And-Or tree (attack tree) or a directed graph (attack graph). Nodes in the tree/graph represent system states that may be of interest to the attacker. Edges connecting the nodes denote a cause-consequence relationship among the states. A key weakness of this representation is the explosion of state space. This becomes a critical drawback for analyzing large cyber-physical systems with many resources that need to be protected from a multitude of attacks. Automated planning holds promise to reduce the number of nodes in the attack graph/tree and produce a scalable solution. [START_REF] Boddy | Course of action generation for cyber security using classical planning[END_REF] [START_REF] Boddy | Course of action generation for cyber security using classical planning[END_REF], presented Behavioral Adversary Modeling System (BAMS), a planning system that models attack scenarios and produces countermeasures to subvert the attacks in networks of large organizations. Ghosh and Ghosh [START_REF] Ghosh | A planner-based approach to generate and analyze minimal attack graph[END_REF] proposed a planner based approach for tractable representation of attack graphs and automatic generation of attack paths. However, none of these works discuss how an attack graph can be automatically constructed, refined and updated as needed from textual description of vulnerabilities such as those in the National Vulnerability Database or CVE repositories.

In this work, we model the attack graph generation and analysis problem as a planning problem [START_REF] Ghosh | A planner-based approach to generate and analyze minimal attack graph[END_REF] in the artificial intelligence community. When compared with logic programming approaches like [START_REF] Ou | A scalable approach to attack graph generation[END_REF], the planning approach lends itself to incremental updates and aggregation, which are quite useful to network administrators. We encode the attack graph in the Planner Domain Definition Language (PDDL) representation, referred to as a PDDL domain. However, there are some important challenges that arise in this modeling. First challenge is that, translating the attack graph/tree of a large network to the corresponding PDDL domain is an iterative process, which demands a lot of time and effort from engineers. The issue is further exacerbated by the lack of tool support to build, debug and maintain PDDL domains from textual CVE descriptions. The second challenge is that, if the underlying system is changed in any manner, for example, by installing a new application, then updating the corresponding attack graph is a computationally complex and error-prone process. The existing approaches have not addressed this situation and require generating a fresh attack graph for the changed system environment. The third challenge is that, when a PDDL domain is incrementally built more actions are added into a domain or actions already in the domain are edited. Such incremental development is found in scenarios where network administrators start by analyzing smaller parts of a network and then try to aggregate the smaller network models into a larger network model.

To address these challenges, we present a formal methodology and a corresponding tool-set, AGBuilder -Attack Graph Builder, designed to automatically generate PDDL based representation of attacks from textual description of vulnerabilities found in the CVE system or the NVD system. Our tool-set incorporates a natural-language processing based generator to generate a PDDL based model of attacks from vulnerabilities and support for incremental development of the PDDL model to reconcile incremental versions of PDDL domains by generating explanations for changes in plans that result from running the modified domain against a planner. Additionally, the tool-set constructs abstract syntax trees and attack graphs for the PDDL domain representation, which facilitates visualization of the domain and the planning problems.

The rest of the paper is organized as follows. In Section 2, we give an overview of the PDDL language and explain the modeling of attack graphs using PDDL. In Section 3, we give an overview of our approach. In Section 4, we describe the AGBuilder tool set and our methodology in detail. In Section 5, we describe the related work in this domain and conclude in Section 6.

Attack Graph Modeling using PDDL

In [START_REF] Ghosh | A planner-based approach to generate and analyze minimal attack graph[END_REF], the authors provided an approach for modeling the attack graphs using AI planners. In this section, we describe this process in detail. A PDDL definition is composed of two key parts: (1) a PDDL domain definition and (2) a PDDL problem description.

PDDL Domain:

A PDDL domain is a high-level description of a set of problems and the corresponding actions and constraints involved. A PDDL domain specifies the requirements it supports, the available actions, the pre-conditions and post-conditions of actions. The pre-conditions and post-conditions are expressed as first-order logic predicates. The requirements of the PDDL domain specify which features it expects the planner to support. A planner will only accept a domain if it supports all the requirements mentioned in the domain. A single PDDL domain can be used to represent multiple attacks from vulnerability databases. The PDDL domain stores pre-conditions, post-conditions and cause-effect relationships in courses of actions that represent attacks. Consider the following PDDL domain that models an attack:

(define (domain PAG) (:requirements :equality :disjunctive-preconditions) (:functions (version ?software)) (:predicates (user ?User) (email-msg ?User ?Msg) ... (browser-sslcompromised ?Browser) (certificate-authorized ?Certificate)) (:action attacker-sends-email-with-keylogger :parameters (?User ?File ?Keylogger) :precondition (and (user ?User) (file ?File) (has-trojan ?File) (keylogger-trojan ?File ?Keylogger)) :effect (and (email-msg ?User bad-email) (mail-attachment bad-email ?File)))) (:action user-visits-site :parameters (?User ?Browser ?Site) :precondition (and (user ?User) (software ?Browser) (browser ?Browser) (site ?Site)) :effect (and (use-software ?Browser) (user-visits-site ?User ?Site))) (:action user-starts-email :parameters (?User ?Mailer) :precondition (and (user ?User) (mailer ?Mailer)) :effect (and (use-software ?Mailer) (running ?Mailer))) (:action user-reads-email :parameters (?User ?Mailer ?Msg) :precondition (and (user ?User) (mailer ?Mailer) (use-software ?Mailer) (email-msg ?User ?Msg)) :effect (and (msg-opened ?Msg)) (:action user-presses-F1-at-vbscript-site :parameters (?User ?Browser ?Site) :precondition (and (user ?User) (use-software ?Browser) (browser ?Browser) (= ?Browser browser-IE) (= ?Site vbscript-link) (user-visits-site ?User vbscript-link)) :effect (user-types F1)) (:action user-opens-attachment :parameters (?User ?Msg ?File ?Mailer) :precondition (and (user ?User) (use-software ?Mailer) (mailer ?Mailer) (msgopened ?Msg) (mail-attachment ?Msg ?File) (file ?File)) :effect (opened ?File)) (:action key-logger-installed :parameters (?User ?File ?KeyLogger) :precondition (and (user ?User) (opened ?File) (file ?File) (has-trojan ?File) (keylogger-trojan ?File ?KeyLogger)) :effect (and (key-logger ?KeyLogger) (installed ?KeyLogger))) :: :: (:action user-login-with-keylogger-activated :parameters (?User ?Account ?Keylogger) :precondition (and (user ?User) (account ?Account) (key-logger ?Keylogger) (running ?Keylogger)) :effect (and (logged-in ?User ?Account) (information-available ?User ?Account) (records ?Keylogger ?Account))))

The predicates (user ?User) and (file ?file) among others describe the state of the world. They can either be true or false. ?User and ?file are formal parameters to the predicates, user and file. They describe who the user is and which file is being used.

Actions allow a planner to move from one state to another. An action can have pre-conditions and post-conditions, both of which are expressed as predicates. An action can only occur in the current state if the current state supports its preconditions, i.e., the predicates already in the current state do not negate the predicates in the action's preconditions. The effects of an action result in the next state.

To elaborate, the shown PDDL domain Personalized Attack Graph (PAG), contains ten actions. Each action is defined with pre-conditions and post-conditions (effects). For example, action user-reads-email with parameters (?User, ?Mailer and ?Msg) has preconditions(user ?User), (mailer ?Mailer), (use-software ?Mailer) and (email-msg ?User ?Msg)). These preconditions verify if the mailer supplied as an argument actually exists, if the user is indeed the user supplied in the argument and whether the email message has the user supplied in the argument and the message supplied in the argument. In other words, the pre-conditions test to see if those predicates are true in the current state. If the pre-conditions are true in the current state, then the post-conditions or effects are applied. The effects are (use-software ?Mailer) and (running ?Mailer). When the effects are applied, the predicates (use-software ?Mailer) and (running ?Mailer) are set to true. Each action can be a unit step towards exploiting a vulnerability.

PDDL Problem: A PDDL problem is a concrete instance of a specific PDDL domain where the general variables in a PDDL domain are replaced with concrete values and a sub-set of actions defined in the PDDL domain. A PDDL problem contains an initial state: a set of predicates that are set to true initially, and a goal state: a set of predicates that may or may not be true with the actions defined in the domain. A PDDL problem can be used to perform what-if analysis by simulating conditions of the system and testing various attack paths originating from the current simulated state of the system. Consider the following PDDL problem that corresponds to the domain "PAG".

(define (problem PAG-problem1) (:domain PAG) (:objects user1 ... browser-seamonkey browser-mozilla) (:init (user user1) (mailer gmail) (exploit-vulnerability vulnerabilitykey-logger) (file file-with-trojan) (has-trojan file-with-trojan) (keylogger key-logger1) (key-logger-trojan file-with-trojan key-logger1) (site vbscript-link) (has-crafted-dialog-box vbscript-link) (vb-script-version VB-5-1) (software browser-IE) (browser browser-IE) (software browserfirefox) (= (version browser-firefox) 2) (browser browser-firefox) (information-available user1 account-bank) (account account-bank)) (:goal (and (information-leakage account-bank))))

In the above problem, the initial state consists of predicates, (user user1) and (mailer gmail) etc. The initial state describes what is true about the system when the planner starts out. The goal state is defined as (informationleakage account-bank). This indicates that when (information-leakage account-bank) becomes true, the goal state is said to have been reached.

PDDL Planner: A PDDL planner tries to solve a PDDL problem by finding a plan that satisfies it. A successful plan is a sequence of actions from those specified in the PDDL problem for a given initial state.

PDDL Plan: A plan is a sequence of actions from the initial state in the PDDL problem to the final state in the PDDL problem. A plan can also be thought of as a sequence of transitions from the initial state to the goal state.

Here is the plan produced for the domain "PAG" and problem "PAG-problem1" by using the Metric-FF planner [START_REF] Hoffmann | The metric-ff planning system: Translating"ignoring delete lists"to numeric state variables[END_REF]:

0: ATTACKER-SENDS-EMAIL-WITH-KEYLOGGER USER1 FILE- WITH-TROJAN KEY-LOGGER1 1: USER-VISITS-SITE USER1 BROWSER-IE VBSCRIPT-LINK 2: USER-STARTS-EMAIL USER1 GMAIL 3: USER-READS-EMAIL USER1 GMAIL BAD-EMAIL 4: USER-OPENS-ATTACHMENT USER1 BAD-EMAIL FILE-WITH- TROJAN GMAIL 5: KEY-LOGGER-INSTALLED USER1 FILE-WITH-TROJAN KEY- LOGGER1 6: USER-PRESSES-F1-AT-VBSCRIPT-SITE USER1 BROWSER-IE VBSCRIPT-LINK 7: KEY-LOGGER-ACTIVATED KEY-LOGGER1 BROWSER-IE 8: USER-LOGIN-WITH-KEYLOGGER-ACTIVATED USER1 ACCOUNT-BANK KEY-LOGGER1 9: ATTACKER-INTERCEPTS KEY-LOGGER1 ACCOUNT-BANK
The sequence of actions is "ATTACKER-SENDS-EMAIL-WITH-KEYLOGGER USER1 FILE-WITH-TROJAN KEY-LOGGER1" followed by "USER-VISITS-SITE USER1 BROWSER-IE VBSCRIPT-LINK" and so on until the last step, "ATTACKER-INTERCEPTS KEY-LOGGER1 ACCOUNT-BANK"

In essence, these steps describe that an attacker sends an email with a keylogger to a user. Once the user opens his/her browser and goes to their Gmail account, reads their email, and opens the attachment from the email sent by the attacker, the keylogger is installed on their system. When the user presses F1 on a website with VB Script, the keylogger is activated. This allows the attacker to remotely track all of the user's keystrokes and allows the attacker to intercept the user's bank account credentials when the user visits their bank's website and tries to sign in. The PDDL domain above only has one vulnerability, but in a more realistic scenario, we can expect thousands of such vulnerabilities in a domain and at least one plan for every vulnerability, which allows us to derive attack paths.

Planning Graph: A planning graph is a layered directed graph, consisting of alternating layers of states and actions. The state layers contain predicates that are for that state. The action layers consist of actions that map pre-conditions and post-conditions. An edge from a predicate to an action indicates that the predicate is the pre-condition of that action. An edge from an action to a predicate implies that the predicate is an effect or post-condition of that action. The planning graph, therefore, represents the transitions from the initial state to the goal state by using the actions and predicates defined in the PDDL domain. A planning graph is, simply put, a more granular way to look at a PDDL plan and can help us visualize the attack path.

Our Approach for Automated Attack Graph

Generation and Refinement The AGBuilder tool set's workflow shown in Figure 1 has the following key steps each of which has been developed as an independent software module:

-Step 1. The Extractor is used to extract structured information from the vulnerability descriptions. Such information is typically obtained from vulnerability databases such as NVD (https://nvd.nist.gov) or ICS-CERT (https://icscert.us-cert.gov). -The structured information is used to generate a PDDL domain by the Generator module. The PDDL domain represents cause-effect relationships in the attack. -Step 2. The PDDL domain is tested using different PDDL problems, which are extracted from the information in event logs of the system. 4 Each PDDL problem is meant to test at least one attack/vulnerability. These PDDL problems are stored in a database internally maintained by the AGBuilder tool. -Step 3. An AI planner is used to generate one PDDL plan for each PDDL problem along with the PDDL domain. The set of actions in the PDDL planner describe an attack path in the attack graph. -Step 4. Whenever the domain is updated/modified, the tool ensures that the latest version of the PDDL domain is consistent with respect to the last known stable version. The tool checks for the consistency of PDDL plans against the PDDL domain and PDDL problems, and provides feedback on plans which failed, thus helping the developer maintain the cause-effect relationships.

Automatically Generating PDDL Domain from Natural Language Textual Descriptions

The automatic generation phase takes vulnerability descriptions (CVE or NVD) from a vulnerability database as input and renders an automatically generated PDDL domain as output. Our tool extends the NLP-based (natural language processing) software previously developed by us as part of a prior project [START_REF] Weerawardhana | Automated extraction of vulnerability information for home computer security[END_REF] to extract structured information from unstructured text. The NLP algorithm implementation is based on parts-of-speech tagging model wherein lexical patterns are identified from the text and the relationships of the subjects and rules are identified from these patterns. The Stanford coreNLP POS Tagger [START_REF] Toutanova | Enriching the knowledge sources used in a maximum entropy part-of-speech tagger[END_REF] was used for tagging. A corpus of 30 descriptions were used for the manual rule generation. Based on these rules, the parts-of-speech tagging algorithm works by tagging labels of a word in the text based on its role in the sentence, like verb, noun, adjective etc, and the context of the word's usage. For instance, software names are typically tagged as proper nouns. Another rule is that software names are followed by a preposition or subordinating conjunction. A pre-stored gazette of 48709 entries, consisting of software and operating systems, is used to match a proper noun to a software name. File names can be matched using regular expressions containing period "." and so on. To identify attacker and user actions, we partition the description and based on the relative positioning of the subject, verbs and modifiers, e.g., like "through", to extract the subjects [START_REF] Klein | Accurate unlexicalized parsing[END_REF] and the respective actions. As a subject can be either attacker or user, sentiment analysis [START_REF] Esuli | Sentiwordnet: A publicly available lexical resource for opinion mining[END_REF] is used to label the subject as positive or negative sentiment by considering the sentiment labels of the respective verbs and modifiers, and finally, labeling the respective subject as attacker or user. The information extracted comprises of the following: software name(s), software version(s), user action(s), attacker action(s) and attacker impact(s) Here is an example of a vulnerability description from NVD: The structured information extracted from vulnerability descriptions is then used to automatically generate the corresponding PDDL domain. Figure 2 an example of an attack graph that is automatically generated by the Generator module of our AGBuilder toolset using the above domain and the relevant problem file, and illustrates the attack path taken to exploit the vulnerability.

is

Incremental Building and Refinement of the Attack Graph

AGBuilder assumes that the PDDL domain, PDDL problem and the plan that represent the cyber threat situational awareness model are syntactically correct and valid. A system administrator focuses only on the undesired plans, i.e., plans that have changed since the last update of the domain. Figure 3 illustrates the process flow for the domain reconciliation algorithm. Given that the system administrator has the last known stable version of the PDDL domain, the PDDL problem set, archived plans from the last known stable version, and the new PDDL domain with bugs in it, a PDDL planner is run on each problem from the PDDL problem set and the new PDDL domain to generate one plan per problem. The tool then matches each pair of a newly generated plan and its corresponding archived plan. For each pair of plans that do not match, the tool constructs an explanation for the observed difference in plans. Sometimes plans may have a different sub-sequence of actions such as

A → B → C → D as opposed to A → C → B → D.
If actions B and C can be executed in parallel, the tool will consider the two plans to be equivalent.

As a motivating example, for incrementally refining the model, let us assume that a planner runs on a stable PDDL domain and a PDDL problem and creates a plan (useropensemailclient → useropensemail → userdownloadskeyloggerinattachment → userentersusernameandpassword-on-site1 → user-enters-username-and-password-on-site2) where the actions in the plan are defined in the domain. If some modification to the domain causes the plan to be generated as (useropensemail → useropensemailclient → userdownloadskeyloggerinattachment → userentersusernameandpasswordon -site1 → userentersusernameandpasswordon -site2), this new plan may be considered an undesirable plan by the developer since the user now opens the email before even opening the email client. Now, to debug the domain definition and fix the plan, the developer needs to track the state of the system starting with the initial state defined in the PDDL problem and trace all the actions in the plan and their effects on the state of the system, to figure out what caused the observed difference in the plans. Further, it is possible that a new plan (useropensemailclient → user-opens-email → user-downloads-keylogger-in-attachment → userenters-username-and-password-on-site2 → user -enters-usernameandpasswordon -site1) is observably different, but it might still be equivalent to the old plan (useropensemailclient → useropensemail → userdownloadskeyloggerinattachment → userentersusernameand-password-on-site1 → user-enters-username-and-password-on-site2. This is possible if userentersusernameandpasswordon -site1 and userentersusernameandpassword-on -site2, are independent actions, i.e., actions that do not affect each other in anyway and can be executed in parallel. If the goal of the PDDL plan is for the user's credentials from site1 and site2 to be compromised in no particular order, it should not make a difference if the user's credentials for site1 are compromised before his/her credentials for site2 and vice-versa. If the actions userentersusernameandpasswordon -site1 and userentersusernameandpassword-on -site2 do not have any preconditions or effects in common, then they can be considered independent. Therefore, even though the two plans are observably different, they are equivalent. This would imply that neither of the two is an undesired plan. The developer would still need to manually look at the code to make this deduction.

With incremental development, some inadvertent changes to the old actions in the PDDL domain can also lead to unexpected outcomes in terms of the plans produced. At some point, the interaction of the actions in the PDDL domain can get very challenging to visualize for the developer. If multiple developers collaborate on a PDDL domain, and some unintended changes are made to the domain (for instance, adding a new pre-condition to an action or deleting an action), this change in the domain can cause a different plan to be generated by the planner. It can get very hard to manually inspect this change in plan and deduce what caused the change.

Our tool assists the PDDL domain developer ensure that subsequent versions of the PDDL domain are consistent by constructing explanations for the observed changes in the old and new plan by creating two planning graphs: (1) a planning graph using the last stable version of the domain, the PDDL problem and the last stable version of the plan, and (2) planning graph using the new domain, the PDDL problem and the new plan. It then traverses the two planning graphs layer by layer and determines what caused the change in the plan. It infers whether the cause for the change is the addition/removal/replacement of a predicate in the set of pre-conditions or post-conditions, or the addition/removal/replacement of an action. This is then reported as an explanation for the observed change in plans. Next, we describe the details of the modules in AGBuilder and their functionality.

AGBuilder Modules

We categorize AGBuilder into its knowledge base components and processing modules.

Knowledge Base Components

Input data: Input to AGBuilder includes the presumably faulty domain which needs to be fixed, the most recent known stable version of the domain, the set of PDDL problems pertaining to the faulty domain, and the archived PDDL plans.

Most recent stable domain: This is the last known stable version of the domain that produces all the plans as expected by the user.

Faulty domain: A domain file is considered faulty because of changes made to the most recently stable version of the domain. The most recently stable version of the domain produces all the plans as expected but the faulty domain produces unexpected/undesired plans. Unexpected/undesired plans are plans with unexpected sequences of actions in them, or sequences of actions that are different from those produced in plans from the last known stable version of the domain.

PDDL problem set: The PDDL domain is accompanied by a set of problems. The PDDL problems are used for generating plans. The tool uses the planner, the faulty domain, and PDDL problem set to generated plans for the faulty domain.

Archived PDDL plans: The archived PDDL plans can be thought of as the reference output. There is one archived plan per problem in the problem set. The archived PDDL plans were generated using the most recently stable version of the PDDL domain. If the plans generated using a PDDL domain and the problem set match those in the archived set, then the plans are treated as correct and the PDDL domain used to generate those plans is considered "stable" and not "faulty".

AGBuilder Processing Modules

AGBuilder has a parsing module, a planning graph construction module, and a module for generating explanations.

Parsing module:

The parsing module has a built-in lexer and parser that reads a PDDL domain or problem into an abstract syntax tree (AST). The AST structure is useful as it allows the tool to run queries on it to find actions that contain a predicate for determining if two or more actions are independent of each other. AGBuilder uses a parser and a lexer. The parser and lexer were generated using a BNF representation of PDDL 3.1 and ANTLR [START_REF] Parr | Antlr: A predicated-ll (k) parser generator[END_REF], a popular parser generator for Java.

Planning graph construction module:

We use the Metric-FF the PDDL Planner to generate plans [START_REF] Hoffmann | The metric-ff planning system: Translating"ignoring delete lists"to numeric state variables[END_REF]. However, any other new planner can also be used, which gives the tool a distinct advantage of keeping up to date with minimal effort. The planning graph construction module takes as input, a PDDL domain, a PDDL problem and a plan generated using the PDDL domain and the PDDL problem. It converts the domain and the problem into ASTs and then uses the ASTs and the plan to create a planning graph.

1. Initialize the first layer as the set of predicates in the initial conditions from the PDDL Problem's AST. 2. For every action a i in the sequence of actions in the plan:

(a) Initialize the next layer as an action layer (if it is not initialized already), and set it as the current layer. (b) If the current action layer is not the first action layer and the current action a i is "independent" with respect to every single action in the previous action layer: i. Add current action a i to previous action layer and set previous action layer as current layer. (c) Initialize the next layer as state layer (if it is not initialized already) and set it as the current layer. (d) For every precondition of action a i in the previous state layer, set a directed edge from the pre-condition in the previous state layer to the action a i in the previous action layer. (e) Apply the postconditions of action a i to the current state layer. (f) For every postcondition of the action a i in the current state layer, set a directed edge from the action a i in the previous action layer to the postcondition in the current state layer.

This module determines whether two actions are independent. The criteria for two actions to be independent is that the negative effects (negated predicates) of either action should not have any intersection with the preconditions or the positive effects (predicates that aren't negated) of the other action. This is formally expressed in the following relationship as: actions a1 and a2 are independent if and only if:

ef f ects -(a1) ∩ (preconditions(a2) ∪ ef f ects + (a2)) = {φ} and ef f ects -(a2) ∩ (preconditions(a1) ∪ ef f ects + (a1)) = {φ}
The relationship implies that two independent actions don't interact with each other in any way, so they can be executed simultaneously, or can be in the same layer of a planning graph. For a set of actions to be independent, every possible pair of actions in that set needs to satisfy the aforementioned relationship for independence. Thus, for a plan A → B → C → D where B and C are independent according to the aforementioned criteria, the planning graph would have A in the first action layer, B and C in the second action layer and D in the third action layer. Another plan A → C → B → D would also have A in the first action layer, B and C in the second action layer, and D in the third action layer. This is how it is determined that two plans with differing sub-sequences of actions are equivalent.

Module for constructing explanations: The module for constructing explanations is the main module of AGBuilder. It takes one problem at a time from the PDDL problem set, generates two planning graphs, one for the last known stable version of the domain and the archive plan, and another for the faulty domain and the new plan. It then compares these two planning graphs to deduce if two plans are actually different or if they are equivalent but have different sub-sequences of actions. If the plans are different, it uses the planning graphs to deduce an explanation for causes of the change in the new plan. The main algorithm for generating explanations in AGBuilder is as follows: For each PDDL problem x, in the problem set {X}:

1. Run planner on PDDL problem and the new (faulty) domain to generate a plan. 2. If the plan produced has a different sequence of actions than the archived plan: (a) Run the faulty domain and the stable version of the domain through the parsing module to get two ASTs. (b) Run the PDDL problem x i through the parsing module to get an AST for the problem. (c) Construct one planning graph using the stable domain AST, problem x i AST and the archived plan of the table domain on the problem x i . (d) Traverse both the graphs simultaneously, one layer at a time, and find differences in actions or states at each layer. If a difference is observed in the corresponding layers of the two planning graphs, report the differences observed and halt any further traversal of planning graphs. The process of constructing explanations is discussed in more detail next. Now, the explanation construction module takes as input the planning graph from the most recent stable domain, the planning graph from the new (presumably faulty) domain, the old domain AST and the new domain AST. The algorithm for generating explanations is as follows:

1. Skip the first state layer in the two planning graphs. This is because the first state layer has the initial preconditions from the PDDL problem (which both planning graphs share), therefore they must be the same. i. Print the action(s) from the previous action layer which has this predicate ¬P i in its post conditions. The action(s) that had this predicate as its post condition is what contributed to the change in the observed plan. ii. Print the action(s) from the previous action layer of the old graph that has the predicate P i in its post conditions for reference. (c) Print the predicates in the current layer of the old graph which are not in the corresponding layer of the new graph. For each of these predicates: i. Print the action(s) from the previous action layer in the old planning graph that has this predicate in its post condition.

5. If the sets of predicates in the current state layer of the two graphs are the same and there are more action layers: (a) Repeat step 2) with the next action layer of the two graphs as the current layers.

Finally, we present a worked out example for the domain PAG.

Working Example of Explanation Constructor

For the exercise, we consider the PDDL problem, PAG-problem1 from Section 2. We edited the action user-visits-site and included all the parameters, pre-conditions and effects from user-starts-email in user-visits-site. In essence, the two actions were combined and put in user-visits-site. This was to simulate an inadvertent change to the domain.

The planner runs on the last known stable version of the domain and the problem, and then on the new version of the domain and the problem. By constructing planning graphs for both instances and crawling the planning graphs, the tool displays the change in domain that caused the new plan to be different from the previous version. The original actions in the PDDL definition of PAG-problem1 are:

(1) user-visits-site and (2) user-starts-email. A new updated PDDL Domain needs is generated with the following new actions: (1) user-visits-site and (2) user-starts-email:

(:action user-visits-site :parameters (?User ?Browser ?Site ?Mailer) :precondition (and (user ?User) (software ?Browser) (browser ?Browser) (site ?Site) (user ?User) (mailer ?Mailer)) :effect (and (use-software ?Browser) (uservisits-site ?User ?Site) (use-software ?Mailer) (running ?Mailer))) (:action user-starts-email :parameters (?User ?Mailer) :precondition (and (user ?User) (mailer ?Mailer)) :effect (and (use-software ?Mailer) (running ?Mailer)))

Finally, the updated plan from new PDDL domain for PAG-problem1 is given by: As shown above, the tool runs on the two versions of the PAG domain and PAG-problem1. It crawls the two planning graphs generated using both versions of the domain, the problem and the two versions of the plans. The plan generated from the new domain does not include "USER-STARTS-EMAIL USER1 GMAIL" because "USER-VISITS-SITE USER1 BROWSER-IE VBSCRIPT-LINK GMAIL" has all of its pre-conditions and post-conditions. AGBuilder finds a disparity at state layer 3, which is after USER-VISITS-SITE was run for both domains and complaints that the predicates in the state layers were different and leads to the action which caused this change. This is how the tool generates an explanation for the change observed in plans.

Related Work

There is a wealth of knowledge [START_REF] Ou | A scalable approach to attack graph generation[END_REF][START_REF] Sawilla | Identifying critical attack assets in dependency attack graphs[END_REF][START_REF] Lippmann | An annotated review of past papers on attack graphs[END_REF][START_REF] Wang | Measuring the overall security of network configurations using attack graphs[END_REF][START_REF] Poolsappasit | Dynamic security risk management using bayesian attack graphs[END_REF][START_REF] Jhawar | Attack trees with sequential conjunction[END_REF][START_REF] Singhal | Security risk analysis of enterprise networks using probabilistic attack graphs[END_REF][START_REF] Sun | Using bayesian networks for probabilistic identification of zero-day attack paths[END_REF][START_REF] Cao | Assessing attack impact on business processes by interconnecting attack graphs and entity dependency graphs[END_REF][START_REF] Audinot | Guided design of attack trees: a systembased approach[END_REF] on attack graphs and attack trees. We discuss a few works in brief here.

In [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF], demonstrated the first technique for automatic generation of attack graphs using symbolic model checking techniques. However, this approach suffers from scalability issues. In [START_REF] Ou | A scalable approach to attack graph generation[END_REF], the authors model the attack graph generation as a logic programming problem in Prolog. Their tool MulVAL takes in information from vulnerability databases, configuration information from each machine and the network. Once the entire information is available and encoded in the MulVAL framework, for a given host and policy configurations, an attack simulation is performed by the MulVAL scanner for policy violations or presence of exploit paths. However, even small changes in the configuration will require the simulations to be rerun again. In AGBuilder, the configuration information can be updated incrementally and generate new attack paths. Furthermore, we can combine two smaller PDDL domains of different networks and check for attack paths. While the underlying logical framework remains same, the planning domain formulation allows for simpler way to perform incremental updates and analysis. In [START_REF] Poolsappasit | Dynamic security risk management using bayesian attack graphs[END_REF], the authors describe Bayesian Attack Graphs that not only encodes cause-consequence relationship between network states but also consider the likelihoods of exploiting these relationships. However, none of the existing works did considered building attack graphs from natural language descriptions of the attack/vulnerabilities.

Prior work in the area of applying AI planning in cyber-security applications, provide evidence for the ability of PDDL being used to model attack-graphs. Mark Roberts et al. have demonstrated that PDDL can be used for modeling an attack graph for use in personalized security agents. [START_REF] Roberts | Using planning for a personalized security agent[END_REF].

Existing tools for PDDL allow for automatically generating PDDL code from formal models, developing PDDL code in an IDE with an integrated planner, and determining whether plans generated by a planner are correct [START_REF] Vaquero | A brief review of tools and methods for knowledge engineering for planning & scheduling[END_REF]. AGBuilder seeks to compliment the existing research on knowledge engineering tools by assisting in the generation and incremental development of very large and complex domains.

ItSimple [START_REF] Vaquero | The itsimple tool for modeling planning domains[END_REF][START_REF] Vaquero | itsimple4. 0: Enhancing the modeling experience of planning problems[END_REF] is a knowledge engineering tool that uses simple UML models and converts them into PDDL representations. Invariants (constraints) on UML classes are represented using OCL (Object Constraint Language). According to the authors, ItSimple was designed to give support to users during the construction of a planning domain application mainly in the initial stages of the design life cycle" ItSimple 2.0 [START_REF] Vaquero | itsimple 2.0: An integrated tool for designing planning domains[END_REF][START_REF] Vaquero | itsimple4. 0: Enhancing the modeling experience of planning problems[END_REF] assists users to resolve issues during requirements specification, analysis and modeling phases. ItSimple 2.0 allows users to build use case diagrams from UML, thus allowing the requirements to be represented at a high level of abstraction. ItSimple 4.0 also features a text editor for further editing after the PDDL domain has already been created, uses modeling patterns (essentially a set of common planning models in UML), time based models that describe how properties of objects change during the execution of an action, and a wizard that allows users to quickly select the initial preconditions and goal states for actions [START_REF] Vaquero | itsimple4. 0: Enhancing the modeling experience of planning problems[END_REF].PDDLStudio is an IDE for PDDL that features document management, syntax highlighting, code completion with hints, and planner integration [START_REF] Plch | Inspect, edit and debug pddl documents: Simply and efficiently with pddl studio[END_REF].

ModPlan is an integrated environment that allows for knowledge acquisition and domain analysis in planning applications. ModPlan helps in knowledge engineering by examining pairwise dependencies in actions and letting the user examine these dependencies [START_REF] Edelkamp | Knowledge acquisition and knowledge engineering in the modplan workbench[END_REF]. It allows for plans to be visualized using Vega and validated using VAL.

VAL is used to determine if the plans generated by a planner are correct. It first examines if the domain and the problem are syntactically correct and if the objects, preconditions and goal state(s) in the problem match the domain. It then validates the plan generated by a planner for a given domain and a problem, and reports if the plan is flawed, and how it might be fixed [START_REF] Howey | Val: Automatic plan validation, continuous effects and mixed initiative planning using pddl[END_REF].

Conclusion and Future Work

In this paper, we presented a tool, AGBuilder, that generates attack graphs in PDDL from textual descriptions of CVEs. The tool assists developers with incrementally developing PDDL domains for modeling attack graphs by generating explanations for why undesired plans are produced when PDDL domains are modified, and also allows for what-if analysis of attacks with the PDDL representation. The tool also allows for generating abstract syntax trees of PDDL domains and problems, and generating attack graphs as DOT files, which can then be rendered into image files, in order to visualize attack paths. We demonstrated our tool on an NVD description of a key-logger malware propagation and showed the corresponding attack graph/paths in PDDL.

Future work will look into extending the tool to perceive the current state of the system. This will allow us to estimate courses of actions that could lead to an attack in real time. Secondly, we will obtain quantifiable quality measurements of AGBuilder's scalability. Thirdly, we will investigate the feasibility of stitching together attack paths from the various attack graphs modeled by the attack graph domain to build a single consolidated attack graph. This task will require using the domain and all problem files to generate a DOT file that can then be rendered into an image file. Since the AGBuilder already has the capability of building abstract syntax trees and attack graphs for individual graphs, we anticipate this feature enhancement to be an immediate attainable goal. Finally, we will seek to integrate AGBuilder with an online IDE that we are in the process of developing. This will allow for multiple users to collaborate and build a PDDL domain.

material is also based upon work performed by Indrajit Ray while serving at the National Science Foundation. Research findings presented here and opinions expressed are solely those of the authors and in no way reflect the opinions the DOE, the NSF or any other federal agencies.

Fig. 1 .

 1 Fig. 1. Overview of the process of generating and maintaining attack graphs

CVE- 2010

 2010 -0483: vbscript.dll in VBScript 5.1, 5.6, 5.7, and 5.8 in Microsoft Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP2, when Internet Explorer is used, allows user-assisted remote attackers to execute arbitrary code by referencing a (1) local pathname, (2) UNC share pathname, or (3) WebDAV server with a crafted .hlp file in the fourth argument (aka helpfile argument) to the MsgBox function, leading to code execution involving winhlp32.exe when the F1 key is pressed, aka "VBScript Help Keypress Vulnerability." For the above vulnerability description, our extractor gives the following output: Software : VBScript Versions : [51, 56, 57, 5.8, 2000, 2003, SP2, SP2, winhlp32.exe] Modifiers : [ and 5.8] User Action: Internet Explorer is used User Action: the F1 key is pressed Attack Vector: referencing a -LRB-1 -RRB-local pathname , -LRB-2 -RRB-UNC share pathname , or -LRB-3 -RRB-WebDAV server with a crafted hlp file in the fourth argument -LRB-aka helpfile argument -RRB-to the MsgBox function , leading to code execution involving winhlp32exe Attack Impact: execute arbitrary code

Fig. 2 .

 2 Fig. 2. Attack Path generated for NVD 2010-0483

Fig. 3 .

 3 Fig. 3. Overview of incremental support for maintaining/refining attack domains

2 . 3 .

 23 Compare the two sets of actions after the first state layer of the two planning graphs. If the sets of actions in the current action layer of the old graph and the new graph are different: (a) Print the actions in the current layer of the new graph which are not in the corresponding layer of the old graph. These actions are extra actions in the new plan. (b) Print the actions in the current layer of the old graph which are not in the corresponding layer of the new graph. These actions are missing actions in the new plan. 4. If the sets of predicates in the current state layer are different: (a) Print the predicates in the new graph which are a negation of the predicates in the old graph. (b) For each predicate P i in the new graph that is ¬P i in the old graph:

  0: ATTACKER-SENDS-EMAIL-WITH-KEYLOGGER USER1 FILE-WITH-TROJAN KEY-LOGGER1 1: USER-VISITS-SITE USER1 BROWSER-IE VBSCRIPT-LINK GMAIL 2: USER-READS-EMAIL USER1 GMAIL BAD-EMAIL 3: USER-OPENS-ATTACHMENT USER1 BAD-EMAIL FILE-WITH-TROJAN GMAIL 4: KEY-LOGGER-INSTALLED USER1 FILE-WITH-TROJAN KEY-LOGGER1 5: USER-PRESSES-F1-AT-VBSCRIPT-SITE USER1 BROWSER-IE VBSCRIPT-LINK 6: KEY-LOGGER-ACTIVATED KEY-LOGGER1 BROWSER-IE 7: USER-LOGIN-WITH-KEYLOGGER-ACTIVATED USER1 ACCOUNT-BANK KEY-LOGGER1 8: ATTACKER-INTERCEPTS KEY-LOGGER1 ACCOUNT-BANK Below is an example output of AGBuilder on all the problems for the last known stable version of the domain and the new version of the domain and reporting changes: Problems found: 1) problems/PAG-problem1.pddl: PAG-problem1 Archived plans found: 1) archivedPlans/PAG-problem1.plan Creating planning graph for domainPAG.pddl, PAG-problem1.pddl and PAG-problem1.plan ...done Creating planning graph for domainPAGV2.pddl, PAG-problem1.pddl and new plan ...done plans different? True Difference observed: State Layer 1: same Action Layer 1: same State Layer 2: same Action Layer 2: same State Layer 3: different! extra predicates found in action: USER-VISITS-SITE extra effects: 1) (use-software ?Mailer) 2) (running ?Mailer)

An event log is record of actions taken by users and may represent the exploitation of a vulnerability.

Acknowledgment

This work is partially supported by the U.S. Department of Energy under award number DE-NE0008571 subcontracted through the Ohio State University. This