jacy: a jvm-based intrusion detection and security

HAL Id: hal-03168756https://hal.archives-ouvertes.fr/hal-03168756v1Preprint submitted on 14 Mar 2021 (v1), last revised 2 May 2021 (v3)

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

JACY: a JVM-Based Intrusion Detection and SecurityAnalysis System

Mohammadreza Ashouri, Christoph Kreitz

To cite this version:Mohammadreza Ashouri, Christoph Kreitz. JACY: a JVM-Based Intrusion Detection and SecurityAnalysis System. 2021. �hal-03168756v1�

https://hal.archives-ouvertes.fr/hal-03168756v1

https://hal.archives-ouvertes.fr

JIPC: a JVM Based Intrusion Detection andProtection System

Mohammadreza AshouriChristoph Kreitz

[email protected]

[email protected]

Abstract. This paper introduces a practical approach to identify inputsanitization errors in Java applications. Our introduced technique analyzesthe bytecode of given Java applications based on a successful combinationof call graph backward slicing and dynamic taint tracking. As a result,our analysis technique allows overcoming common restrictions in previouswork such as unexpected runtime errors in Java Virtual Machine (JVM) orapplications, altering the normal behavior of target programs under analysis,and the lack of source code.

Our approach can be deployed without special firmware modifications orroot privileges on different standard operating systems, supporting the JVM,e.g., Linux, Windows, Mac OS. Moreover, we evaluated our technique witha new Java benchmark suite called Orbitz Security Benchmark Suite. Orbitzincludes 8 programs written in modern Java compilers (e.g., Java SE 9, 11,14, and 16), comprises 1,201,934 lines of code, with different workloadsfor various application domains. As a result, we could identify 130 securityviolations out of 349 suspicious runtime data flows, demonstrating ourproposed mechanism’s aptitude to identify real-world security issues in theJava ecosystem.

Introduction

The lack of proper input sanitization in software systems can lead to serioussecurity issues and financial damages, such as leaking sensitive information andlosing data. Consequently, Java applications that contain such bugs are vulnerableto input sanitization errors, which adversaries can exploit to hijack confidential datafrom target machines, damage system resources, and provide additional supportsfor further attacks. For instance, internet worms often exploit sanitization errorsand infect hundreds of thousands of machines in a short amount of time, causinghundreds of millions of dollars in losses [25, 60].

Nevertheless, it seems there is still a significant deficiency in the existence ofpractical systems and approaches to tackle this fundamental coding issue. Naturally,a practical solution should allow identifying zero-day vulnerabilities, exploits, andruntime attacks in both free and open-source (FOSS) and commercial off-the-shelf programs (COTS) before being exploited by adversaries. Furthermore, suchmechanisms should be easy to deploy, cost-effective, and result in few false positivesand false negatives.

2 Mohammadreza Ashouri & Christoph Kreitz

This paper introduces an effective mechanism to identify input sanitization errorsin real-world Java COTS and FOSS in the JVM ecosystem, swiftly extending to theAndroid ecosystem and other JVM-based ecosystems as Scala, Clojure, and Kotlin.Our work introduces the following contributions:

i Tracking only actual runtime data flows by handling real environment inputs

ii Non-reliance on source code

iii Providing a safe runtime environment for vulnerable applications by blockingsanitization errors exploits and reporting adversaries

iv Introducing a modern benchmark suite for security evaluation in Java based onnew Java Development Kits (JDKs)

v Preventing runtime intrusion in Java bytecode by intercepting runtime attacksand vulnerability exploitation

1 Java Virtual Machine

The Java virtual machine (JVM) is a virtual machine that allows a computer torun Java programs as well as programs written in other languages (e.g., Scala, Kotlin,Ceylon) that are also compiled to Java bytecode [50]. Hence, we can describe JVMas an abstract computing machine that has its own instruction set, byte codes, andmanages multiple memory blocks. When the compilation of a Java program takesplace, it generates a sequence of bytecode as an array of bytes. These bytecodeinstructions are described in a class file, which also holds the program data [53].

1.1 Java Class FileA class file is a file holding bytecode and having .class extension that can be

executed by JVM. A Java compiler creates a class file from .java files as a resultof the successful compilation. The Java class file is a precisely defined format forcompiled Java. The program source code is compiled into class files that can beloaded and executed by any standard Java virtual machine [26]. Also, the class filescan travel across a network before being loaded by the JVM. JVMs are available forcommon platforms, and a class file compiled on one platform will execute on theanother platforms’ JVM. This makes Java applications platform-independent [40].Listing 1.1 represents the structure of a sample class and how to initiate it in Java.

We can also define a class as an element in object-oriented programming thataggregates attributes (fields), which can be public accessible or not, and meth-ods(functions), which also can be public or private and usually writes/reads thoseattributes. Figure 1 illustrates instantiating of a class in the Java ecosystem.

Java Security Analysis 3

1 public class Sample {2

3 private String property1 ;4 private int property2 ;5

6 void SetMethod(int val) {7 this . property2=val;8 }9

10 int GetMethod2() {11 return this . property2 ;12 }13 }14

