Security Exploit of Business Logic Flaws, Business Logic Attacks
•Download as PPT, PDF•
3 likes•6,725 views
Business Logic Attacks: vulnerability analysis and risk management presentation at ISSA Security Conference in Louisville, KY, October 7, 2010
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Security Exploit of Business Logic Flaws, Business Logic Attacks
Similar to Security Exploit of Business Logic Flaws, Business Logic Attacks (20)
More from Marco Morana
More from Marco Morana (20)
Recently uploaded
Recently uploaded (20)
Security Exploit of Business Logic Flaws, Business Logic Attacks
- 1. How to Prevent Business Flaws Vulnerabilities In Web Applications Marco Morana OWASP Cincinnati Chapter, January 2011 Meeting
- 7. Business Logic Attacks Examples
- 10. Vulnerability Analysis of Business Logic Flaws
- 13. Vulnerabilities Potentially Exploited By BLAs
- 19. Identification and Mitigation of Business Logic Flaws
- 20. Business Logic In Web Application 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
- 22. Identification Of Security Flaws: Application Threat Modeling Process
- 23. Data Flow Diagramming 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
- 24. Security Flaws Identification With Use And Abuse Cases: Password Reset
- 25. Identification of Business Logic Flaws Using Transaction Analysis: Shopping Cart
- 26. Shopping Cart BLA Example Catalogue Price: $ 27.99 Charged Price: $.99
- 28. Checking Configuration of Security And Business Rules
- 30. Q & Q U E S T I O N S A N S W E R S
Editor's Notes
- 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 http://www.coolcart.com/jewelrystore.html 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 http://www.owasp.org/index.php/ESAPI_Access_Control. 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)