This week, we have news of a high severity remote code execution (RCE) vulnerability in the F5 BIG-IP security suite. We also feature an article from Curity on API security maturity, an article on hardening Google Cloud Platform implementations, and finally a threat matrix for GraphQL APIs.
Vulnerability: RCE vulnerability in F5’s BIG-IP security suite
This week, F5’s BIG-IP load balancing and security suite was affected by a Remote Code Execution (RCE) vulnerability. The vulnerability is in the iControl REST API that allowed remote access to platform configuration. Attackers could gain access to an exposed endpoint /mgmt/tm/util/bash that did not require any authentication.
The vulnerability was given a CVSS score of 9.8 and is tracked as CVE-2022-1388. F5 have addressed the issue and advised users to patch their systems immediately. They also advised users of affected systems to block this API endpoint or restrict access to the ports that it uses.
According to Shodan and Censys searches, up to 16,000 BIG-IP systems with a management interface are exposed on the public internet. The Stack reports that users of the BIG-IP platform include Amazon, Google Cloud, Huawei, Microsoft, Korea Telecom, and numerous other telecommunication companies.
This is a rather severe case of API2:2019 โ Broken authentication โ always ensure that exposed APIs are fully authenticated to prevent anonymous access.
Article: API security maturity model
As readers of this newsletter are only too aware, the security implementation of APIs covers a broad spectrum. Curity has produced a four-level API security maturity model to enable organizations to assess their current maturity and define a roadmap to improved security.
The key elements of each stage are as follows:
- Level 0: API Keys and Basic Authentication: This level is the most elementary and โ unfortunately โ most widely occurring, particularly in legacy systems. In this case, authentication is over Basic Auth, or with API keys inserted into the header or the body.
- Level 1: Token-Based Authentication: At this level, a token exchange mechanism is used to identify the client based on a token. Although this level improves on level 0, there is still no indication of what the client is allowed to do, only their identity is verified through the possession of the token.
- Level 2: Token-Based Authorization: Modern APIs typically use OAuth2 to achieve the next level of maturity, allowing scope-based authorization to resources. However, improved maturity comes at the cost of increased complexity.
- Level 3: Centralized Trust Using Claims: On the final level of maturity, a strong claims-based model based typically on JWTs, typically signed for integrity, is used. Using standard protocolsย like OAuth and OpenID Connect is advised.
The key takeaway for me: highly mature APIs place trust in very few sources.
Article: Hardening Google Cloud Platform implementations
Cloud platforms are increasingly popular with developers due to their flexibility and advanced features driving innovation. Unfortunately, modern cloud platforms are extremely complex and open to misconfiguration.
In a technical blog post, the security research team at Mitiga describes a scenario of a “command and control” takeover on the Googe Cloud Platform (GCP). The details were reviewed by the security team at GCP who awarded a small bounty to the researcher but did not categorize the scenario as a vulnerability.
The researchers discovered that the GCP control plane exposed an API endpoint getSerialPortOutput() on the VM compute module. By sending arbitrary data to this API, the researchers believed that attackers could use this API to send “command and control” data to affected VMs. Although certain API calls required elevated privileges, access to getSerialPortOutput() required only very basic permissions. The GCP security team recommends using the VPC Service Controls to remove access to this API if it is not required.
The researchers provided the following general advice for hardening cloud systems:
- Avoid using built-in roles, rather use principles of least privilege.
- Evaluate whether dangerous functionality is required and switch it off if not required.
- Only allow access through standard, secure methods, such as SSH and RDP.
- Run applications and services at the lowest privilege level possible.
The usual advice applies: beware of hidden complexity and potentially insecure default configuration.
Article: A threat matrix for GraphQL APIs
Finally this week we have a handy guide for those tasked with the implementation of GraphQL solutions: a threat matrix for common GraphQL backends.
The author assesses how commonly used GraphQL backends rank according to a number of security topics relating to GraphQL:
- Validations
- Field suggestions
- Query depth limit
- Query cost analysis
- Automatic persisted queries
- Introspection
- Debug mode
- Batch requests
A very useful guide for developers and pentesters alike. As per the previous article, beware of potentially insecure default configurations.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
