Security Audit of Code

1
Security Audit of Code

Or, How I Learned to Stop Worrying and Love the
Code(Honey, did you find that last injection
attack?)?
2
Who the heck am I?

• Ed Dengler, co-founder of eSentire
• Hacking code (and systems) since 1981
• (ugh, I feel old now, anybody have a punch
  card?)?
• Interests high performance systems for security
  monitoring (yeah, big brother!) and code auditing
• Credentials? We don't need no stinking
  credentials!
• (Well, I graduated a couple of times, does that
  count? Or does that just show I'm slow?)?

3
Why Do We Care?

• Vulnerabilities allow people to gain access to
  information or systems they are not suppose to
• And we hopefully want to stop that -)?

4
Types of Vulnerabilities(got to have a few
definitions)?

• Technical Vulnerability
• No matter who you are, these are always problems
• Eg, SQL Injection
• Business Rule Vulnerability
• Requirement/policy by the business
• Eg, bank a person can only access their account
  information

5
Why a Concern?

• Great place to break in!!
• Automated scanning of SQL injections on the rise,
  used to exploit sites and inject malicious
  malware
• Regulatory requirements (PCI DSS, SOx/SAS, HIPAA,
  etc)?

• Information critical!! - bank, health-care,
  government, etc

6
Traditional Audits

• Vulnerability Assessment by Black Box testing
• Pretend to be the baddie, try to break in
• Tools such as proxy servers for manipulation
• Automated scanning tools
• Guessing game!
• Source Code Audit
• For any largish site, full audit impractical!
• An auditor takes 2-5 of the source code and
  reviews
• Only good for systemic issues, doesn't find
  everything

7
Types of Vulnerabilities

• For web applications
• Injections SQL Injection, Cross Site Scripting,
  LDAP Injection, etc
• Cross Site Reference
• Misconfiguration
• (This is always fun!) Control panel access from
  outside!
• For full applications
• Buffer overflow attack (having your email address
  be 10MB in size!!)?

8
Types of Vulnerabilities

• Any kind of logic error!!
• Denial of Service (DoS), resource exhaustion
• Trust of systems (attack one, access another)?
• Etc, etc, etc
• We will concentrate on web applications for this
  talk
• (they also happen to be the most fun!!)?
• Now for a couple in depth ...

9
SQL Injection

• Var account Request(account)Var password
  Request(password)SQL select count(1) from
  accounts where account ' account '
  and password ' password 'Results
  SQLServer.execute(SQL)?
• Heh, heh, loads of fun!!
• account ' drop table system_tables --

10
SQL Injection

• Fairly typical injection attack
• No validation/cleanup/escaping of the input
• Construction of an unsafe command from bad input
• Some Black Box Techniques
• Suite of good injection attacks
• Blind SQL (hopefully access to sleep() for
  determining if injection occurred)?
• Try to get errors (but what if errors caught?)?

11
SQL Injection

• Lots of difficulty here to get Black Box testing
  to work!!
• What if injecting into an UPDATE or INSERT?
• More complex interactions may require very
  sophisticated injections if automatic casting
  does not occur
• What are all the possible filterings and escape
  codes for the database?
• Variations between databases, which one are you
  attacking?
• What if there is some initial data checking (but
  not comprehensive)?

12
Cross Site Scripting (XSS)?

• Var question Request(question)Response.write(
  Your question was ' question '.)?
• Lots of fun again!
• Inject Javascript code to monitor interactions,
  etc
• Type 1 vs Type 2
• Blogs, news, etc are fun!

13
Cross Site Scripting (XSS)?

• Black Box testing means lots of variations!
• Context dependent usage in text, an attribute,
  in script code, etc
• Nice example is uppercasing data makes typical
  Javascript injections difficult, but not Visual
  Basic!
• Cleansing difficult
• Complex HTML via rich content editors
• Whitelist vs blacklist cleansing on input, some
  may or may not work
• Finding bad input may take quite a bit of
  ingenuity

14
Techniques for Black Box Testing

• Scanning tools, automation (needed for the volume
  we are dealing with!)?
• Proxy server to monitor/log efforts, manipulate
  queries/URLs (labour intensive!)?
• Injection attacks modify user input, cookies,
  etc (many, many variations!), fuzzing
• AJAX makes life more difficult
• Both to generate valid input for injection, as
  well as verifying output has been changed

15
Techniques for Black Box Testing

• Configuration scan network, access urls that
  might be administration tools
• Business requirements no help here, must use
  your brain to analyze!
• Dark grey box testing as you learn, you can use
  info to modify your attack!
• But this is a the labourious part!

16
Classes of Findings(yeah!! more definitions!!)?

