elFinder is an interesting open-source project implementing a file manager in JavaScript and PHP. The file manager promises a user experience similar to the "Finder" in macOS. Once you have elFinder installed, uploading/downloading files to your web server will be a lot easier.

But then there are vulnerabilities. Over the years, elFinder had several severe vulnerabilities. Snyk lists 7, some as recent as June 2021. The most recent vulnerability, CVE-2021-32682 is a remote code execution vulnerability. SonarSource has a nice blog post with details about the vulnerability.

When it comes to allowing file uploads, there is one critical rule: Do not allow uploads into the document root. Otherwise, an attacker can upload a PHP script and later execute the code by accessing the script from the browser. Tools like elFinder do not always have that luxury. The tool's purpose is to upload files into more or less arbitrary locations. The most common use case allows uploads of assets like images to the document root.

To mitigate that risk, these tools implement blocklists of particular extensions and filetypes that must not be uploaded. And with all blocklists, it is easy to miss something. For example, elFinder by default did not block ".phar" files, which are often associated with PHP. 

The next, also common, vulnerability involves calling operating system commands. elFinder will allow users to upload zip files and unzip them for the user. To accomplish this, elFinder uses the operating system's zip utility. The elFinder developers did cover the most prominent issue: Someone attempting to append a second command. For example, if a user uploads a zip file with the name "test.zip&wget%20exploit", the "&" would be appropriately dealt with. But often overlooked is a second path to code execution: Many tools (and "zip" is one of them) allow for command execution via command line parameters. This option was overlooked and led to past vulnerabilities.

So what are we seeing?

For the last couple of weeks, we started seeing scans for elFinder popping up in our "First Seen" list of URLs reported by our honeypots. 

Attackers are paying attention. Some quick "Google Dorking" shows likely about 100,000 or so (hard to get a good number) of exposed instances. I didn't check how up-to-date they were, but I assume many of them to be vulnerable. (again: this number is not great. On the one hand, it includes some pages about elFinder, but it also misses instances that are not "linked," and Google didn't index). 

What can we expect attackers to do with elFinder: The number one issue will likely be phishing. Whenever I look at a phishing page, it usually involves a compromised WordPress page (and elFinder is used as a plugin with WordPress) if the attacker didn't opt for some cloud hosting. 

What do you need to do? Take the list of URLs above, and scan your internal systems quickly, making sure you are not exposing elFinder. It may have been included in other tools. While the list of URLs is not exhaustive, it is a good start, and this is what the attackers are looking for (one of the values you get out of a honeypot).

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|