15 class TestClass {16 public static void main (String [] args) {17

18 // create an instance of the class .19 Sample sample = new Sample();20 sample.SetMethod(2019);21 System.out. println (sample.GetMethod2());22 }23 }

Listing 1.1: Java class instancing at runtime.

Fig. 1: Instantiating is the creation of a new instance of a class and is part of object-orientedprogramming, which is when an object is an instance of a class


1.2 Java BytecodeSince JVM bytecode is the instruction set for the JVM, it acts similar to an

assembler [29]. As soon as a program is compiled, Java bytecode is generated.Required resources for running the bytecode are made available by the JVM, whichcalls the processor to allocate the required resources. JVM’s are stack-based, sothey stack implementation to read the codes [3]. Diagram 2 outlines the compilationprocess [4]. Listing 1.2 and Listing 1.3 respectively show the bytecode of the classafter the compilation.

Fig. 2: Overview of the compilation process in the Java compiler

1 for ( int i = 2; i < 1000; i++) {2 for ( int j = 2; j < i ; j++) {3 if ( i % j == 0)4 continue outer ;5 }6 System.out. println ( i ) ;7 }

Listing 1.2: Sample Java code before the compilation

1.3 Bytecode PortabilityBytecode is essentially the machine level language which runs on the JVM. Hence,

when a class is being loaded, it gets a stream of bytecode per class method. Also,


1 Code:2 0: iconst 23 1: istore 14 2: iload 15 3: sipush 10006 6: if icmpge 447 9: iconst 28 10: istore 29 11: iload 2

10 12: iload 111 13: if icmpge 3112 16: iload 113 17: iload 214 18: irem # remainder15 19: ifne 2516 22: goto 3817 25: iinc 2, 118 28: goto 1119 31: getstatic #84; //Field java/lang/System.out:Ljava/io/PrintStream;20 34: iload 121 35: invokevirtual #85; //Method java/io/PrintStream.println:( I )V22 38: iinc 1, 123 41: goto 224 44: return

Listing 1.3: Manifesting the bytecode of the compiled class after the compilation process inJava

if that method was called during the program execution, the bytecode for thatmethod gets invoked. This flexibility results in portability, which is lacking in otherprogramming languages, such as C and C++ [48]. Portability guarantees that aprogram can be implemented and executed on a wide range of platforms, such asweb, desktop, mobile devices, and mainframes.

1.4 JVM InternalsPrecisely, bytecodes will be executed by the Java Runtime Environment (JRE) [47].

In the fact JRE is the implementation of JVM, which analyzes, interprets and executesbytecodes [28]. As shown in Figure ??, JVM includes three main subsystems asfollows:

– Class Loader Subsystem– Runtime Data Area– Execution Engine

Classloader.Classloader is responsible for loading program class files. Any program must be

first loaded by the classloader. There exist three built-in Classloaders in the Loadingphase: BootStrap ClassLoader, Extension ClassLoader, and Application ClassLoader.


– Bootstrap ClassLoader: It is the first classloader, which is the superclass ofExtension classloader. It loads the rt.jar file, which contains all class files of JavaStandard Edition, such as java.lang package classes, java.net package classes,java.util package classes, java.io package classes, java.sql package classes [5].

– Extension ClassLoader: This is the child classloader of Bootstrap and parentclassloader of System classloader. It is responsible for loading the jar files locatedinside of the compiler library folder.

– System/Application ClassLoader: This sub-component, which is recognized asthe child classloader of Extension classloader, is responsible for loading the classfiles from the classpath. It is also called ”Application Classloader”.

Listing 1.4 shows how to interact with ClassLoader pragmatically in Java.

1 public class ClassLoaderExample2 {3 public static void main(String [] args)4 {5 // Let ' s print the classloader name of current class .6 //Application/System classloader will load this class7 Class c=ClassLoaderExample.class;8 System.out. println (c.getClassLoader()) ;9 //If we print the classloader name of String , it will print null because it

is an10 //in−built class which is found in rt . jar , so it is loaded by Bootstrap

classloader11 System.out. println ( String . class .getClassLoader()) ;12 }13 }14 // output : sun.misc.Launcher$AppClassLoader@4e0e2f2a15 // null

Listing 1.4: Working with ClassLoader at runtime

1.5 Bytecode Instrumentation in JavaBytecode instrumentation (BCI) is an important capability of the JVM to modify

the program execution at runtime without knowing or changing its source code [21,17, 35]. BCI is the foundation of this dissertation. This important feature is feasibleby utilizing the instrumentation API that is provided by JVM to alter existing loadedbytecodes before executing in the JVM [34].

Common use cases for BCI are dynamic analysis, event logging, memory leakagesdetection, and performance monitoring [11, 32]. Using this technique makes it possibleto introduce almost any changes to already deployed Java application by operatingon its bytecode level which is interpreted by JVM at runtime, without modifyingapplication’s source code (since there is no need to re-compilation, re-assembly andre-deployment) [35]. It is conducted through implementing an agent that makes it


possible to transform every class loaded by Classloader before being used for thefirst time [33]. Since the manual bytecode manipulation is relatively complicatedand error-prone, there are some BCI libraries bundled in the JRE to help developersfor BCI implementations, e.g., BCEL [11], Java Assist [36], ASM [24], and ByteBuddy [55].

Operational Code. Java programs are compiled into a generic intermediate format,which is called the JVM bytecode. A method in the bytecode is a series of instructions.Each instruction consists of an one-byte operational code defining the operationand it is followed by one or more arguments. An instruction can be expressed in thefollowing format:

1 <index><opcode>[<operand1>[<operand2>...]][<comment>]

¡index¿ is the index of the operational code in the array that holds the bytecode.It can be considered as a bytecode offset from the beginning of the method. Thefollowing code shows a simple constructor from a MIDlet application with a simplemethod String.valueOf():

1 public MainMidlet() {2 String number = String.valueOf(”H”);3 }

The corresponding bytecode is shown in Listing 1.5, which is consisted the indexand the instruction code in each line. The opcode aload 0[this] takes the referenceof the class from the stack. The line 5 and line 7 are two instructions of methodcalls. invokespecial invokes the method of an instance of class. invokestatic invokesthe static method of a class. Opcode ldc pushes the value of the String ’H’ onto thestack. The astore 1 stores the value returned from the method call into the variablenumber.

1 // Method descriptor #10 ()V2 // Stack: 1, Locals : 23 public MainMidlet();4 0 aload 0 [ this ]5 1 invokespecial javax . microedition . midlet .MIDlet() [12]6 4 ldc <String H > [14]7 6 invokestatic java . lang . String .valueOf(java . lang .Object) : java . lang . String [16]8 9 astore 1 [number]9 10 return

Listing 1.5: showing corresponding bytecode associated with the simple MIDlet method.


Methodology

In this research, we look for input sanitization errors in Java applications, whichlead to various code injection attacks such as SQL-injection, cross site scripting (XSS),and remote code execution [39]. In other words, in our threat model, adversaries canlaunch successful attacks through input data sanitization errors and exploit sensitivecoding methods in a target Java applications.

Furthermore, we assume that cyber-attacks not exploiting code-level vulnerabilitiesare outside the scope of our research. For instance, hijacking external service securitytokens due to the weak security of these external services is respected as a separateissue.

Additionally, the denial-of-service (DoS) behavior of interrupting service is not inour research scope [49] even though, in some cases, it can be identified by JIPCthrough a proper set of source-sink specifications. Henceforth, in this work, weaim to identify runtime attacks and taint-style vulnerabilities caused by code-levelsanitization errors in a target program.

Sanitization: Sanitization is the process of assuring that data adapts to theprogram conditions (security-related requirements regarding leaking or disclosureof sensitive data). Sanitization may involve eliminating unwanted characters fromthe input by eliminating, substituting, or terminating the characters. Note thatsanitization functions can often neglect particular characters or unknown complexitiesin the code, or they may not be sufficiently maintained when new features areappended to the software.

Security violation: We assume that there exists at least one security vulnerability(violation) in a given application, where there is at least one input that is introducedby an untrusted source (e.g., web forms, program arguments, file, network, externalprocess, keyboard) and this input can reach at least one sensitive method (e.g.,console, database, file, network) without being appropriately sanitized. Consequently,if we can identify such an unsafe data flow during the execution time of a programunder analysis, we can identify the security vulnerability associated with that particularruntime data flow.

1.6 Problem ScopeWe aim to raise the bar for the aforementioned code-level attacks by providing a

conservative monitoring system. To do this, our techniques performs the followingstages:

1. Statically analyzing the binary files of a given Java applications to generates acall graph

2. Performing backward slicing to recognize potential exploitable paths

3. Instrumenting the extracted paths

4. Dynamically monitoring runtime behavior of the instrumented paths our dynamictaint analysis (DTA) engine in order to report the propagation of non-properlysanitized input arriving from external sources during runtime


Fig. 3: Illustrating the abstract architecture of JIPC

Note that our approach can also be used as a complementary tool for programdebugging, auditing, or penetration testing for software developers and securityexperts. The abstract architecture of our analysis mechanism is shown in Figure 3.

Call Graph Generation. JIPC builds a dependency call graph [?,?] for a givenapplication class in order to represent all potential sensitive paths, where can beexploited by potential vulnerabilities. In other words, the generated graph call, whichis called ”Code Property Graph” (CPGs) [56] illustrates a graph in which we candiscover critical methods (we call them sinks). Given a source method (where theprogram receives input) and a sink method, generated CPGs can be effectively utilizedto find data dependency paths between source and sink arguments, and therefore,potential attacking runtime data flows.

Backward Slicing. Because these sinks nodes can be exploited by adversaries,we should control them in order to determine whether there are vulnerable to inputsanitization errors. Note that, in this paper an entry point means an external source ofarbitrary input data (e.g., user inputs, web forms, network packages, files). Accordingly,we leverage a ”backward slicing” algorithm introduced in [] (Figure 4) to find anactual entry point, where introduce arbitrary input to the program. The backwardslicing method we used is shown in Algorithm 1, and it is expected to return the listof potential critical (i.e., exploitable) paths.


Fig. 4: Backward slicing

Procedure 1 Backward slicingInput : Sink MethodsResult: Critical Paths

1 initialization SensitiveNodes ← SearchSensitiveNodes(SensitiveMethods)2 foreach SensitiveNode ∈ SensitiveNodes do3 SensitivePaths = AnalyzeNode(SensitiveNode)4 end5 returnSensitivePaths6 Function AnalyzeNode(node):7 SensitivePaths ← [] ExtractedPaths = Backward(SensitiveNode)8 foreach path ∈ ExtractedPaths do9 if pathhasasource then

10 SensitivePaths ← path;11 else12 invokePaths = NodeAnalysis(invokeNode) SensitivePaths ← path + invokePaths13 end14 end15 return SensitivePaths;

16 Function Backward(node):17 IntraPaths ← []18 while node is not a source node is not a method argument do19 AddNodes = ExtractNextNode(node) UnNodes = FILTERNodes(AddNodes) node ← UnNodes20 end21 IntraPaths = ReachPathToSources(node) return IntraPaths;

This algorithm starts scanning nodes for any call-site (invocation) to a sink method.Each node represents an instruction in the graph. Therefore, we traverse backwardthe data dependency edges for all variables used in that sink instruction by usingthe function NodeAnalysis. This function also calls the Backward function to gainall data dependency paths from an instruction node to either a source or a methodargument (if the instruction is inside a method). If a path ends at a method argument,NodeAnalysis will be invoked recursively over the nodes. Furthermore, the Backwardfunction classifies paths between sources and sinks. It also controls protection methods(e.g., sanitization functions) in paths and prunes non-exploitable ones. Finally, theReachPathtoSources function returns critical paths in the graph.


2 Bytecode Instrumentation

While the source code of synthetic and educational software projects is often avail-able on the Internet (places like GitHub), the source code of commercial off-the-shelf(COTS) applications is usually non-public for various understandable reasons, suchas protecting intellectual properties [44, 11]. This limitation challenges conductingpractical vulnerability analysis for real-world COTS.

In the effort to overcome this obstacle, we created a JVM agent [30], named”Instrumentor” to manipulate the bytecode of a target application and implement ourdynamic taint tracking and analysis. Therefore, in contrast to the previous work [44,43, 37, 51, 46, 57, ?], in JIPC, we do not need to access the source code for theinstrumentation. In other words, with the absence of source code, our BCI agentallows us to track the propagation of input data during execution time. Listing 1.6represents the standard initiation of a Java application alongside the BCI agent.

1 java −javaagent:agentA.jar −javaagent:agentB.jar TargetApp

Listing 1.6: Launching a Java application carried along with 2 JVM agents.

Instrument agent. In this work, we created our BCI agen with the help of theByteBuddy [41] library due to its simplicity in comparison with other libraries inJava [11, 15] Note that, the agent loads the target bytecode to the ClassLoader ofthe local JVM (see Listing 1.6). Then, it injects logging code into the bytecode. Thisinjected code later will allow us to perform dynamic taint tracking during the targetapplication’s execution time. Figure 5 illustrates the BCI agent in our approach.

Fig. 5: Instrumenting Java application bytecode

3 Dynamic Taint Tracking

The dynamic taint analysis module (DTA) is the main component for monitoringand analyzing the propagation of untrusted input data introduced by external sourcesin a target program. In other words, the DTA is responsible for monitoring the dynamicexecution of an instrumented bytecode and identifying sanitization errors at runtime.Hence, if a tainted data can reach a sensitive sink without proper sanitization, the


DTA module will mitigate the attack and report the associated security violation.The DTA module comprises the following components:

Sources: Source methods identify where untrusted data originate from.Sinks: These are programming locations (i.e., functions) where we can controls

the state of tainted data to identify any malicious activity in the code. For example,executeQuery(SQLquery) and processBuilder.command(”bash”, ”-c”, ”ls /home/”);are associated with the SQL injection and RCE attacks, respectively. Table 1 presentssome of sink methods in Java.

Table 1: Some of the J2EE sink methodsSink Descriptiontomcat.util.net.NioBufferHandler.getReadBuffer Reads the buffer of Apache serverjavax.servlet.jsp.JspWriter.println(C) Print objects/strings/booleans on web documentsjavax.servlet.http.Part.getHeaderNames Gets the header namesorg.eclipse.jetty.server.Request.getReader Shows a Post form itemjava.lang.Runtime.exec Executes the string command in a processjava.sql.Statement.executeQuery Executes a given SQL statement with JDBCjava.net.URL.openConnection Returns an HttpURLConnection objectjavax.servlet.jsp.JspWriter Writes characters to stream or consoleorg.apache.struts.action.ActionForward.setPath Sets URI to which control should be forwardedognl.OgnlReflectionProvider.getValue Evaluates the provided OGNL expressionutil.TextParseUtil.ParsedValueEvaluator Evaluates the value of OGNL value stackturbine.om.peer.BasePeer.executeQuery Executes a given query in Apache Turbinorg.hibernate.Session.createSQLQuery Executes a given SQL statement in Hibernate

Intrusion Terminator: After identifying a runtime attack based on a non-sanitizeddata flow, this component protect the end-user by terminating the vulnerable Javaprocess.

3.1 Shadow ObjectsTo track the propagation of tainted data introduced by triggered sources in the

bytecode, we utilized the ”memory shadowing” technique in our analysis. Note thatthis technique has been introduced in previous work [?,31, 7, ?]. However, in our work,we optimized it in such a way to track the potential exploitable path introduced bythe call graph analysis only. This extension enables our DTA systems to log or trackonly necessary objects at runtime by creating a shadow instance (or a copy) of themin the runtime bytecode without making a separate structure or extra resources forcomputing the state of taints.

As a result, we could reduce runtime overhead and unexpected errors associatedwith dynamic taint tracking.

Our DTA module performs the following operations during the execution time ofa target application:

1. Labeling program various inputs from untrusted source methods as ”tainted”.2. Identifying intrusions by tracking suspicious data flows


3. Using regular expressions to analyze the lack of proper sanitization on targetdata flows

3.2 Intrusion TerminationIF the DTA found a regex match, it provides a report associated with the vulnerable

data flow in a target program. This YAML reports introduces necessary informationregarding the vulnerability and its associated sink. Listing 1.7 presents a generatedreport for SQL injection vulnerabilities in a data flow on one of our benchmarkprograms.

1

2 − app: ZooBank3 JVM: Java HotSpot(TM) 64−Bit Server VM4 user : root5 violation :6 − login . class7 − StrEmail8 − org.apache.http. client .methods.HttpGet9 − java. sql .Statement.executeQuery

10 − false11 − 20245213912 tainted : ”;/∗∗/SELECT sleep(25)13 inside : wool14 − 161510690815 − true16 − true17 − false

Listing 1.7: Showing a generated report including necessary information for tracing a runtimeattack

After identifying a non-sanitized data flow, i.e., a vulnerability, JIPC block successfulattacks by terminating the vulnerable Java process. To end an instrumented Javaprogram under the dynamic taint tracking, JIPC’s agent injects the exit() methodof the System class. It is the most popular way to end a program in Java. System.exit() terminates the Java Virtual Machine(JVM) that exits the current program thatwe are running (Listing ??). Even though this approach can also interrupt a Javaprogram’s normal behavior, this protects the end-users from potential exploitationand further damage by exploiting a hidden security vulnerability introduced in thetarget application. Note that the Termination occurs only when there is a successfulgoing attack. On the other hand, JIPC does not disturb application behavior undernormal circumstances. Our method, along with a vulnerability report, allows theprotect users until receiving a proper bug fix for the vulnerability.


Evaluation

Even though there are a number of standard Java-based benchmark suites((e.g.,Secure Micro-Bench [45], DaCapo [22])), they are mostly relatively old, and therefore,do not reflect the modern features introduced by recent Java Development Kits(JDKs). Consequently, in this research, we built and introduced our own Javabenchmark suite, which includes modern JDKs’ modern features for both securityand performance measurements. We call this benchmark suite . The Orbit benchmarksuite aggregates various application domains, such as database, web, network, andfile management. It also includes programming classes associated with multi-threadprogramming, image processing, and message passing. To challenge the usefulnessof JIPC, we also deliberately introduced different security issues such as cross-site scripting, SQL injection, code injection, insecure deseriazalition, and directorytraversal. Table ?? represent our benchmark suite, which comprises 1,201,934 linesof code (LoC).

Table 2: Summary of the security collection of .Name Description LoCDNA String functions 7011Duke Browser Web Browsing functions 48295Icy Files File Management 3724Memory Leaks Using various methods and loops for Garbage Collector security issues 2387Net Messenger Network messaging using various network APIs with the core encryption libraries 129057Picture-Pro Image Processing 8700RAT Remote screen control with the core libraries, no encryption used 825098Zoo-Bank Database application with common functionalities used in database systems 177662

3.3 Analysis ResultWe performed our evaluation on a mac-OS Sierra machine (version 12) with 128

GB memory and Intel Xeon W CPU using OpenJDK 11 as the runtime environment.As Table 3 indicates, JIPC could successfully report a total of 301 security violationsin our benchmark suite in which 248 are actual vulnerabilities, while 53 are falsepositives.

3.4 Attack SimulationIn order to perform various runtime attacks, we performed the following stages:

1. We specified a remote access to the benchmark applications (e.g., by networkrequests)

2. We directed exploits’ payloads to the sources in target applications. Precisely,we used Burp Intruder [9], which is a standard and configurable security tool forexecuting different sets of exploit strings.

3.5 Result VerificationWe manually compared each reproduced report by comparing its detected sources,

sinks, and tainted values with our pre-knowledge about the vulnerabilities intentionally


Table 3: Actual Vuln. indicates true vulnerabilities after our valida-tion process, and FP introduces false positives.Project Tainted Flows Reported Vuln. Actual Vuln. FPDNA 7 0 0 0Duke Browser 3 1 1 0Icy Files 80 31 28 3Memory Leaks 8 7 3 4Net Messenger 43 41 27 14Picture-Pro 67 43 37 6RAT 59 11 9 2Zoo-Bank 82 16 15 1Total Result 349 150 120 30

Table 4: Various identified vulnerabilities

Benchmark DN

AD

UK

EB

RO

WS

ER

ICY

FIL

ES

ME

MO

RY

LE

AK

SN

ET

ME

SS

EN

GE

RP

ICT

UR

E-P

RO

RA

TZ

OO

-BA

NK

SQL INJECTION 7 7 7 7 7 7 7 3

CROSS-SITE SCRIPTING (XSS) 7 7 7 7 3 7 7 3

REMOTE CODE EXECUTION 7 3 7 7 7 7 3 3

INSECURE DESERIALIZATION 7 3 7 7 7 3 7 7

XML EXTERNAL ENTITIES (XXE) 3 7 7 7 3 7 7 3

OGNL INJECTION 7 7 7 7 7 7 7 3


installed in the benchmark suite to verify our reports’ accuracy. In some cases, wealso imported the benchmark source code into the IntelliJ IDEA [6]. Then we startedto debug and monitor corresponding data flows with runtime values to interceptpotential hidden vulnerabilities that we were unaware of them. We often employedCurl [1] to direct exploit payloads to the benchmarks’ sinks.

False Positives. JIPC mistakenly reported 53 data flows. We figured out this isdue two cases:

1. Lack of proper regex specifications in the DTA module2. ”Sink Intervention” issue, which means having a couple of sink methods that

interfere.

4 Related Work

Static code analysis is one of the popular techniques for discovering programmingbugs and security issues in software systems [23]. The main advantage of this methodis performing program analysis does not require the compilation and the execution ofa given source code. Developers mostly use this technique during the developmentstages before realizing the program to the market [23].

For instance, FindBugs [18] is a popular and free-open source static analysistool, which can report various bugs and security errors. It works based on staticspecifications of target bugs and allows developers to review and correct their projects’code during popular IDEs such as Eclipse [2] and NetBeans [8]. However, this tool’smain downside and similar static-based approaches are demanding source code, whichis often unavailable for real-world COTS and introduces substantial false-positiveresults, resulting from the lack of access to actual runtime data.

Other research tools manipulate the runtime environments (e.g., operating system,hardware [59]) to perform conservative dynamic taint tracking. In this regard, HiS-tar [58] introduced a tagging system to show the taint level of operating system (OS)abstractions and control information flow from sensitive objects to natural objectswithout using a trusted agent. PRECIP [54] also proposed as a lightweight toolfor blocking information leaks by intercepting system calls and monitoring outputchannels (e.g., network, file, process, database) in which sensitive input data, e.g.,files, user inputs, are existed. To prevent running malicious programs, e.g., malware,from gaining access to the sensitives resources, PRECIP tracks runtime informationflow at the object-level at the kernel level. Although this tool works similarly toTaintEraser [59], it does not track taint propagation within the target programs’code. Hence, PRECIP’s security policies have to stop all system calls when a programreceives sensitive information. As a well-known taint analyzer for Linux, Dytan [27]is a generic dynamic taint analysis framework for the Linux platform that supportsconfigurable taint-propagation policies. However, Dytan requires significant executionoverhead due to its complicated internals.

Moreover, Vachharajani et al. introduced RIFLE [52] as a runtime mechanismfor implementing information-flow security policies. The proposed solution tracksinformation flow by using new hardware extensions based on the devised binarytranslation. RIFLE could also handle conditional dependencies and loops, but itrequires significant hardware support, not instantly applicable to existing systems.


Similarly, Ho et al. [38] introduced a page-granularity taint analyzer built on theXen virtual machine that monitors and switches dynamically from virtualization tohardware-based emulation to identify security violations if the processor accessed atainted page.

However, the common drawbacks of the work mentioned above are the substantialruntime overhead stemming from the extensive monitoring system, lack of flexibility,and unwanted errors to target binaries. Furthermore, the restriction of using a specificlab-made runtime environment only prevents a wide range of real-world apps frombenefiting from these approaches.

This paper aims to introduce a practical approach for performing in-depth securityanalysis for the JVM ecosystem by considering real-world conditions. Thus, we usedthe strengths in previous related work, especially in [12–14, 10, 16, 19] and eliminatetheir weaknesses in our proposed system. We significantly converged on the Javaecosystem to cover Java-based applications (e.g., J2EE, J2ME, and J2SE) and severalstandard programming languages such as Scala, Kotlin, Clojure.

Although the core concept of JIPC has been inspired by some of the previousrelated work [12–14, 10, 16, 19, 36, 43, 45]), our primary goal is introducing a practicalsoftware level intrusion detection and attack prevention system that is able to identifya wide range of input sanitization errors in Java COTS, where source code is oftenunavailable, overhead is critical, and punctuality is vital. Precisely, our approach worksbased on a successful combination of backward slicing, bytecode instrumentation,and dynamic taint tracking. Moreover, as a software level intrusion detection system,JIPC suppers various JVM-based programming languages Java, Scala, Kotlin, andClojure.

Finally, we implemented a guided bytecode instrumentation engine that onlyinstruments potential executable paths in a target binary because of our call graphalgorithm. In contrast to previous work in the JVM [37, 20, 51, 44, 45, 42, 46], whichinstrument the whole of statements in target applications and imposes substantialruntime overhead and unexpected error, our binary instrumentation technique reducesthe instrumentation time, runtime overhead, and unexpected errors.

In order to represent the advantages of JIPC in comparison with related work, wecompared the critical features in our approach with the essential contributions inrelated work; the result of this comparison is shown in Table 5.

According to our comparison results, the number of reported true and false positivesindicates that our hybrid analysis is more effective in detecting actual vulnerabletainted flows and pruning false-positive flows that do not involve runtime attacksand vulnerabilities present in the code. These precise results gained by accessing theactual runtime information, controlling the content of introduced untrusted inputs,and pruning false positives data flows from our analysis.

Future Work

Improving specification completeness. While our evaluation proves our securitytechnique’s soundness and application, we could analyze only those security issues,which are well-specified for our DTA engine. However, if a particular source is missed,potential vulnerabilities provoked by the source will be missed as well.


Table 5: Comparison between the advancements in JIPC and related work.

JIP

C

Fin

dB

ug

s

Ph

osp

ho

r

Ta

intD

roid

Hel

dar

Sca

laS

tyle

Sca

peg

oa

t

WA

SP

Ju

turn

a

Tri

shu

l

Ch

an

dra

Bytecode Instrumentation D X D D D X X D D D DReal-world case studies D D X D D - - - - - -

Compatibility on standard JVMs D - - - X - - X X X X

String Propagation D D D D D - - D D D DByte array propagation D - - D X - - - - - -

All primitives data type propagation D - D - X - - - - - -

Supporting reflection D D - D D X X - - - -

Attack (vulnerability) detection D D X X D D X - - - -Key concept Hybrid Static Dynamic Dynamic Dynamic Static Static Dynamic Hybrid Dynamic Dynamic

Adaptable source/sink specification (by users) D X X X D D X - D - -

False-positive filtration D X X X X X X - - - -

Duke

-Bro

wser

Icy-

Files

Picture

-Pro

Net

-Mes

senge

rRAT

DN

A

Zoo-Ban

k

Mem

ory-

Leaks

0

10

20

30

40

1

28

37

27

9

0

15

31

16

29

11

20

12

2 Nu

mb

ero

fac

tual

vuln

erab

iliti

esre

por

ted

JIPC FindBugs

Fig. 6: The number of true positives on benchmark suite analyzed by JIPC and FindBugs.


Duke

-Bro

wser

Icy-

Files

Picture

-Pro

Net

-Mes

senge

rRAT

DN

A

Zoo-Ban

k

Mem

ory-

Leaks

0

5

10

15

20

0

3

6

14

2

01

4

2

7

10

19

2

0

8

4

Nu

mb

ero

ffa

lse

po

siti

ves

rep

orte

d

JIPC FindBugs

Fig. 7: The number of false positives on benchmark suite analyzed by JIPC and FindBugs.

Although inferring blueprints in the general case is a task for future research,we used a hybrid strategy to find corresponding sources in a given application callgraph. For example, we found the sources by backtracking sensitive nodes (i.e.,sinks) in the generated call graph. However, we acknowledge that using sophisticatedcode obfuscation tools can interrupt our approach. Thus, tackling code obfuscationtechniques for the sake of data flow specification would be one of the future works.

Auto-sanitize malicious input. By giving write privilege to JIPC for restricting(overwriting) vulnerable tainted methods, we should be able to fix sanitization errorsand protect target applications against runtime threats at the bytecode level. Byimomene=ting these features, instead of terminating the whole vulnerable process,we can better mitigate and control runtime attacks in order to protect vulnerableapplications against cyber-attacks (e.g., Internet worms) to buy additional opportunityfor security teams to deliver proper security patches.

Multi-layer sanitization. In real-world applications, there are conditions in whichtainted data must be sanitized to be used, for instance, as a SQL command (e.g.,searching database), as well as if the data is used again, for example, on a web page(e.g., as a result of a search box). The current version of JIPC does not includethe analysis for cases where ”multi-layer sanitization” is needed. Hence, we wouldconsider implementing this feature as a future extension.

Conclusion

In this paper, we introduced a JVM-based mechanism for detecting and block-ing sanitization-error-based vulnerabilities and runtime exploitation. We name ourmechanism ”JIPC”, which is an intrusion detection and protection system designedspecifically for real-world Java COTS and FOSS. Our technique works based on a


combination of static call graph analysis and bytecode instrumentation, which istailored to a dynamic taint tracking system to propagate runtime data and circum-vent malicious activities inside a JVM target process. Moreover, JIPC can also getextended for Android applications.

References1. curl - how to use. https://curl.haxx.se/. (Accessed on 10/25/2019).2. Enabling open innovation & collaboration — the eclipse foundation.

https://www.eclipse.org/. (Accessed on 01/11/2020).3. Java bytecode - javatpoint. https://www.javatpoint.com/java-bytecode. (Accessed on

01/28/2018).4. Java programming/print version2 - wikibooks, open books for an open world.

