Last week, Askar from Shells.Systems published two remote code execution (RCE) vulnerabilities in rConfig [1]. The blog post included details about these vulnerabilities and proof of concept code. Both vulnerabilities are trivially exploited by adding shell commands to specific URLs, and one of the vulnerabilities does not require authentication.

My next step was our honeypot logs. I was somewhat surprised that I saw pretty active exploitation of the vulnerability. The exploits came from over 300 different sources at that point, and still kept coming in at a pretty steady pace. But only one particular exploit string was used. The exploit only verifies if a system is vulnerable. These exploit attempts did not originate from a known security company or research effort. I checked a couple of the IPs scanning my honeypots, and the web servers I found had a variety of more or less default configured tools that are likely vulnerable as well. I assume that a botnet is used to scan for the vulnerability, and the origin hosts have been infected themselves.

Figure 1: Geographic distribution of scanning hosts.

Example exploit attempt:

GET /install/lib/ajaxHandlers/ajaxServerSettingsChk.php?rootUname=%3Becho%20-n%20HellorConfig%7Cmd5sum%20%23

The exploit attempt sends the string "HellorConfig" to "md5sum". This is likely done to check if the vulnerable systems returns the output of the command. The output from my test system:

{"phpSafeMode":"Pass - php safe mode is off<\/strong><\/font>","rootDetails":"The root details provided have not passed: a42e705f4cade6b3e84b99b0e0400e74 -<\/strong><\/font>"}

So it looks like we got all the pieces in place for a major security issue. Next, I did a bit of research on rConfig itself. I went to the website distributing it [2]. It looked reasonably well done, and offers the free version of rConfig, as well as a paid support option and teases an upcoming new release. But it wasn't exactly straight forward to find a contact address. I had a bit more luck with the GitHub repository [3]. This is also where I got some indicators that rConfig isn't necessarily all that popular. The last update appeared over a year ago, and even before that, things look sparse. The author also left a note that "I am no longer fixing bugs on rConfig version 3.x. I will manage PRs.". 

Next, I installed the tool in a virtual machine. The install process worked fine (and appeared to be quite complex). At the end, the software was configured via a web-based "install" tool. This tool is also where the pre-authentication vulnerability happens. However: rConfig requires that this install directory is deleted after the install is complete. So in short: You are not vulnerable if you completed the install. This reduces the risk significantly.

So in short: probably not a big deal.

My advice: It doesn't look like rConfig is currently maintained (at leas the version offered for download right now). I would stay away from it. And tools like this should NEVER be exposed to the public internet.

and finally a quick snort rule:

alert tcp $EXTERAL_NET any -> $HOME_NET 80 (msg: "rConfig Remote Code Execution"; sid: 1500123; uricontent: "/install/lib/ajaxHandlers/ajaxServerSettingsChk.php?rootUname=|3b|";)

[1] https://shells.systems/rconfig-v3-9-2-authenticated-and-unauthenticated-rce-cve-2019-16663-and-cve-2019-16662/
[2] https://www.rconfig.com/
[3] https://github.com/rconfig

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