Application Trustworthiness · “Hacking Second Life”, Metaverse08, Karlsruhe 2008 “Hacking Second Life”, Hack-in-the-Box, Dubai 2008 “Reversing – A structured approach”,

Application Trustworthiness

Michael Thumann [email protected]

© ERNW GmbH . Breslauer Str. 28 . D-69124 Heidelberg . www.ernw.de 1 10/15/08

#whoami

© ERNW GmbH . Breslauer Str. 28 . D-69124 Heidelberg . www.ernw.de

  Head of Research & Chief Security Officer, ERNW GmbH

  Talks und Publications:   “Reversing – A structured approach“, Troopers, München 2008   “Hacking Second Life”, Metaverse08, Karlsruhe 2008   “Hacking Second Life”, Hack-in-the-Box, Dubai 2008   “Reversing – A structured approach”, RSA Conference, San Francisco 2008   “Hacking SecondLife”, Blackhat Europe, Amsterdam 2008   “Hacking the Cisco NAC Framework”, Sector, Toronto 2007   “Hacking SecondLife”, Daycon, Dayton 2007   “Hacking Cisco NAC”, Hack-in-the-Box, Kuala Lumpur, 2007   “NAC@ACK”, Blackhat-USA, Las Vegas, 2007   “NAC@ACK”, Blackhat-Europe, Amsterdam, 2007   “Mehr IT-Sicherheit durch PenTests”, Vieweg Verlag 2005

  Main Tasks:   Reverse Engineering   Security Research   Penentrationstests   Code Audits

10/15/08 2

Agenda

1.  Introduction 2.  Blackbox Tests 3.  Fuzzing 4.  Code Review 5.  Reverse Engineering 6.  Metrics 7.  Summary

© ERNW GmbH . Breslauer Str. 28 . D-69124 Heidelberg . www.ernw.de 10/15/08 3

Let’s start …


Bryan, this is for you

Introduction

  Programming Errors are everywhere   An Error is not a security vulnerability, but it can be one   There is no bug free software   This talk covers the most important approaches for

security testing to answer the question “Can I trust this application?”


Application Lifecycle


LOW HIGH

Design Review

Blackbox Box Test Threat

Model

Security implementation costs

Code Review

Blackbox Test


Phases of a Pentest


Initial Workshop

Technical Assessment Report

Initial Workshop

  The type of attacker must be defined (Insider / Outsider)   Most important: The tester must understand the real

question of the customer   Emergency procedures should be defined for high severity

findings


Technical Steps in a Pentest

Reconn-aissance

Enumer-ation

Vulnera-bility

Research Exploita-

tion

Documen-tation


Vulnerability Research

  Automated Tool Approach (Vulnerability Scanner)   Manual Research on Web Sites based on enumerated

versions of running services


Exploitation

  Use of Exploit Frameworks (Metasploit, Core Impact, CANVAS) or Attack proxies (for web applications)

  Web Research for usable Exploits   Analysis of the vulnerability and development of an exploit


Documentation

  Screenshots   Tool output / reports   Time of test


The report

  Detailed description of all findings including exploits   Mitigating controls   Severity rating for example based on CVSS (Common

Vulnerability Scoring System)   Management Summary   The answer to the customers question


Fuzzing


Definition

  “Fuzz testing or Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion http://www.owasp.org/index.php/Fuzzing

  “A highly automated testing technique that covers numerous boundary cases using invalid data (from files, network protocols, API calls, and other targets) as application input to better ensure the absence of exploitable vulnerabilities.” Peter Oehlert, “Violating Assumptions with Fuzzing”, IEEE Security & Privacy, March/April 2005


Why fuzzing?

  Uncovering Security Problems with Reverse engineering is really hard work

  Fault injection or fuzzing ist the easiest approach to check your applications for vulnerabilities and bugs

  Most bugs are discovered using fuzzers   No need to investigate the bug, just proove that it is there   And it‘s cost effective and works quite well if the source

