1 / 34

Jarhead Analysis and Detection of Malicious Java Applets

Jarhead Analysis and Detection of Malicious Java Applets. Johannes Schlumberger , Christopher Kruegel , Giovanni Vigna University of California Annual Computer Security Applications Conference (ACSAC) (December, 2012 ) Reporter: 鍾怡傑 2013/03/25. Outline. INTRODUCTION BACKGROUND

carys
Download Presentation

Jarhead Analysis and Detection of Malicious Java Applets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. JarheadAnalysis and Detection of Malicious Java Applets Johannes Schlumberger, Christopher Kruegel, Giovanni Vigna University of California Annual Computer Security Applications Conference (ACSAC) (December, 2012) Reporter: 鍾怡傑 2013/03/25

  2. Outline • INTRODUCTION • BACKGROUND • Java applet • Java exploits • JARHEAD SYSTEM OVERVIEW • FEATURE DISCUSSION • Obfuscation • Behavior • EVALUATION • Manually Dataset • Wepawet Dataset • POSSIBLE EVASION • CONCLUSIONS

  3. INTRODUCTION • We address the problem of malicious Java applets, a problem on the rise that is currently not well addressed by existing work. • Jarhead uses static analysis and machine learning techniques to identify malicious Java applets.

  4. INTRODUCTION • Drive-by download attacks • Social engineering attacks

  5. INTRODUCTION • Signature-based detection avoidable byobfuscation • Honeyclients need vulnerable softwarecombination • Java plugin version • Java version • Browser and OS version

  6. BACKGROUND-Java applet • Java bytecode + application files • Commonly bundled as Jar-archive • Embedded in web pages • Executed by web browsers in sandboxed JVM • Optional digital signature disables sandbox • Developed in the 90ies for mobile code • Superseded by CSS, JavaScript, Flash, . . . • Modern browsers still support Applets Next

  7. Jar-archive

  8. Embedded in web pages • <applet code="xxxx.class” archive="test.jar" width="550" height="150"><param name="bgcolor" value="255,255,255"><param name="font" value="新明細體"></applet>

  9. Digital Signature https://chrometerm.appspot.com

  10. BACKGROUND-Java exploits • Users unaware of Java applets • Plugins default enabled • Plugins out of date • Multiple vulnerabilities in the JVM or Javalibrary

  11. JARHEAD SYSTEM OVERVIEW • Detector for malicious Java applets • Static • Reliable • Accurate • Fast • Offline • Robust • Low maintenance • Analyzed large number of samples • Detected previously unknown exploits

  12. How does Jarhead work? • Unpack • Disassemble • Statically extract feature set • Classification • Result

  13. Why statically? • Partial exploits can not be analyzed dynamically • Resistant to fingerprinting/evasion • Independent of Environment (JVM/Java version, OS,. . . ) • 100% Code coverage

  14. FEATURE DISCUSSION • General metrics (size in bytes, . . . ) • Obfuscation • Code metrics • String obfuscation • Active code obfuscation • Behavior • Interaction with security-critical components • Download and execute • Jar Content • Known vulnerable functions • 42 features total

  15. Obfuscation

  16. Code metrics • We collect a number of simple metrics that look at the size of an applet, i.e., the total number of instructions and the number of lines of disassembled code, its number of classes, and the number of functions per class. • Cyclomatic complexity is a complexity metric for code, computed on the control flow graph (CFG). • To find semantically useless code, we measure the number of dead local variables and the number of unused methods and functions.

  17. String obfuscation • Strings are heavily used by both benign and malicious applets. • The reason for string obfuscation is to defend against signature-based systems. • For the length feature, we determine the length of the shortest and longest string in the pool as well as the average length of all strings.

  18. Active Code Obfuscation • To counter code analysis techniques that check for the invocation of known vulnerable library functions within the Java library, malicious applets frequently use reflection. • To detect such activity, we count the absolute number of times reflection is used in the bytecode to instantiate objects and to call functions. • We check if the Java.io.Serializablejava.lang.Objector java.lang.Classinterface. • we check if the JavaScript interface is used.

  19. Behavior

  20. Interaction with security-critical components • Several vulnerabilities in different versions of the Sun Java plugin have led to exploits that bypass the sandboxing mechanisms. • Runtime class • System class • ClassLoaderclass

  21. Download and execute • For a successful exploit, it is necessary to execute a file after it has been downloaded. • Java.net.URL objects • Sockets • Write files • spawn a new process

  22. Jar Content • The number of files in the Jar that are not Java class files(media files, images, . . . ). • Binary machine code in the archive.(executable or library) • The total size of the Jar archive in bytes

  23. Known vulnerable functions • MidiSystem.getSoundbank() • javax.management.remote.rmi.RMIConnectionImpl() • MIDlet • The combination of functions is MidiSystem.getSequencer, and Sequencer.addControllerEventListener • javax.management.MBeanServer interface

  24. Obfuscation features • Cyclomatic complexity • Semantically useless code (dead variables,unused functions, . . . ) • Percentage of non-ASCII strings • Length and number of Strings • Use of Reection • Dynamic code loading • Invocation of JS interpreter

  25. Behavioral features • Interaction with Runtime • Interaction with System Security Manager • Check for extensions of the ClassLoader • Use of URLs, FileStreams, . . . • Ability to spawn process • SMS-send functionality • Call to known vulnerable functions

  26. Top ten features

  27. EVALUATION • Manually collected (2,854 samples) • Applet collection sites • http://echoecho.com • http://javaboutique.internet.com (http://www.jguru.com/) • Malware researchcommunity site • http://filex.jeek.org • Security site • http://www.malwaredomainlist.com • Web crawl • Wepawet (1,551 samples) • https://wepawet.iseclab.org/

  28. Manually Dataset • Virustotal found 1,721 (82.1%) of the files to be benign and 374 (17.9%) to be malicious • Virustotal has actually misclassified 61 (2.9%) applets. • 34 (1.6%) benign applets as malicious • 27 (1.3%) malicious applets as benign • The classifier only misclassified a total of 11 (0.5%) samples. • The false positive rate was 0.2% (4 applets) • The false negative rate was0.3% (7 applets)

  29. Comparison of Jarhead and Virustotal misclassifications

  30. Wepawet Dataset • The authors of Wepawet provided us with 1,551 Jar files. • Virustotal found 413 (32.4%) applets to be benign and 862 (67.6%) applets to be malicious.86 (6.7%)samples • 59 (4.6%) malicious applets as benign • 27 (2.1%) benign applets as malicious. • We found a total misclassification count of 21 (1.6%) • The false positive rate was 0.9% (12 applets) • The false negative rate was 0.7% (9 applets)

  31. Jarhead’s performance on the Wepawetdataset

  32. POSSIBLE EVASION • It is possible to use the Java native interface (JNI) to execute native code on the machine. This is not covered by our analysis. • Malicious behavior is distributed among multiple applets within a single page • A completely new class of exploits or vulnerabilities could bypass our detection either

  33. CONCLUSIONS • We address the quickly growing problem of malicious Java applets by building a detection system based on static analysis and machine learning. • We also deployed our system as a plugin for the Wepawet system, which is publicly accessible. • In the future, we plan to improve our results by using more sophisticated static analysis techniques to achieve even higher accuracy.

  34. Thank you. . .any Questions?

More Related