Finding Your Organization’s Business Logic Flaws

DarkReading.com reports:

 Cybercriminals increasingly are employing no-tech or low-tech techniques for making big money online — no exploits or sophisticated hacker tools required.

The techniques themselves aren’t new — some have been around for nearly a decade. But the Web model has made these schemes that capitalize on so-called business logic flaws more lucrative than ever, according to Jeremiah Grossman, one of the researchers who will pull back the covers on these insidious and often transparent methods of attack at Black Hat USA next week in Las Vegas.

A sample:

One hack that Grossman and Ford will show at Black Hat involved a bank customer of WhiteHat’s, which was among 600 small- to medium-sized financial institutions that were vulnerable to a logic flaw in their application-hosting provider’s system. The flaw allowed attackers to steal money from the bank. “The attackers didn’t build [or] host their own Website,” Grossman says. “One particular flaw in the ASP’s [application service provider] system allowed [them] to see and transfer money on any account on the entire system.”

The ASP wasn’t willing to do the complete system redesign it would have taken to shore up the problem once WhiteHat pointed it out. “During one of our tests, we got the [system] to send us a check in the mail for $2, made out to ‘WH Test,’ and we emailed a photo of it to our customer.”

It was discovered that the cybercriminals had stolen money from the bank using the flaw in the ASP’s system and wired over $70,000 to Eastern Europe, Grossman says. He plans to provide details of the ASP’s flaw in his presentation next week.

If you’re looking for business logic flaws in your organization’s application, here are a few handy places to look:

  • Look through your organization’s meeting notes, and find any place where a developer said, A user would never do that! where “that” is “Enter a negative value for the dollar amount or item quantity,” “Change the URL to a different account number,” or any sort of thing which a normal user wouldn’t do but someone gaming the system might try.
  • Review your defect tracker for issues marked Resolved – Won’t Fix, Functions as Designed, or Known Issue – To Be Fixed Later.  Developers like to hide the hard things in these buckets.
  • Open old drafts of requirements documents and find the expensive validation things that the project managers or other stakeholders struck in the interest of time or budget.

That’s where I’ve seen those “business logic” issues hidden.  Of course, don’t expect to fix them.  What’s a user’s money when compared to meeting timeline and budget?  Unimportant, that’s what!

Comments are closed.


wordpress visitors