code is not available


Fuzzing Pitfalls

  Some knowledge about the stuff you want to fuzz is needed (protocols, file formats)

  You need smart tools to ensure that you‘re not just looking for the „low hanging fruit“

  E.g. think of fuzzing the „Subject“ field when sending an email over SMTP with authentication

  You have to send useful data, just sending lots of „As“ won‘t do the job


Code Review


Source Code Audit


Source Code

Automatic Code

Review

Authenti-cation

Secure Program-

ming

Error Handling

Access Control

Code Complex-

ity

Sensitive Data

Handling

Automatic Code review

Code review   Using Code Scan tools the provided Source Code is

checked for common programming errors leading to security vulnerabilties. The findings are reviewed manually to filter „False Positives“.

  After the automated audit the source code is also checked manually to find errors that can’t be detected by tools.

  The reviewer follows a strict questionnaire that is explained in the following slides

10/15/08 21 © ERNW GmbH . Breslauer Str. 28 . D-69124 Heidelberg . www.ernw.de

Fortify SCA

  Automated Source Code Scan including input trace


Authentication

check if …   Sensitive Applications are using a multifactor

authentication (username, password, token)   Authentication is predictable (e.g. Session or

Authentication Cookies, default passwords)   Corporate users are stored in a central directory that is

separated from external/partner identities.


Secure Error Handling

  Error Handling must be done in an appropriate way to avoid unhandled error situations and the disclosure of sensitive information.

  Don’t send stack traces or debug output to the user!   Check return values for errors to avoid null pointer

dereference problems   During the code review the reviewer checks if this

requirement is fulfilled.


Principles of Secure Programming

  Developers must follow the principles of secure programming for the chosen language to avoid errors that lead to security vulnerabilities. The auditor checks the code for the following principles:   No use of „Banned Functions“   Well known cryptology that is considered to be secure (algorithms, key

length and so on) is used   All input and output is validated and sanitized


Principles of Secure Programming


Access Control

Check if …   The application provides separate roles for general users,

administrators and line-of business roles   Privileges are applied to roles rather than to named users.   If permissions are enforced, e.g. in the database (users or

even better roles must be impersonated when accessing the database)


Code Complexity

  Program code should be simple to avoid errors and to ensure the maintainability of the code.

  Code qualitiy metrics (McCabe, Halstaed and Maintainability Index of the Software Engineering Institute) are used to ensure that the code is simple and maintainable.


Code Complexity

  The McCabe Metric (aka Cyclomatic Complexity) is based on the decision tree (number of decisions) in an application (if- and case statements, loops)

  The Halstaed Metric contains different values. The most important are “estimated number of bugs” and “implementation effort” that are based on the size and complexity of the code. Halstaed uses the number of operands and operators to calculate the values.

  The Maintainability Index is based on McCabe and Halstaed values, average lines of code and average percent of lines of comments


McCabe Code Complexity


0

5

10

15

20

25

30

35 com.ernw.test.action

com.ernw.test.action.util com.ernw.test.actionreference

com.ernw.test.bean

com.ernw.test.comparator

com.ernw.test.custom

com.ernw.test.entity

com.ernw.test.entity.base

com.ernw.test.entity.base.impl

com.ernw.test.entity.copy

com.ernw.test.entity.impl

com.ernw.test.entity.test

com.ernw.test.hibernate com.ernw.test.job

com.ernw.test.listener com.ernw.test.mediator

com.ernw.test.scheduler

com.ernw.test.service

com.ernw.test.sitemesh

com.ernw.test.struts2

com.ernw.test.struts2.components

com.ernw.test.struts2.converter

com.ernw.test.struts2.interceptor

com.ernw.test.struts2.validation

com.ernw.test.struts2.views.jsp

com.ernw.test.struts2.views.jsp.ui

com.ernw.test.transformation com.ernw.test.util

AVCC

