API Security Weekly: Issue 169

This week, we have details of a vulnerability in the popular WordPress plugin, WP HTML Mail, which potentially exposed 20,000 WordPress sites, and a vulnerability in TeslaMate software exposing dozens of Teslas to remote access. On more positive news, we have an introduction to vAPI, an open-source laboratory for learning API security, and an article on how to reduce API attack surfaces.

Vulnerability: WordPress Sites Exposed by Insecure REST API

This week, we have another vulnerability in a WordPress plugin: this time, the popular WP HTML Mail plugin. The vulnerability is tracked as CVE-2022-0218 with a CVSS score of 8.3, and it was discovered by Wordfence researcher Chloe Chamberland. The vulnerability may have impacted up to 20,000 WordPress installations, rendering them vulnerable as a result of the cross-site scripting (XSS) bug courtesy of an unprotected REST API endpoint in the plugin.

This REST API endpoint allowed clients to save email theme settings that were used for rendering WordPress content. According to Chamberland, there was no authentication at all, which allowed attackers to upload any content — such as malicious JavaScript — to the template that was then stored in the WordPress database. XSS attacks execute within the context of the current browser session, meaning that users with elevated privileges could have enabled attacks like phishing campaigns or even entire site takeovers.

Chamberland recommends that users verify they are using version 3.1 — the patched version of the plugin — or higher.

Vulnerability: Tesla Vehicles Exposed by a Vulnerability in 3rd Party Software

Another vulnerability disclosed this week comes from security researcher David Colombo. The vulnerability was found in a 3rd party application, TeslaMate, which is widely used by owners of Tesla vehicles, and it does not affect Tesla’s infrastructure directly. News of the vulnerability first broke in a Tweet by Colombo in early January, when he claimed to have “full remote control of over 20 Tesla’s in 10 countries.” Fortunately, it turned out that this did not include the ability to remotely control the movement of the vehicle.

TeslaMate is a free logging and dashboard utility used by Tesla owners to access their vehicles’ hidden data. Typically, TeslaMate is self-hosted by users and requires a vehicle API key to access the data of the vehicle. Unfortunately, the web dashboard contained several security flaws that allowed anonymous access and using default passwords. These issues — coupled with the fact that many users exposed the dashboards to the internet for convenience — meant that an attacker could gain access to the vehicle API key.

Colombo claimed that he could access dozens of vehicles through these exposed dashboards, but the total number exposed in this manner is likely higher. The maintainer of the TeslaMate provided a software update within hours of being notified, and Colombo believes that Tesla has revoked thousands of driver’s API keys.

Lessons learned here include:

• API keys are the keys to the kingdom — always be wary of directly or (as in this case) inadvertently disclosing these keys.
• As an API provider, always ensure that you have a tested, reliable key revocation and rotation procedure in place.
• As an API consumer, be wary of default configurations and passwords. It pays to make a habit of always checking and changing these.

Tools: Introducing vAPI, an Open-source Laboratory for API Security

An extremely popular item this week has been the coverage vAPI, an open-source tool designed to mimic OWASP API security Top 10 vulnerabilities. The tool is primarily intended as a vulnerability exercise and a test platform to provide an immersive environment where to learn more about API security.

The tool is available on GitHub and was developed by the security researcher Tushar Kulkarni. It is based on the Laravel PHP framework using MySQL as the database layer. A Docker image is provided for ease of use. Kulkarni recommends using a "manipulator-in-the-middle" (MitM) proxy, such as Burp Suite or OWASP Zap, to explore all available vulnerabilities.

We’re excited to feature this tool and look forward to featuring updates in the future: the tool’s roadmap includes, for example, a dashboard on progress through the challenges the tool provides. Certainly, the OWASP Juice Shop has been invaluable in enabling the community to learn about web application security, and we wish Kulkarni well in establishing vAPI as the equivalent for API security.

Article: Reducing API Attack Surfaces

The final article this week comes from Security Boulevard discussing practical approaches to reducing API attack surfaces and the risk of exposure. Beyond the obvious security benefits, this also brings greater quality and reliability, and reduced maintenance effort.

The author suggests the following techniques for reducing API complexity:

• Use existing standards and conventions whenever possible: Don’t reinvent the wheel and go adding complexity and maintenance issues.
• Use a stateless authorization model: Use standard authorization patterns to reduce the complexity instead of rolling your own.
• Deprecate old endpoints: Identify and actively deprecate and remove old or unused endpoints.
• Push functionality to clients when possible: Leverage clients for intensive processing, but be careful you don’t introduce unintended client-side security issues.
• Be conservative about returned data: Reduce the amount of data returned to the client.
• Reduce variant resource representations: Avoid creating multiple endpoints for similar functions — consolidation is the key.
• Separate the endpoints with read or write permissions: Restrict user roles based on allowed actions, and use the correct HTTP verbs (methods).
• Align resource boundaries to permission boundaries: Use fine-grained resources to minimize the likelihood of excessive exposure or mass assignments.
• Implement generic audit logs: Use standard patterns when implementing logging.
• Use a web application and API protection solution: Protect API endpoints with runtime "shield right" protections.

Although many of these techniques are self-evident, they may prove hard to implement in reality. Nevertheless, the article is a worthwhile read for all API architects.