Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint //


02:30 PM
Jerry Gamblin
Jerry Gamblin
Connect Directly
E-Mail vvv

Lessons Learned from the Facebook Breach: Why Logic Errors Are So Hard to Catch

By ensuring that each layer of protection scours an application for unintended uses, you can find the flaws before the bad guys do.

The fact that a relatively simple flaw allowed an anonymous hacker to compromise 50 million Facebook accounts serves as a powerful reminder: When hackers, professional or amateur, find business logic errors, as defined by CWE 840, the exploitation can be incredibly damaging.

The worst part is that finding logic errors can't be solved with automated tools alone. The best advice on how to avoid logic errors comes from Aristotle: "Knowing yourself is the beginning of all wisdom."

In practice, that means three stages of review: At the DevOps level, use automated tools to find the low-hanging fruit and developers who code with security in mind. Use quality assurance (QA) teams that have deep knowledge of how your application should work. Lastly, beef up your bug bounty program to ensure an external review of your application from talented and experienced security researchers.

While logic errors are some of the hardest vulnerabilities to spot, setting up your teams and incentives the right way can help you catch them before a hacker does.

What Happened at Facebook
Logic errors, sometimes called design flaws, are flaws in code that allow users to take unwanted actions because they weren't foreseen by the original developers. In the early days of e-commerce, some sports fans discovered they could change the date of an event in a URL to gain access to tickets before the rest of the public. The flaw is that nobody told the system not to sell tickets before a certain date.

In Facebook's case, the flaw involved the ability to preview birthday videos as someone else using Facebook's "View As" function. Before posting a birthday video, users could see what the post would look like to their co-worker or friend using View As. But once there, if the user right-clicked to view the page's source code, instead of seeing the access token for their own profile in that code, it contained the access token of the person they were viewing the video as.

The discovery of the vulnerability itself required no special tools, just the ability to right-click. Exploiting it required only a minimal understanding of how access tokens work. And with knowledge of the flaw, most college freshmen software developers would be able to write a code to scrape 50 million tokens. In other words, the breach was not an incredibly sophisticated attack.

And while the exploit itself was not technically sophisticated, it took place in a fairly obscure portion of Facebook's user experience. The exploited code had been released 14 months previously, so the person behind this could have been someone who was simply in the right place at the right time to discover it, or it could have been an extremely methodical bug hunter.

Finding Logic Errors Is a Personnel Issue
Some apps have millions of lines of code for developers and production teams to review. It's not surprising that something like this flaw slipped through at Facebook. Frankly, it can happen to any company.

Logic errors are the result of a logical failure that another human made. They cannot be discovered with automated scanners because there has not been a development tool created that can replicate the creativity of the human mind when interacting with an app.

Finding logic errors is simply a people management issue, in an era where good cybersecurity talent is hard to find. At a basic level, developing secure code is the responsibility of the team that wrote the code. But at a higher level, it's up to executives to institute processes and gather resources to give development teams the time and resources to uncover these issues.

The Three Layers of Checks Needed to Spot Logic Errors
The first step of minimizing logic errors is to create a development team that codes with security in mind. Developers should be maniacal about looking for logical errors in their code. To do that successfully, they need to be in tune with the business, its architecture, and the entire application, not just their subset.

Second, a strong QA team can also reduce the risk of design flaws, but it must have an in-depth understanding of how the application is designed. The QA team should also have a few people on board with an inclination to experiment outside the application's intended uses.

When a company unveils a photo sharing tool, you want someone on QA who thinks "I wonder what happens when I upload a terabyte at once" or "How can I delete photos on someone else's account?" QA isn't about making sure the app fits your use case, it's about making sure the app fits the real world.

Lastly, the importance of a bug bounty program can't be overstated, but it has to be managed for success. There are two reasons for this. Lots of firms operate on the "move fast and break stuff" model. They code fast and don't always follow best practices. This means they rely more heavily on security researchers to do their QA.

Also, if your security program is mature, you have automated security tools in place that allow security researchers to spend more of their time looking for potential logic errors. You should compensate them accordingly.

Bug bounties should be proportionate to the size and importance of the app. Your bug bounties should also take into account the market for zero-day exploits which is often willing to pay more than you.

Facebook is one among many companies that have been caught with a logic error. It certainly won't be the last. But by ensuring that each layer of protection, from the developers to QA to bug bounty hunters, scours the application for unintended uses, you can find the flaws before the bad guys do.

Related Content:


Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Jerry Gamblin's interest in security ignited in 1989 when he hacked Oregon Trail on his 3rd grade class Apple IIe. As a security evangelist, researcher and analyst, he has been featured on numerous blogs, podcasts and has spoken at security conferences around the world. When ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Moderator
10/11/2018 | 5:24:50 PM
Obtaining security
Your highest goal cant be cutting costs. It has to be providing security. Ask what can be done to improve security rather than what needs to be done to satisfy management. Certifications, test driven development, and automated tools can destroy security unless you understand that they are the starting point, not the finish line. I knew a manager who fired people who found bugs because he didnt want to admit his unit might be at fault. You need people who appear obsessive about security, but it just means theyre realistic. Most incentive programs actually encourage insecurity.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Cybersecurity Bounces Back, but Talent Still Absent
Simone Petrella, Chief Executive Officer, CyberVista,  9/16/2020
Meet the Computer Scientist Who Helped Push for Paper Ballots
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/16/2020
Register for Dark Reading Newsletters
White Papers
Latest Comment: Exactly
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-21
IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 is vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information. IBM X-Force ID: 185590.
PUBLISHED: 2020-09-21
IBM WebSphere Application Server Liberty through running oauth-2.0 or openidConnectServer-1.0 server features is vulnerable to a denial of service attack conducted by an authenticated client. IBM X-Force ID: 184650.
PUBLISHED: 2020-09-21
IBM Aspera Web Application 1.9.14 PL1 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 188055.
PUBLISHED: 2020-09-21
IBM Business Automation Content Analyzer on Cloud 1.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the i...
PUBLISHED: 2020-09-21
IBM DataPower Gateway 2018.4.1.0 through 2018.4.1.12 could allow a remote attacker to cause a denial of service by sending a specially crafted HTTP/2 request with invalid characters. IBM X-Force ID: 184438.