Exploiting WordPress Plugin Vulnerabilities to Steal AWS Metadata

In an ideal world, vulnerabilities would not exist. A request would be sent to a server, properly validated, and only the intended information would be provided by the server. Of course, this is not a perfect world, and vulnerabilities can be introduced unintentionally, or even found due to previously unknown weaknesses within the programming language.

One type of vulnerability that can have severe consequences if exploited, yet is not frequently talked about, is Server Side Request Forgery (SSRF).

What is Server Side Request Forgery?

Server Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to abuse normal functionality on the server by getting the server to send a request that the attacker has control over. This can be accomplished relatively simply with a modified URL in a browser, or by using a tool like Burp Suite to capture the browser request and modify it before sending it on to the server.

SSRF vulnerabilities are not often difficult to exploit, but can provide a threat actor with information that can assist them in further attacks, or even allow them to make requests to internal resources that can lead to data alteration. In some cases, a threat actor may be able to run arbitrary commands on the server, allowing the actor to complete a full takeover of a vulnerable site.

A Real World Example: Server Side Request Forgery Vulnerability in the Google Web Stories Plugin

On October 25, 2022, a SSRF vulnerability in the Web Stories plugin by Google was disclosed in versions <= 1.24.0. This vulnerability was discovered and responsibly disclosed by Aymen Borgi who requested a CVE ID from the Wordfence team.

Wordfence Premium, Care, and Response users received a firewall rule to block exploit attempts targeting this SSRF vulnerability on October 27, 2022. Wordfence Free users received the firewall rule 30 days later on November 26, 2022.

The vulnerability existed due to improper validation of URLs provided through the ‘url’ parameter called via the /v1/hotlink/proxy REST API endpoint. Exploiting this vulnerability, an authenticated user could make web requests to arbitrary locations originating from the web application. The authenticated user does not need high level privileges to exploit this vulnerability. The attack can succeed for users logged in with an account that has minimal permissions such as a subscriber, which would be easy access to obtain on sites with open registration.

This vulnerability does require the threat actor to obtain their own REST nonce, which is a simple process. All that is required to obtain the nonce is to log in to the website, then go to the website with /wp-admin/admin-ajax.php?action=rest-nonce appended to the domain name.

Once the nonce has been obtained, the vulnerability can be easily exploited. At this point an attacker can supply a path to an internal service via the ‘url’ parameter when calling the /web-stories/v1/hotlink/proxy REST API endpoint and gain access to internal resources.

Leveraging Server-Side Request Forgery to Extract Sensitive Information on AWS

If the site is hosted on an Amazon Web Services (AWS) server, then collecting the AWS metadata is relatively simple. This exploit only requires calling the appropriate REST API endpoint with the right payload in the ‘url’ parameter to achieve a successful exploit. The following is an example:

?rest_route=/web-stories/v1/hotlink/proxy&url=http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance&_wpnonce=f76869efe5

The _wpnonce value would be replaced with the nonce obtained in the first step. Once the vulnerability is successfully exploited, the AWS metadata will be displayed in the browser. As seen here, the requested metadata includes such sensitive information as the AccessKeyId, SecretAccessKey, and Token.

This specific metadata is used to identify on-instance software to the EC2 instance in order to use features like EC2 Instance Connect. This feature could then allow a successful attacker to log in to the virtual server and run commands through the terminal. There are many metadata categories provided by AWS that each have specific uses and varying degrees of severity if misused.

While the Google Web Stories plugin did try to validate the ‘url’ parameter in its first attempt to patch the vulnerability, it did not take AWS into account within the code. Two blocks of code were updated to fully patch the vulnerability in the plugin. In the first block of code additional IP address ranges were added to the URL validation list.

The AWS IP was also added as a disallowed IP address.

With the patch applied within version 1.25.0 and newer, attempts to obtain AWS metadata will fail.

How to Prevent Server-Side Request Forgery Vulnerability Creation

Preventing the creation of SSRF vulnerabilities is similar to other vulnerabilities. Developers must develop their code in a way that accounts for vulnerabilities within the chosen programming language, and also ensures that any input is properly sanitized and validated.

In order to properly validate the input, the developer must understand how the functionality can be misused, and programmatically eliminate each way the functionality can be misused. That is why understanding the impact of vulnerabilities such as SSRF vulnerabilities is critical for developers. Keeping code secure can be difficult to ensure during the development phase, which is why the code must be tested for vulnerabilities during and after it has been written.

For SSRF vulnerabilities specifically, the best method for developers to secure the endpoint is to ensure that all forms of input are properly validated and URLs are properly restricted if passed to a function that does a call to the URL. This means that every input should only be accepted if it meets the expected formatting and content, and checks should be in place to ensure that the current user is allowed to make the request. If the request does not fit what is expected from the application, the user is not authorized for the request, or the location the request is coming from is not the expected location, then the request should simply return an error.

How to Protect Sites and Networks Against Server Side Request Forgery

There are steps that can be taken to protect websites from this and other vulnerabilities. While it is not always possible to avoid vulnerabilities entirely, taking steps to protect websites, significantly minimizes the chances of a successful compromise.

Updating plugins, themes, and the WordPress core is the best way to protect WordPress websites from vulnerabilities. Because vulnerabilities can be unknown, a web-application firewall (WAF), like the Wordfence firewall, helps to block attack attempts against unpatched vulnerabilities on a website and will also alerts you to when vulnerabilities are present on your site.

SSRF & Zero-Trust

Server-Side Request Forgery vulnerabilities serve as an important reminder that the Zero-Trust framework should be practiced in modern day environments. In essence, SSRF vulnerabilities are possible because the internal and external resources may be configured to assume that requests sent from an internal location are inherently trustworthy. By requiring validation and authorization for every action, this default trust is removed, and requests must be validated properly before being considered trusted.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.

This article was written by Topher Tebow, a former Wordfence Threat Researcher.