Threat Modeling. A workshop on how to create threat models by creating a hands-on example

(1)

Threat Modeling

A workshop on how to create threat models by creating a hands-on example

(2)

(3)

3

(4)

Part 1:

Application-Layer Attacks

A brief primer on some web application attacks

(5)

5

Authentication

• How can you break authentication?

– Brute-force – Dictionary

– Birthday paradox

– Forgotten passwords (Paris Hilton attack)

• More advanced forms:

– Timing-based attacks – Cryptanalysis

(6)

Session Management

• Lots of potential attacks:

– Guess Session ID – Modification attacks – Content-caching

– Replay attacks / Session-hijacking – Cookie attack – DNS cache poisoning – XSS (Input/Output validation)

(7)

7

Parameter Manipulation

• Free TVs for everyone!

(8)

SQL Injection

• DB can’t differentiate between user-supplied values and computer generated values

• Classic ‘1’=‘1’ attack – of course can get very severe

(9)

Part 2: Threat Model

Case Study

Intro to the case study for this class

(10)

Case Study Introduction

• You are consultants for Security Compass

• You have been contracted to perform a source code review and threat model on the False Secure Order web services site

– You will have 1 week to cover 7,500 out of over 145,000 lines of code

• You, as a group, have just over 2 hours to perform the threat model

– Prioritize which areas to cover in the threat model and identify which components are most critical

• You will review the architecture, interview the architect,

determine data flows, determine and prioritize risk, and provide a list of countermeasures against high risk threats to look for in the review

(11)

11

Steps of Threat Modeling

Gather

Information

DFDs

Brokerage Users Diagram User Type

Regular User Admin User Decompose App Identify Risk

Regular Users Read ACR Values

Calls

Caller Action Client Bro wser Request data Apache Web Server Send MQ Message My App Server Retrieve data from DB

Affected Roles Regular, Administrative Users

Net Data Effect ReadMailing Options/ Mailing Options History

Threats and Risk Ratings

Use Cases

Attack Trees

(12)

Gather Information

• Architect will walk you through the architecture of the application

– Please review the architecture documents provided

• Questions to ask Architect:

– Describe the application – Who uses it? What is it used for? How often is it used? What kinds of data does it hold?

– Determine regulatory / legislative applicability – Does it store/handle Personal data? Financial-reporting data? Cardholder data? Any others?

– What systems does it connect with? – What are the entry points?

– Major app-sec domains: How does it handle access control, session

management, logging, and input validation? Note that the architect is at too a high level to discuss issues such as error handling

– Remember the 5 Ws to determine business risk

• Who? What? When? Where? Why? • “How” comes afterwards

(13)

13

Steps of Threat Modeling

Gather

Information

DFDs

Calls

Use Cases

Attack Trees

(14)

Decompose App

• Using the worksheets and stickers provided, break down:

– System Components – Users

– Data Types

(15)

15

Steps of Threat Modeling

Gather

Information

DFDs

Calls

Use Cases

Attack Trees

(16)

Data Flow Diagrams

• As a group, we’re going to create

a Level 1 DFD for a typical

transaction flow based on the data we’ve been given

– Identify components, data stores, and flow of data

– Determine trust boundaries – are those trust boundaries legitimate?

• A Level 2 DFD would use the layers described in the

presentation and middle tier design documents

– Allows us to drill in on those components we need to look at most Client Browser Web Server End User App Server Database 1. Client sends request over web 2. Web server forwards request to app server 3. App server processes logic and updates DB 4. Application server returns message to web server 5. Message returned to client

(17)

17

Interactive Time

• Our next steps will involve examining use cases and determining risk levels • So what are the most pertinent use cases for this application?

(18)

Steps of Threat Modeling

Gather

Information

DFDs

Calls

Use Cases

(19)

19

Create Use Case

• Using the worksheets and stickers provided to fill out use cases – based on a single transaction flow from the DTD

• Example: I-Tracker DB I-Tracker App Client Browser 1. Sends inventory update HTTP form 2. Forwards HTTP Request 3. Upda te DB I-Tracker Web Notifications 4. Notifies sh_ipping team

User Updates Inventory in I-Tracker User Updates Inventory in I-Tracker

Notification is sent to shipping if necessary Notifications

I-Tracker App 4

App Server updates DB with new value for inventory I-Tracker DB

I-Tracker App 3

Web server forwards request to app server I-Tracker App

I-Tracker Web 2

Client sends an inventory request form submitted via the app along with JSESSION ID cookie

I-Tracker Web Client 1 Description Receiver Sender Call #

Description of Call Flow

Notification is sent to shipping if necessary Notifications

I-Tracker App 4

App Server updates DB with new value for inventory I-Tracker DB

I-Tracker App 3

Web server forwards request to app server I-Tracker App

I-Tracker Web 2

