Automated Analysis and Signature Generation for Script

Report
Automated Signature
and Policy Generation
Douglas S. Reeves
MURI Annual Meeting
October 29, 2013
Past Work: NSDMiner
• Automated
discovery of
network
service
dependencies,
based on
passive
observation of
network traffic
2
Recent Work: MetaSymploit
• Goals for malware analysis
• Faster signature generation (less time from
release of exploit to availability of signature)
• High quality signatures + efficient pattern matching
3
Script-Based Attack “Factories”
• 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
Ex: Metasploit
5
Script Example
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
MetaSymploit
• 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
MetaSymploit
IDS
Signatures
7
Attack
Script
Architecture
Symbolically executed
Symbolic API
Extension
Output API
Hooking
Behavior &
Constraint Logging
Symbolic Execution Layer (SymExeLayer)
Script-based Attack Framework &
Scripting Language Interpreter
Attack Payloads
Constant Pattern
Extracting
Behavioral API Calls &
Attack Constraints
Pattern Refining &
Consolidating
Pattern Context
Deriving
Signature Generation (SigGen)
Extracted Patterns
IDS
Signatures
Pattern Context
8
Symbolic Execution Layer
• “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
Script Example
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
Signature Generation Layer
• 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
Example of Signature
Line 23: payload => [ <sym_shellcode, len=sym_integer>,
<sym_rand_alpha, len=(1167-sym_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
Implementation
• 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
Evaluation: Speed and Completion
• Tested 548 attack
scripts
• Average symbolic
execution time:
Less than 1 minute
Category
Num
Percentage
Manual Modify
Automatically Executed
509
92.88%
No
Symbolic Loop
9
1.64% Avg 10 LOC/per script
Non-Symbolic-Extended API Call
12
2.19% Avg 3 LOC/per script
Obfuscation & Encryption
13
2.37%
Not Supported
Multi-threading
3
0.55%
Not Supported
Bug in Scripts
2
0.37%
Change 2 LOC
14
Evaluation: Detection Rate
15
Evaluation: Detection Rate
• 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
Evaluation: Comparison with
Public Ruleset
• 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
17
rules and 50 official Snort rules for 22 Metasploit attack scripts
Evaluation: Comparison (cont’d)
• 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
Discussion
• 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
Future Work: Test-Driven
Security Policy Generation
• 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 status of SEAndroid Policies
• 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
Proposed Approach

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
Proposed WorkFlow
JUnit
Test
Suites
JUnit
Test
Suites
The tested
app
Android Middleware
Linux Kernel
Static Parser
Semantics
of Test
Cases
SEAndroid Test Runner
SEAndroid
(Audit Mode)
Runtime Behaviors of
Middleware/Kernel APIs
SEAndroid Policy Rule Generator
Auto-Generated SEAndroid
Policy Rules for this App
23
Assumptions
• 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
Example



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
Example (cont'd)

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
Challenges



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

similar documents