Welcome back to the Patchstack Weekly Security Update! This update is for week 26 of 2022.
Introduction
This week’s Patchstack Weekly is a little different, and a little longer – I will be sharing with you highlights of a conversation I had with Rotem Bar.
Rotem works at Cider Security as Head of Marketplace Integrations and has been working in the security field for 20 years.
Back in February he found an Unauthenticated DOM-based Reflected Cross-Site Scripting vulnerability in Elementor and reported it through the Patchstack Alliance.
If the bug’s name sounds confusing, convoluted, and complicated, don’t worry – Rotem explains what it means and where the threat is exactly.
He’ll also dive into his motivations and more during our discussion.
I hope sharing conversations like this one shows you that the researchers reporting security issues in open source software are nice people, with good intentions and positive attitudes. They just happen to know a thing or two about spotting security bugs and are trying to help.
Listen to the interview here, or if you prefer, read through the full transcript below:
Conversation with Rotem Bar
<Robert> I’m here with Rotem Bar the Head of Marketplace for Cider security. Hello Rotem how are you?
<Rotem Bar> I am good how are you.
<Robert> I am very good, thank you. I should start by congratulating you on finding and now releasing details about a security bug in Elementor, which was patched a few months ago is that right?
<Rotem Bar> Yeah, it was patched in I think, February, something like that.
<Robert> February. It is now middle of June, so you did a pretty long, respectful delay, full disclosure.
<Rotem Bar> Yeah, we wanted as many people to patch and be updated before releasing it to the public
<Robert> That is super awesome.
<Robert> I am curious. Would you mind telling a little more about yourself and how you got started in security and bug bounty hunting.
<Rotem Bar> My name is Rotem, and I work for Cider Security. I started doing security in the Army, doing penetration testing. Since then, it was 20 years ago I am doing penetration testing for different companies around the world doing red team. Working with Volkswagon a lot for production plant and vehicle security. From bug bounty perspective, only the last couple of years I started playing with hacking into different companies, doing bug bounty and doing live hacking events. It is a good way to collaborate with people and other researchers around the world.
<Robert> What got you motivated to look for this bug in Elementor?
<Rotem Bar> There was a HackerOne worldwide championship, and we got a group of different Israeli security researchers and started hacking together. Trying to find different targets for the competition, we found this WordPress website with the Elementor plugin. When we scanned it we saw there was a CVE from last year that was fixed, and a few of us (Gal Nagli, Tomer Zait and Rotem Bar) together we started playing with this website and thought let’s go deeper, let’s see if they missed a fix or something happened. So we went to find the bug if there was a bug.
<Robert> I read the article/blog post with the timeline and noticed there were multiple people who gave you help. Did you want to give them a shout out?
<Rotem Bar> Yeah, we had Tomer Zait from F5. He is a very veteran security researcher and a good friend of mine. And Gal Nagli he is actually in HackerOne in 5th place worldwide, so he does lots of bug bounty hacking and I met him through the bug bounty community. We have our own bug bounty community in Israel, we meet twice a month. Together, we worked on this bug, Each of us did our own thing. Gal Nagli helped with finding the assets and after we found a bug, finding where it could be exposed, and who could be impacted. Tomer Zait helped with finding the bug itself.
<Robert> So, it was a group effort. You first found a vulnerability that was already patched (CVE-2021-24891) and that gave you the idea to look for a similar vulnerability.
<Rotem Bar> Yes, usually when there is a vulnerability in a place there may sometimes be another beside it. Specifically here, what I saw when I looked how they did it, I said yeah, let’s read the javascript, it is DOM-based, let’s see if something was missed or changed since then. Companies have continuous development, they always add features, so one vulnerability patched a year ago does not mean they did not add new features in the past year.
<Robert> Yeah, they may have added new features and accidentally added new bugs.
<Rotem Bar> Yeah.
<Robert> That’s cool, so you used it as a point to look deeper to see if there was something missed or reintroduced, and you ended up finding something. I don’t need the PoC, but you ended up finding another similar vulnerability. A DOM-based XSS right?
<Rotem Bar> Yes, a DOM-based XSS that allows you to attack authenticated users.
<Robert> Yeah. So, to explain to the listeners. They may have heard about XSS before, but may not know the depth of XSS is, there are many different types. Maybe we could go into the different types, Reflected and Stored XSS, and go into scenarios and their differences.
<Rotem Bar> Sure, let’s start with Stored XSS. Stored XSS is a way that I can add script, javascript of my own to a website that I do not own and when someone else goes not the website they will land the javascript in the context of them-self. The javascript will actually have the same permissions that this user would have. This is usually done against other users, or you can sometimes do a blind stored XSS that you can do it on an admin user. So, if I try to infect an admin that will one day go into the system and look at my profile, they will be infected.
<Robert> Yeah, so in that scenario. Perhaps an XSS exists on the profile page for the user. It is something that will not show to yourself, but you will store a value, maybe your name or Twitter or website URL. The value they accept in your profile, may be properly escaped when you view your own profile, but you’re saying when the admin goes into the backend, sometimes developers may forget to escape there and that creates the issue. Why it is called stored XSS, makes it easy to remember that the payload is stored, such as in the database. Based on the context where it gets displayed, the severity can be higher or lower.
<Rotem Bar> Yeah
<Robert> So, you’re saying the admin could click on the profile for the user in the admin page, which loads the payload javascript and is run as if it was the admin user.
<Rotem Bar> It could happen in the back end of the website, so it could expose a different application or another website.
<Robert> Oh, yes. So it could expose a secondary website that may pull in the data?
<Rotem Bar> Yes, this could happen and it is very interesting.
<Robert> What is Reflected XSS then? Because that is the vulnerability you found in Elementor?
<Rotem Bar> Actually, let’s talk reflected then DOM-based which are different.
<Rotem Bar> Reflected is when a website gets input and then when it outputs the web page it writes the input but does not sanitize or escape the information, and you can create javascript or HTML that has javascript inside in a way that when it becomes the data it will execute code like before. But, this needs to be as a link or something that is reflected immediately. It is not stored. It can be by manipulating a URL, and when you send to someone, the website will return back information that will execute the javascript
<Robert> So, that still sends a request to the webserver?
<Rotem Bar> Yes.
<Robert> Dom is different though?
<Rotem Bar> DOM-based is similar to reflected, that you still send a URL and create a specially crafted URL, but in DOM-based you are actually executing code a javascript is executing inside the DOM of the client (web browser). So, nothing is sent to the server, and the server actually shows the same web page, but let’s say you have javascript that is looking that the location URL, and the location URL has some different HTML or javascript code. Because of this javascript code the client is attacking itself and executing the code.
<Robert> So, this completely exists within the browser right?
<Rotem Bar> Yes.
<Robert> let’s talk about impact now, what are the scenarios for DOM-based XSS that make it more or less dangerous?
<Rotem Bar> Let’s say in Reflected XSS, there are lots of ways to block the attacks. WAFs, browsers sometimes sanitize if it sees the same input and output. In DOM-based XSS, the server say never gets the payload, so even when we tested let’s say when I tested WordPress websites all around the world: nobody got my payload.
<Robert> Nobody saw the payload?
<Rotem Bar> Nobody saw it. If it was Reflected, someone would see it, a honeypot or researcher. The logs could see it and steal my payload and get it, and also then block it. If you have a DOM-based XSS, there is no way to know that it is not a regular request.
<Robert> Nice. So it is completely hidden from detection. Which you mentioned if it showed up in the log, that is something I would do to defend sites. I would look at the web server access logs to find the malicious requests to understand how the attack really worked. You’re saying DOM XSS exists only in javascript, so it will never be exposed.
<Rotem Bar> yes, everything after the hash tag will never be sent server-side. So, there is no easy way to block this on the server-side. You can block it on the client if you have protections.
<Robert> The plugins authors were able to patch this right? They patched the javascript?
<Rotem Bar> Yes, of course. They patched the javascript, they fixed it. I did not really go into how they fixed it, but you can no longer run lightbox settings automatically. I think they added some hash validation, so you can not send any more of these payloads.
<Robert> Did you want to talk about more about the HackerOne world cup and the results? How many sites did you reach out to that were affected? The Elementor install base is huge!
<Rotem Bar> If you look at the statistics, Elementor is a product that lots of SMBs are using and lots of website hosting use, and usually they do not have normal bug bounty programs. If you go to the large companies, then they do have bug bounty programs and we got tens of programs, but we could not find thousands of programs affected. They were mostly small, because I think Elementor is not a product that is used by many big corporations, or if it is used, sometimes it is on internal websites that we do not know exist or do not have access to.
<Robert> In the end, the bounties were not the main thing then, but finding it and getting it patched on Elemetor ended up helping out all of the SMBs that do not have bug bounty programs right?
<Rotem Bar> yes, the fun part is to research together, to look at stuff, to find a vulnerability that not every day you find a vulnerability that affects several million websites. The thing is to patch them, I scanned again a few months after the vulnerability was patched, and I still see hundreds of websites vulnerable to this CVE, and the previous CVE, and other stuff which could have remote code execution and other areas. The thing is, it is very hard, because you do not have anybody to tell to that these sites are vulnerable. If I go to SMBs, I do not have the resources to find out who is the contact, take time to understand if they care about being hacked or not.
<Robert> Hah, I hope that they do care! I understand this program though, finding the right point of contacts takes time. Trying to do that with thousands or millions of websites would take a lot of time, and no one is getting paid to do that.
<Robert> This opens a nice segue for what I wanted to talk about next, the vulnerability disclosure timeline. You had a very long one here. It was the end of February when the security bug fix was public, and you notified the developer on the 11th of February when you privately disclosed to Elementor, and less than 2 weeks later the 23rd that they had a public fix. Yet, you waited 4 more months almost before you went to public disclosure. Would you share a little more about what was going on in the background there?
<Rotem Bar> Part of it was laziness. But, when we found it we talked with Elementor and the security team was really great. They gave good feedback, and they fixed it really fast. The other area to understand, is “should we create a CVE?” “what is the meaning of it?” they wanted to tell their customers before a CVE was released, so they wanted time to contact their customers, even upgrade their own website because they were vulnerable because they used Elementor themselves. So, they had to catch everything. Then, after a while, I forgot about it. I remembered and we went to talk to create the CVE, and the CVE is out now. I think it is a good timeline, because it takes time, even WordPress, to upgrade themselves. Especially the people who care, and I do not expect if it was only 2 weeks that we would have seen sites patched. The thing is, the attack payload is easy to weaponize after seeing the details, I hope nobody does it, but I hope everybody patches.
<Robert> Yes, I hope they patch. You mentioned you saw Elementor websites still had year-old security bugs unpatched in them. Perhaps the sites are abandoned, or the site owner to not know. I thought it was super generous of you to wait a few months, but I like your excuse that you were just being lazy, you don’t feel like a vulnerability has to be disclosed as quickly as possible to make a big impact. I think this is sufficient impact, and it shows that anybody who has not updated, if this is the first you have heard about this. That is OK, go ahead and update. But, perhaps you need to rethink your process on updating websites, and checking websites for insecure components. Make sure you’re on top of security updates.
<Rotem Bar> Yeah, it is a good way. Also, I created a Nuclei plugin to check yourself. I talked yesterday with the Nuclei maintainer. Nuclei is a scanner that is able to scan different CVEs and known vulnerabilities. I am running it now, because I got interested in seeing which versions are available now. I see lots of, on my list, I have 2.8, 3.0.5, 2.7.5, lots of, mostly, 3.4.4 and stuff, but I am only looking at vulnerable versions. There are so many, hundreds, thousands, many.
<Robert> So, Nuclei is a free tool?
<Rotem Bar> Yes, Nuclei is a free tool by project discovery it can scan for different CVEs and you can use a list that I got, and we have lots of things to scan for. It costs $100-200 to get a list like this, but it pays back easily.
<Robert> To touch back about these websites that are not patching. Is there a reason, like a remediation that makes it so they don’t have to worry about the DOM XSS vulnerabilities. Is there a valid reason they don’t need to rush to patch?
<Rotem Bar> I don’t think so. I think lots of people with these plugins are website builders, and they don’t know what to do. They may be a son of someone who set up the website.
<Robert> This is that attrition issue, you need someone to maintain your websites.
<Rotem Bar> Yes, you need to maintain or you need to be in a company that manages your hosting. You should make sure your hosting company maintains not only WordPress itself, but the plugins, and the ecosystem around, like Linux.
<Robert> Yes, that is the concept of managed hosting. Managed means taking care of everything. Don’t run a website on Digital Ocean or AWS where you set it up and forget about it, because it will be a matter of time that many security bugs start racking up on the website, someone needs to be updating.
<Robert> We have talked about a lot already, but I wanted to ask a broader question now: Do you believe that WordPress is secure software?
<Rotem Bar> First of all, I don’t believe that anything is secure software. You have every software that is continuously developed, so you have it is secure until it is not secure anymore. WordPress is a very old technology that gets developed, but what it is based on PHP and there have been a lot of improvements in the last years. The WordPress team is really going on fixing the bugs and is mature. But, the real question is: Is the whole WordPress ecosystem secure? Let’s say we have WordPress and we trust it, nobody can hack it, no known security issues, but then you have lots of dependencies installed, lots of plugins in WordPress. These plugins have different code, they are maintained by different people, some big companies, some small companies or just one maintainer that just decided he wanted a plugin that shows a cat. These plugins can be vulnerable. If you find a vulnerability like remote code execution or XSS, or anything else, it affects the whole ecosystem. It will not be contained only to the plugin itself.
<Robert> Yes, because plugins are not ran in containers. They are run as the website, which is ran by the same web server processes.
<Rotem Bar> Maybe it’s a good idea to containerize plugins? I don’t know how to do it.
<Robert> I’m sure someone may take that idea and do something surprising with the idea, maybe we will spark someone to do it.
<Robert> It is not about WordPress core’s software, but about the ecosystem. Nowadays everyone releases new features, new services, and new add-ons to their code and plugins, and unfortunately that also introduces new bugs. Some of those bugs will be, unfortunately, security bugs.
<Rotem Bar> Yes. This is part of what Cider is doing. Going into the whole continuous development area, making sure everything is secure. Not only now, but also in the future.
<Robert> Integrating security as part of the development process is so important. That is how software becomes secure software. You have checks and balances, to warn before a release goes out that a security review of the code is done. Would you like to comment on what Cider does?
<Rotem Bar> Yes, I would be glad to. What Cider does is connect to the whole supply chain of companies, they start from the development process, GitHub/GitLab, those areas and puts proper security measures. Code scanning, artifact scanning, scanning the whole CI/CD environment to find flaws and give a full holistic view of what could go wrong. Then, shifts everything left to the developer. I as a security person, do not want to handle millions of bugs for the developer, I want them to shift left. This is why I do my research, it is part of the stuff I do and find fun. Bug bounty and also research.
<Robert> Awesome, that’s cool. How do you stay up to date on security knowledge? Is this a lifelong passion?
<Rotem Bar> Yes, this is a lifelong passion. I have done this even before the army, in high school I played with security and stuff. In my life I think about how to secure and protect things, how to build things in a better way, but also how to break them. Because of this, I also read lots of blogs and play around with systems. This is why I love the bug bounty groups, I work with top researchers around the world, bouncing off ideas, collaborating, and this way I am always on the edge of security knowledge. Learning new things, tinkering, deep-diving into everything that I can look at.
<Robert> Nice. So, blogs, community, and I agree. Blogs and community are a great way to learn, having someone to ask questions to is critical and can save you a lot of time and give you new ideas. You mentioned blogs, you have one at rotem-bar.com where you have the write-up about this Elementor vulnerability. They patched months ago in February, and you released this blog post in June?
<Rotem Bar> Yes. Once the CVE was approved we could talk about it. The proper systems were patched, so now is the proper time for people to be aware of it so they can be aware of it.
<Robert> Users can know to patch, a simple solution for them. And for the security researchers and bug bounty hunters, you can read how Rotem approached the issue, seeing one vulnerability was already patched but kept looking into it to find more. I noticed you also have a great proof of concept video at the end to show how things worked, and you have a link to a tool that users can use to test if their Elementor websites are vulnerable or not.
<Rotem Bar> Yes.
<Robert> So, users of Elementor can go to the blog post and at the bottom of it is a link to the script that will test websites. How does that script work? Will it give a Yes/No if a site is vulnerable or not?
<Rotem Bar> So it actually redirects or opens a new tab, because this is a DOM-based XSS I just add my payload, my special payload that does not do an attack (I hope)
<Robert> I hope too!
<Rotem Bar> But, the payload will just pop a shell … I mean the javascript alert box, if you go to it and see nothing then the site is probably fixed. Or my payload is wrong.
<Robert> Oh, so basically you go to this tool and put in your website’s domain and if your site is vulnerable it will show an alert box.
<Rotem Bar> Yes.
<Robert> It might be a good idea, and I trust you Rotem, but … it might be a good idea if you’re running Elementor on your website to log out first. Rotem probably could not pop a shell, but if you know a way to pivot a DOM-based XSS to shell then we should talk some more.
<Rotem Bar> I think you can. If you have XSS, and you have the admin logged in, and another plugin with code execution. Even if it’s an internal plugin only for admins. Then I think it can be an interesting chain reaction resulting in a shell.
<Robert> Oh, yea! That would work. The site would need 2 or more vulnerable plugins, one having DOM XSS, but the second having an authenticated RCE. The DOM XSS vulnerability alone is medium/low risk but can be used to access the higher risk remote code execution bug.
<Robert> Thank you very much Rotem for your time, is there anything else you would like to mention?
<Rotem Bar> No. Thank you very much. The Patchstack community helped me with the CVE, so I wanted to thank you.
<Robert> You’re very welcome, we are happy that you let us know about the vulnerability and that you’re participating in the Patchstack Alliance. I hope you have a great rest of your day, thank you very much.
<Rotem Bar> Thank you, bye-bye.
