identification & exploitation of business logic flaws in web applications filippos georgiadis...

Identification & Exploitation of Business Logic Flaws in Web Applications

Filippos Georgiadis (MScIS, CISSP, CISA)Security EngineerCosmote Mobile Telecommunications


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.


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


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)


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, …


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


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!


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)


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.



[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.



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.



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.



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.



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!



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.


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


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 ]


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]


…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]


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]


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


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)


Putting it all together [ The kickoff ]


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)


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.


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)


Questions?

[email protected]

Be realistic. Demand the impossible...

identification & exploitation of business logic flaws in web applications filippos georgiadis...

Documents

business policy

web applications disclaimer

identification of entry

gene kim slide

parameter names

weak points

information exchange

parameter values