Security Exploit of Business Logic Flaws, Business Logic Attacks


Published on

Business Logic Attacks: vulnerability analysis and risk management presentation at ISSA Security Conference in Louisville, KY, October 7, 2010

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Business logic attacks are attacks target the application business logic such as the business rules that are specific for the application. These include for example rules for baking on-line In general when we talk of application security risks we refer to exploit of critical vulnerabilities such as exploit of the OWASP T10 such as injection flaws, XSS, Do not exploit common vulnerabilities such as XSS and SQL injection and broken authentication and session management. This vulnerabilities are usually rated critical because of the technical impact and the business impact that cause when are exploited. This is the same in the case of BLA since these attacks exploits flaws in the application business logic for commit fraud such as unauthorized financial transactions such as wire transfers, stealing user credentials to gain access to some else emails, and sensitive data as well as to damage the reputation of the company or individuals by posting false information for different reasons The problem with BLA is that the flaws that are exploited are very difficult to discover with VA/penetration testing since they DO NOT rely on known attack patterns and workflows pose the same level of risk to exploit of critical vulnerabilities
  • Pump and dump " is a form of microcap stock fraud that involves artificially inflating the price of an owned stock through false and misleading positive statements, in order to sell the cheaply purchased stock at a higher price. Once the operators of the scheme "dump" their overvalued shares, the price falls and investors lose their money. Stocks that are the subject of pump-and-dump schemes are sometimes called "chop stocks". [1] While fraudsters in the past relied on cold calls , the Internet now offers a cheaper and easier way of reaching large numbers of potential investors. [1]
  • In case of vulnerabilities that are application logic specific the commonality is in applications implementing same logic for example in the case of password management, use of MFA, weak enforecement of RBAC such as when relying on client side parameters and insufficient defenses against automations/bots designed to exploit the application business logic fr different reasons The most specific cases are the ones related to lack of strong validations for each step such a validation is required at step B to go to step C while step A is T&C a user can go directly from A to C can bypass any validation this is common independently
  • It is important to differentiate between design flaws and secuirity bugs. Security flaws might have different root causes mostly due to design defects. Require manual analysis since tools do not have the contextual knowledge of the application since these lack the contextual knowledge of the application Security bugs can be identified via source code analysis and require developers knowledge of secure coding principles, can be driven by secure coding standards
  • There are different ways to categorize the most common vulnerabilities, OWASP is famous for the T10 we also have WASC and SANS-25 most common software security errors. It is possible to map these. The vulnerabilities that are exploited by BLA include broken authentication and session management, misconfiguration also failutre to restrict URL access WAASC insufficient authorization. A new one that does not map is insuffcient anti-automation. On the right end side you have improper authorization that is one of the main consequences that is security control bypass All these vulnerabilities inn one way or another can be used for exploit business logic and business logic attacks
  • Authorization issues stem for lack of enforcement of role base access controls such as enforcement of the policy rules sometimes handled as configuration at the application server to restrict access to resources such as web pages and transactions. Lack of this enforcement allow attackers to elevate privileges. Forceful browsign is probably the easer way to perform BLA attacks Other casses include manipulation of URL paramters such us unique ID that are used for query transactions and incurrectly also to enforce permissions. The main root causes are: RBAC logic is not enforced server side bur rely on parapemeters RBAC does nto cover at granular level all users and trasnactions that the users can perform and resources that can access. This might be du to problem in design and integration of business logic at the application layer
  • Flaws on the workflows for password resets and userID reminders, lack of locking for failed attempts, weak check for origination identification Risk Based Authentication (RBA) is not configured to challenge users for all high risk transactions (e.g. password reset is not challenged with extra authentication) MFA failing insecurely when primary MFA fails since is not backed up by secondary MFA (e.g. KBA fails)
  • Configuration management process lacks validation that rules for business policy are properly configured in the application to enforce authorization and authentication Flaws on the workflows for password resets and userID reminders, lack of locking for failed attempts, weak check for origination identification Risk Based Authentication (RBA) is not configured to challenge users for all high risk transactions (e.g. password reset is not challenged with extra authentication) MFA failing insecurely when primary MFA fails since is not backed up by secondary MFA (e.g. KBA fails)
  • Most of business logic attacks are carried out by malware and automation scripts. These scripts are tailor made to attack the application transactions such as for example can target forms where the user is asked to enter validate his credit card#, CVV, security work, Pin the script run by the attacker has gained such data from black market but to know if is valid it will use the application to validate expecially PINs. In the case of bank trojans a typical attacks is the one to alter the flow of high risk transactions such as wire transfers to request the victim to enter data in a extra form. Also this attacks change the buttons being clicked by the application UI to perform un-authorized transactions. Other attacks include overloading processes for denial of servce such as sending a lot of registrations for online credentials/accounts or by locking accounts to cause flooding of request to call centers and deny service the regular users
  • Workflow requires validation at UI-A to move to UI-B and then validate again to UI-C but attacker can move from UA-A to UI-B directly. This might allow for example to order the shipping of an item without checking if has been purchased Some times the sequence of events of a transaction can eb altered such as by calling back end logic such as messages out of sequence. This might allow to bypass validations if these messages can be executed without a previous validation or because the session is not properly maintained across tiers
  • It is important to have security requirements and a process for mitigating BLA. For a start, it is important to document the business logic of the application this can be done through business requirements supported by transaction flows. Document who can do each trasnaction and the privileges that are given to each resource. Using secure architecture to identify flaws in the application architecture that can be used for bypass controls and access control policy are crititcal. Threat modeling techniques ito identify flaws in the business logic nclude data flow analysis and use and misuse cases Even if an application is designed securely that does not mean that implementation and configuration issues can still lead to business logic flaws and vulnerabilities. Devise a suite of tests for BLA attacks is very important as well as to test for common vulnerabilities that can be exploited for BLA. These need to be tested as aprt of manual penetration tests of the application As for any vulnerability being identfied it is important to rank the severity or risk posed by the vulnerability and therefore it is possible to apply the appropriate risk mitigation
  • From secure architecture perspective we need to ask where the application business logic resides not all business logic resides on the logic tioer. Web 2.0 are more exposed to application attacks since allow to incorporate business logic on the client, this should be avoided, for example not to allow transaction logic built into The JS on the client. Also integration of third party applications might expose to business logic attacks on the client when the client talks directly with APIs served by third party (see Google Map API) or when authenticated pages frame third party services
  • From threat analysis perspective it is important to analyze threats to the business logic of the application from the perspective of the application architecture This view allow to visualize the end to end architecture and the threats affecting the different assets and data flow elements. In particular BLA are possible because of threats to the communication tiers sich as by spoofing the communication channel or by tampering parameters. Since the application server is where the BL resides it is target for elevation of privileges Enforce Role Base Access Controls Ensure that RBAC is enforced on the server side to enforce which user has access to which web page Do not use security by obscurity No HIDDEN parameters to enforce which web pages are accessible Enforce white list filtering to which web pages should be accessible Only allow file types that you intend to serve, block any attempts to access log files, xml files, etc.
  • Definition : Defining use and abuse cases is the foundation of the security requirement phase in which security requirements are developed. Abuse cases are instrumental to elicit requirements for security controls and for testing these controls.
  • Shopping cart allow user to browse catalogues as un-authorized per-authenticated user role or vistor and add items ina shopping cart. When it is decided to purchase an item tor checking our from shopping cart the user is required to log on and enter a valid credit card number as well as shipping address. A cart like this can be attaked in due main stages. One is when the items are added for checkout since the price can be altered before the items is pusrchaes. The second is to attack the purchase of the item when the shipping data is already entered and eventially is possible to bypass he checkout credit card step. This might occu by forceful browsing or by exploiting flaws such as lack of flags validation that can be tampered in transit by the attacker.
  • HIDDEN Parameter Manipulation Exploit Look for HIDDEN values that contain business sensitive information (e.g. price) in the web page The price charged for the “Two Stone Feather Ring” is now 99 cents
  • This example shows how ACM is enforced for the EASPI This policy should be taken as reference to test business logic attacks such as for elevation of privileges or escalation of privileges. It is important to keep this policy under strict change management cotnrol
  • A suite of tests for BLA is probably the best bang for the back you can have against BLA. These tests can be derived from use and misue cases where usually the happy and unhappy paths are documented. In particular the focus of these tests is to test critical bypass of authentication and authorization controls, parameter and check validations as well as session managekent tests and anit-automation tests
  • Once business logic vulnerabilities are identified, either as design flaws during threat modeling or during security tests or manual penetration tests it is important that these are assigned a risk value. The assigned of a risk value to a vulnerability can be done using risk factors. The one shown hereina re the ones used by OWASP risk methodology that include factors for how the attack vector can be exploited, how the vulnerability or flaws is prevalent, how easy to detect and what the technical impact is. An exploit is more risk when is easy to exploit and common as exploit vs, is diffcult to exploit and is rare as vulnerability.A vulnerabiity that is easy to detect is also less risky vulnerabiloity that is not easy to detect. The overall impavt can be SEVERE to MODERTE This ratings put here ar the everage of the previously dealt vulnerabilities such as OWASP A3, A4, A8
  • Finally by ranking the vulnerabilities it is possible to determine the mitigation strategy. In general BLAs need a defense in depth approach that includes deterrent controls 9reduce the likelihood of the attack) preventive (reduce the impact) detective (detect the attack) and compensating (can reduce risk in presence of gaps/exploits in other controls)
  • Security Exploit of Business Logic Flaws, Business Logic Attacks

    1. 1. Analysis and Risk Mitigation of Business Logic Attacks Marco Morana OWASP ISSA Info Security Conference Louisville, KY October 7 h 2010
    2. 2. Agenda For Today’s Presentation <ul><li>General Background on Business Logic Attacks (BLA) </li></ul><ul><ul><li>Problem statement </li></ul></ul><ul><ul><li>Business logic exploits, exploits </li></ul></ul><ul><ul><li>Categorization of BLAs </li></ul></ul><ul><li>Vulnerability Analysis of Business Logic Flaws </li></ul><ul><ul><li>Threat, vulnerabilities, and attacks </li></ul></ul><ul><ul><li>Root causes of vulnerabilities </li></ul></ul><ul><ul><li>OWASP T10, SANS-25, WASC </li></ul></ul><ul><li>Risk Analysis and Mitigation of BLA </li></ul><ul><ul><li>Security requirements </li></ul></ul><ul><ul><li>Threat analysis </li></ul></ul><ul><ul><li>Risk management </li></ul></ul><ul><li>Q & A </li></ul>
    3. 3. Business Logic Attacks
    4. 4. Business Logic Attacks: The Problem Statement <ul><li>Target the business logic of the site by attacking the data and the transactions: </li></ul><ul><ul><li>Attacking check out credit cards in shopping cart transactions </li></ul></ul><ul><ul><li>Attacking wire transfers in on-line banking transactions </li></ul></ul><ul><li>Pose the same level of risk of attacks exploiting critical vulnerabilities : </li></ul><ul><ul><li>Abuse web sites business logic for: </li></ul></ul><ul><ul><ul><li>fraud, </li></ul></ul></ul><ul><ul><ul><li>theft of user’s credentials and sensitive information, </li></ul></ul></ul><ul><ul><ul><li>reputational damage </li></ul></ul></ul><ul><li>Business Logic flaws are overlooked by security tests and tools: </li></ul><ul><ul><li>Undetected by vulnerability scanning tools </li></ul></ul><ul><ul><li>Require specific business logic abuse tests not usually included as part of the security testing process </li></ul></ul>
    5. 5. Business Logic Attacks Examples
    6. 6. Categorization of Business Logic Exploits <ul><li>Exploit flaws in the design, implementation and configuration of the application business logic rules and data , examples include: </li></ul><ul><ul><li>Weak enforcement of workflows and steps required by transactions, </li></ul></ul><ul><ul><li>Implicit trust and weak process validations in transactions, </li></ul></ul><ul><ul><li>Committing to transactions without all checks required are first validated </li></ul></ul><ul><li>Exploit weaknesses in the implementation of security controls whose function is protect the application business logic , examples include: </li></ul><ul><ul><li>Gaps in enforcement of role base access controls policy rules, </li></ul></ul><ul><ul><li>Insufficient parameters validation (e.g. priceID, roleIDs, userIDs), </li></ul></ul><ul><ul><li>Password reset flaws, username recovery flaws, </li></ul></ul><ul><ul><li>Security controls failing insecurely, </li></ul></ul><ul><ul><li>Insufficient anti-automation defenses to detect the attacks </li></ul></ul>
    7. 7. Vulnerability Analysis of Business Logic Flaws
    8. 8. Threat, Attacks, Vulnerabilities in the context of BLA <ul><li>Threats </li></ul><ul><ul><li>Some agent or adverse condition that target the application business logic to cause a negative impact to the business </li></ul></ul><ul><li>Attacks </li></ul><ul><ul><li>Realizing the threat to cause the negative impact , includes different ways for an attacker to conduct business logic attacks by exploiting one or more vulnerabilities and logic flaws </li></ul></ul><ul><li>Vulnerabilities </li></ul><ul><ul><li>Weaknesses in the business logic that can be exploited by a threat and cause a negative impact to the application. </li></ul></ul>
    9. 9. General Categorization Of Vulnerabilities By Root Causes <ul><li>Security Design Flaws </li></ul><ul><ul><li>Caused by lack of security requirements, knowledge, design reviews </li></ul></ul><ul><ul><li>Cannot be identified by security tools alone since are logical vulnerabilities and require manual threat analysis/ threat modeling </li></ul></ul><ul><li>Security Coding Errors </li></ul><ul><ul><li>Coding bugs that result in vulnerabilities </li></ul></ul><ul><ul><li>Can be identified with source code analysis tools and manual code reviews </li></ul></ul><ul><li>Security Mis-configurations </li></ul><ul><ul><li>Mis-configuration for application security policies </li></ul></ul><ul><ul><li>Can be identified through change control processes </li></ul></ul><ul><li>Business Logic Attack, Mostly Exploit Security Flaws in Design and Security Mis-Configurations </li></ul>
    10. 10. OWASP T10, WASC And SANS T25 Vulnerabilities Potentially Exploited For Attacking Business Logic
    11. 11. Attacks Exploiting Authorization Vulnerabilities & Root Causes <ul><li>BUSINESS LOGIC ATTACKS: </li></ul><ul><ul><li>Attackers are allowed to access web resources not restricted by role, simply changes the workflow/URL to a privileged page using forceful browsing </li></ul></ul><ul><ul><li>Attacker change the transaction data by modifying parameters to change data used in a transaction such as the price of goods purchased </li></ul></ul><ul><li>VULNERABILITIES: </li></ul><ul><ul><li>INSUFFICIENT AUTHORIZATION (WASC-02), FAILURE TO RESTRICT URL ACCESS (OWASP A7), IMPROPER ACCESS CONTROL ( SANS-CWE-285) </li></ul></ul><ul><li>ROOT CAUSES: </li></ul><ul><ul><li>Lack of granular enforcement of authorization rules through policy such as Role Base Access Controls (RBAC) </li></ul></ul><ul><ul><li>Business rules enforced using client side parameters instead of server side logic </li></ul></ul>
    12. 12. Attacks Exploiting Authentication Vulnerabilities & Root Causes <ul><li>BUSINESS LOGIC ATTACKS : </li></ul><ul><ul><li>Attacker guesses questions in challenge/questions (e.g. account creation, change password, recover password, this includes KBA , Knowledge Based Authentication) </li></ul></ul><ul><ul><li>Attacker replay the session such as a valid sessionID to logon in the application after previous logout </li></ul></ul><ul><li>VULNERABILITIES: </li></ul><ul><ul><li>INSUFFICIENT AUTHENTICATION (WASC-01), BROKEN AUTHENTICATION AND SESSION MANAGEMENT (OWASP A3), INSECURE DIRECT OBJ REFERENCES (OWASP A4) MISSING AUTHENTICATION FOR CRITICAL FUNCTION (CWE 306) </li></ul></ul><ul><li>ROOT CAUSES: </li></ul><ul><ul><li>Design flaws for password reset transactions </li></ul></ul><ul><ul><li>Easily guessable Challenge/Questions </li></ul></ul><ul><ul><li>Session management issues such as lack of single logout across applications-tiers </li></ul></ul>
    13. 13. Attacks Exploiting Mis-Configurations Vulnerabilities & Root Causes <ul><li>BUSINESS LOGIC ATTACKS: </li></ul><ul><ul><li>Attacker exploit mis-configuration of access control policy to exploit fail open-insecure conditions, unauthorized access to resources, bypass of authentication and RBAC, information disclosure through errors </li></ul></ul><ul><ul><li>Transaction and security events are not logged so the attack cannot be audited/investigated </li></ul></ul><ul><li>VULNERABILITIES: </li></ul><ul><ul><li>SERVER MISCONFIGURATION (WASC-14), SECURITY MISCONFIGURATION (OWASP A6) </li></ul></ul><ul><li>ROOT CAUSES: </li></ul><ul><ul><li>Configuration management process lacks validation/testing of enforcement of roles and permissions in the configuration policy used by application’s development frameworks (e.g., Struts, Spring, ASP.NET) </li></ul></ul><ul><ul><li>Logging and auditing does not cover BLA events </li></ul></ul>
    14. 14. Attacks Exploiting Insufficient Anti-Automation Vulnerabilities & Root Causes <ul><li>BUSINESS LOGIC ATTACKS: </li></ul><ul><ul><li>Automatic injection of web pages (e.g. forms/Frames) in application workflows to collect PII (e.g. Zeus Trojans) and do fraud </li></ul></ul><ul><ul><li>Automated trying of credit card values to validate them through conventional validation flaws (e.g. enumeration) </li></ul></ul><ul><ul><li>Spam of pre-authenticated transactions to flood back-office processes </li></ul></ul><ul><ul><li>Denial of service by locking usernames through automation locking and by flooding of call center for unlocking requests </li></ul></ul><ul><li>VUNERABILITIES: </li></ul><ul><ul><li>INSUFFICIENT ANTI-AUTOMATION (WASC-21) </li></ul></ul><ul><li>ROOT CAUSES: </li></ul><ul><ul><li>Lack of detective control for automation (e.g. CAPTCHA, automated intrusion detection) to protect transactions </li></ul></ul>
    15. 15. Attacks of Insufficient Process Control Vulnerabilities & Root Causes <ul><li>BUSINESS LOGIC ATTACKS: </li></ul><ul><ul><li>Fraudster can bypass validations checks for performing transactions such as shipping for goods not being purchased </li></ul></ul><ul><ul><li>External or internal attacker can spoof the data traffic between front end and back-end business logic processing </li></ul></ul><ul><ul><li>Fraudster can have secrets required to perform a transaction sent to him by spoofing authorized user emails, phone numbers etc </li></ul></ul><ul><li>VULNERABILITY </li></ul><ul><ul><li>INSUFFICIENT PROCESS CONTROLS (UNCLASSIFIED) </li></ul></ul><ul><li>ROOT CAUSES: </li></ul><ul><ul><li>Insufficient enforcement of transaction validations performed at different stages of the business transaction before committing to it </li></ul></ul><ul><ul><li>Gaps in enforcing authentication at different tiers of the application architecture (e.g. application and messaging) </li></ul></ul><ul><ul><li>Lack of out of band validations and call backs to validate the transaction </li></ul></ul>
    16. 16. Risk Analysis and Mitigation of BLA
    17. 17. Security Requirements for Mitigation of BLA <ul><li>Require every application to document business logic with data flows for transactions and the access control matrix used </li></ul><ul><li>Use application threat modeling to identify threats to application data flows and use and abuses cases that can be exploited for business logic attacks </li></ul><ul><li>Security test (manually) for business logic attacks that could exploit common vulnerabilities such as OWASP 3,4,8, WASC 1,2,14,21 and SANS-25-CWE 285,306 </li></ul><ul><li>Develop and execute business logic tests for insufficient process controls by deriving them from the use-abuse cases and transaction/data flow analysis performed during threat modeling </li></ul><ul><li>Rank the risk severity of business logic flaws/vulnerabilities can be exploited for business logic attacks </li></ul><ul><li>Manage the risk by devising preventive and detective controls to mitigate the likelihood and impact of business logic attacks </li></ul>
    18. 18. The Logic Tier In Web Architectures Not All Business Logic Resides on the Application Server ! Beware of Web 2.0 Apps that include business logic client side (e.g. AJAX, Widgets, Mashups Beware of Flaws in Integration of Business Logic with Server Components
    19. 19. Threat Analysis Of End to End Data Traffic Spoofing And Tampering XML/HTTP Parameters Forceful browsing Threats to Application Business Logic Spoofing And Tampering Web Service Calls Spoofing And Tampering Message Calls Spoofing And Tampering SQL Queries Elevation Of Privileges/ RBAC Misconfigurations
    20. 20. Threat Analysis with Use And Abuse Cases
    21. 21. Threat Analysis Using Business Logic Transaction Flows
    22. 22. Business Logic Attack To Shopping Cart (Real) Catalogue Price: $ 27.99 Charged Price: $.99
    23. 23. Enforcement of Roles and Permissions With Design of Role Base Access Controls
    24. 24. Security Testing Of Business Logic Attacks <ul><li>Main objective is to test that the application business rules cannot be altered by business logic attacks </li></ul><ul><li>Require testers to write NEGATIVE test cases and scripts to identify potential exploits of business logic flaws during Q/A test validation cycles. Examples include : </li></ul><ul><ul><li>Trying to bypass of user validations and prerequisite checks for a transaction, </li></ul></ul><ul><ul><li>Trying to bypass multi factor authentication in a transaction, </li></ul></ul><ul><ul><li>Trying to force a transaction and access high privileged resources logging as low privilege user, </li></ul></ul><ul><ul><li>Tampering with business logic parameters during a request to try to access resources, </li></ul></ul><ul><ul><li>Replaying session tokens after logouts to try to log back to the application, </li></ul></ul><ul><ul><li>Trying to force the application to fail in unsecure conditions such as fail open or as un-handled exceptions </li></ul></ul><ul><ul><li>Trying to alter price of items and validate if they can be added, </li></ul></ul><ul><ul><li>Trying to abuse registration, account openings/applications with automation scripts </li></ul></ul>
    25. 25. Assigning Risks to Business Logic Flaws Using OWASP Risk Methodology
    26. 26. Possible Countermeasures Against BLAs <ul><li>Deterrent controls </li></ul><ul><ul><li>Anti-automation (e.g. CAPTCHA, logic puzzles) </li></ul></ul><ul><li>Preventive controls </li></ul><ul><ul><li>Authentication and authorization of transactions (e.g. ESAPI) </li></ul></ul><ul><ul><li>Secure pre-auth password reset and userID reminder processes </li></ul></ul><ul><ul><li>Strong business process validation/checks for transactions (e.g. Out Of Band) </li></ul></ul><ul><ul><li>Data validation/filtering of transaction parameters (e.g. ESAPI) </li></ul></ul><ul><ul><li>Secure session management such as the SessionIDs used in business transactions </li></ul></ul><ul><li>Detective controls </li></ul><ul><ul><li>Application layer detection rules for BLA patterns (e.g. ESAPI IDS) </li></ul></ul><ul><ul><li>Web Application Firewall (WAF) rules (e.g. ESAPI WAF) </li></ul></ul><ul><ul><li>Fraud monitoring and detection rules (e.g. Fraud Detection Systems) </li></ul></ul><ul><ul><li>Logging and alerts of business transaction events as well as related security events </li></ul></ul>
    27. 27. Q & Q U E S T I O N S A N S W E R S
    28. 28. Thanks for listening, further references <ul><li>Designing a Framework Method for Secure Business Application Logic Integrity in e-Commerce Systems </li></ul><ul><ul><li> </li></ul></ul><ul><li>Seven Business Logic Flaws That Put Your Website At Risk </li></ul><ul><ul><li> </li></ul></ul><ul><li>Testing for business logic (OWASP-BL-001) </li></ul><ul><ul><li> </li></ul></ul><ul><li>Get rich or die trying, “Making money on the web, the black hat way” </li></ul><ul><ul><li> </li></ul></ul>
    29. 29. Further references con’t <ul><li>OWASP Top Ten Project </li></ul><ul><ul><li> </li></ul></ul><ul><li>The WASC Threat Classification v2.0 </li></ul><ul><ul><li> </li></ul></ul><ul><li>CWE/SANS TOP 25 Most Dangerous Coding Errors </li></ul><ul><ul><li> </li></ul></ul><ul><li>OWASP Application Threat Modeling </li></ul><ul><ul><li> </li></ul></ul><ul><li>OWASP EASPI </li></ul><ul><ul><li> </li></ul></ul><ul><li>OWASP Testing Project </li></ul><ul><ul><li> </li></ul></ul>