Actions you should take if you have Elementor installed:

1. Scan yourself with this nuclei plugin

wget https://raw.githubusercontent.com/projectdiscovery/nuclei-templates/3581482df1bfe1aef4e7fff96e183f9ef0e5bf13/cves/2022/CVE-2022-29455.yaml
nuclei -t ./CVE-2022-29455.yaml -u https://...

1. Verify yourself here - Elementor XSS Tester

It all started during the Hackerone ambassador WorldCup.

While scanning our selected target websites we found an interesting wordpress website. After a quick scan for known plugins we found a wordpress plugin installed named "Elementor".

Elementor is a very popular wordpress plugin that had a few vulnerabilities in the past, see previous vulnerabilities here

Credits

Before we begin our story some credits are due:

Gal Nagli from Salesforce - Currently 5th place worldwide at HackerOne.
Tomer Zait from F5- Veteran Security Researcher.
Rotem Bar from Cider Security - Creating the first Appsec Marketplace Elementor Security Team - Amazing security team with awesome response.

History Recap

While searching for known bugs in Elementor we saw an interesting bug (CVE-2021-24891) that was raised in the past which uses a DOM-XSS to attack a user logged in to the system.
Because we already have some knowledge in Javascript and had fun with DOM-XSS together in the past, we decided to deep dive into this CVE.

In CVE-2021-24891, Joel Beleña, a cyber security researcher, found out that injecting a payload into the lightbox settings allowed to inject arbitrary javascript into the website where the plugin is used, see more details here - https://www.jbelamor.com/xss-elementor-lightox.html

Dissecting Joel’s vulnerability showed us that the payload used the lightbox settings payload in Elementor to force display the lightbox module and give it custom settings in a base64 payload:

#elementor-action:action=lightbox&settings=eyJ0eXBlIjoibnVsbCIsImh0bWwiOiI8c2NyaXB0PmFsZXJ0KCd4c3MnKTwvc2NyaXB0PiJ9

Base64 Decoding the settings payload returns us the following json, which shows that the attack attempts to set the type to “null” and setting an html parameter which injects raw unsafe html code into the page:

{"type":"null","html":"<script>alert('xss')</script>"}

Back to our story:

Trying to reproduce the original payload in the website (which had an up to date version) didn’t work, but when reading the code it brought us to the understanding that there are different values which can be put in the parameter “type” shown above which can be investigated.

The original problem happened when the “type” parameter was not catched in the switch case code and as you can see in the code it is setting html received from the user.

Unfortunately the fix for the vulnerability was in place and the javascript deletes the “html” parameter before passing it to the affected function as seen below

Stay a while and research

First a small disclaimer, all screenshots and our research was done on the obfuscated code inside the browser, later we found out the code is open source and can be much more easier to read, but for learning purposes we are posting the research as is on the obfuscated code which will simulate better your future assessments.

Going back to the whiteboard, we looked at the different “type” parameters the lightbox module accepts: image, video and slideshow

The “image” doesn’t do much so we skipped through it, and decided to continue with the “video” parameter:

First obstacle:
When using the "video” parameter it needs also a “url” parameter, There is a check that the “url” parameter has to start with “http” (My guess is that in the past it didn’t have it and someone injected a “javascript://” or something like that)

Dissecting the video function brings in interesting insights. It uses JQuery (t variable) to set the video parameters which are coming from a parameter called “videoParams”:

As you can see in the code, in order to reach the state of using the jQuery (t) variable we need to add another parameter called “videoType”. When “videoType” is equal to “hosted” the function creates a new object which is built dynamically and receives parameters "src" and "autoplay" but can be overridden by “videoParams”.
Because "videoParams is controlled by the user, we can add whatever parameter to the video object.

Better Explained by demo

Creating a new payload to verify this:

{
  "type": "video",
  "url": "http://",
  "videoType": "hosted",
  "videoParams": {
    "style": "background-color:red"
  }
}