https://en.wikibooks.org/wiki/JavaP rogramming/Printversion2.(Accessedon02/22/2019).5. Jvm (java virtual machine) architecture. https://www.zeplus.com/. (Accessed on

20/11/2018).6. Run/debug configuration: Remote debug - help — intellij idea.

https://www.jetbrains.com/help/idea/run-debug-configuration-remote-debug.html.(Accessed on 06/27/2018).

7. [sonarjava-1709] fn in s2077: support extra methods such as springframework sql-relatedmethods - sonarsource. https://jira.sonarsource.com/browse/SONARJAVA-1709. (Accessedon 07/16/2019).

8. Welcome to netbeans. https://netbeans.org/. (Accessed on 11/05/2019).9. Ivan Andrianto, MM Inggriani Liem, and Yudistira Dwi Wardhana Asnar. Web application

fuzz testing. In 2017 International Conference on Data and Software Engineering (ICoDSE),pages 1–6. IEEE, 2017.

10. Mohammadreza Ashouri. Detecting input sanitization errors in scala. In 2019 SeventhInternational Symposium on Computing and Networking Workshops (CANDARW), pages313–319. IEEE, 2019.

11. Mohammadreza Ashouri. Practical dynamic taint tracking for exploiting input sanitizationerror in java applications. In Australasian Conference on Information Security and Privacy,pages 494–513. Springer, 2019.

