Background

On 28 September 2018, Facebook disclosed that they had discovered three vulnerabilities in their platform. They were subsequently able to determine that an attacker had exploited the combination of these vulnerabilities and this led to the disclosure of profile information of around 30 million of their users to the attacker.

Facebook have been relatively transparent about what they have found in two detailed blog-posts although the end result, the theft of access tokens, has wide ranging implications including affecting 3rd party web sites where a user uses their Facebook account to login. It was also suggested that the access tokens could be misused to affect 3rd party sites which a user had not used Facebook to login but which had configured in a certain way, allowing the attacker to create that link and login to the 3rd party site.

Facebook gave a detailed explanation of each of the three bugs in their blog-post but they boil down to the following:

1. Missing authorisation on one out of a whole set of possible actions in a particular feature.
2. Access token generated with incorrect permissions.
3. Access token generated for incorrect user.

Whilst it is possible with the benefit of hindsight to see ways in which these issues could have been detected, there are a few important points to consider.

The challenge of business logic bugs

Bugs and vulnerabilities are always going to exist in code. Certain types of bugs such as Cross-site Scripting (XSS) or SQL Injection (SQLi) tend to follow a certain pattern which doesn’t rely on how the site works and are therefore easier to identify and prevent using standard secure development life-cycle controls such as static analysis or automated or manual dynamic testing (for example Burp scanner or a manual tester performing Application Security testing). Additionally, there may be ways of detecting these issues at run-time such as the report flag of the X-XSS-Protection header or alternatively a Web Application Firewall (WAF) which looks for suspicious content in requests.

However, vulnerabilities related to business logic (which applies to all three of the above issues) may not be immediately obvious and will be very hard to identify and prevent using any form of automated technique. They will also be hard to detect at run-time using any sort of pattern matching rule as they will generally not show an obvious pattern.

Another important point is that the number of bugs/vulnerabilities is going to be in proportion to the size and the complexity of the application. Facebook is clearly a very complex platform but it is certainly not the only organisation with this level of complexity.

Facebook has a highly skilled security team, a mature application security program and a well-developed bug bounty programme. They even went to the trouble of creating an entire test version of their application which ethical hackers can use to experiment and look for security vulnerabilities. Whilst they were unable to prevent this incident from occurring, the maturity of their application security programme meant that they were still able to detect and remediate the issue, despite the vulnerabilities being business logic bugs.

Detection at the application level

The OWASP (Open Web Application Security Project) Top 10 Most Critical Web Application Security Risks project provides a list of the most common and concerning web application security risks based on data and feedback provided by the application security community. The 2017 release included a number of new items, one of which was “Insufficient Logging and Monitoring”. The 2018 release of the OWASP Top 10 Proactive Controls project similarly includes “Implement Security Logging and Monitoring” as item number 9.

This brings us to the reason that Facebook were able to report this incident in the first place. Facebook have application level monitoring through which they noted the unusually high volume of token activity. This led to them carrying out an investigation which ultimately led to them detecting the attack. Interestingly, Facebook also have much more granular monitoring (which they have published information about here) which is designed to detect permission issues on an individual basis but this did not appear to catch the issue. Nevertheless, the fact that they had multiple layers of monitoring meant that they still detected the issue.

Advice on application level monitoring

We would strongly recommend that the key lesson which organisations should be taking from this incident is the importance of having a programme of implementing application level monitoring and continually improving and refining this process.

Organisations should start by instrumenting sensitive operations within the system such as when security validations fail or authentication and authorisation actions. The OWASP AppSensor project provides some ideas of the types of events and actions which should be monitored and recorded. A Web Application Firewall (WAF) may provide some of this functionality but it is unlikely to be able to capture business logic specific events.

The organisation should then start creating alerting rules around the events which have been captured based on how suspicious or dangerous they are. As a simple example, for something like an incorrect login, an alert may only be raised after a number of attempts. However, for something like an invalid value for a client-side validated field sent to a web API which would be a clear indicator of someone attempting to subvert the functionality, the alert may occur after only one incidence.

The organisation can then decide how these alerts will be received and consider proactive steps to take in response. This could range from just informing the operations team to throttling the connection with the suspicious activity. The application could even block particular users or sources or disable certain sensitive operations for them or for all users.

All of this activity should be implemented on an incremental basis whereby monitoring, alerts and actions are implemented on a gradual basis so as to assess the impact and benefit at each stage.

Conclusion

Many organisations have network or infrastructure level monitoring but this will only be able to detect a network or infrastructure level attack. This monitoring is still important but it will be completely unable to detect an application business logic attack of the sort experienced by Facebook. By investing in application level monitoring as well, even on an incremental basis, organisations will be in a far better position to detect these types of application level attacks.

This is a really interesting topic so if you want to discuss further, please feel free to get in touch using the details below. I hope to produce some more specific and detailed resources and guidance on this in the future.

Josh Grossman

Thanks to Mikael Levy for reviewing and providing feedback on this post.