MULTI-REPRESENTATIONAL SECURITY ANALYSIS

(1)

MULTI-REPRESENTATIONAL

SECURITY ANALYSIS

Eunsuk Kang MIT CSAIL ExCAPE Webinar April 30, 2015

(2)

Third-Party Authentication

OAuth protocol

Widely adapted, support from major vendors Analyzed formally using verification tools

(3)

Empirical study of OAuth providers [Sun & Beznosov, CCS12] Majority of them vulnerable (Google, Facebook,...)

(4)

Provably Secure, Practically Vulnerable?

RFC OAuth 2.0, Internet Engineering Task Force

Protocol analysis at the abstract level

(5)

Provably Secure, Practically Vulnerable?

Protocol analysis at the abstract level

Agents, messages, and rules at each protocol step

Blame protocol designers?

Can’t predict all manners in which protocol will be used!

Attacks exploiting details absent from model

Unanticipated behavior from browser features e.g. HTTP redirects, hidden forms

(6)

Abstractions in System Design

Customer authentication Payment workflow Shopping cart interaction Mobile app API Deployment on HTTP Delivery processing

Most systems too complex

(7)

Abstraction vs Security

System designer

One system view/abstraction at a time Exclude details in other views

(8)

Abstraction vs Security

System designer

One system view/abstraction at a time Exclude details in other views

(9)

Abstraction vs Security

Attacker

Jump between abstractions & combine details

(10)

Poirot

A framework for incremental

reasoning of security properties across

multiple abstraction boundaries

(11)

MS P MS ⊨ P? Property Verification Engine Analysis Result System Model

(12)

Our Framework: Poirot

Property Composition Operator Verification Engine Domain Model Library System Model Mapping Analysis Result

(13)

Our Framework: Poirot

Start with & analyze an initial model MS

MS P

(14)

Our Framework

Generic, reusable models e.g., browser, protocols

(15)

Our Framework

Property Composition Operator Verification Engine Domain Model Library System Model Mapping Analysis Result Elaboration of MS with knowledge in MD MD M' = Compose(MS,MD,K) MS M' K

(16)

Our Framework

M' ⊨ P? M'

Re-analyze P & repeat

(17)

Key Features

Increment, iterative analysis

Start with an initial model, elaborate, analyze & repeat Find & fix simple attacks first, complex ones later

Explore impact of design alternatives

Reusing domain knowledge

Encoded by domain experts

Reusable across multiple systems Details hidden from user

(18)

System Model

(19)

Modeling Approach

Behavior

Trace-based semantics (event traces)

Declarative constraints for specifying behavior

Structure

Components with input/output channels End-to-end dataflow through channels

Inspirations

Architectural description languages Process algebras (CSP)

(20)

Structure

Model

Components (C), operations (O), datatypes (D)

D = {CustomerID, ItemID, Cart, Credential, Order}

Customer _MyStore

AddItem

(21)

Structure

Component

Input & output channels

Each channel typed to an operation

Connection between channels with the same type

Customer _MyStore AddItem ShowCart X1 X2 Y1 Y2

(22)

Structure

Component states

Encoded as relations Updated by operations

creds ⊆ CustomerID x Credential

cart ⊆ CustomerID x ItemID

orders ⊆ CustomerID x Order

MyStore AddItem

(23)

Behavior

Behavior as traces

A stream of events generated through each channel

Behavior of a component ≡ set of all possible traces

beh: C → ℙ(T) MyStore AddItem ShowCart Y1 Y2

(24)

Behavior

Interaction

Parallel composition, synchronized on shared operation

⟨addItem1, addItem2, showCart1⟩ ∈ beh(Customer || MyStore)

Customer _MyStore AddItem ShowCart X1 X2 Y1 Y2

(25)

Behavior

Restricting behavior

Each channel associated with a guard condition Specified as a declarative constraint

Guard on Y1:

_∀e _∈ E | (e.cust, e.cred) _∈ p.creds