12. Mohammadreza Ashouri. Practical dynamic taint tracking for exploiting input sanitizationerror in java applications. In Australasian Conference on Information Security and Privacy,pages 494–513. Springer, 2019.

13. Mohammadreza Ashouri. Kaizen: a scalable concolic fuzzing tool for scala. In Proceedingsof the 11th ACM SIGPLAN International Symposium on Scala, pages 25–32, 2020.

14. Mohammadreza Ashouri and Christoph Kreitz. Hybrid taint flow analysis in scala. In 2019IEEE Symposium Series on Computational Intelligence (SSCI), pages 657–663. IEEE, 2019.

15. Mohammadreza Ashouri and Christoph Kreitz. Scalayzer: a portable tool for vulnerabilityanalysis in scala. In Proceedings of the 4th ACM/IEEE Symposium on Edge Computing,pages 371–376. ACM, 2019.

16. Mohammadreza Ashouri and Christoph Kreitz. Scalayzer: a portable tool for vulnerabilityanalysis in scala. In Proceedings of the 4th ACM/IEEE Symposium on Edge Computing,pages 371–376, 2019.

17. Arra E Avakian, Randolph G Hudson, Martha S Borkan, Rowan H Maclaren, Raymond MBloom, and Jeffrey Rees. Instrumenting java code by modifying bytecodes, January 272009. US Patent 7,484,209.