AVCC

Halstaed Efficiency


0

200000

400000

600000

800000

1000000

1200000



com.ernw.test.bean








com.ernw.test.entity.test com.ernw.test.hibernate

com.ernw.test.job com.ernw.test.listener

com.ernw.test.mediator com.ernw.test.scheduler











HEFF

HEFF

Maintainability Index


0

50

100

150

200



com.ernw.test.bean








com.ernw.test.entity.test com.ernw.test.hibernate

com.ernw.test.job com.ernw.test.listener

com.ernw.test.mediator com.ernw.test.scheduler











MI

MI

Overall Result


Metric Value

McCabe AVCC 1,41

Halstaed HBUG 67,53

Maintainability Index MI 146,92

Sensitive Data Handling

  Sensitive data (e.g. user credentials) must be encrypted in transit and stored securely (encrypted) on the systems.

  Usernames, password and crypto keys should not be stored in the source code


Sensitive Data Handling


Reverse Engineering


Reverse Engineering - Definition

  is the process of discovering the technological principles of a device or object or system through the analysis of its structure and functions. It often involves taking something (mechanical device, electronic component, software program) apart and analyzing its workings in detail, usually to try to make a new device or program that does the same thing without copying anything from the original.


Why Reversing


  Because you need to know how the stuff is working   Because Applications are very often distributed as

binaries only   Because someone wants you to answer the question “Can

I trust this application?”   Answering this question can be a MUST in big companies,

e.g. because of regulatory requirements

Program Flow - Flowchart


Program Flow – From main

Main


Program Flow – ignore everything but user defined functions


Program Flow – Uff


Understand what the function is doing – Example


Understand what the function is doing – Example (Decompiler)


Reversing .NET

  Of course IDA can do this job too   There are also dedicated tools like .NET Reflector which

are able to do very good disassemblies




Did you know ...

  That you‘re giving your sources away with C#?   That reversing/decompile native C# Apps is sooo easy?   That attackers can find interessting point of attacks quite

easily, if they have source code access?   Security through obscurity doesn‘t work, but Code

Obfuscation makes the Reverse Engineers life at least harder


Combining Test Methodologies

  Some of the mentioned test methodolgies can be combined, e.g. Blackbox Test and Code Review to look for vulnerabilities from a different point of view and get a greater accuracy

  Reverse Engineering as a requirement to do some kind of Code Review


Metrics


Metrics

  Metrics can help to decide about the trustworthiness of an application depending on the processed data

  Metrics are not based on a technical assessment only   Metrics should be comparable to measure improvements   Measuring Code Complexity is already the usage of a

metric


Metrics

  ERNW uses a special metric in customer projects   Parts are based on the Application Insecurity Index (AII)

developed by Andrew Jaquith   Parts are changed to reflect our customers requirements

and our testing methodology


Example of a result


Summary


Final conclusion

  Security Testing is a MUST today, especially when you’re processing internal or confidential data

  Security Testing must be part of the application lifecycle (think Microsoft )

  There are different approaches for security testing, each with its own value

  Metrics must be used that reflect the requirements of the companies (not only technical results)

  Metrics must be comparable between applications and between assessments to support you in choosing the right application and measure your security improvements


Looking further

  There’s stuff that must be improved   We need better and more effective tools for binaries like

Vulnerability Scanners and Code Metrics tools   We need standardized metrics that are well understood

and accepted by the companies   There will be a big need for rating the application

trustworthiness in the future and we must be prepared


© ERNW GmbH . Breslauer Str. 28 . D-69124 Heidelberg . www.ernw.de

Questions? And Answers…

10/15/08 57

Thank you for your attention! Email:[email protected] Homepage: www.ernw.de


Documents

Application Trustworthiness · “Hacking Second Life”, Metaverse08, Karlsruhe 2008 “Hacking Second Life”, Hack-in-the-Box, Dubai 2008 “Reversing – A structured approach”,