NoTamper: Automatic Blackbox Detection of Parameter Tampering Opportunities

In Web Applications

Prithvi Bisht (http://cs.uic.edu/~pbisht)+

Timothy Hinrichs*, Nazari Skrupsky+, Radoslaw Bobrowicz+, V.N. Venkatakrishnan+

+: University of Illinois, Chicago* : University of Chicago, Chicago

Background: User Input Validation

• Web applications need to • Validate user supplied input • Reject invalid input

Examples: • “Credit card number is exactly16 digits”• “Expiration date of Jan 2009 is not valid”

• Validation traditionally done at server: round-trip, load

• Popular trend: Client-side validation through JavaScript

Client Side Validation using JavaScript

onSubmit=validateCard();

validateQuantities();

Validation Pass?

send inputsto server

rejectinputs

Yes No

Problem: Client is Untrusted Environment

• Validation can be bypassed

• Previously rejected values, sent to server

• Invalid quantity: -4

• Ideally: Re-validate at server-side and reject

• If not, security risks

Example: Bypassed Validation Security Risks

Client validation: Field: quantity

“reject negative values”

Server-side code: cost = cost + price * quantity

How to automatically find such inputs in a blackbox fashion?

quantity = 1, price = 100cost = cost + 100

quantity= -1, price = 100 cost = cost - 100

Intuition Automatically generate two sets of inputs

Valid inputs quantity = 1 Invalid inputs quantity = -1

Done through client code analysisIf ( quantity ≥ 0 )

submit to applicationelse

reject, ask to re-enter

How does the server-side code respond Heuristically determine if server rejects invalid inputs Server rejects: quantity = -1

quantity = 1 (valid input)

quantity= -1(invalid input)

NoTamper Architecture and Outline

Formula ExtractorWeb

Page

Input Generator

Opportunity Detector

External analysis

Logical formula for client side validation

Fclient: quantity ≥ 0

Solve constraints

Benign inputse.g., quantity = 0

Hostile inputse.g., quantity = -1

Compare responses for benign and hostile inputs

opportunities

exploits

hints

Outline1.Formula extraction from client code2.Input generation3.Opportunity detection4.Evaluation5.Conclusion

Formula Extraction from Client Code

HTML and JavaScript both restrict inputs

HTML form controls Drop down menu: value IN (value_1, …, value_n) Radio/Checkboxes: value IN (value_1,…, value_n) Hidden attribute: value = constant Readonly attribute: value = constant Maxlength attribute: length(value) ≤ constant

Drop down menu: select one of these

card == 1234… OR card == 7890…

tags

attributes

Constraint

Formula Extraction from Client Code (cont…)

Event driven JavaScript validation

State machine Start: no fields validated, end: all validation passed Transitions w/ validation functions: f1, f2, … fn

Over-approximation: All function executed: f1 f2 …fn

Execute functions symbolically conditions when all functions accept inputs

Valid: noneInvalid: all

Valid: allInvalid: none

(form submitted)Valid: field1Invalid: rest

fk

f1

f2

fn

fm

onChange

onSubmit

Formula Extraction from Client Code (cont…)

Program condition when validation succeedsif (quantity ≥ 0)

return true; constraint: quantity ≥ 0else

return false;

JavaScript interaction w/ Document Object Model Reading form fields (e.g., getElementById) Enable/disable form fields (e.g., disabled property)

At the end of symbolic execution

Fclient = (path conditions) AND (constraints of enabled fields)

1. Formula extraction from client code

2. Input generation

3. Opportunity detection

4. Evaluation

5. Conclusion

Outline

Input Generation Benign inputs

Pass client side validation Satisfy Fclient

Example: Fclient: quantity ≥ 0

Satisfying values determined with type information Collected while analyzing HTML/JavaScript quantity: -? [0-9]*

quantity = 1

Constraint solving

Input Generation (cont…) Hostile inputs

Bypass client side validation Satisfy NOT (Fclient)Example: NOT ( quantity ≥ 0 )

Supplying required variables Example:

Field value mandated by JavaScript Heuristics: special markers like * in the field description

quantity = -1

quantity = -1gift-note = “abc”

gift-note = “-”

NOT (quantity ≥ 0) U NOT (gift-note in [a-z]*)

1. Formula extraction from client code

2. Input generation

3. Opportunity detection

4. Evaluation

5. Conclusion

Outline

Opportunity Detection

Rejected inputs

Acceptedinputs

Different structures

Responsefor hostile inputs

Responsefor Benign inputs

Responsefor hostile inputs

Exploit opportunity

Similarstructures

Opportunity Detection (contd…) Compare responses to benign and hostile inputs

But noise: user name, address, time, online users, …

a1a2a3

a1a2a3

b1a2a3 h1

a2a3

B1

B2

---a2a3

Remove differences

H1

B1---a2a3

C1

C2

Difference rank =

Edit Distance (C1,C2)

Low rank opportunity

1. Formula extraction from client code

2. Input generation

3. Opportunity detection

4. Evaluation

5. Conclusion

Outline

ApplicationsApplication LOC Constraints

sourceUse

SMF 97K HTML+JavaScript Forum

Ezybiz 186K HTML+JavaScript Busn Mgt

OpenDB 92K HTML+JavaScript Inventory

MyBloggie 9K HTML+JavaScript Blog

B2evolution 167K HTML Blog

PhpNuke 228K HTML+JavaScript Content Mgt

OpenIT 114K HTML+JavaScript Support

LegalCase 58K HTML Inventory

smi-online.co.uk

--- HTML Conference

wiley.com --- HTML+JavaScript Library

garena.com --- HTML Gaming

selfreliance.com

--- HTML Banking

codemicro.com

--- HTML+JavaScript Shopping

8opensource

5livesites

Applications (cont…)

Hostile and benign responses separated by an order of magnitude

Application Forms

Hostile Inputs

Opportunities

Confirmed

SMF 5 56

Ezybiz 3 37

OpenDB 1 10

MyBloggie 1 8

B2evolution 1 25

PhpNuke 1 6

OpenIT 3 28

LegalCase 2 13

smi-online.co.uk

1 23

wiley.com 1 15

garena.com 1 4

selfreliance.com

1 5

codemicro.com 1 6

Application Forms

Hostile Inputs

Opportunities

Confirmed

SMF 5 56 42 √

Ezybiz 3 37 35 √

OpenDB 1 10 8 √

MyBloggie 1 8 8 √

B2evolution 1 25 21

PhpNuke 1 6 5 √

OpenIT 3 28 27 √

LegalCase 2 13 9 √

smi-online.co.uk

1 23 4

wiley.com 1 15 4

garena.com 1 4 4

selfreliance.com

1 5 1 √

codemicro.com 1 6 1 √

Confirmed exploits: 9/13 applications

Opportunities: 169Examined: 50

SelfReliance.com: Online banking

Vulnerability: from/to – arbitrary accounts Exploit: Unauthorized money transfers

Transfer money from unrelated accounts Account number hardly a secret e.g., checks contain them

Status: fixed within 24 hours ESP solution (espsolution.net) s/w provider patched s/w for other clients

Client-side constraints: 1.from IN (Accnt1, Accnt2)2.to IN (Accnt1, Accnt2)

Server-side code: transfer money from to

CodeMicro.com : Shopping

Vulnerability: quantities can be negative Exploit: Unlimited shopping rebates

Two items in cart: price1 = 100$, price2 = 500$ quantity1 = -4, quantity2 = 1, total = 100$ (rebate of 400$ on price2)

Status: fixed within 24 hours

Client-side constraints: 1.quantity1 ≥ 0 2.quantity2 ≥ 0

Server-side code: total = quantity1 * price1 + quantity2 * price2

OpenIT: Support

Vulnerability: update arbitrary account Exploit: Privilege escalation

Inject a Cross-site scripting (XSS) payload in admin account Cookies stolen every time admin logged in.

Status: open

Client-side constraints: 1.userId == 1(hidden field)

Server-side code: Update profile with id 1, with new details

Hidden Field

1. Formula extraction from client code

2. Input generation

3. Opportunity detection

4. Evaluation

5. Conclusion

Outline

Conclusion

Framework to identify parameter tampering opportunities Used client-side restrictions to aid hostile input generation Several serious problems in open source / commercial

applications

Significant gap: validation that should happen and that does happen

Thanks and Questions

Backup

False positives

• maxlength constraints : 31• Mutated inputs : 12

Split of HTML, JavaScript and Hidden Field Constraints

• HTML constraints : 110/169 (65%)• JavaScript constraints : 20/169 (12%)• Hidden fields constraints: 39/169 (23%)

Manual intervention

• Unique variables : 3 • (SMF: 2, phpNuke: 1)

• Session id/cookies : all except phpNuke

• Required variables : 12 • (SMF: 5, phpNuke: 4, B2Evolution: 1, Garena.com: 2)

• Typically 5 minutes per form• Bounded by the number of fields

Limitations

Unsound False positive: application mutates invalid inputs e.g., truncate

12 such instances in our experiments

False positive: similar responses for failure/success

Incomplete JavaScript over-approximation

Mutually exclusive events may cause Fclient – false

JavaScript unhandled features document.write/eval

constraints not checked at client Fclient = true

Some related work Input validation

Prevent affect of invalid inputs: Su et al. POPL’06, Bandhakavi et al. CCS’07, Saxena et al.NDSS’09, Van Gundy M et al. Oakland’09, Ter-louw et al. Oakland’09

Find insufficient validation: Livshits et al. Usenix’05, Balzarotti et al. CCS’07, Balzarotti et al. Oakland’08, …

Vulnerability analysis JavaScript analysis based client side attacks: Saxena et al. Oakland’10

Fuzzing/directed testing Benign/Hostile input generation: Godefroid et al. SIGPLAN’05, Godefroid et al.

NDSS’08, Saxena et al. NDSS’10, …

Prevention techniques Sandbox/restrict client code: Grier et al. Oakland’08, Reis et al. EuroSys’09, Wang

et al. Usenix’09, Vikram et al. Oakland’09, Chong et al. CCS’09, …