18. Nathaniel Ayewah, William Pugh, David Hovemeyer, J David Morgenthaler, and John Penix.Using static analysis to find bugs. IEEE software, 25(5):22–29, 2008.


19. Jonathan Bell and Gail Kaiser. Phosphor: Illuminating dynamic data flow in commodityjvms. ACM Sigplan Notices, 49(10):83–101, 2014.

20. Jonathan Bell and Gail Kaiser. Dynamic taint tracking for java with phosphor. In Proceedingsof the 2015 International Symposium on Software Testing and Analysis, pages 409–413.ACM, 2015.

21. Walter Binder, Jarle Hulaas, and Philippe Moret. Advanced java bytecode instrumentation.In Proceedings of the 5th international symposium on Principles and practice of programmingin Java, pages 135–144. ACM, 2007.

22. Stephen M Blackburn, Robin Garner, Chris Hoffmann, Asjad M Khang, Kathryn S McKinley,Rotem Bentzur, Amer Diwan, Daniel Feinberg, Daniel Frampton, Samuel Z Guyer, et al.The dacapo benchmarks: Java benchmarking development and analysis. In ACM SigplanNotices, volume 41, pages 169–190. ACM, 2006.

23. Dan Boxler and Kristen R Walcott. Static taint analysis tools to detect information flows. InProceedings of the International Conference on Software Engineering Research and Practice(SERP), pages 46–52. The Steering Committee of The World Congress in Computer Science,Computer . . . , 2018.

