Detecting Logic Vulnerabilities in E- Commerce Applications FANGQI SUN, LIANG XU, ZHENDONG SU UNIVERSITY OF CALIFORNIA, DAVIS NDSS (FEBRUARY,2014) 1

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 2

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 3

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 4  Luottokunta (v1.2) (CVE ) -> Luottokunta (v1.3) (latest version)

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 5

ILLUSTRATIVE EXAMPLE Luottokunta(v1.3) patched the vulnerability CVE (v1.2) (R1) Checkout_confirmation.php (R3) Checkout_process.php (R4) Checkout_success.php Intermediate representation (IR) 6

ILLUSTRATIVE EXAMPLE before_process() Second ‘if’ statement’s false branch OrderID, OrderTotal, MerchantID, Secret_key, Currency 7 checkout_process.php

ILLUSTRATIVE EXAMPLE- logic attack 8

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 9

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. 10

APPROACH - Definitions 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. 11

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 12

APPROACH – Automated Analysis Logic Vulnerability Detection Algorithm: 13

APPROACH – Automated Analysis Logic Vulnerability Detection Algorithm: 14

APPROACH – Automated Analysis Taint 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’]) 15

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 16

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. 17

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] 18

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. 19

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

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 21

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. 22

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. 23

EMPIRCAL EVALUATION - Analysis Results Logic Vulnerability Analysis Results. 24

EMPIRCAL EVALUATION - Four categories 1)Untrusted Request variables : 2) Exposed Signed Tokens: 3) Incomplete Payment Verification 4) Missing Payment Verification Authorize.net Credit Card SIM iPayment (Credit Card) Luottokunta (v1.3) PayPoint.net SECPay ChronoPay RBS WorldPay Hosted Sage Pay Form Sofort¨uberweisung Direkt PayPal Standard ChronoPay Luottokunta (v1.2) NOCHEX 2Checkout PSiGate 25

EMPIRCAL EVALUATION – On live Websites 26

EMPIRCAL EVALUATION – Attack on Currency 27

EMPIRCAL EVALUATION – Attack on Order ID 28

EMPIRCAL EVALUATION – Attack on Merchant ID 29

EMPIRCAL EVALUATION - Performance 30

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 31

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 32 Parameter pollution vulnerabilities in web applications: ◦WAPTEC [5] : Takes a white-box approach. ◦NoTamper[4] and PAPAS [2] adopt black-box based approaches.

Outline  INTRODUCTION  ILLUSTRATIVE EXAMPLE  APPROACH  IMPLEMENTATION  EMPIRCAL EVALUATION  RELATED WORK  CONCLUSION 33

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 34  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)