1

Detecting Logic Vulnerabilities in E-Commerce ApplicationsFANGQI SUN, LIANG XU, ZHENDONG SU

UNIVERSITY OF CALIFORNIA, DAVIS

NDSS (FEBRUARY,2014)

2

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

3

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

4

INTRODUCTION U.S. retail e-commerce sales for the second quarter of 2013 reached $64.8 billion, 18.4% increase

The prevalence of Internet and the rise of smart mobile devices contribute to the rapid growth of e-commerce web applications

logic vulnerability is not the most common type of web vulnerabilities, it often has serious impact and is easily exploitable.

Writing a perfectly secure payment module (dosen’t have logic vulnerabilities) is difficulty Luottokunta (v1.2) (CVE-2009-2039) -> Luottokunta (v1.3) (latest version)

5

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

6

ILLUSTRATIVE EXAMPLE Luottokunta(v1.3) patched the vulnerability CVE-2009-2039 (v1.2)

(R1) Checkout_confirmation.php

(R3) Checkout_process.php

(R4) Checkout_success.phpIntermediate representation (IR)

7

ILLUSTRATIVE EXAMPLE before_process() Second ‘if’ statement’s false branch

OrderID, OrderTotal, MerchantID, Secret_key, CurrencyOrderID, OrderTotal, MerchantID, Secret_key, Currency

checkout_process.php

8

ILLUSTRATIVE EXAMPLE- logic attack

9

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

10

APPROACH - Definitions Def1 ( Merchant ):

◦ Merchant is the central role in e-commerce applications .◦ Merchants are responsible for initializing orders, tracking payment status, recording order details,

finalizing orders and shipping products (or providing services) to users .

Def2 ( Cashier ): ◦ Cashiers bridge the gap between merchants and users when they lack mutual trust.◦ Users trust cashiers with their private information, and merchants expect cashiers to correctly charge

users. Def3 ( User ):

◦ User inputs and actions drive the logic flows of checkout processes.◦ Some users are malicious, therefore merchants need to defend against untrusted user inputs and

actions.

11

APPROACH - Definitions Def4 ( Logic Flows in E-commerce Applications ):

◦ Communications Between three possible parties: merchant nodes, cashier nodes and user.◦ logic flows in an e-commerce application can be II = {(ni , Qi) -> (nj , Qj) | 0 i , j k}.

Def5 ( Logic State ): ◦ Consists of taint annotations and links to other valid nodes of a checkout process.◦ Logic state stores taint annotations for the following payment status components and exposed signed

tokens.( OrderID, OrderTotal, MerchantID, Currency, exposed signed tokens( Secret_key ) )

Def6 ( Logic Vulnerabilities in E-commerce Applications ): ◦ Exists when for any accepted order ID, the merchant cannot verify that the user has correctly paid the

cashier the amount of order total in the expected currency to merchant ID.

12

APPROACH - Definitions Assumption:

◦ Third-party cashiers are secure (black boxes).◦ Developers of payment modules are often less security-conscious than those of cashiers,

thus payment modules are generally more prone to logic vulnerabilities.

Five types of taint annotations:◦ Tainted order ID◦ Tainted order total◦ Tainted merchant ID◦ Tainted currency◦ Exposed signed token

13

APPROACH – Automated AnalysisLogic Vulnerability Detection Algorithm:

14

APPROACH – Automated AnalysisLogic Vulnerability Detection Algorithm:

15

APPROACH – Automated AnalysisTaint Rules:

• The underlying assumptions of the taint rules are:(1) Requests from users are untrusted.(2) Unsigned cashier requests sent via insecure channels are untrusted. (3) Cashier responses that are relayed by users to merchants via HTTP redirection (status code 302) are also untrusted.

• Initially: order ID, order total, merchant ID and currency are all tainted.

• Taint removal rules: Conditional checks, Writes to merchant database, Secure communication channels

• Taint addition rule: Exposed signed token ex: $_GET[’hash’] == md5($secret.$_GET[’oId’].$_GET[’oTotal’])

16

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

17

IMPLEMENTATION• Developed a symbolic execution framework that integrates taint analysis for PHP written in OCaml.