24. Eric Bruneton. Asm 3.0 a java bytecode engineering library. URL: http://download. forge.objectweb. org/asm/asmguide. pdf, 2007.

25. Ben Buchanan. The Hacker and the State: Cyber Attacks and the New Normal of Geopolitics.Harvard University Press, 2020.

26. Patrick Chan and Rosanna Lee. The Java class libraries: An annotated reference. Addison-Wesley Longman Publishing Co., Inc., 1996.

27. James Clause, Wanchun Li, and Alessandro Orso. Dytan: a generic dynamic taint analysisframework. In Proceedings of the 2007 international symposium on Software testing andanalysis, pages 196–206. ACM, 2007.

28. Zack Coker, Michael Maass, Tianyuan Ding, Claire Le Goues, and Joshua Sunshine. Eval-uating the flexibility of the java sandbox. In Proceedings of the 31st Annual ComputerSecurity Applications Conference, pages 1–10. ACM, 2015.

29. Markus Dahm. Byte code engineering. In JIT’99, pages 267–277. Springer, 1999.30. Markus Dahm, J van Zyl, and E Haase. The bytecode engineering library (bcel), 2003.31. Manuel Egele and Kruegel. Dynamic spyware analysis. 2007.32. William Enck, Peter Gilbert, Seungyeop Han, Vasant Tendulkar, Byung-Gon Chun, Landon P