which when encoded to base64 looks like

eyJ0eXBlIjoidmlkZW8iLCJodG1sIjoieCIsInVybCI6Imh0dHA6Ly8iLCJ2aWRlb1R5cGUiOiJob3N0ZWQiLCJ2aWRlb1BhcmFtcyI6eyJzdHlsZSI6ImJhY2tncm91bmQtY29sb3I6cmVkIn19

The payload successfully added a new style parameter which is rendered into the video:

We are able now to color any video we want and make users see a red screen (Further playing with the payload we were able also to change it to a picture and create a nice phishing page)

Bug bounty is all about impact!!!

Going through attributes that can accept, we found that “onerror” is also allowed, and accepts javascript, so quickly creating a new payload with “onerror” parameter gave us the full exploit.

{
    "type": "video",
    "url": "http://",
    "videoType": "hosted",
    "videoParams": {
        "onerror":"alert(document.domain+' '+document.cookie)",
        "style": "background-color:red"
    }
}

ewogICAgInR5cGUiOiAidmlkZW8iLAogICAgInV
ybCI6ICJodHRwOi8vIiwKICAgICJ2aWRlb1R5cG
UiOiAiaG9zdGVkIiwKICAgICJ2aWRlb1BhcmFtc
yI6IHsKICAgICAgICAib25lcnJvciI6ImFsZXJ0
KGRvY3VtZW50LmRvbWFpbisnICcrZG9jdW1lbnQ
uY29va2llKSIsCiAgICAgICAgInN0eWxlIjogIm
JhY2tncm91bmQtY29sb3I6cmVkIgogICAgfQp9

If you want to sneak peek at code you can see the exact area which is vulnerable: https://github.com/elementor/elementor/blob/release/3.5.0/assets/dev/js/frontend/utils/lightbox/lightbox.js#L257

Our next steps

Our target website is vulnerable, but can we find more?

Elementor is a mega technology, as it is used by at least 6,441,433 websites on the Internet. - BuiltWith

Luckily for us we have lists of many domains and subdomains we can scan for the technology. Crafting a quick search for the plugin started to give us vulnerable websites:

cat list.txt | \
cut -d"/" -f3 | awk 'NF{print $0 "/wp-content/plugins/elementor/assets/js/frontend.min.js"}' | \
httpx -nc -fr -ms "elementor" -er "elementor - v[^\s]*"

Sample scanning..

Disclosure process

The first thing we did was submit the vulnerability to the vendor, so they could start fixing the issue.

We also submitted the vulnerability to the target we researched, letting them know of the vulnerability as we were initially researching them.

Meantime we wanted to prepare for when a fix is available to let all the programs we can find know about it and disclose it in a safe and private matter to customers who are affected by this threat so they can take proper measures to protect themselves. (As this is a DOM based xss, using a WAF cannot help here, but there are other measures customers can take such as hot-patching, removing the plugin, disabling video support etc.)

The task of reaching affected customers and notifying them in a private matter is not easy. Many questions arise here. If the vendor has not fixed the vulnerability yet, what does it help if we tell them about it? Also we don’t want to shout publicly about the problem as it can fall into the wrong hands.

We went on profiling target customers:
Many of the Elementor users are smb businesses which cannot really do anything if we tell them about it and should wait for a proper fix.

But we do have bigger companies who also use Elementor with mature bug bounty programs and security disclosure programs which we can safely communicate with and privately disclose to them the vulnerability.

Searching for the possible candidates was the hardest part of this job.
We created lists of subdomains of companies that do have VDP/BB programs and do accept 3rd party submissions and scanned them for the found vulnerability, then we started disclosing the problem.

The responses were divided into 3 different types of answers:

1. They accepted the vulnerability and created the needed measures to secure themselves
2. They do not accept disclosures of 3rd party vendors which affect them
3. They are already affected by the previous CVE and did not yet patch their systems

A bit about the impact

