identification & exploitation of business logic flaws in web applications filippos georgiadis...
TRANSCRIPT
Identification & Exploitation of Business Logic Flaws in Web Applications
Filippos Georgiadis (MScIS, CISSP, CISA)Security EngineerCosmote Mobile Telecommunications
Identification & Exploitation of Business Logic Flaws in Web Applications
Disclaimer:All vulnerabilities presented were discovered during my professional avocation with web application penetration testing. Although the essence behind these vulnerabilities is presented intact, actual URLs, parameter names, parameter values, etc. have been altered to protect those involved.
BLE, theory and implementation, is a project pursued in my own free time and is not a direct product of my work at my current employer.
All contents of this presentation represent my own beliefs and views and do not, unless explicitly stated otherwise, represent the beliefs of my current, or any of my previous in that effect, employers.
Identification & Exploitation of Business Logic Flaws in Web Applications
Presentation Agenda Defining business logic and business logic abuse
Real life examples on the identification and exploitation of business logic
flaws
The good, the bad and the ugly of business logic penetration testing
Automating the identification of business logic flaws [BLe]
Mitigation theory, steps and ideas
Identification & Exploitation of Business Logic Flaws in Web Applications
Business logic is a non-technical term generally used to describe the functional
algorithms [business rules, business policy and workflows] that handle
information exchange between a repository [database] and a user interface of
any [web] application.
It's the process, formula, algorithm, decision tree, methodology, query, magic 8
ball, or any other means used to perform a piece of work that is specific to a
[web] application.
…If it is a part of a [web] application then Business Logic / Business Rules /
Business Logic Layer CAN be exploited.
Hope is not a strategy. Trust is not a control. (Gene Kim)
Identification & Exploitation of Business Logic Flaws in Web Applications
What business logic exploitation / abuse is NOT:
[*] Overflows [buffers, stack, heap]
[*] Injections [SQL, LDAP, XML, SSI, ORM, command]
Cross Site [*] [scripting, request forgery, flashing, tracing]
Traversal, hijacking, denial of service, …
Identification & Exploitation of Business Logic Flaws in Web Applications
What business logic exploitation / abuse MIGHT be:
Learning / understanding how the [web] application works
Information gathering, reconnaissance, identification of entry points, application
fingerprinting
Identification of interesting and sensitive functions and parameters
Behavior analysis, error codes and identification of problematic conditions
Brute forcing and / or fuzzing
Race conditions, replays
Analysis of authentication and authorization schemas, session management,
cookie attributes
Privilege escalation
Identification & Exploitation of Business Logic Flaws in Web Applications
What business logic exploitation / abuse IS:
Inspiration
Thinking out of the box
Trying to imitate and find weak points on the developer’s way of thinking
Creating and executing what - if scenarios
Trying to force the application to perform things it is not supposed to do
Everything of the above fails? Then try digging deeper!
Identification & Exploitation of Business Logic Flaws in Web Applications
Why business logic exploitation / abuse is HOT:
Every application has unique business logic [lack of boredom!]
There are virtually unlimited ways to identify business logic flaws and to exploit
them
Requires personal effort, inspiration and imagination [not execution of tools]
It is really difficult to use generic defenses [WAF, web server add-ons, safe functions
and procedures] in order to defend against and to eradicate the existence of
business logic flaws
This is security hacking, breaking a system by thinking differently. (Bruce
Schneier)
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [1]
Web Banking Site: Abuse of Process Validation
Case: Money transfer at third parties
If you maintain one account at the Bank only a destination account is requested.
If you maintain multiple account at the Bank then you get an additional [From] field in
order to choose the account from which you will transfer the money
Executing the transaction the following POST request is generated:Where is the catch:
Intercept and reverse values [Account] and [TargetAccount] and you reverse the transaction.
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [2]
[virtual] Cards Issuing Site: Abuse of Functionality
Case: Issuing cards with fake data
If you successfully authenticate into the site then you can request the issuing of a credit
card.
All required personal data are fetched from your account [except the card’s requested
money limit and the card type]. The [accept] button generates the following POST request:Where is the catch:
Intercept and modify [FirstName], [LastName], [Bday], [TaxNo], etc. and this will result in issuing a credit card with fake [arbitrary] personal data.
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [3]
Billing Site: Information Leakage
Case: Obtaining arbitrary billing records
Each customer is identified with a unique [secret] customer code.
Each customer can maintain multiple accounts. If such a customer requests cumulative
billing records then a request is generated containing those [secret] customer codes
separated with commas.
[e.g.: …&custcodes=871386036,955832114]Where is the catch:
No check whether the customer code belonged to the logged in client. Furthermore, intercepting the request and injecting thousands of [hard to guess] customer codes, separated by commas, a malicious user could retrieve, eventually, all registered users’ billing records.
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [4]
Various Payments Site: Abuse of Process Validation
Case: Issue payment even if the expiration date has elapsed
The site allowed customers to perform various monthly payments. [e.g.: phone, electricity,
water bills]
The payment could be performed until a specific date [deadline]
If the client crossed the deadline a message informed the client that the specific payment
could not be processed / posted.
Two JavaScript functions were used. The SubmitOnlinePayment(); if
everything was OK and the DenyOnlinePayment(); if the payment had
expired.
Where is the catch:
The payment expiration check was taking place client side. Spotting those two functions and issuing a Javascript:SubmitOnlinePayment(); on the page resulted in bypassing this security control.
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [5]
Gaming Platform: Authentication Bypass
Case: Authentication bypass using hashed passwords
Upon authentication the site stores various values in cookies.
Those credentials are used in each post authentication HTTP request for [some kind] of
verification.
One of the values was identified as the username [in clear text] and the other as the
user’s hashed password [md5] Where is the catch:
HTTP traffic can be intercepted, cookies can be stolen. By replaying this request, using only game_hash and game_user a malicious user can bypass authentication and access the game as another user.
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [6]
Travel Bookings Site: Information Leakage
Case: Bypass of brute force protection mechanism
A registered user [valid username] can issue up to [3] consequent invalid login attempts.
The specific username, after those attempts, is locked for a period of one day.
A warning message is presented to the user that the specific username is locked and will
be unlocked the next day. […Or the user can contact the website’s support]
Where is the catch:
If the username and / or password were invalid a [403 Forbidden] message was generated. By locking a user out and sending a visual alarm to the browser a malicious user can enumerate usernames. Furthermore, when an account was locked, and you used the valid password in order to login a different [500 Internal Server Error] was presented to the user. Continuing the brute force attempt was trivial, all you had to do, after guessing the correct password, was …waiting one day!
Identification & Exploitation of Business Logic Flaws in Web Applications
Real Life Examples [7]
Quiz Platform: Abuse of Functionality
Case: Total results manipulation
Registered users competed in a ten questions quiz.
The questions were chosen from a specific large pool.
The winner was the one who would answer the most questions correctly in the minimum
time.
After the final question an [XML] was posted to the web server.
Where is the catch:
Code leaked the path to the questions pool. Furthermore Intercepting and manipulating this XML request a malicious user could modify the [TimeSpent] for each question, choose specific questions to answer and impersonate other users.
Identification & Exploitation of Business Logic Flaws in Web Applications
What we have seen so far… [ the nice part ]
Business logic is present, in various forms, in every [web] application
Identifying business logic flows and exploiting them is, many times, the fastest
and fancier route to the treasure
Business logic exploitation leaves minimum traces of malicious activities. [Looks
like legitimate traffic]
Business logic and business logic abuse is irrelevant to the [web] application
underlying technology [programming / scripting language, web server, application server,
database technology] so no expertise on specific technologies is required on behalf
of the penetration tester
Identification & Exploitation of Business Logic Flaws in Web Applications
What we have seen so far… [ what to look for ]
Dedicate some time on exploring and understanding the [web] application, it’s
logic, it’s rules, it’s singularity…
Ask for any logic / business logic / data flow diagrams and for technical or
business documents in order to understand how the business owners and the
developers though when building the [web] application.
Do not believe anything, even if you have read it in the documentation and no
matter who said it! Check the validity of the business rules and of the diagrams,
try to build your own and do comparisons, build attack scenarios, try to identify
weak points and exploit them.
Identify the normal / legitimate sequence of actions. Try various combinations
and examine the results. [ e.g.: if a b c TRY a c OR CALL b, c directly ]
Identification & Exploitation of Business Logic Flaws in Web Applications
What we have seen so far… [ what to look for ]
Search for business logic friendly variables [usernames, passwords, prices, dates,
session values, account numbers, credit cards, authorization levels, customer codes,
personal data, …] and try to build attack scenarios around those variables and the
related functions.
Check for custom made sensitive functions and controls [authentication and
authorization mechanisms, crypto-related functions and operations e.g.: encryption,
hashing, randomness, …] there is a [very] good chance that they will fail the test!
Search for things which try to stay in the dark… [hidden fields, obfuscated data,
cookie values, asynchronous calls, client side scripts] try to understand their purpose,
why they are not in plain view, is it bad programming, laziness, security through
obscurity, something else…?
Search for mechanisms which reduce the initial entropy [secret questions,
predictable or serial values, reduced alphabet, length limitations]
Identification & Exploitation of Business Logic Flaws in Web Applications
…Theoretically any of the following ideas is a good place to start when examining a [web] application for business logic flaws:
Try to impersonate another user. This can be accomplished by changing specific parameters [user-ids, usernames, session-ids, URL paths, cookie values, guess the secret question]
Try to modify specific values [prices, account numbers, credit cards information, expiration dates, invoice numbers] in order to privilege from such modifications.
Try to reverse specific fields [from-to money transfer accounts, from-to dates, from-to folders for file transfers, from-to email addresses]
Try to retrieve sensitive information [predictable resource locations and paths, serial and/or easily guessable session-ids, serial and/or easily guessable file names, serial and/or easily guessable folder names]
Try to bypass [vertically & horizontally] authentication and authorization schemes [direct calls to post authentication web pages, exploitation of asynchronous requests (XHR and/or JSON), unauthenticated consummation (direct calls) to web services, modification of referer URLs, manipulation of cookie values]
Identification & Exploitation of Business Logic Flaws in Web Applications
What we have seen so far… [ the ugly part ]
The identification of business logic flaws is not a trivial task. [no predefined
patterns, algorithms, rules]
Business logic flaws identification and exploitation can be an [extremely] time
consuming task.
No matter the hard work and effort, the penetration tester can never be certain
that has identified all business logic flaws in a [web] application.
Limited tools are available [at least the ones I know of] that can automate business
logic flaws identification and exploitation.
http://code.google.com/p/accorute/ [OWASP project] … best of luck trying to use it!
Cenzic ClickToSecure [SaaS, so possibly not automated … either way commercial]
WhiteHat Sentinel [SaaS, so possibly not automated … either way commercial]
Identification & Exploitation of Business Logic Flaws in Web Applications
Automating the IDENTIFICATION process [ Theoretical approach ]
Web application crawling [obvious step]
Identification of variables and functions [authentication, data exchange, forms, …]
Selection of a subset of business logic friendly variables and actions
Categorization of those variables [usernames, passwords, prices, dates, session
values, account numbers, credit cards, authorization levels, customer codes, personal
data…]
Fuzz each value appropriately [using a pool of predefined signatures and scenarios]
Never mind what the result is but how unique it is [under specific rules] in
comparison to the cloud [even the smallest but not repeated changes might indicate the
existence of business logic flaws]
Manually examine the top scored results in order to conclude in a business logic
flaw was successfully detected
Identification & Exploitation of Business Logic Flaws in Web Applications
Putting it all together [ BLe - The Logic Exploiter ]
BLe is an alpha stage project written in RUBY with various extensions [scruffy,
yaml, fxruby, hpricot, spider, nokogiri, ...and quickly shifting to wwmd(*)]
For each response various factors are recorded, weighted and combined–The amount of time required for the web server in order to process and respond to each request.–The HTTP return code.–The length of the response.–The number of HTML tags in the response.–The presence of HTML comments in the response.–The presence of predefined specific words in the response.–The md5 hash of the response.
BLe will not conclude if a business logic flaw definitely exists but it will calculate
the probability of a business logic flaw under the chosen scenario / weights /
parameterization
(*) Black Hat USA 09, Ruby for Penetration Testers (Mike Tracy, Chris Rohlf, Eric Monti)
Identification & Exploitation of Business Logic Flaws in Web Applications
Putting it all together [ The kickoff ]
Identification & Exploitation of Business Logic Flaws in Web Applications
Putting it all together [ The kickoff ]
Identification & Exploitation of Business Logic Flaws in Web Applications
Putting it all together [ The kickoff ]
Identification & Exploitation of Business Logic Flaws in Web Applications
Putting it all together [ The kickoff ]
Identification & Exploitation of Business Logic Flaws in Web Applications
Putting it all together [ Looking ahead ]
BLe : What [almost] works!?
The idea, the algorithms, the calculations…
Trivial things [data handling, decent performance, browser interaction, customizable, expandable]
The commitment
BLe : What doesn’t work!?
The user friendliness
The error handling
The automated operation in medium and large web applications
The code quality
…many more
I have not failed. I have just found 10,000 ways that will not work. (Thomas Edison)
Identification & Exploitation of Business Logic Flaws in Web Applications
Is it possible to defend against business logic abuse? …you can at least try!
Follow the Defense in Depth principle [If the application is the last component
standing and every defensive mechanism protecting it has been destroyed then the
application must protect itself]
Never trust client side security controls. Always implement data input validation
and business logic controls on the server side
Stick to standards for sensitive functions [authentication, authorization, crypto
related…]
Do not consider encryption as a silver bullet [rarely solves the problem]
Avoid, avoid, avoid password recovery schemes relying on secret questions
Just because you can't see it doesn't mean it's not there. (Jeremiah
Grossman)
If you think encryption is the answer to your problem, then you don’t
understand encryption and you don’t understand your problem.
Identification & Exploitation of Business Logic Flaws in Web Applications
Is it possible to defend against business logic abuse? …you can at least try!
If you need to rely in randomness [sessions, tokens, URLs, coupons, order numbers…]
think twice on how random is what you are building / using
Avoid, avoid, avoid security through obscurity. If you are not certain how to
secure any part of the [web] application ask a professional
Think of the security implications before you decide to add / change / modify any
part of the [web] application
Do not rely on automated scanning tools only. Have professionals examine your
[web] application. Request explicitly for business logic security testing
Complexity is the worst enemy of security, and it almost always comes in the
form of features or options. (Niels Ferguson)
Identification & Exploitation of Business Logic Flaws in Web Applications
Questions?
Be realistic. Demand the impossible...