Dear Planet Earth: Patch Webmin now – zero-day exploit emerges for potential hijack hole in server control panel

Updated The maintainers of Webmin – an open-source application for system-administration tasks on Unix-flavored systems – have released Webmin version 1.930 and the related Usermin version 1.780 to patch a vulnerability that can be exploited to achieve remote code execution in certain configurations.

Joe Cooper, one of the contributing developers, announced the patch in a blog post over the weekend.

"This release addresses CVE-2019-15107, which was disclosed earlier today," Cooper said. "We received no advance notification of it, which is unusual and unethical on the part of the researcher who discovered it. But, in such cases there's nothing we can do but fix it ASAP."

The patch also deals with several XSS issues that were responsibly disclosed, he said, noting that a bounty has been paid to the researcher who reported them.

The bug at issue is a pre-authentication command-injection flaw in the &unix_crypt function* used in the password_change.cgi file, used to check the password against the system's /etc/shadow file. By adding a pipe command ("|"), an attacker can execute remote code.

To be vulnerable, Cooper said, the Perl-based software must have the Webmin -> Webmin Configuration -> Authentication -> Password expiry policy set to Prompt users with expired passwords to enter a new one.

"This option is not set by default, but if it is set, it allows remote code execution," he said.

That may be the case for most versions – the vulnerability exists in versions 1.882 through 1.920 – but Webmin 1.890 is vulnerable in its default configuration.

The bug appears to have been revealed on Saturday, August 10, by Özkan Mustafa Akkuş at DEF CON and to have been made available as an exploit in a module for the Metasploit framework. The Webmin maintainers didn't hear about it until Saturday, August 17, when they noticed people discussing the issue on Twitter and Reddit. The CVE was created Thursday, August 15.

Webmin has about 215,000 installations, according to a Shodan search (account required), and about 13,000 instances of the particularly vulnerable version 1.890.

Tiago Henriques, developer relations lead for Microsoft Azure and founder of binaryedge.io, puts that number higher at about 598,000 Webmin instances and 29,000 instances of version 1.890.

According to Cooper, the malicious code was introduced into Webmin and Usermin through the project's build infrastructure. "We're still investigating how and when, but the exploitable code has never existed in our GitHub repositories, so we've rebuilt from git source on new infrastructure," he said.

In an email to The Register, Cooper said the malicious code – which appeared in the Sourceforge repo but not the GitHub repo – was introduced to Webmin on local package build infrastructure before it reached Sourceforge.

"Jamie [Cameron, the project's primary author,] would know more details, but my understanding is that it was a build server in his home that had been in service for many years," Cooper said.

"It was shut down a few months ago, but the build directories were copied over from backups to the new build system...so, the exploit came along with it. The new build is from new infrastructure and from a fresh git checkout; Jamie compared the exploited code against the git code, as well, looking for any other introduced code."

Cooper said the bug is of fairly limited risk in the version of the software (Webmin 1.920, Usermin 1.770) that immediately preceded today's patch because it requires changes to the default configuration.

"An earlier iteration, presumably introduced by the same attacker since it was introduced through the same vector, was more serious (in Webmin 1.890, and did not need any non-default options for a similar attack), and it took Jamie a while to find it (or even realize the reported bug was real) because it was not in git, so we were looking at, and trying to reproduce, against code that didn't have the problem," he explained.

The Register asked Cameron if he could shed any light on the origin of the server compromise, but he didn't immediately respond. Cooper however suggested the project's ability to investigate may be limited.

"The build server that was originally exploited is no longer available for forensics, so we're kinda left guessing about how the attacker got in, but that's maybe less useful than just putting in place practices that make that vector impossible to exploit again," said Cooper. ®

Updated to add

* Cooper got in touch with El Reg after this story was published to say that the researcher's explanation of the bug misses the mark. The issue isn't the &unix_crypt function. Rather, he said, it "was due to an injected `qx//` in one of the function calls. Specifically, this line in password_change.cgi:"

$enc eq $wuser->{'pass'} || &pass_error($text{'password_eold'},qx/$in{'old'}/);

"qx// is equivalent to backticks in Perl, so it runs whatever is in the // in a shell," he said.

Cameron's reply also arrived after we published. He said he is unable to say how the compromise occurred because the server was decommissioned shortly afterwards, eliminating any log files that could have been used for forensics.

“Unfortunately the file with the vulnerability inserted was migrated to a new machine, so it persisted into later releases – even though the build had been moved to a new and more secure environment,” he said. “Since this was detected, I’ve cross checked all code in GitHub with code on the build system to detect any other hidden vulnerabilities (there were none) and spent a bunch of time reviewing all recent commits. In the interest of full disclosure, I’m going to write up more details of what happened and publish it on webmin.com in the next day or two.”