When found, this vulnerability affected more than 6.5M websites around the world, Every Elementor based website available on the internet was affected if it was hosted by Elementor or self hosted.

As for the Security Impact, an attacker could do the following:

• Cookies Exfiltration from the affected origins utilizing the Cross Site Scripting vulnerability, that could even allow in certain scenarios into Account Takeovers.
• Executing JavaScript on the victim's behalf
• SOAP Bypass
• CORS Bypass
• Defacement

POC||GTFO

We were able to create an account takeover POC which when clicked created a new user if an admin was logged in to his wordpress account.

Disclosure Timeline

11/02/2022 - Disclosure to Elementor.
23/02/2022 - Public Fix.
12/06/2022 - Full Disclosure - Thanks for the patchstack team for helping disclose the CVE.

Bonus - Please test yourselves

https://www.rotem-bar.com/elementor

Hope you enjoyed the blog

Open Distro is a plugin for ElasticSearch that enhances security, alerting, SQL querying, and gives more advanced capabilities.

Jump directly to how it was found

The Vulnerability

If you are running ODFE 1.12.0.2 and below, It may be possible for existing privileged users to enumerate listening services or interact with configured resources via HTTP requests in your environment. (SSRF)

Do note that the severity and probability may change according to the usage and environment of the specific installation.
For example, If only known administrators can access the elastic instance and the elastic instance is isolated from reaching any network then the risk is low.
On the other hand, if the elastic instance is reachable by all users in the company and open to clients when no network hardening was done this vulnerability severity may be high and sometimes critical.

For starters, before you read about how this CVE was found, if you are using Elasticsearch and using Open Distro as part of your installation, now is a good time to go and check the version, and upgrade the plugin to the latest version, if you are not up to date.

If you are not sure if you are using Open Distro you can go to your ElasticSearch instance and run the command https://{YOUR_IP}:9200/_cat/plugins?v to see if you have the Open Distro plugin installed. If you are running Open Distro, you will see the following packages in the response:

opendistro-job-scheduler 
opendistro-sql    
opendistro_index_management   
opendistro_security

Mitigation

1. Upgrade to the latest version of ODFE (1.13.1.0 and above)
2. Configure the alerting module to access only the needed resources.

First thing you’ll need to do is check your alerting default by running the following command which will show you the default configuration:

curl -u "admin:your_password" -k "https://{YOUR_IP}:9200/_cluster/settings?include_defaults=true" | \
 jq ".defaults.opendistro.alerting"

Make sure the destination.allow_list enables only the required actions, some installations don’t need all features of ODFE and can pose a risk

{
  "alerting": {
    /**...**/
    "destintation": {
      "allow_list": [
        "chime",
        "slack",
        "custom_webook",
        "email",
        "test_action"
      ]
    }
  }
}

In the latest patch, ODFE added the field destination.host.deny_list which allows an administrator to control which IP addresses the plugin is denied access to. By default this list is empty. It is highly recommended to configure at least all known internal networks in order to deny traffic to your internal resources.

Example:

