This week, we have two API vulnerabilities: a command injection vulnerability in the control API of the Wavlink WL-WN531P3 router, and another one on the website of a security regulator in South Africa. In addition, we have views on the management of internal and external APIs, and how the new Lambda Function URLs on AWS enable rapid API development.
Vulnerability: Command injection vulnerability in Wavlink WL-WN531P3 router
This week’s first vulnerability is a command injection vulnerability in an internal API of the Wavlink WL-WN531P3 router. A security researcher discovered an internal admin interface /cgi-bin/adm.cgi that the router UI used to execute arbitrary commands. Unfortunately, this endpoint was vulnerable in several ways:
- The endpoint did not enforce authentication at all — an example of API2:2019 — Broken authentication.
- The endpoint also did not enforce any Cross-Site Request Forgery (CSRF) protection, making the router vulnerable to attacks beyond the local network.
- Most importantly, the endpoint was vulnerable to OS command injection attacks that allowed attackers to execute arbitrary commands on the router.
The researcher initially discovered the vulnerability through the UI, which provided a diagnostic function to perform ping commands to user-supplied IP addresses. By manipulating the IP address to a malicious payload, such as ; ls, the researcher observed that the router responded with a response that included a directory listing. This implied that the router concatenated the user input with the ping command to execute a potentially dangerous command, like ping ; ls. This is a textbook example of command injection common on IoT devices.
The researcher went on to use Burp Suite to discover that the session cookie could be removed, and that arbitrary commands could be injected by setting the pingIp parameter.
The vulnerability is tracked as CVE-2022-23900. At the time of writing, there was no patch available or other product update details.
Vulnerability: System passwords exposed through an API
The second vulnerability this week is another example of broken authentication on a web API, this time affecting the website of a South African private security regulator.
The vulnerability affected an API endpoint that allowed attackers to download a single XML file containing a variety of sensitive information of administrative users, including PII and passwords. The endpoint did not require any form of authentication, allowing totally anonymous access to this data. Another concern was that where passwords were used, they were very weak and could be easily guessed in many cases.
A local news site MyBroadband was made aware of the vulnerability and contacted the site owner who moved rapidly to close the vulnerability. There is no evidence that any attackers were able to exploit this vulnerability to leak information.
The key takeaway is to beware of backend web APIs as these are easily discoverable, and ensure that all APIs exposed publicly enforce robust authentication.
Article: Management of internal versus external APIs
A common contentious topic in the API community is the concept of “internal-only” APIs and whether they should be treated differently from external, or public, APIs. This week, we have views on some considerations on these differences.
Internal APIs are most commonly used to interconnect internal backend systems in a standard manner to eliminate numerous bespoke integrations. Typically, these APIs may be referred to as east-west APIs. External APIs are intended to be exposed to either customers and API consumers, or to 3rd parties, like partners. Typically, these APIs may be referred to as north-south APIs.
The author highlights six areas where management of internal and external APIs may be different:
- Publishing and discovery
- Security and access control
- Policy enforcement
- Performance testing
- Monitoring and metrics tracking
- Deprecation/sunsetting processes
Of interest to readers of this newsletter are the perspectives on security and access control and policy enforcement. Most importantly, internal APIs should still be subject to adequate API security measures and controls: the fact that they are internal does not mean they are immune to attack, or that they may not be exposed externally in the future. However, priority should be given to securing external APIs as these are the ones most readily accessible to bad actors. While external APIs generally require more specific access control policies (typically rate and quota limits) to reduce abuse or misuse by external users, internal APIs can be laxer with respect to access controls since their users can be more easily controlled.
Article: New Lambda Function URLs on AWS
Finally this week, we have coverage of the recently introduced Lambda Functions URLs on the AWS platform. These are specifically aimed to facilitate the more rapid development of APIs without requiring the complexities of API gateways. The new feature allows API developers to create an API by specifying the endpoint URL, selecting the authorization type (either AWS_IAM or none), and the specifics of the backing Lambda function (language and architecture) as shown below:
If the endpoint does not use IAM authorization, the user must implement the authorization in the Lambda code, which can support JSON Web Token (JWT), OpenID Connect (OIDC), and OAuth2 authentication methods. It is also possible to configure Cross-Origin Resource Sharing (CORS) to control HTTP access from other servers.
Whilst this is likely to be a boon to API developers, it poses some new security challenges such as:
- How are these APIs to be governed, and tracked in an inventory?
- How are these APIs to be tested from a security perspective?
- How to use standard libraries and patterns for authorization code? There is a danger of excessive code duplication if every Lambda has to implement the same method.
- How can runtime protections (API firewalls or WAAPs) be included in front of such APIs? Security is now totally reliant on the integrity of the backing Lambda code.
The drive toward serverless is likely to drive new API deployment architectures, such as these Lambda Function URLs. However, a savvy security team should ensure all new risk vectors are considered.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
