Issue 78: Vulnerabilities in WordPress Rank Math, Tapplock, and TicTocTrack ⌚

A popular WordPress plugin, Rank Math, had a critical API security vulnerability. This plugin makes search engine optimization (SEO) of WordPress sites easier, and it has over 200 000 installs.

One of the functions of the plugin was to update metadata on WordPress post. For this, the plugin registered a REST-API endpoint, rankmath/v1/updateMeta. This endpoint had no authorization checks and so no restrictions for its use.

This allowed attackers to modify various metadata of not just WordPress posts, but also elsewhere in the WordPress deployment. The most critical scenario allowed attackers to make changes to the users table. Attackers could disable or modify any existing users, and even create their own administrative accounts for takeover. Attackers could also create redirects, opening the door for further attacks through malicious websites.

Luckily the vulnerability has already been fixed. Lessons learned from this one:

• APIs should always have authentication and authorization checks.
• The scope of using an API usage should be limited to cover only the bare minimum of what is required for the business operations.
• Input should always be checked to enforce only the scenarios for which the API is supposed to be used.

US Federal Trade Commission (FTC) has reached a settlement with the smartlock manufacturer Tapplock. The company had been marketing their lock as “unbreakable” when in fact it had pretty glaring security issues. These also included some API vulnerabilities:

• Transport: Communications between the Tapplock app and API server were not using HTTPS but unencrypted HTTP, and thus susceptible to snooping and man-in-the-middle (MITM) attacks.
• Broken Object Level Authorization (BOLA, aka IDOR): After successfully logging in, a user could then access the account of another user without being redirected to the login page. This gave access to all personal information of the other user, including “usernames, e-mail addresses, profile photos, location history, and precise geolocation of smart locks”.

See the full FTC document or a summary from The Register. We have previously covered vulnerabilities in smartlocks in our issues 38 and 45.

We covered a vulnerability in TicTocTrack, an Australian GPS-enabled smartwatch for kids, about a year ago in issue 27. Now, Gordon Beeming has found that the system had a recent regression and the vulnerability was re-introduced.

This BOLA/IDOR issue allowed any user to get data and gain control over any other TicTocTrack smartwatch. That obviously endangered both privacy and the physical security of children using the devices. As serious as they come.

With product teams iterating on the versions of their systems, you cannot treat security as a one-time review or one-time fix process. Security vulnerabilities may be introduced or re-introduced on any code change. This is especially dangerous when data access interfaces are used like OData (Open Data Protocol) in this particular case.

Security needs to shift left and be a part of API design, development, and testing, iterating as the code is iterated on.

Microsoft Visual Studio Code (VS Code) has a popular OpenAPI extension, OpenAPI (Swagger) Editor, that helps create, edit, and check the security of REST API definitions.

This week, the extension has been updated, and it now enables developers to perform API Contract Security Audit — a SAST analysis — even on composite API contracts: API definitions that reference parts like payload definition schemas from external files with $ref references.