Cox, Jaeyeon Jung, Patrick McDaniel, and Anmol N Sheth. Taintdroid: an information-flowtracking system for realtime privacy monitoring on smartphones. ACM Transactions onComputer Systems (TOCS), 32(2):5, 2014.

33. Nan Fan, Allan Bradley Winslow, Ting Bin Wu, and Jean Xu Yu. Automatic deployment ofjava classes using byte code instrumentation, March 12 2013. US Patent 8,397,227.

34. Marco Gagliardi. Injection of updated classes for a java agent, October 24 2017. US Patent9,798,557.

35. Allen Goldberg and Klaus Haveland. Instrumentation of java bytecode for runtime analysis.2003.

36. Vivek Haldar, Deepak Chandra, and Michael Franz. Dynamic taint propagation for java. InComputer Security Applications Conference, 21st Annual, pages 9–pp. IEEE, 2005.

37. Vivek Haldar, Deepak Chandra, and Michael Franz, editors. Dynamic taint propagation forJava., December 2005.

38. Alex Ho, Michael Fetterman, Christopher Clark, Andrew Warfield, and Steven Hand. Practicaltaint-based protection using demand emulation. In ACM SIGOPS Operating Systems Review,volume 40, pages 29–41. ACM, 2006.

39. Yunhan Jack Jia, Qi Alfred Chen, Shiqi Wang, Amir Rahmati, Earlence Fernandes, Zhuo-qing Morley Mao, Atul Prakash, and Shanghai JiaoTong Unviersity. Contexlot: Towardsproviding contextual integrity to appified iot platforms. In NDSS, 2017.


