real world application threat modelling by example · •threat modelling requires good...

Real World Application Threat Modelling

By Example

44Con 2013

Agenda

Threat modelling 101

Our goals

Doing it

Threat modelling 101

Why threat model?

Help with risk analysis (defensive)

Help with efficient effort investment (offensive)

Threat modelling 101

Attacker centric aka attack trees

Software, system, design or architecture

centric

Asset centric aka traditional risk analysis

Threat modelling 101

Our goals

Asses a virtual appliance with zero initial

knowledge

Map its attack surface

Develop a threat model

Our goals another perspective

Target

Djigzo Email Encryption Gateway

http://www.djigzo.com/gateway.html

Steps?

Steps

Enumeration / Discovery

Dataflow

Threat model

Phase 1 - Enumeration

Step #0 – Tools

Notepad / VIM / Whatever

Mind Mapper (FreeMind etc.)

Diagram Drawer (Visio etc.)

OS specific tooling (enumeration / debug)

Step #1 – Get shell

• Possible approaches

• Mount virtual disk image

• Live CD – add a user

• Single user mode

• Allowed functionality

• Allowed functionality

• Default username and password

Step #2 – Get root

• Possible approaches

• Mount virtual disk image

• Live CD – add a user

• Single user mode

• Product configuration issue

• Product configuration issue

• They allow a shell

• They made a mistake / overlooked

Step #3 – Enumerate?

Step #3 – Enumerate

• Product functionality

• Technologies in use

• Processes

• Listening ports

• Process to port mappings

• Users processes are running as

• Mooch around the interfaces (*scientific)

• Dig into the database (if there is one)

Step #3 – Enumerate – Product functionality

Source: Administration / Installation manual

• Console administration interface

• Web administration interface

• Email gateway

• Email encryption solution

Step #3 – Enumerate – Technology

• Linux

• Postfix

• Java

• Apache Tomcat 6

• Spring (web framework)

• Apache James (mail)

• Tanuk Software Wrapper (allow Java to run as a

daemon)

• Jetty web server (SOAP interface)

• Postgres

Step #3 – Enumerate – Processes

Step #3 – Enumerate – Listening Ports

Step #3 – Enumerate – Processes to ports

Step #3 – Enumerate – Listening Ports

Port Process Description Verified who

22 SSHD SSH daemon No need

25 Master Postfix mail transfer agent No need / experience

8080 Java Tomcat /etc/tomcat6/server.xml

8443 Java Tomcat /etc/tomcat6/server.xml

Step #3 – Enumerate – Listening Ports

Port Process Description / Function Verified how

5400 Java RMI for JMX /etc/djihzo/spring/services.xml

5432 Postgres Database server Obvious from the process

name

8005 Java Tomcat shutdown port Internet knowledge

9000 Java SOAP interface /etc/djigzo/djigzo.properties

10025 Java Mail content filter port /etc/djigzo/james/config.xml

/etc/james/smtp_server.xml

/etc/postfix/main.cf

10026 Master Postfix mail transfer

agent – mail reinjection

/etc/djigzo/james/config.xml

/etc/postfix/main.cf

15012 Java Wrapper /etc/djigzo/djigzo.wrapper.conf

58490 Java Unknown

Step #3 – Enumerate – Listening Ports

Step #3 – Enumerate – Listening Ports

Step #3 – Enumerate – Listening Ports

Step #3 – Enumerate – What’s missing?

Step #3 – Enumerate – Processes

Step #3 – Enumerate – Open Handles

ls /proc/[pid]/fd

Step #3 – Enumerate – Missing Process

Step #3 – Enumerate – Missing Process

Step #3 – Enumerate – Missing Process

Step #3 – Enumerate – Mooch

Step #3 – Enumerate – Mooch

Step #3 – Enumerate – Mooch

Step #3 – Enumerate – Firewall Rules

Step #3 – Enumerate – Database

Step #3 – Enumerate – Other Tools

Tool Purpose

checksec.sh Operating system and binary defense in depth

find File system permissions, SUID binaries etc.

tcpdump Sniff loopback adapter for database, SOAP and other IPC traffic

lsof List open files for a particular process or path

strace System call trace – see which system calls are being made by a

process

ltrace Library call tract – see which library calls are being made by a process

unzip For extracting JAR and WAR files containing the Java classes

JD-GUI Java decompiler for the Java classes

Summary so far

We have a shell and file system access

We have root on the appliance

We know the technologies

We know product functionality

We know roughly how it is built

We know what speaks to what

We have mooched around the interfaces

We have had a quick look at the database

Phase 2 – Dataflow

Step #0 – Dataflow - High-level

Step #1 – Dataflow – With Boundaries

What’s still missing?

What still missing

High-level: Logging, Platform defences

etc.

Low-level: Detailed functional flows

e.g. authentication, actions, commands,

mail transiting

Phase 3 – Threat Model based on High-Level

Threats: The Microsoft Way

Threats?

Threats: Web Interface

Threats: Admin Console

Threats: Daemon

Threats: Mail Transfer Agent

So what’s next?

We now ‘test’, ‘assess’ and or ask the

architects / developers what has been

considered and any present mitigations

How do we summarize?

Threat Impact / Risk Mitigation Residual Risk

Malformed

PDF

document

Memory corruption

leading to arbitrary code

execution in the main

daemon or wrapper

process

Written in Java Denial of Service

Phase 4 – Going Deeper

Going deeper

• Rip into database

• Application passwords stored in clear-text

• File system contents

• Soap interface credentials in clear-text

• Certificates are dynamically generated

== a more complete real world threat model

Going deeper

• Grab the Tomcat configurations

• Work out the filter chains

• See which URLs don’t’ need authentication

• Chain URLs back to Java classes

• Grab the JAR and WAR files contain the classes

• Disassemble

• Review code

== a more complete real world threat model

Conclusions for now…

The ideal process

Challenges

• Development may not have the deep threat /

mitigation knowledge

• Brainstorming with a security person helps here

• Organisations under estimate the effort, size and

complexity required to do threat modelling right

Conclusions

• Threat modelling requires good understanding of

security risks

• Developing a good threat model takes a lot of time /

effort and resource

• Enumeration of technologies and interfaces is key

• Think about possible attacks and how they are

mitigated

• Verify threats either statically or dynamically

… this presentation was only the beginning

UK Offices

Manchester - Head Office

Cheltenham

Edinburgh

Leatherhead

London

North American Offices

San Francisco

Atlanta

New York

Seattle

Australian Offices

Sydney

European Offices

Amsterdam - Netherlands

Munich - Germany

Zurich - Switzerland

Thanks! Questions?

Ollie Whitehouse ollie.whitehouse@nccgroup.com