Rafal Los, Security Strategist for HP Software, Down the Security Rabbithole Podcast
It’s no secret that web applications are at the center of the ongoing conflict between malicious hackers and those defending the applications. As more and more critical business functions migrate to an Internet presence, web applications play an extremely [...]
Rafal Los, Security Strategist for HP Software, Down the Security Rabbithole Podcast
It’s no secret that web applications are at the center of the ongoing conflict between malicious hackers and those defending the applications. As more and more critical business functions migrate to an Internet presence, web applications play an extremely vital role in business. Hackers know this well and have been exploiting weaknesses in web applications at an alarmingly high rate.
While age-old issues like SQL Injection and authentication weaknesses continue to plague developers, there is another class of security defects that has been flying under the radar. Web application logic defects are not new. In fact, the topic has been covered at great length by various academic and research organizations. But unfortunately, this class of issues has not received enough attention due to the prevalence of much simpler attack vectors. While hackers may not be exploiting this class of defects in high volume, they are nevertheless extremely effective and stealthy.
Discuss in Forums
Mapping and Hacking
To attack application logic, a hacker must first understand the function of the application itself. Although a small detail, it makes this type of hacking different. While it is an advantage to know the application when looking for SQL Injection and like defects, application flow knowledge is absolutely critical when discovering and exploiting logic defects. Application flow presents a complex and often difficult attack surface, but, to a hacker looking to remain undetected, it is the perfect choice.
A hacker who wants to exploit application logic must first take the time to map out the application flow and determine vulnerabilities. An experienced hacker would use a visual graphing tool to draw the application page-flow and workflow to fully understand the application. As the application is being mapped, the hacker keeps track of page-state, page parameters and available actions. Finding logic defects in applications is painstaking, requiring a hacker to look for subtle hints inside these tracked components.
For example, hidden variables that only exist on certain pages within an application, such as the login page or during privilege elevation, may point to an exploitable issue in the authentication or authorization service. Finding such parameters can be tricky, but once they are identified they can be studied for patterns, or simply fed to a targeted fuzzer to discover lapses in logic.
There are a number of application logic defects that are obvious to someone looking for them. For example, an application that implements a login lockout mechanism to prevent hackers from guessing passwords, but stores that information in a cookie, is easy to manipulate. The hacker simply deletes the cookie (or never accepts it) and can keep grinding away at the password mechanism. This is yet another reason to perform all critical functions away from the client – in other words, at the back-end server where the logic and environment is more likely to be under the control of the developer. Allowing logic to be stored and executed on the client is like a bank building miniature cash dispensing machines that customers can take home with them. It sounds great in theory, because it allows customers to not have to visit a banking center, but, since the bank no longer has direct control over the physical component given to the customer to take home, this will ultimately lead to fraud.
Online gaming systems are a particular target for logic tampering and hacking. An application, such as an online poker room that allows re-submission of an action in the form of a bet or hand, is vulnerable to being manipulated. For example, if a player feels he has a winning hand and places a large bet, then discovers a sign that their opponent also feels they have a good hand, they would be able to re-submit a previous request (typically in the form of an AJAX request) and make a lower bet. An application that does not have appropriate logic controls to identify that the player has already used their turn, can be manipulated and, in fact, has been in the past.
Picking on Parallel Processes
Turning a developer’s time-optimization technique against the application is also a great way to exploit application logic defects. Developers are often trying to speed their applications and optimize workflow to accomplish multiple tasks concurrently. An attacker can exploit this type of optimization by looking for what appear to be parallel processes that should logically run in serial.
A good example is a business with an online shopping cart that has also implemented a customer loyalty system. Once a customer logs in and places their order, their purchases are converted to ‘points’ which can be redeemed for goods or services at a later date. A hacker can attempt to manipulate this system by placing a small order, then entering an incorrect payment method to ensure that the transaction fails. Often, the loyalty points transaction and payment transaction are conducted in parallel for speed. However, even though the payment transaction fails, the loyalty points are still added to the customer’s account. This type of attack can be repeated, or even scripted, to obtain a large volume of loyalty points while not spending any money with the vendor.
Exploiting Numerical Handling Vulnerabilities
It’s important to validate that an application handles various numeric inputs correctly. Once again turning to a shopping cart feature, if a hacker can input a negative number into an order system, various issues can arise including something called “phantom inventory.” If the application allows a negative number to be used, a hacker can simply add inventory that doesn’t exist during the purchase or acquisition process.
The Devil is in the Details
Logic defects in an application can cause serious business challenges. Discovering these types of issues takes time, and isn’t a simple matter of coding up a scanner tool. Each issue has a unique method of discovery, is different from one application to another, and is often different from one developer to another. The one thing all logic defects have in common is they are virtually invisible to modern web attack mitigation platforms. Whether there is a web application firewall, an intrusion prevention system, or any combination thereof – it’s nearly certain that attacking web application logic will be invisible to the victim –whether that it be an enterprise, a small business, or a governmental entity.
This is primarily due to the lack of identifiable patterns such as tell-tale SQL Injection markers. Requests and responses are often legitimate, and don’t trigger an alarm or raise suspicion, even if the hack is successful. Remaining undetected makes this type of attack very attractive to hackers, fraudsters, and others.
Additionally, these types of security defects in applications often slip past testing teams as scanning tools and formal logic testing methodologies are still maturing. The best weapon against these types of security defects is the Quality Assurance testing organization at each business. QA testers are well-versed in application logic for the purposes of functional testing. Rather than developing logic testing methodology from scratch, security testing teams should collaborate with their QA organizations to add logic testing into their already well-adopted methodologies.
It Takes a Village
Logic defects are difficult to avoid in code, difficult to effectively test for, and nearly impossible to detect. As hackers exhaust obvious and scriptable defects on the Internet, web-based applications will likely be their next attack vector. Rather than waiting for the deluge of attacks, and for the appearance of scathing headlines, now is the time for development organizations, application security teams, and businesses to work together to fortify their web-based applications against these attacks. Focus on discussing this with your QA organization, develop an internal testing methodology that suits the applications you build, and test your existing applications. You can then apply these lessons learned to new applications you design, before they are deployed throughout the organization.
* Image at top of article from book cover of “Lewis Carroll in Numberland: His Fantastical Mathematical Logical Life” by Robin Wilson.
Rafal Los, Enterprise and Cloud Security Strategist for HP Software, combines over a decade of deep technical expertise in information security and risk management with a critical business perspective. From technical research to building and implementing enterprise application security programs, Rafal has a proven track record with organizations of diverse sizes and verticals.
Prior to joining HP, Los defined the framework for a software security program and served as a security lead at a Global Fortune 100. Los also contributed to the global organization’s security and risk-management strategy internally and with their customers.
Be sure to check out his podcast, Down the Security Rabbithole:
“Follow the Wh1t3 Rabbit! Have you ever wondered why “the business” doesn’t understand “security”, or vice versa? Do you lead an organization where security and business are disconnected? This podcast is for you, then. This podcast/show is dedicated to building a better relationship between security and the business it serves, because unfortunately even though no one wants to purposely be ‘insecure’ it is clear, at least on the business level, there is a lack of understanding.”
Article source: http://www.ethicalhacker.net/content/view/395/2/