40. Douglas Kramer. The java platform. White Paper, Sun Microsystems, Mountain View, CA,1996.

41. Eugene Kuleshov. Using the asm framework to implement common java bytecode transfor-mation patterns. Aspect-Oriented Software Development, 2007.

42. Yue Li, Tian Tan, and Jingling Xue. Understanding and analyzing java reflection. ACMTransactions on Software Engineering and Methodology (TOSEM), 28(2):7, 2019.

43. Benjamin Livshits, Michael Martin, and Monica S Lam. Securifly: Runtime protection andrecovery from web application vulnerabilities. Technical Report, 2006.

44. V Benjamin Livshits and Monica S Lam. Tracking pointers with path and context sensitivityfor bug detection in c programs. In Proceedings of the 9th European software engineeringconference held jointly with 11th ACM SIGSOFT international symposium on Foundationsof software engineering, pages 317–326, 2003.

45. V Benjamin Livshits and Monica S Lam. Finding security vulnerabilities in java applicationswith static analysis. In USENIX Security Symposium, volume 14, pages 18–18, 2005.

46. Florian D Loch, Martin Johns, Martin Hecker, Martin Mohr, and Gregor Snelting. Hybridtaint analysis for java ee. In Proceedings of the 35th Annual ACM Symposium on AppliedComputing, pages 1716–1725, 2020.

47. Mauro Marinilli. Java deployment. Sams Publishing, 2002.48. Lutz Prechelt. An empirical comparison of c, c++, java, perl, python, rexx and tcl. IEEE

Computer, 33(10):23–29, 2000.49. Eyal Ronen and Adi Shamir. Extended functionality attacks on iot devices: The case of

smart lights. In 2016 IEEE European Symposium on Security and Privacy (EuroS&P), pages3–12. IEEE, 2016.

50. Robert F Stark, Joachim Schmid, and Egon Borger. Java and the Java virtual machine:definition, verification, validation. Springer Science & Business Media, 2012.

51. Omer Tripp, Marco Pistoia, Stephen J Fink, Manu Sridharan, and Omri Weisman. Taj:effective taint analysis of web applications. In ACM Sigplan Notices, volume 44, pages87–97. ACM, 2009.

52. Neil Vachharajani, Matthew J Bridges, Jonathan Chang, Ram Rangan, Guilherme Ottoni,Jason A Blome, George A Reis, Manish Vachharajani, and David I August. Rifle: Anarchitectural framework for user-centric information-flow security. In 37th InternationalSymposium on Microarchitecture (MICRO-37’04), pages 243–254. IEEE, 2004.

53. Bill Venners. The java virtual machine. McGraw-Hill, New York, 1998.54. XiaoFeng Wang, Zhuowei Li, Ninghui Li, and Jong Youl Choi. Precip: Towards practical

and retrofittable confidential information protection. In NDSS, 2008.55. Rafael Winterhalter. Byte buddy.(2017). Retrieved April, 15:2017, 2017.56. Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. Modeling and discovering

vulnerabilities with code property graphs. In 2014 IEEE Symposium on Security and Privacy,pages 590–604. IEEE, 2014.

57. Jeong Yang, Young Lee, Amanda Fernandez, and Joshua Sanchez. Evaluating and securingtext-based java code through static code analysis. Journal of Cybersecurity Education,Research and Practice, 2020(1):3, 2020.

58. Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David Mazieres. Makinginformation flow explicit in histar. In Proceedings of the 7th symposium on Operatingsystems design and implementation, pages 263–278. USENIX Association, 2006.

59. David Yu Zhu, Jaeyeon Jung, Dawn Song, Tadayoshi Kohno, and David Wetherall. Tain-teraser: Protecting sensitive data leaks using application-level taint tracking. ACM SIGOPSOperating Systems Review, 45(1):142–154, 2011.

60. Aaron Zimba and Mumbi Chishimba. Understanding the evolution of ransomware: paradigmshifts in attack structures. International Journal of computer network and informationsecurity, 11(1):26, 2019.


1

2 protected void VulnerableMethod(HttpServletRequest request, HttpServletResponseresponse)

3 throws ServletException , IOException {4 boolean success = false ;5 String username = request.getParameter(”username”);6 String password = request.getParameter(”password”);7 // Unsafe query which uses string concatenation8 String query = ”select ∗ from tblAccounts where username='” + username +

”' and password = '” + password + ”'”;9 Connection conn = null;

10 Statement stmt = null;11 try {12 conn = DriverManager.getConnection(”jdbc:mysql://0.0.0.0:3306/user”, ”

root”, ”toor”);13 stmt = conn.createStatement();14

15 //−−−−−−Termination−−−−−−16 System.err . println (”attack intercepted !”);17 System.exit (1) ;18 //−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−19

20 ResultSet rs = stmt.executeQuery(query);21 if ( rs .next()) {22 // Login Successful if match is found23 success = true;24 }25 } catch (Exception e) {26 e. printStackTrace () ;27 } finally {28 try {29 ...

Listing 1.8: Injecting the exit() method to block successful SQL injection attack at runtime

jacy: a jvm-based intrusion detection and security

Documents