• Consults Satisfiability Modulo Theories (SMT) solver Z3. Z3: An Efficient SMT Solver

• 25, 113 lines of Ocaml code

• Wrote transfer functions for built-in PHP library functions, which include string functions, database functions, I/O functions, etc.

18

IMPLEMENTATION - Symbolic Execution

• PHP page can either statically or dynamically include other pages.

e.g. Static include require(DIRS_CLASSES.‘cart.php’) Dynamic include require($language.‘.php’)

• For heap modeling, uses five variable maps:

1) Variable-to-symbolic-value memory map. 2) Instance-to-class-name map.3) Alias-to-variable map. E

e.g. $this 4) Array-parent-to-array-elements map .5) Object-parent-to-object-properties map.

McCarthy rule[13]

19

IMPLEMENTATION - Path Exploration

• Goal: To explore all possible intra-procedural and inter-procedural edges in the control-flow graph (CFG).

Use a worklist-based algorithm and explore CFG edges with a depth-first strategy.

Example for Path Exploration.

• Work list Stores execution states for feasible branches that have not been explored yet.

Execution state includes a program counter, a logic state, path condition, memory maps of global and local variables, etc.

IMPLEMENTATION - Logic Flows• Discard backward flows, error flows or aborted flows.

• Parser recursively examines each component of a symbolic value to correctly handle non-literals.

• In most cases, merchants embed URLs in HTTP requests to cashiers.

• An untrusted request parameter is compared against a trusted payment status component ->analyzer removes taint. e.g. $_POST[’x_amount’] == $order->info[’total’]

20

21

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

22

EMPIRCAL EVALUATION Performed experiments on osCommerce

◦ Long history of 13 year.◦ More than 14,000 registered sites.◦ Contains 987 files with 38,991 lines of PHP code.◦ Supports various third-party cashiers and multiple currencies with different payment modules.

23

EMPIRCAL EVALUATION

Payment Modules for Cashiers

• Evaluated 46 payment modules, 22 of which have distinct CFGs.

• 46 payment modules are included in osCommerce by default.

• 44 of them are developed to integrate third-party cashiers.

• The 44 payment modules that accept online payment have 20 Unique CFGs.

24

EMPIRCAL EVALUATION - Analysis Results

Logic Vulnerability Analysis Results.

25

EMPIRCAL EVALUATION - Four categories1) Untrusted Request

variables :

2) Exposed Signed Tokens:

3) Incomplete Payment Verification 4) Missing Payment Verification

Authorize.net Credit Card SIMiPayment (Credit Card)Luottokunta (v1.3) PayPoint.net SECPay

ChronoPay RBS WorldPay Hosted

Sage Pay Form Sofort¨uberweisung Direkt PayPal StandardChronoPayLuottokunta (v1.2) NOCHEX 2Checkout PSiGate

26

EMPIRCAL EVALUATION – On live Websites

27

EMPIRCAL EVALUATION – Attack on Currency

28

EMPIRCAL EVALUATION – Attack on Order ID

29

EMPIRCAL EVALUATION – Attack on Merchant ID

30

EMPIRCAL EVALUATION - Performance

31

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

32

RELATED WORK Logic vulnerabilities in e-commerce applications:

◦ Wang et al. [30] : The first to analyze logic vulnerabilities in Cashier-as-a-Service based web stores◦ InteGuard [33] : Offers dynamic protection of third-party web service

Parameter pollution vulnerabilities in web applications:◦ WAPTEC [5] : Takes a white-box approach.◦ NoTamper[4] and PAPAS [2] adopt black-box based approaches.

33

Outline INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH IMPLEMENTATION EMPIRCAL EVALUATION RELATED WORK CONCLUSION

34

CONCLUSION First static detection of logic vulnerabilities in e-commerce applications

◦ Based on an application-independent invariant◦ A scalable symbolic execution framework for PHP applications, incorporating taint

tracking of payment status

Three responsible proof-of-concept experiments on live websites

Evaluated our tool on 22 unique payment modules and detected 12 logic vulnerabilities (11 are new)