Rafal Los and Prajakta Jagdale, researchers for HP Software & Solutions, have come up with a proof-of-concept (PoC) for automating the discovery of so-called business logic flaws -- defects or chinks in an application's design that can be manipulated for nefarious purposes. These aren't security vulnerabilities, but instead design flaws that expose the business process or transaction to abuse, such as a bad guy retooling an online order to get an expensive item for a lot less money.
Los will demonstrate the PoC tool, as well as the beginnings of a testing framework for automating the process of finding these flaws, at Black Hat Europe in Barcelona next week. He says he and Jagdale decided it was time to dig into this "new territory" and try to find a way to automate the process of finding these flaws in Web apps. "We're planting a flag on the moon," Los says. "I seriously doubt this [research] is going to be the be-all, end-all. But I do hope that we come up with something that gets people excited" about the problem, he says.
It's difficult to know for sure just how many online fraud incidents began with an attacker manipulating a business logic flaw in a Web application. There have been a few high-profile breaches that were executed via a logic flaw, such as the infamous AT&T iPad customer breach last summer where researchers with Goatse Security used a business-logic flaw in AT&T's Web app to get the email addresses of more than 100,000 iPad customers, including some high-profile people. And a logic flaw in the app that handles Sears' gift card account queries on its website allowed a researcher to brute-force attack the app and grab all valid and active Sears and Kmart gift cards from the company's database.
Given that security scanners and research focuses on security vulnerabilities and not business logic flaws, researchers long have warned that attackers can easily manipulate logic flaws to make the apps do their bidding -- all without disrupting the application itself and often going undetected. An attacker could lower the price of an item he orders online, for example, without raising any flags in web application firewalls or intrusion prevention systems.
"It's very encouraging to see researchers digging more deeply into classification of business logic problems. While business rules are domain-specific, there may be some domain-independent patterns to them. We are likely to find new wrinkles to old problems, and maybe some new problems that will be easier to find once we know what to call them. Where automated methods can help is still anybody's guess, but it's worthwhile to explore," says Steve Christey, the technical lead for the Common Weakness Enumeration project at Mitre.
Christey says as the more obvious exploitable security bugs are eradicated, the more attackers could then target business logic flaws, so this research could be helpful in preventing more of those attacks.
So why has it taken so long to come up with a way to find these flaws in apps? Los says it requires painstaking manual testing and knowing the underlying logic of the app itself to find logic flaws. "I'd say that a fair amount of attacks on applications" originate in business logic flaws, he says. "There's a difference between hacking the app or injecting something and defrauding a system. Business logic attacks fall into 'defrauding' the system."
Los has identified two main types of logic flaws: privilege manipulation, a defect due to insufficient authentication or authorization, and transaction control manipulation, in which a business process is broken.
At Black Hat Europe next week, Los will demonstrate the PoC tool and introduce a framework for automated fuzzing of these flaws across multiple applications and transactions, for instance. He says the tool isn't ready for release. "This is show-and-tell," he says. "In order to make something that you can take home and start using is going to require significantly more effort ... we are just providing [proof] that this kind of stuff can be tested in a logical fashion."
It's unclear just how research will evolve: Los says depending on whether it catches fire, it could remain an R&D effort or even morph into a commercial one.
Either way, it has to cross the chasm between security experts and software developers, he says. He says quality assurance testers ultimately would be the ideal adopters of such a tool. "Initially it will go to security testers to find these bugs, and then how do you have that conversation with the developer? What do you tell them to fix? And how do we fix it?"
The automation piece will be different than in today's security testing, he says. "It will be more like with what the QA folks do in functional testing," he says.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.