creds ⊆ CustomerID x Credential

Customer _MyStore ShowCart X1 X2 Y1 Y2

AddItem(cust: CustomerID, item: ItemID, cred: Credential)

(26)

Dataflow Model

Inter-component data flow

Transmitted as arguments of an operation

v ∈ hasAccess(c, t) if c has access to value v after trace t

Assumptions

c has access to value v if (1) it initially knows v or

(2) it has received an event with v as argument

Can send an event only if it has access to all arguments

(27)

Verification

(28)

Analysis

Encoding in Alloy

Modeling language based on first-order relational logic

Translation to a SAT formula; solve(M _⋀ ¬P)

Bounded verification (trace length, data values)

Properties

Confidentiality & integrity

More broadly, safety properties

∀ t ∈ T, o: Order, s: MyStore, c: Customer |

o ∈ hasAccess(c, t) (c.id, o) ∈ s.orders(t)

(29)

Domain Model Library

(30)

Domain Model Library

Benefits

Amortized cost; built once, reused multiple times Expertise not required of user

Web-related domain models

Category Models

Component Browser, HTTP server, network endpoint

Feature Encryption, scripting, same-origin policy, cross-_{site origin requests (CORS), PostMessage} Protocol SSL, OAuth, OpenID

(31)

Composition Operator

(32)

Composing Models

Problem

Two partial models, describing different viewpoints With distinct vocabularies

But potentially overlapping in reality

Store model HTTP model Relate? Browser _Server HttpReq Customer MyStore AddItem ShowCart M1: M2:

(33)

Representations

Formally, every instance of S1 is also an instance of S2

Representation relation (R)

Informally, “represented as” ≅ “deployed as”,

“implemented as”, “encoded as”

(S1, S2) ∈ R

S2 S1

Introduced between a pair of components, operations, datatypes i.e., R = (RC, RO, RD)

(34)

Relating Elements

AddItem HttpReq

(AddItem′, HttpReq) _∈ R

=

Representation as a way of describing overlaps

i.e. “AddItem is implemented as a kind of HTTP requests”

HttpReq AddItem'

M1 M2

(35)

Mapping Elements

=

Describe how members of the two sets are mapped

AddItem HttpReq

Mapping as a concretization relation

Corresponds to design decisions!

HttpReq(method: Method, url: URL, headers: set Header)

AddItem(customer: CustomerID,

item: ItemID, cred: Credential) _HttpReq

(36)

Complex Mapping

MyStore OAuth Client

=

i.e. “MyStore is deployed as HTTP server and also participates in OAuth protocol”

Server MyStore'

Server OAuthClient

(37)

Behavior Expansion

Types of expansion Channel Addition Dataflow Expansion Alphabet Expansion Effects of composition

Possible introduction of behavior into the system Previously verified properties may no longer hold!

Browser _Server HttpReq

Customer MyStore

AddItem

(38)

Channel Addition

Customer MyStore AddItem Server Customer [Browser] MyStore AddItem HttpReq

Component obtains channels & generates new events

Customer interacts with other HTTP servers

Allows attacks where attacker sets up malicious pages

(39)

Dataflow Expansion

Customer _MyStore AddItem

Server HttpReq(Method,

URL, set Header) Customer

[Browser]

MyStore AddItem(CustomerID,

ItemID, Cred)

New types of data flow into component

Server may now receive credentials as headers

Customer → Browser Cred → Header

(40)

Alphabet Expansion

Customer _MyStore AddItem MyStore [Server] AddItem [HttpReq] Customer Browser

Component generates new event types

Any HTTP client can invoke AddItem operation Can’t assume how AddItem will be invoked

Common mistake among web developers!

MyStore → Server AddItem → HttpReq

(41)

Composition Operator

M′ = compose(M1, M2, K)

with mappings K = (KC, KO, KD)

Two-step procedure

For each pair (S1, S2) appearing in K:

1. Merge Introduce representation relation between S1 & S2

2. Refine Constrain members of S1 & S2 according to K

