{{announcement.body}}
{{announcement.title}}

API Security Weekly: Issue #72

DZone 's Guide to

API Security Weekly: Issue #72

This week, look at how WordPress got exploited by a 3rd-party plugin and how API security research can sometimes be a very ungrateful endeavor.

· Integration Zone ·
Free Resource

This week, we take a look at how WordPress got exploited by a 3rd-party plugin and how API security research can sometimes be a very ungrateful endeavor. In addition, we also have the cost of ignoring API security as showcased by Facebook as well as several good JSON Web Token (JWT) talks. And as a cherry on top, we have a patch release to the OpenAPI Specification (OAS).

Vulnerability: WordPress ThemeREX Addons Plugin

WordPress REST APIs got exposed and exploited through ThemeREX Addons plugin, installed on about 44,000 sites.

This critical vulnerability allows remote code execution. Quoting the Wordfence researchers:

“ThemeREX Addons is a plugin installed as a companion to many ThemeREX themes and provides a number of theme management features. One of the plugin’s functions registers a WordPress REST-API endpoint. When doing so, it does not verify that a request is coming from an administrative user.

While this is not cause for concern on its own, the endpoint allows any PHP function to be executed, rather than being limited to a select few functions. This means that remote code can be executed by any visitor, even those that are not authenticated to the site. The most worrisome capability that we are seeing actively attacked is the ability to create a new administrative user, which can be used for complete site takeover.”

ThemeREX says they have already fixed the issue.

You may also like: RESTful API Security

Case Study: Voatz and Anti-Pentesting Policies

MIT researchers Michael Specter, James Koppel, and Daniel Weitzner have reported multiple issues in Voatz, a voting app used in the US elections.

In their scientific paper, the research team identifies several vulnerabilities, including man-in-the-middle (MITM) attacks on the API server of the app, that could allow attackers to discover the personal information or vote of the voter or even submit votes.

The vendor claims that the votes are safe because Blockchain is used to record them. However, it is the backend server that adds the data to blockchain, thus any manipulation that happens on the mobile app, in the communication between the app and the server, and on the server itself, would still be recorded as legitimate.

What is even more frustrating is that the researchers had to limit their research only to the fraction of the actual application. The application consists of the mobile app and the server with which the mobile app communicates over the REST API. Neither of them are open source, and the mobile app is obfuscated to complicate research. The vendor does not allow API pentesting nor does it disclose the source code.

Not only can researchers not access the source code of the backend server, the vendor actually actively prohibits its pentesting and has a history of reporting earlier research attempts (by University of Michigan) to FBI.

The research team has also published an FAQ page on their research and the communication from the vendor.

Modern applications are distributed by nature, and excluding backend components and APIs from security research significantly reduces the scope of vulnerabilities found and thus reported and fixed. We encourage vendors running bug bounty programs to expand these to the complete solution and not just the client.

Postmortem: Facebook API Breach

Laurence Dodds has compiled a fascinating postmortem of the infamous Facebook API breach in this Twitter thread (the one that we covered in our inaugural issue). The analysis is based on the documents disclosed in the lawsuits that followed the breach.

As Dodds’ thread shows, the original security flaw was known already since December 2017, but de-prioritized. It was not until that flaw combined with two other issues and led to the breach that it eventually got fixed.

Another good example of how expensive neglecting API security can get.

Videos: JWT Security and Best Practices

JWT has become the prevalent format of security token used in OAuth2 and OpenID Connect, hence it is the cornerstone of security of many REST APIs.

A few talks that cover JWT, its possible implementation vulnerabilities, security, and best practices have been recently published:

  • Dmitry Sotnikov’s talk at AppSec California 2020
  • Louis Nyffenegger at AppSec California 2020
  • A JWT webinar by Philippe Leothaud from 42Crunch

See this page for all 3 recordings.

Standards: OpenAPI 3.0.3 Released

The OpenAPI Initiative (OAI), the standards body behind the prevalent REST API contract standard, has announced the official release of the OpenAPI Specification v3.0.3.

This is a patch release, so the changes are only improvements to readability and accuracy. No behavioral changes have been made to the specification.

The next OAS release, v3.1.0, will contain some new features and elements (but no breaking changes). Its RC0 is expected soon.

You can subscribe to this newsletter at APIsecurity.io.

Further Reading

The Role of API Gateways in API Security

Introduction to REST API Security Guidelines

Topics:
apis ,api ,api security ,cybersecurity ,newsletter ,integration ,api security news ,api vulnerabilities

Published at DZone with permission of Dmitry Sotnikov , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}