Issue 147: Vulnerabilities in SEOPress plugin and Steam portal, results from an application security survey

On July 29, 2021, the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability that they discovered in SEOPress, a WordPress plugin installed on over 100 000 sites.

The researchers found that a REST API endpoint that the SEOPress plugin exposed for adding metadata to a post also allowed injecting arbitrary HTML payloads into the SEO fields of WordPress posts. This potentially left the door open for performing Cross-Site Scripting (XSS) based attacks, such as various administrative tasks, web shell injections, arbitrary redirects, and even a complete site takeover. The vulnerability is registered as CVE-2021-34641 and is currently waiting for classification.

The issue boils down to the fact that the implementation of the API endpoint did not fully validate the request for relevant permissions. Instead, the permission_callback method handler only validated the presence of a nonce that any authenticated user on a WordPress site can easily generate:

'permission_callback' => function ($request) {
$nonce = $request->get_header('x-wp-nonce');
if ( ! wp_verify_nonce($nonce, 'wp_rest'))
{
    return false;
}
return true;

The vendor was notified of the vulnerability, and they have released a patch in version 5.0.4. Lessons learned here:

• Failure to fully validate API requests is a leading factor in vulnerable APIs. Authentication is not enough and authorization needs to be in place. In this particular case, we saw an example of OWASP API:5 Broken Function-Level Authorization.
• Skilled attackers can combine vulnerabilities,  like an API vulnerability and a cross-site scripting vulnerability, to totally compromise the target system. Define, validate, sanitize API inputs to prevent malicious payloads.

A security researcher found an API vulnerability in Steam Wallet API — part of the popular Steam portal by Valve Software — that generated quite literally money for nothing.

The researcher created an account on the Steam platform and then examined transactions made to the secure Smart2Pay API endpoint [https:]//globalapi.smart2pay.com/. He wondered if he could add money to his account by forging the corresponding parameter in the payload. The payload was protected with a hash. However, the construction of the POST request body revealed a flaw in how a transaction hash was calculated: the calculation appeared to be eliminating special separator characters like & and =.

The amount of the payment was included in the amount parameter of the request, as was the customer email. Thus, from hashing perspective, amount = 100 (as a parameter) and amount100 as a substring in another parameter (for example, the email address of the user) would generate the same hash.

The researcher made a request using the crafted email address and modified the request body to inject separators into the email address, thus forcing the transaction hashing to add additional amount fields to the request.

This vulnerability allowed a user with a Steam account to transfer arbitrary amounts to their Steam Wallet by a relatively trivial POST request modification. Valve Software confirmed the vulnerability and has fixed the issue. The vulnerability was disclosed on HackerOne, and the researcher was rewarded with a bounty (this time not money for nothing).

Lessons learned here:

• User inputs cannot be trusted. Valve did a good job adding payload signing with a hashing function but the function was vulnerable and could be exploited.
• To that point, it is also recommended that you thoroughly describe all payload schemas (including patterns for all strings) and enforce them.
• This example also demonstrates the business value of a well-run bug bounty program: for the outlay of a $7500 bounty, Valve Software was able to identify a vulnerability that could have resulted in financial loss of several orders of magnitude.

The recent Dark Reading survey “Secure Applications” indicated that organizations are increasingly paying attention to the security of their APIs in their software security initiatives. As many as 41% said they were treating API security as part of their application security program and 23% have a dedicated API Security process.

Other key takeaways from the survey include:

• 18% of organizations are outsourcing the evaluation of their API security to 3rd party or SaaS providers (up from 5% in 2020)
• As many as 18% of organizations do not have any specific API security activity (unchanged from 2020)

OAI’s API Specifications Conference (ASC) is a place for API practitioners to come together and discuss the evolution of API technology. ASC includes cutting-edge technology keynotes and sessions that chart the future of APIs with in-depth specification and standards discussions.

The OpenAPI Specification (OAS), RAML, Blueprint, gRPC, OData, JSON Schema, GraphQL, AsyncAPI, and other formats will all be topics at the event, enabling attendees to get familiar with these formats and discuss how to use them in practice.

Of interest to security practitioners will be the talk from Isabelle Mauny, co-founder and Field CTO of 42Crunch, discussing how to inject security into API development.

Like other conferences at the present, ASC will be virtual, so you can participate from wherever you are.