MURI Annual Meeting
October 29, 2013

• Automated discovery of network service dependencies, based on passive observation of network traffic
2

• Goals for malware analysis
• Faster signature generation (less time from release of exploit to availability of signature)
• High quality signatures + efficient pattern matching
3

• All-in-one framework with built-in components provide rich attack-generation capabilities
• Written in scripting languages (Ruby, Python,
PHP…)
• Development / deployment of attacks + variants + combinations much faster and easier than development of patches
4

5

1. Probe Target
Port scanning,
Fingerprinting, etc.
2. Compose Attack
Payload
Includes shellcode, junk, target-specific vul bytes, etc.
3. Send Payload
Trigger vulnerability
4. Post Exploit
Wait for shellcode to be executed, backdoor channel created, etc.
6

• First system for attack script analysis
– Automatic IDS signature generation from source code
• Features
– Based on symbolic execution
– Only a few minutes to analyze new attack scripts and generate signatures: “day-one defenses”
Attack
Scripts
IDS
Signatures
7

Attack
Script
Symbolically executed
Symbolic API
Extension
Behavior &
Constraint Logging
Output API
Hooking
Symbolic Execution Layer (SymExeLayer)
Script-based Attack Framework &
Scripting Language Interpreter
Attack Payloads
Behavioral API Calls &
Attack Constraints
Constant Pattern
Extracting
Pattern Refining &
Consolidating
Pattern Context
Signature Generation (SigGen)
Deriving
Extracted Patterns Pattern Context
IDS
Signatures
8

• “Symbolize” APIs related to environment and dynamic content
• Record behavioral APIs and attack branching conditions
• Hook output API to capture the entire attack payload
9

Symbolic APIs: probe_ver() shellcode() rand_alpha()
Behavior & Constraint
Logging: probe_ver() sym_ver == 5 shellcode() & get_target_ret()
Hook output API: sock.put(payload)
10

• Extract signature patterns for specific attack payload
(e.g., constant bytes, length, offset)
• Refine patterns to filter out benign/trivial patterns, avoid duplicates
• Derive semantic context of patterns by analyzing behaviors and constraints
11

Line 23: payload => [ < sym_shellcode , len= sym_integer >,
< sym_rand_alpha , len=(1167sym_integer )>,
<" \xe9\x38\x6c\xfb\xff\xff\xeb\xf9\xad\x32\xaa\x71 ", 12 >,
< sym_rand_alpha , 2917 > ] red is symbolic value, green is concrete value alert tcp any any -> any 617 ( msg :“script: type77.rb (Win), target_version: 5, behavior: probe_version, stack_overflow, JMP to
Shellcode with vulnerable_ret_addr"; content :"| e9 38 6c fb ff ff eb f9 ad 32 aa 71 |"; pcre :" /[.]{1167}\xe9\x38\x6c\xfb\xff\xff\xeb\xf9\xa d\x32\xaa\x71[a-zA-Z]{2917}/ "; classtype :shellcode-detect; sid :5000656; )
12

• We developed a lightweight symbolic execution engine for Ruby
– No modification to Ruby interpreter required
• Integrated MetaSymploit into Metasploit Console as a simple command
• Output is
Snort rules (signatures)
• Gecode/R & HAMPI used as constraint solvers
• Currently applied to 10 popular built-in components in
Metasploit: Tcp, Udp, Ftp, Http, Imap, Exe,
Seh, Omelet, Egghunter, Brute
13

• Tested
548 attack scripts
• Average symbolic execution time:
Less than 1 minute
Category
Automatically Executed
Symbolic Loop
Non-Symbolic-Extended API Call
Obfuscation & Encryption
Multi-threading
Num Percentage
509 92.88%
9
12
13
3
Manual Modify
No
1.64% Avg 10 LOC/per script
2.19% Avg 3 LOC/per script
2.37%
0.55%
Not Supported
Not Supported
Bug in Scripts 2 0.37% Change 2 LOC
14

15

• Tested signatures on 45 Metasploit attack scripts targeting 45 vulnerable applications from exploitdb.com
• Results
– 100% detection rate with generated signatures
– 0% false positive rate on “normal” network traffic
(collected in our department)
16

• From 11/2012 Snort ruleset, only 22 out of 45 scripts had corresponding official Snort rules (based on CVE analysis)
Pattern comparison between 53 MetaSymploit generated rules and 50 official Snort rules for 22 Metasploit attack scripts
17

• Snort ruleset 07/2013 has more rules to cover
Metasploit-generated exploits
– Including Meterpreter shellcode
– Example specific rules: exploit-kit.rules
malware-tools.rules
• Good news?
18

• Fast, successful, accurate automated signature generation for scripting-based exploits
• Limitations
• Requires source code
• Standard limitations of symbolic execution: loops, path explosion, constraint solvers
• Cannot handle multi-threaded attacks
19

•
SEAndroid is currently being merged into AOSP
–goal is to reduce the attack surface using least-privilege policy
• Challenge:
(human) effort required to write suitable
MAC policies for a particular platform and applications
20

• Current policy ruleset is manually written by NSA
SEAndroid team
–793 allow rules
• Categorizes apps in a very coarse-grained way for simplicity
• Difficult to adapt rules for new platforms (ex.: The current ruleset breaks “Enforcing” mode for Nexus 7)
• The community often argues whether a new rule is correctly written
21


Automatically generate MAC policy from functional tests provided by the developers

Not intended to be comprehensive ruleset; instead, a major head start on creating rules

Writing test cases is already an essential step in app deployment; policy generation is “free”

Test cases exercise expected use and correct behavior of an app

System apps and middleware framework are already equipped with rich tests in AOSP
22

JUnit
Test
Suites
Static Parser
JUnit
Test
Suites
The tested app
Android Middleware
Linux Kernel
SEAndroid Test Runner
SEAndroid
(Audit Mode)
Semantics of Test
Cases
Runtime Behaviors of
Middleware/Kernel APIs
SEAndroid Policy Rule Generator
Auto-Generated SEAndroid
Policy Rules for this App
23

• Developers are benign, and conscientiously provide test cases with high coverage
– Should be true for system and platform developers, not necessarily true for 3rd party application developers
• Generated policies should be sound, won’t be complete, but…
– Too many policy rules?
24


We processed the test suite of the Gallery app that invokes Camera functionality to take and store photos

The test suite CameraTestRunner contains 3 test classes (13 test methods)

These tests cover all camera activities, including image storage
25


The test code and audit trace logs were analyzed to generate SEAndroid policy (only partially automated):
– allow gallery3d_app mediaserver:binder call;
– allow gallery3d_app servicemanager:binder call;
– allow gallery3d_app system_server:binder { transfer call };
– allow gallery3d_app media_app:binder { transfer call };
– allow gallery3d_app media_app:fd use;
– …(29 rules generated)
26


How to distinguish runtime contexts between the execution of test code and target app

How to handle mock / fake / isolated
Content / ContentProvider used in test cases

How to aggregate / generalize policy rules derived from test cases (reduce ruleset size)
27