Client sends an inventory request form submitted via the app along with JSESSION ID cookie

I-Tracker Web Client 1 Description Receiver Sender Call #

(20)

Find Risk for Threats

• This is the most difficult part of the threat model

• Starts with a solid base of knowledge of application security attacks (learned through your last class)

– What are the attack types? Do they affect C,I, or A? How likely are they?

• Enhanced by keeping up-to-date with other attacks. Reading the OWASP attacks section is a great resource:

(21)

21

Find Risk for Threats

• Common Weaknesses Enumeration is another great resource:

http://cwe.mitre.org/data/leafnodes.html

• May be too big to read all, but can do meaningful keyword searching (e.g. look for XML)

(22)

Find Risk for Threats

• For the purposes of this class we’ll rely on the knowledge of the students • Please use blank template provided

– Ignore Threat # for now

Inventory Levels Customer IDs Sales Order Numbers Product IDs

Session IDs

From client to web server

Session IDs

At client

Session IDs

At client

Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client Threat # Risk CIA Data Types Attack Vector

Session IDs

At client

Session IDs

At client

Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client Threat # Risk CIA Data Types Attack Vector

(23)

23

Use Cases – Determining Risk

• We take the highest value from the data-types for each threat, and use that as our

impact rating

Data Risk

Data Type _Description

Inventory Levels L H M Amount of inventory for each product Customer IDs L H M Unique ID for each end customer Sales Order Numbers L H M Unique order # for each sales order Description of Orders L L L Description of sales order

Product IDs L H M User is authenticated, User is authorized to perform functions Password H M M Password of system user

User ID M M M ID of system user

Session ID H M M Session ID value for user (JSession from Tomcat)

Session IDs At client

Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client CIA Data Types Attack Vector

(24)

Find Risk for Threats

• Likliehood was determined from our knowledge of threats and by external resources.

We assign a value of 1 for low, 2 for medium, and 3 for high for both likelihood and impact

• Risk = Likelihood X Impact

• Use the following chart from the resulting product to determine the risk level

High 7-9 Medium 4-6 Low 1-3 Risk Score Likelihood X Impact =

(25)

25

Fill in the Risk!

6 N/A

Session IDs

5 H

Session IDs

4 H

Session IDs

3 N/A

Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client 2 H Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client 1 H Inventory Levels Customer IDs Sales Order Numbers Product IDs Session IDs At client Threat # Risk CIA Data Types Attack Vector

(26)

Steps of Threat Modeling

Gather

Information

DFDs

Calls

Use Cases

(27)

27

Attack Trees

• Determine how a threat may be exploited

Confidentiality at client

Plaintext data read during transmission

Cross-site scripting in app

(28)

Attack Trees

• Can be very cumbersome and time-consuming • Alternative notation is easier:

Threat #1: Confidentiality at client

– Attack: Malware steals data

• Countermeasure: Set cache-control to no-cache for sensitive pages

– Attack: Sensitive data stored on client machine

• Countermeasure: Set cache-control to no-cache for sensitive pages

• Countermeasure: Prevent sensitive data from reaching client in error messages by providing a default, generic error page defined in Struts web.xml. Ensure all runtime and checked exceptions are caught and handled before reaching any JSP or Servlet.

– Attack: Session compromised

• Countermeasure: Use strong session identifiers – use existing functionality to do this (e.g. JSESSION ID)

• Countermeasure: Expire sessions after 15 minutes of inactivity

• Countermeasure: Enforce hard time out after 8 hours regardless of amount of activity • Countermeasure: Expire cookie at end of browsing session

(29)

29

Determine Attacks

• For the three highest risk threats in your use case:

– Determine attacks

– Determine possible countermeasures (from your own knowledge, web resources, or by asking experts)

(30)

Share Findings

• Which areas of code are most pertinent to review given our limited timelines?

• What suggestions would we make to the architect/management to improve the application’s security in the next release?

(31)

31

Tools

• Unfortunately, not many tools out there

• Microsoft Threat Analysis & Modeling free tool is best bet

(32)

Questions / Profile

• Our consultants have serviced large (Fortune 500) and medium sized companies across most major industries

• We have worked for major security players, including Foundstone and Deloitte

• We have co-authored or contributed to several security books, including:

– Hacking Exposed: Web Applications, 2nd Edition

– HackNotes: Network Security

– Buffer Overflow Attacks: Detect, Exploit & Prevent

– Windows XP Professional Security

– Writing Security Tools and Exploits

• We have presented at and continue to present at security conferences, including:

– Blackhat Amsterdam; Reverse Engineering Conference 2005 in

Montreal; HackInTheBox 2005 in Malaysia; ISC2's Infosec Conferences in Las Vegas, NYC, Toronto & DC; CSI NetSec; DallasCon; ToorCon; and Freenix.