{
  "alerting": {
    /**...**/
    "destintation": {
      "allow_list": [
        "custom_webook",
        "test_action"
      ],
      "host": {
        "deny_list": [
          "127.0.0.0/8",
          "10.0.0.8/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ]
      }
    }
  }
}

Ok, now that required a lot of trust…. now that we got the important part out of the way, let’s actually talk about the adventure itself.

The Story

Bug bounty and penetration tests are a part of my way of life, Every project I have taken on, I have had the privilege of learning something new, sometimes it’s just small stuff, and other times when I really get lucky, mind-blowing tricks.

The Open Distro CVE adventure actually started off, after the kick-off with a client, as a seemingly frustrating penetration test. This was because there wasn’t a single line of code written in the actual project itself. The project basically consisted of a supplier combining different open source solutions into one big tech stack, configuring and supporting the system for the needs of the customer.

This actually happens a lot, especially in government contracts, banks, insurance companies, and other large corporates where projects are outsourced to external system integrators. These system integrators then combine different components into one cohesive solution (really “templatey” type stacks to solve specific problems rapidly).

Back to our story, the purpose of this specific solution was to provide a friendly Kibana interface for a system that does a lot of processing on the backend and ultimately enables users to easily fetch and process data. (As an aside, this is already the second system I’ve seen this year that essentially “ditched” the custom user interface and provides direct access to a highly customized Kibana interface.)

After ticking the regular boxes, and checking the different configurations, and running the required hardening tests, I still wanted to do better. This is where it gets interesting, I started to investigate what I could potentially do with the permissions granted in the system to a typical user.

The OpenDistro plugin

OpenDistro is an AWS-maintained open-source plugin and is actually pretty cool. It provides many capabilities which are missing in ElasticSearch. The experience is like using a native and complementary add-on to ElasticSearch...but by now we know very well, with great power comes great responsibility.

As part of my investigation, I came upon the alerting module. This module allows the user to create an "open distro monitor" (read more about these here ), define a trigger as a webhook to any resource, control the method type, as well as have full control of the body.

The first thing that came to my mind when seeing this was a potential SSRF vulnerability. Server Side Request Forgery is a common attack method that exploits one service to make a request on your behalf from other servers. You can read more about this here .

After creating a trigger in the alerting module, you can then test it. This is where the SSRF option comes in. When testing your request it is sent to the requested server, which returns some kind of response. Sweet!

Crafting some script magic I was able to edit a trigger, invoke it, and read the results. With this ability, I was able to start scanning the network, access the metadata API (which specifically in the project was unhardened), access the Kubernetes API, as well as other local resources.

The next thing an attacker would do in such a scenario is scanning the available resources and cross-reference them with known and reported vulnerabilities, or other open and vulnerable/unauthenticated endpoints. So that’s what I did too.

The alerting module has support for POST, PUT and PATCH access, and because of this POST access, I was able to request a resource from another server and exploit a different known vulnerability in the connected server (out of the scope of this article) to achieve remote code execution (AKA RCE).

Investigating the source of the problem brought me to this source code:

https://github.com/opendistro-for-elasticsearch/alerting/blob/opendistro-1.12/notification/src/main/java/com/amazon/opendistroforelasticsearch/alerting/destination/client/DestinationHttpClient.java#L115

CustomWebhookMessage customWebhookMessage = (CustomWebhookMessage) message;


uri = buildUri(customWebhookMessage.getUrl(), customWebhookMessage.getScheme(), customWebhookMessage.getHost(),
        customWebhookMessage.getPort(), customWebhookMessage.getPath(), customWebhookMessage.getQueryParams());


httpRequest = constructHttpRequest(((CustomWebhookMessage) message).getMethod());

This line of code essentially creates HTTP requests based upon user input and sends them without any validations.

Remediation Process

After searching for how and who to submit this issue, I found that the OpenDistro plugin actually belongs to AWS, and started the disclosure process.

The AWS security team was very responsive, and I want to thank all of the team members involved who took the issue seriously, started the triage process immediately, and kept me in the loop during the whole process.

The fix has now been deployed, and now administrators can upgrade their ODFE plugin and configure a list of allowed hosts to communicate with. (See mitigation section above)

From An Attacker’s Perspective

Many times attackers that are unable to access resources directly will find the “proxy” resource that will provide them the access they need to your sensitive internal resources and data.

Once they have a good understanding of the technologies in the stack - it’s a simple search to find vulnerabilities in the different versions, and try to exploit those known vulnerabilities.

Lessons Learned

Don’t underestimate yourself in any pentest/bounty program.
Don’t leave any stone unturned, especially in areas you think are battle-hardened. You might surprise yourself.

Be aware of the plugin ecosystem.
When we come to secure/attack our stacks and systems we can’t only look only at the application itself - but we also need to take into account the different third-party resources they integrate with, and in this case plugins. Each and every one of these integrations need to be examined individually, as they can be your single point of failure. Take the SolarWinds example, where an old unpatched version was the key to the kingdom.

Test carefully webhooks
Because most systems born today use multiple microservices, webhooks and the environment are easily exploited into doing stuff they shouldn't.
Any time your service requests external HTTP resources you should validate that users cannot change the target of the server. In the event that this is by design, it will be your responsibility to add the required validations needed to properly secure your other services.

Disclosure & Remediation Timeline:

24 January - Reported to AWS
24-26 January - First response from AWS and start of triage process
26 February - Fix committed into github repo in version 1.13.1.0
5 March - Dockerhub updated with version 1.13.1
26 April - CVE created
6 May - CVE released
11 May - Blog published

Our mission is to prevent, detect and remediate all security issues within our environment. Our goal is to enable rather than block our developers’ work. In order to achieve this, our strategy has been to share our knowledge through building new processes and systems that help our developers release their latest feature safely without introducing vulnerabilities into our production systems.

This is a story about a traversal vulnerability, how we handled it and why it can also impact your organization.

BACKGROUND:

We found a Traversal Vulnerability in one of our application services through our in-house scanner Jirachi (more on this in another post). Although it was a simple traversal attack and seemed easy to exploit, for some reason when testing through our staging site our Proof Of Concept kept failing.

We were able to exploit the directory traversal vulnerability when communicating directly with the service, and thought that this should be an easy Jira ticket to write up. However, when we went to write the full end-to-end POC, the exploit kept failing. We looked at the only other component that had changed between the two tests, and we found that the service was behind an AWS Application Load Balancer (ALB). However, there were no rules, no Web Application Firewall (WAF), nothing — so we couldn’t figure out why the load balancer was preventing our POC.

Investigating the AWS ALB further, we found an HTTP 400 error response that had similarities with an error response in NGINX that we found in a git commit. We quickly downloaded the latest version of NGINX, and digging through the commit history, we found that there was a configuration option called merge_slashes. When we set merge_slashes to “off”, we saw the same behaviour as we did with the ALB. We came to the realisation that the AWS ALB url parsing shares similar functionality as NGINX. Furthermore it was this functionality that was responsible for sending the http 400 error response and not allowing the request to reach the vulnerable application.

We couldn’t give up there though. We had to find a way to get our request to the vulnerable application!

Technical POC: Traversal Attack through NGINX URL parser

To demonstrate how we can get the malicious request through the NGINX url parser, we put together a sample application.

As you can see below, We created a sample web server code which has a Local File Inclusion vulnerability

const express = require('express');
const app = express();
const port = 80;
const fs = require('fs');


app.get('*', (req, res) => {
    const data = fs.readFileSync('secure/' + req.url)
    res.send(data);
})

app.listen(port, () => {
    ***console***.log(`Vulnerable App listening at http://localhost:${port}`)
})

The server accepts a GET request. The user-supplied url is concatenated with the ‘secure’ string and that file is then sent back to the user.

As an example sending a request to http://server/1.txt will cause the server to send back a file from <CurrentWorkingDirectory>/secure/1.txt

In order to demonstrate this, we send a GET request directly to the server and in the response we get the content of file 1.txt.

Vulnerable application

In order to exploit the traversal vulnerability in this app, we can request a file from a directory one level up by using the ‘../’ notation. Here we request the index.js file directly from the server .

POC —

Carrying out the same traversal attack through AWS ALB, we received a 400 bad request

However, after some research we found that we can get our malicious request through the url parser by using multiple slashes (‘/’).

In order to demonstrate this point further, the below image shows an attempt at retrieving the /etc/passwd file through an AWS ALB. Once again, we get a 400 bad request.

As before, we’re able to reach the vulnerable application by appending more slashes (‘/’).

Root Cause Analysis

How did we know AWS ALB shares similar functionality in url parsing as NGINX?

When the requests were blocked we saw a certain pattern.

The 400 bad request response from the AWS ALB above had a distinctive html signature:

<body bgcolor=”white”> …

After simple Google search and digging in GitHub we found that this signature is used by NGINX.

Specifically, we’re able to find which commit and version this error signature was removed in.

https://github.com/NGINX/NGINX/commit/8117b3f5a06b68afb292ddd19bf6ee6000707232#diff-05d6b8ae21d192f78b349319edaeb9bf

Fun fact:

body bgcolor=white was pretty common in the past as IE rendered pages by default in light gray, other browsers let the user select a default background such as black and there was large inconsistency between browsers. Putting bgcolor=white ensured that all browsers display the background as white.

How did we determine that merge_slashes is ‘off’:

Within the NGINX documentation, we are able to see that the merge_slashes default value is “On”. Therefore two or more ‘/’ characters will be normalized into one ‘/’ character.

http://NGINX.org/en/docs/http/ngx_http_core_module.html#merge_slashes

Enables or disables compression of two or more adjacent slashes in a URI into a single slash.

Syntax: merge_slashes on | off;
Default: merge_slashes on;
Context: http, server

When the merge_slashes configuration is turned on, using multiple slashes ‘///’ did not allow us to exploit that vulnerability successfully.

Trying out our bypass on latest version of NGINX:

The following shows the POC carried out on the latest stable version of NGINX (v1.18.0) with merge_slashes ‘off’.

Identification of NGINX issue:

In order to better understand how NGINX handles the url, we built a program to test the parsing function within the ngx_http_parse file:

ngx_http_parse_complex_uri(ngx_http_request_t *r, ngx_uint_t merge_slashes)

Within this function, the handling of state == sw_dot_dot at https://github.com/NGINX/NGINX/blob/master/src/http/ngx_http_parse.c#L1581 is what our tests focus on.

This shows the code written for testing the parsing function.

Here we can see when we run the test with a regular traversal attack, we get an error and return code 11.

Here we can see that when we run the test with extra slashes, we return 0.

What is the Impact?

The impact here is complicated

Looking at CVE’s we saw about 4000 known directory traversal CVE’s dating from 1999 to 2020. Directory Traversal attacks are here to stay!

Furthermore, companies testing themselves behind any ALB or NGINX solution configured with merge_slashes ‘off’ will probably not find this bug so easily. However, more knowledgable or dedicated attacks would know how to get their malicious request through the url parsing mechanism.

In order to get a better understanding of how wide-spread this issue is, we ran a search on github for merge_slashes ‘off’;. There are 549 Open Source Projects that use this configuration and unknowingly may be blocking malicious requests to applications that are vulnerable.

Could this blocking behaviour be changed?

Not really as we see it.

If traversal is blocked within NGINX, then applications relying on “safe traversal as a feature” will start failing. This is critical for some businesses and therefore, we don’t see this behaviour being changed.

Is this a vulnerability?

NGINX as itself is not a protection solution and AWS ALB is not intended to protect your application. If you are looking for a protection solution, consider using a WAF.

What do we recommend?

If possible, run your tests on the application directly without any load balancers in the middle. If you must test through load balancers, you should ensure that your testing takes into account this behaviour so you don’t miss any possible vulnerabilities.

Summary

This exercise showed us why it is important to always look around for additional attack vectors, never rely on one protection mechanism and always continue ramping up our security methods.

We do not consider this a vulnerability within NGINX nor AWS Application Load Balancers. By taking this information public, we are hoping that we are able to make organizations more aware of the behaviour displayed in NGINX and ALB and allow them to better test their application to reduce their risks

Stay tuned for more information about our security efforts. In the following weeks, we will be releasing more security tools we built in house and would love to share with the community.

Want to be part of our security adventures? We’re hiring! Contact us at security@appsflyer.com

TL;DR

Add forward slashes at the beginning of your requests when testing directory traversal attacks through load balancers.