1 / 0

Detecting Logic Vulnerabilities in E-Commerce Applications

Detecting Logic Vulnerabilities in E-Commerce Applications. Fangqi Sun, Liang Xu, Zhendong Su University of California, Davis NDSS (February,2014). Outline. INTRODUCTION ILLUSTRATIVE EXAMPLE APPROACH

luyu
Download Presentation

Detecting Logic Vulnerabilities in E-Commerce Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Detecting Logic Vulnerabilities in E-Commerce Applications

    FangqiSun, 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 Intermediate representation (IR) (R3) Checkout_process.php (R4) Checkout_success.php
  7. ILLUSTRATIVE EXAMPLE before_process() Second ‘if’ statement’s false branch OrderID, OrderTotal, MerchantID, Secret_key, Currency OrderID,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 Analysis Logic Vulnerability Detection Algorithm:
  14. APPROACH – Automated Analysis Logic Vulnerability Detection Algorithm:
  15. 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’])
  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 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
  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: Variable-to-symbolic-value memory map. Instance-to-class-name map. Alias-to-variable map. E e.g. $this Array-parent-to-array-elements map . 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. 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.
  20. 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’]
  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 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
  24. EMPIRCAL EVALUATION - Analysis Results Logic Vulnerability Analysis Results.
  25. EMPIRCAL EVALUATION - Four categories Authorize.net Credit Card SIM iPayment(Credit Card) Luottokunta (v1.3) PayPoint.net SECPay Untrusted Request variables : ChronoPay RBS WorldPay Hosted Sage Pay Form Sofort¨uberweisung Direkt PayPal Standard 2) Exposed Signed Tokens: ChronoPay Luottokunta(v1.2) NOCHEX 2Checkout PSiGate 3) Incomplete Payment Verification 4) Missing Payment Verification
  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 inCashier-as-a-Service based web stores InteGuard [33]: Offers dynamicprotection 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)
More Related