Threats and Countermeasures Against Java Code

1
Threats and Countermeasures Against Java Code

• Ryan Schefke, rschefke_at_arxan.com,
• 469-675-1313
• Mike Dulaney, mdulaney_at_arxan.com,
• 301-468-4286

2
Funny Java Cartoon
3
Market Drivers for Security

• Growth in emerging markets increases risk
• Software platforms of all types becoming more
  open
• Threats moving from network inward to application
• Intermediate languages growing in popularity
• Asset valuations around intangible assets
  (software IP) growing
• 80 of SP 500 companies largest assets are
  intangible
• Trend of GDP moving from physical to conceptual
  output
• Rich internet applications (Web 2.0)
• Silverlight, JavaFX, Flash, AJAX
• Calls for a need to protect investments in
• Licensing
• Software intellectual property
• Digital media
• TODO Incorporate ISVs at Risk and Enterprises
  at Risk Slides

4/20/07 Arxan Confidential
4
Enterprises at Risk

• Malware rampant and growing exponentially
• 327,059 unique malware exploits today
• 33 of those created after 1/1/2007
• 250 new exploits identified daily
• More than 90 of exploits are obfuscated via
  encryption or packing
• Makes todays signature-based detection
  ineffective
• Majority of hacking attacks by insiders
• Estimates range from 60-80
• Perimeter security measures ineffective against
  insiders
• 75 of hacks occur at the application level
  (Gartner, 2007)
• Applications are vulnerable

Source McAfee research, Gartner
5
ISVs at Risk

• Intellectual Property Loss
• Critical algorithms
• Susceptible to insider threats as employee
  turnover increases during the recession
• Competitors save on cost by reverse engineering /
  stealing your code
• Technology increasingly deployed in emerging
  markets
• E.g., outsourced development
• Lost Revenue
• Business Software Alliance estimates that
  collectively, ISVs lose 40B in revenue each
  year due to piracy
• Forums devoted to software cracking
• Give away illegal for pennies on the dollar

6
Java Everywhere Vulnerable

• Widely adopted platform
• Web and enterprise applications
• Thick client applications (have traditionally
  been coded as native desktop applications)
• Javas bytecode format is rich in metadata and
  semantic information ? valuable and easy to
  reverse-engineer, tamper or compromise
• Risk now magnified from Cyber Attacks
• Over 1 Trillion in Intellectual Property lost
  due to data theft and cybercrime
• 75 of hacks occur at the application level

7
Java Code Vulnerabilities

• Reverse engineering
• After download to the client, reverse engineer a
  bytecode file and decompile the code for IP theft
  or bypass critical routines
• Bypass critical routines
• Thick client patches to bypass authentication
  logic or exploit restricted functionality
  contained that enable server attacks
• Key and credential theft
• Secret keys or authentication credentials simply
  identified, and can then be abused to launch
  server attacks
• Easy decompilation
• Hackers can quickly decompile your bytecode with
  free or low-cost Java decompilers that process
  bytecode to produce readable source code, which
  they modify to implement hacks or create
  counterfeits
• JRE Modification TODO

8
Learning about you

• Who is associated with Java projects,
  personal/business?
• Who takes steps to protect the Java code?
• Why is Java inherently insecure?
• What threats face Java applications?
• Who uses software-based license management today?
• Who has experienced piracy or IP theft?

9
Java Hacking Exploit Examples

• Enterprise and web applications
• Exploits enable theft of sensitive data ? whether
  from backend databases or from client front ends
• Enterprise and desktop applications
• Exploits can inject malware ? i.e. exploiting
  input-based vulnerabilities or compromising the
  authentication methods designed to securely
  update deployed software
• Licensed software
• Exploits enable piracy ? circumventing license
  management or by building counterfeits

10
Example

• Example of major Java Breach

4/20/07 Arxan Confidential
11
Java Protection Solutions

• Anti-Reverse Engineering
• Code Transformation
• Mitigates static and dynamic attacks
• Can adversely impact performance
• Metadata Renaming
• String Encryption
• Anti-Debug
• Anti-Tamper
• Integrity Verification
• Encryption

12
Requirements Anti-Reverse Engineering

• Stops decompilation
• Ensures youre not shipping source code
• Protects software at runtime and on disk
• Makes debugging difficult
• Protects against disassemblers
• Make MSIL bytecode hard to follow / reverse
  engineer
• Protects Strings
• E.g., SQL queries
• Robust
• Should not introduce bugs
• Minimal Performance / Size Impact
• Tunable so as not to affect performance
• Supports stack traces
• Provides a mapping to interpret mangled metadata
• Interoperable
• Reflection, Plug-in architectures, DLLs, etc

13
Requirements Anti-Tamper

• Cant easily be disabled
• Protected against decompilation
• Difficult to find
• Behavior is difficult to predict
• Does not significantly impact performance
• Security executes infrequently
• Layered security
• Must disable numerous anti-tamper technologies to
  successfully modify application behavior

14
Class Encryption Class Loader Approach

• Class Loaders Background
• Extend the JVM functionality to load classes from
  various sources (e.g., from a database or an FTP
  server)
• Extend implementation of JRE Class Loader
• Gain access to the class bytes before the JVM
• Reliable place for performing decryption
• Important methods
• defineclass()
• findclass()
• Problem Can be easily defeated by modifying the
  JRE!
• defineclass() method in Encrypted Class Loader
  eventually calls defineclass() in JRE

15
TODO Add more technical detail on class loaders
16
Demonstration Encrypted Class Loader
Implementation Hack
17
GuardIT for Java Technology Framework

• Renaming Guard
• Replacement of meaningful names in bytecode with
  meaningless names.
• Class Encryption Guard
• The Class Encryption Guard transforms Java class
  files to an obscure format (ciphertext) that is
  unreadable by machine or human. The Guard
  encrypts class files at protection time and
  restores them to their pre-encrypted state at
  runtime before they are loaded, so that the
  protected program runs as intended.
• Obfuscation Guard
• Sophisticated code obfuscation using GuardIT to
  deeply leverage the structure and behavior of
  Java code to defeat decompilers
• String Encryption Guard
• Encryption of constant strings and interception
  of constant string references to hinder static
  and dynamic reverse engineering

18
Questions?

• Ryan Schefke, rschefke_at_arxan.com,
• 469-675-1313
• Mike Dulaney, mdulaney_at_arxan.com,
• 301-468-4286

19
Agenda

• Introductions
• Threats A Black Hat World
• Decompilation Demonstration
• Software Protection The White Hat Response
• Class Decryption Demonstration
• Questions Answers