• True Positive found a problem!
• True Negative there is no issue!
• False Positive
• this is a problem!, when it isn't!
• False Negative
• no problem, man!, but there is!
• Heard about the PCI auditors being sued?

17
When Black Box Testing

• Usually no false positives (but only if the
  auditor actually verifies!)?
• Complexity issues way too many pages!
• Cannot test everything
• Some things depend on specific ordering and
  values (think wizards)?
• Lots of false negatives (many missed
  vulnerabilities)!
• SQL injections that don't seem to work

18
So Why Source Analysis?

• No guessing, can see all the code
• White box testing
• But, oh my, so much of it!!
• 10k pages .ASP sites
• 1000's of classes Java sites
• Etc, etc, etc
• Dynamic (run-time) vs Static
• Analogous with TDD and static type checking

19
Why Source Analysis?

• How do you
• Detect backdoors?
• Dead pages?
• Eg, 10k page site, 25 of site old dead pages
  (old versions, with injections fixed in non-dead
  pages!)?
• Bugs in cleansing/validating
• Yeah, corner cases missed!!
• Note REcon showed how to do some of this via
  black box testing, but very hard!

20
Why Source Analysis?

• Parameters for HTTP queries can be found
• May not be used, but legacy still exists
• Persistent attacker may eventually find, or
  leverage parameters from other pages
• Have seen this for XSS!!
• Complex interactions A, then B, then C, then
  problem!

21
Why Source Analysis? Hardware!

• Parallel example
• Intel has become a big proponent of formal
  methods to verify hardware design
• Pentium Floating Bug cost them half-a-billion
  dollars (you bet that hit the bottom line) and a
  big PR headache!!
• Large group within Intel designing verification
  and simulation tools to verify their hardware

22
Where Did It Come From?

• Writing code with more static checks is better
  than dealing with run-time errors is better than
  just failing in random ways
• Language evolution assembler ? early structured
  languages ? user-defined types ? lint ? complex
  implicit type checking
• Logics of programming
• start with Hoare/Floyd ca 1968
• logical assertions (X is true now) at key
  points
• Need theorem provers (big, complex, slow!)?

23
Theorem Proving

• Theoretically perfect except.. that perfect
  theorem proving is impossible
• Just moved the problem, so what now?
• Use a weaker prover that sometimes says "don't
  know"?
• Develop a stronger prover that answers more
  often?
• Use a weaker theory that "ignores" certain
  problems but more provable?
• Use a stronger theory that approaches "the way
  the programmer thinks"?

24
Halting Problem

• Warning! Science content!
• This is similar in scope to the Halting Problem
  (and beyond)!
• This means that sometimes you cannot tell if a
  security vulnerability exists or doesn't exist
• So what do you do?

25
New Class of Findings

• Unknown
• Cannot say anything one way or the other
• How do you treat the unknown?
• Treat as positive (true or false) ? may be too
  large!
• Expense? Time? Risk of cost to solve
• Treat as negative (true or false) ? may leave
  problems
• Risky!! Risk to business if wrong

26
Model Checking

• Beginning Clark/Emerson ca 1980
• Compile source to a model (state transition,
  automata, etc), and validate assertions
• Simpler space to reason about, but abstraction
  may lose too much (maybe too much?)?
• Allows to model conditions you need to prove

27
Quick History

• Good code is secure code
• So check general "goodness", good structuring,
  lint
• Enhance lint for security patterns (splint.org)?
• Eg. array bounds checking is general good
  property
• And no bounds violations no buffer overflows
• Or, model security requirements in logic
  (Glasgow, Panangaden. etc)?

28
Areas of Research

• (For apps) Stack overflow detection via modeling
  of data input
• Abstract interpretation / Flow analysis for
  code/issue tracing
• Temporal logics for code dependencies
• Automata trace verification (ala hardware)?
• SAT/etc models to find closed properties
• Eg, Ardilla checks PHP code for XSS and SQL
  Injection

29
Some Issues

• Does the tool support generation of sample input
  to demonstrate problem?
• Does it run the vulnerability to ensure the issue
  occurs?
• Does the tool accept false negatives to reduce
  the number of false positives?
• Does the tool allow addition of extra information
  to remove whole classes of issues?

30
So Where Are We Today?

• Big active area of research
• Commercial tools now available
• Fortify, Coverity, etc
• SPARKAda verifiable code
• Faster, better theorem provers are allowing us to
  edge out larger problems to solve

31
Current State of Affairs

• Just now starting to become mainstream
• Lots of issues/difficulties still!
• Lots of opportunity to advance!
• eSentire is developing tools for performing such
  audits, for both technical and business rule
  vulnerabilities

32
Questions?

• Ed Dengler
• eSentire, Inc.