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
 Luottokunta (v1.2) (CVE-2009-2039) -> Luottokunta (v1.3) (latest version)
4
Outline
 INTRODUCTION
 ILLUSTRATIVE EXAMPLE
 APPROACH
 IMPLEMENTATION
 EMPIRCAL EVALUATION
 RELATED WORK
 CONCLUSION
5
ILLUSTRATIVE EXAMPLE
Luottokunta(v1.3) patched the vulnerability CVE-2009-2039 (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
checkout_process.php
7
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
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.
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
• Wrote transfer functions for built-in PHP library functions, which
include string functions, database functions, I/O functions, etc.
• 25, 113 lines of Ocaml code
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.g. $this
4) Array-parent-to-array-elements map .
5) Object-parent-to-object-properties map.
E
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.
• 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.
Example for Path Exploration.
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
• 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.
Payment Modules for Cashiers
23
EMPIRCAL EVALUATION - Analysis Results
Logic Vulnerability Analysis Results.
24
EMPIRCAL EVALUATION - Four categories
1) Untrusted Request variables :
Authorize.net Credit Card SIM
iPayment (Credit Card)
Luottokunta (v1.3)
PayPoint.net SECPay
ChronoPay
RBS WorldPay
Hosted
2) Exposed Signed Tokens:
3) Incomplete Payment Verification
Sage Pay Form
Sofort¨uberweisung
ChronoPay
Direkt
PayPal(v1.2)
Standard
Luottokunta
NOCHEX
2Checkout
PSiGate
4) Missing Payment Verification
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
Parameter pollution vulnerabilities in web applications:
◦ WAPTEC [5] : Takes a white-box approach.
◦ NoTamper[4] and PAPAS [2] adopt black-box based approaches.
32
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
 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)
34