Hacking 6.5+ million websites => CVE-2022-29455 (Elementor)
Please upgrade your Elementor websites
Announcing CVE-2022-29455
Actions you should take if you have Elementor installed:
- 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://...
- 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 - 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: github.com/elementor/elementor/blob/release..
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:
- They accepted the vulnerability and created the needed measures to secure themselves
- They do not accept disclosures of 3rd party vendors which affect them
- 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