(42)

Merge

1. Introduce representation relation between S1 & S2

Construct S1′ that obtains characteristics (channels,

arguments, fields) of S1 & S2

MyStore → Server Customer → Browser AddItem → HttpReq Customer MyStore AddItem In resulting model M′: (MyStore′, Server) _∈ RC (Customer′, Browser) _∈ RC (AddItem′, HttpReq) _∈ RO Server Customer [Browser] HttpReq MyStore [Server] Browser AddItem [HttpReq]

(43)

Refine

2. Constrain members of S1 & S2 according to K

Specified as a declarative constraint

{a: AddItem, c: HttpReq | c.method = “POST” _∧

a.customer _∈ c.url.query _∧ a.item _∈ c.url.query _∧

a.cred _∈ c.headers } _⊆ KO

AddItem

HttpReq

HttpReq(method: Method, url: URL, headers: set Header)

AddItem(customer: CustomerID,

(44)

Partial Mappings

Mapping can be partially specified

{a: AddItem, c: HttpReq |

c.method = “POST”} _⊆ KO

AddItem

HttpReq

Analyzer generates mapping that leads to attack! User can leave some design decisions unknown & interactively explore alternative mappings

(45)

Case Studies

Two publicly deployed sites

IFTTT End-user service composition

(46)

Case Studies

Methodology

Start with an abstract workflow model

Elaborate with domain models & re-analyze Replay attacks on the concrete system

Two publicly deployed sites

IFTTT & HandMe.In

Results

Previously unknown attacks on both sites Confirmed with the developers

Analysis times < 15 seconds Modeling effort: 1~2 weeks

(47)

Attack on IFTTT

Authentication on IFTTT

User creates a recipe with trigger & action

(48)

Attack on IFTTT

Confidentiality Property

(49)

Attack on IFTTT

Login CSRF

Attacker tricks user into signing in under its credentials Relatively minor; may see history of user’s actions

But in combination with IFTTT

Security consequences far greater!

Can leak private data through IFTTT channels

Complex interaction

(50)

Attack on IFTTT

User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Blogger [Server] CreateBlog Login Authorize Server (Evil)

(51)

Attack on IFTTT

1. User visits a page hosted by evil server

User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Server (Evil) Req Google [Server] CreateBlog Login Authorize Blogger [Server]

(52)

Attack on IFTTT

2. User gets logged onto Blogger under attacker’s credential User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Google [Server] CreateBlog Login Authorize Server (Evil) Blogger [Server]

(53)

Attack on IFTTT

3. User creates a new recipe on IFTTT User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Google [Server] CreateBlog Login Authorize Server (Evil) Blogger [Server]

(54)

Attack on IFTTT

4. Blogger authorizes IFTTT to perform

action, but under the attacker’s account! User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Google [Server] CreateBlog Login Authorize Server (Evil) Blogger [Server]

(55)

Attack on IFTTT

User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Google [Server] CreateBlog Login Authorize Server (Evil)

5. User posts a photo on Facebook

Blogger [Server]

(56)

Attack on IFTTT

6. IFTTT is notified of the trigger User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Google [Server] CreateBlog Login Authorize Server (Evil) Blogger [Server]

(57)

Attack on IFTTT

7. IFTTT creates a new blog on the

attacker’s account,

with the user’s photo!

User [Browser] IFTTT [Server] Facebook [Server] Create Recipe Notify PostPhoto Req Google [Server] CreateBlog Login Authorize Server (Evil) Blogger [Server]

(58)

Internet of Things Security

(59)

Looking Ahead

Property Composition Operator Verification Engine Domain Model Library System Model Mapping Analysis Result Synthesis:

Construct K that satisfies P

K P M' ⊨ P? MS MD M' M'

(60)

Looking Ahead

Property Composition Operator Verification Engine Domain Model Library System Model Mapping Analysis Result Model Extraction:

MULTI-REPRESENTATIONAL SECURITY ANALYSIS