APIsecurity.io - APISecurity.io Newsletter: Issue 150

This week, Rapid7 disclosed two vulnerabilities in Fortress S03 WiFi home security system that their researcher Arvind Vishwakarma discovered. The vulnerabilities allowed an attacker to remotely disarm the alarm system using an unauthenticated API endpoint and elementary and easily obtainable user account information, such as an email address. At the time of writing, Fortress had not acknowledged the issue, nor provided any indication of an intent to resolve it. It is also not known if the issue can be resolved without a hardware upgrade.

The first vulnerability relates to an unauthenticated API endpoint on the public management portal of the alarm system. The attack consists of two requests, namely:

1. A call to the command 30001 with the target’s email address provided as a parameter.
2. Using the International Mobile Equipment Identity (IMEI) returned in the previous call, a subsequent call to the command 00005 to disarm the system.

A suitably motivated attacker could easily gain knowledge of an intended target’s email address, provided they knew the physical address of a user of the affected Fortress security system. The API endpoints are presumably for internal use only (Fortress does not appear to have documented them) but — as shown below — can very easily be manipulated to disable the system:

The second vulnerability relates to the use of an unencrypted radio frequency (RF) channel for key fobs and accessories. An attacker could record RF packets for disarming a system and then replay these to disarm a target system since no there is no encryption protecting the packet payload.

The original disclosure (including the above image) is available on the Rapid7 website and disclosed as CVE-2021-3927[67].

The lessons learned here include:

• This is a blatant case of API2:2019 — Broken authentication, or more to-the-point, authentication that is entirely absent in this case.
• Undisclosed but publicly accessible API endpoints can easily be discovered and reverse engineered by researchers and attackers alike.

Renowned API researcher/hacker Alissa Knight recently published a whitepaper entitled “Go Fuzz Yourself“. The whitepaper makes a powerful case for the use of fuzzing techniques as part of an approach to securing APIs. Primarily intended for red-team members or pentesters, the paper is of interest to AppSec professionals wanting to further improve the coverage of their API portfolio.

Knight’s view is that a reliance on pentesting or static analysis alone results in false negatives that leads to vulnerabilities remaining undiscovered. At an executive level, this may lead to CISOs concluding that their security posture is artificially strong. In reality, APIs may have latent vulnerabilities which remain undiscovered and which attacker with automated tooling may easily exploit. Knight endorses the wide-scale adoption of the OpenAPI Specification (OAS) as part of a “shift left” approach to API development and security of said APIs. With a well-defined OpenAPI definition, it is possible to conduct automated testing further downstream in the software development life cycle.

In the absence of an OpenAPI definition, Knight describes how an API can be partially “reverse-engineered” by using the Kiterunner tool. Kiterunner is a content discovery tool specifically designed for the enumeration and discovery of APIs. From their GitHub:

“When using traditional content discovery tooling, such routes are often missed and cannot easily be discovered. By collating a dataset of Swagger specifications and condensing it into our own schema, Kiterunner can use this dataset to bruteforce API endpoints by sending the correct HTTP method, headers, path, parameters, and values for each request it sends.”

Knight provides a clear demonstration of Kiterunner in action, showing how it is possible to enumerate a set of API endpoints and then either to fuzz these endpoints with arbitrary data payloads, or to redirect the requests to Burp Suite for further investigation. The API discovery uses a master word list of common REST API nouns and verbs, built from the ingestion of large collections of public OpenAPI definitions. By fuzzing a combination of these nouns and verbs, the tool effectively maps out the API under attack as illustrated below.

Knight also describes Microsoft’s RESTler tool, which is able to exercise an API based on the underlying OpenAPI definition.

Key takeaways from here include:

• Existing static analysis and dynamic analysis tools on their own will leave undiscovered vulnerabilities in an API.
• Similarly, reliance on pentesting or manual testing alone will also result leave vulnerabilities undiscovered.
• Content discovery is a powerful tool for the enumeration of undocumented APIs.
• An OpenAPI definition is a powerful aid toward driving a “shift left” approach to API development and security.
• Thorough security testing of an API is a time-consuming process, and a savvy tester should make use of tools such as those described in the article.

We also have an excellent guide from Jens Neuse on hardening and securing GraphQL API implementations. Increasingly, developers are providing GraphQL APIs to represent more complex datasets and relationships that can readily be presented through REST APIs. Neuse’s hypothesis is that with the relative increased complexity of GraphQL APIs, the are more likely to be insecure. A simple metric that Neuse presents is that the size of the codebase required to render a GraphQL query is about four times the size required to parse a URL — more code is likely to provide for more vulnerabilities. Simply browsing the vulnerabilities on HackerOne suggests this hypothesis has some credence.

The article provides a detailed description and illustration of thirteen of the most common GraphQL security issues. Whilst some are relatively benign or corner cases, there are significant issues relating to data leakage, denial of service (DoS) attacks, SQL injections, CSRF vulnerabilities, and authentication vulnerabilities.

Finally, Neuse concludes with detailed development guidelines aimed at reducing the likelihood and impact of typical GraphQL API implementations. This easily readable and well-written guide should prove invaluable to API developers and security teams alike.

Finally this week, we have an opinion piece from Brian Platz on the evolution of a central data governance model for APIs. Platz suggests that the increased adoption of APIs — led by the likes of Facebook, Google, Uber, and Airbnb — has blurred the more traditional boundaries of a simple producer—consumer model. Increased business pressure to open up access to core business data through APIs has led to a complex data governance paradigm.

As an illustration of this increased complexity, consider the example of a developer implementing a new API endpoint. The API developer is responsible for decisions on how the said endpoint should be authenticated to (standard pattern such as OAuth2 exist to this end) and how users should be authorized, and this is where the challenges begin. Developers may not have the full context of the data rendered by their API and may be overly permissive in allowing access. Platz suggests that organizations with complex data governance and privacy requirements provide centralized functions to allow access to data, thereby allowing data and security experts to control data access rather than the API developers.

The article concludes with an optimistic view on the future state: “A data-centric approach to security makes data governance more automated and scalable, which, in turn, allows organizations to open data sets more freely to consumers of that data”. Somewhat paradoxically, more rigid controls on data at source open up the possibility of more open and accessible data to consumers and end users.