Business Logic Attacks – Stealthly, and Often Hard to Call Illegal, These Fraudulent Attacks Can Cost Organizations Big Money
In my old neighborhood there used to be a “smart” traffic light system. It was put in place to control cars exiting a parking lot and the heavy traffic on the main street. When a car approached the traffic light, a sensor would trigger the lights, which in turn allowed the cars coming out of the driveway to receive the right of way. The problem? There was a huge delay as cars needed to approach the sensor before it turned green, and once the car passed, it would immediately go back to red. This caused heavy congestion every morning for cars coming out of the lot. One day, a neighbor took a scrap of metal and placed it in front of the sensor so the light would stay green. It was not illegal, just one that defeated the logic of the system. The person may not have known it, but my neighbor performed a real-world business logic attack.
Business Logic Attacks
Business logic attacks abuse the functionality of a program—as opposed to an application vulnerability. They’re stealthy because they don’t come as malformed requests and they contain legitimate values. Often, we cannot even call them illegal. Mainly performed by business logic bots (BLBs), these types of attacks can perform a variety of attacks. There’s no better way to illustrate the attacks than by providing a few examples:
* Denial of Service – For example, an online ticketing service may hold reserved seats for ten minutes before actually timing out if a purchase is not made. A business logic bot may then attempt to reserve all seats rendering the seats unavailable for potential customers.
* Queue Jumping – Most commonly we see business logic attacks launched against online ticket providers where high profile concert tickets are being offered. These ticketing applications serve visitors on a first-come first serve basis. The BLBs then send out multiple frequent requests in order to receive front positions in the queue.
* Auction Sniping – Here, the BLBs monitors a timed online auction and places a winning bid at the last possible moment. Ultimately, this gives the other bidders no time to outbid the sniper.
* Poll Skewing – In this case, BLBs are engaged to vote for a particular option. Consider this old – yet very representative – example from 2008. Victoria’s Secret, the lingerie company, held an open poll for customers to vote for their favorite college to appear on the collegiate line. Instead, the poll turned into an episode of revenge of the nerds. Students from various universities wrote scripts to nominate their school. At the peak of college rivalry to gain lingerie fame, MIT servers actually crashed the computers with the influx of votes nominating their university.
* Click Fraud – The attackers abuse the underlying business model where companies pay per click.
* Poker bots – Several bots belonging to a single individual can be placed at the same table to share information and gain an unfair advantage.
As we see, automation is vital to the success of the attacks, which means that by identifying automation, we have a chance to beat the hackers at their own game.
Solution
Combating business logic attacks requires a new set of prevention and detection techniques. The new techniques should strive for accuracy, but at the same time be able to accommodate a certain degree of error (i.e., false positives) without breaking the application.
A solution requires two stages.
Solution Step #1: Detection
Traditional methods of using blacklists and verifying the request structure are important. These techniques will eliminate the mass of attacks. But what about those attacks which bypass these controls? Several methods can be implemented. One such method is adding extra content in the response which would be interpreted differently by a human-driven browser and by an automated tool. A second method would be to add different measurement metrics such as event frequency and click rates. These can be used to detect script-related or brute force attacks. A third technique would be to test the application’s flow usage. For example, a business logic attack might skip transaction validation.
Will a single method do the trick? Probably not. Will there be false positives? Of course. But does this pose a problem? No, and this is where mitigation comes in.
Solution Step #2: Mitigation
Business logic attacks are automated and we cannot prevent the attack from occurring. As such, mitigation techniques should try and decrease the effects of an attack by raising the cost of an attack. Most often the system’s reaction to a suspected automation attempt should not be blocking, but rather challenging the client. In this way, legitimate clients are not materially affected, but automated clients become ineffective. These challenges take into consideration that a second of delay is not noticed by a human, but can make the difference for an automated attack. Such delays can be implemented using CAPTCHAs, by providing client-side computational challenges or adding bogus links which cause an automated tool to follow indefinitely.
| Part in a Cybercrime Series – Read Noa’s Other Featured Columns Here |
Summary
Web automation has changed the way we do business. For example, the indexing of our web applications by search engines is crucial to our business. But as we saw, there’s also a dark side to this type of web automation. It may come in the form of scraping competitor websites, rigged voting, click fraud and other nefarious activities. Are all of these activities considered illegitimate? No. It depends on the context of things: who is performing the activity and which part of the business logic is being invoked. By studying the origin of the request and detecting automation, we can apply subjective measurements to flag any unauthorized use of the application.
Next Column
One use for business logic attacks is to brute force passwords. This will be the focus of my next column – how are passwords being cracked, and what alternatives are out there for enterprises?
