If you run a WordPress site and you use the Elementor website creation toolkit, you could be at risk of a security hole that combines data leakage and remote code execution.

That’s if you use a plugin called Essential Addons for Elementor, which is a popular tool for adding visual features such as timelines, image galleries, ecommerce forms and price lists.

An independent threat researcher called Wai Yan Myo Thet recently discovered what’s known as a file inclusion vulnerability in the product.

This security hole made it possible for attackers to trick the plugin into accessing and including a server-side file…

…using a filename supplied in the incoming web request.

Simply put, a malicious visitor could trick an unpatched server into serving up a file it’s not supposed to, such as the server’s own username database, or coerce the server into running a script it shouldn’t, thus creating a remote code execution (RCE) hole.

As you proably know, web server RCE bugs are typically abused to implant malware that allows the attackers to do something to your immediate, and often costly, detriment.

Typical examples of how cybercriminals exploit RCE bugs include:

• Opening up a backdoor, so they can sell access to your server on to other crooks.
• Launching a cryptominer to steal your electricity or cloud services to generate money for themselves.
• Setting up network surveillance tools to snoop on and steal your own or your customers’ data.
  

  Untrusted input can’t be trusted

  You can see the obvious problem here, namely that if the special text string ${cookie:usr_theme} blindy extracts the text in the usr_theme cookie supplied by the user, and uses it to build a filename, then there’s nothing to stop a malicious user from asking for a theme called, say, ../../../../etc/passwd.

  This would trick the server into #including the file content/theme/../../­../../etc/passwd, which wouldn’t read in a file from the content/theme/ directory, but would navigate up to the root directory, and then descend back down into the system’s /etc/ directory to in the contents of the passwd file instead.

  Even if the resulting HTML file wouldn’t display properly because of the unexpected content in the section of the file served up, the visitor would still end up with a copy of your passwd file, and thus a list of all accounts and usernames on your server.

  Worse still, many web servers and content management systems treat some filenames specially when they’re included.

  Microsoft IIS, for example, considers files with the extension .aspx special; many Linux-based web services do something similar if the file ends in .php.

  Instead of including the raw contents of the file, the system will run the file as a program (written, for example, in Visual Basic on Windows servers and in PHP on Linux servers), and include the output from the program instead.

  This makes content such as customised pages and one-off search results easy to generate on demand, because the code needed to generate the content is embedded in a logical place in the directory tree that represents the structure of the website.

  Of course, this also means that an uncontrolled #include directive, like the theme-based one we envisioned above to steal the password file, could be used for remote code execution as well as data leakage.

  For example, imagine that we replaced the malicious “theme cookie” above with text such as ../../scripts/listusers.php, because we knew or could guess that the server in use contained a PHP utility script of that name to list all the website logins.

  We’d then be able to trick the server into runnning that script, even if it was never intended for running from inside web pages, and wasn’t supposed ot be accessible to outsiders at all.

  Even worse, we might find that we could use the ../.. (“move upwards in the directory tree”) trick to execute a script file called, say, ../../uploads/pending/img000067.php.

  Usually, there wouldn’t be such a file and the #include would therefore obviously fail, but if we knew (or suspected) that the server had an uploads/pending/ directory where user-contributed objects such as comments, images, videos and so on were stored temporarily until a moderator decided whether to approve them…

  …and if we could upload a “pending” file using a name we could subsequently predict, then we’d not only have a remote code execution hole, we’d have a totally arbitrary remote code execution hole.

  We we could first upload a rogue script, so that the file appeared temporarily in the uploads/pending/ directory, and immediately afterwards trick the server into executing it by setting a special cookie to trigger the attack.

  What to do?

  • For Essential Addons for Elementor users. Check that you have version 5.0.6 [released on the day this article was written] or later. The bug was discovered in version 5.0.3, but patch 5.0.4 was quickly superseded by the updated patch 5.0.5, which was in turn quickl superseded by 5.0.6.
  • For web developers. We shouldn’t need to say this as often as we do (or even, perhaps at all) in 2022, but we shall say it anyway: validate your inputs.

  Don’t just check programmatic input when you know for sure that it came from an untrusted source such as an HTTP request.

  Even if you think you can trust the upstream process or user who provided your input, check it anyway, in case that trusted process itself contains a bug, or relied in some way on tainted content that started further up in the data supply chain.