I’ve rolled out Webmin version 1.930 and Usermin version 1.780 for all repositories. This release includes several security fixes, including one potentially serious one caused by malicious code inserted into Webmin and Usermin at some point on our 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 (and checked to be sure the result does not contain the malicious code).
I don’t have a changelog for these releases yet, but I wanted to announce them immediately due to the severity of this issue. To exploit the malicious code, your Webmin installation must have 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.
This release addresses CVE-2019-15107, which was disclosed earlier today. 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.
It also addresses a handful of XSS issues that we were notified about, and a bounty was awarded to the researcher (a different one) who found them. (So, if you’re a security researcher and responsibly disclose your findings, feel free to hit us up with anything you find. We pay.)
Anyway, we’re all a little grumpy, as we needed to drop everything and sort out what happened, figure out how to fix it, and get new releases rolled out immediately. But, the packages in our repos fix it, and also include theme updates and some other new stuff (changelog coming soon). But, you definitely need to update if you use that feature. As far as we know the malicious code is not exploitable if you aren’t using that option, but there are some unrelated XSS issues in Authentic theme that are also fixed, so no reason not to upgrade right away, even if the more serious one doesn’t effect you.
Canonical’s GitHub account hacked once UBUNTU so be carefull with GITHUB ( not this one but ) and other such things / places you all.
IF you read back forum there where few times Installations couldn’t find connect to source to install so errors not online or other problems, maybe you can find those and have a look at those dates when these outages hapened , is only a 123 idea from me.
Is it only Webmin that is targeted? On Usermin configuration that authentication setting was set to “Prompt users with expired passwords to enter a new one”. And when I changed it to “Always deny users with expired passwords” i got an error: “Failed to save authentication : Failed to open PID file”, but the change seems to be saved. Is this because Usermin wasn’t running, we don’t use usermin so it is never running… or should I be worried???
on click of file manager it loads only the first level files and folders. if you try to navigate any folder from there then it load nothing… it takes forever…
update:
suddenly it started to work now… earlier the folder navigation window was also missing… now that is also visible…
Yes, it shows up in the access log as an access of password_change.cgi; though that won’t necessarily indicate a successful exploit. Any version other than 1.890 requires that password expiry/change option to be enabled, so accesses would fail.
When I was testing a couple of different methods of exploit (for 1.890 and for 1.920) it shows up in miniserv.error, as well, though it depends on what is in the input (and which version of Webmin is running) as to what shows up. But, there maybe a perl error looking something like Perl execution failed - Your password has expired [...] at /usr/share/webmin/password_change.cgi
Seeing that error probably indicates the system was exploited in some way, as reaching that code indicates the option is enabled or it was running under version 1.890.
Jamie revived his old Solaris box to build a package just for you, our one remaining Solaris user. (I’m kidding, there may be two or three others running Solaris.)
Our of curiosity, are you running Solaris from Oracle or one of the OpenSolaris off-shoots, like IllumOS or SmartOS?
It looks like 1.890 was released in the Virtualmin repos on 7/16/18, and upgraded to 1.894 about three months later. I guess it wasn’t as short-lived as I’d assumed, but from what we can tell it was not being exploited widely until the tweetstorm and media coverage starting on the 17th. It wasn’t being tracked by researchers who track that sort of thing until it was “dropped” at DefCon, and attacks started ramping up almost immediately, but weren’t super widespread until the 17th.
Reproducing the attack based only on what was in the “0day drop” required tweaking, and so script kiddies couldn’t make it work without people in forums figuring out how to make it work (it even took me a few minutes to figure out why it was failing for me). I suspect the researcher just didn’t understand the bug (either discovering it through fuzzing or finding it mentioned on some black hat site, or similar), and so his PoC was kinda wonky and required a lot of luck to make work (but only a little tweaking was needed to make it super dangerous on 1.890, but it needed the right Webmin configuration on all later versions).
What I’m trying to say is that it was a slow ramp up, at least partly, because the published exploit wasn’t workable in a widespread way without tweaking, and a lot of attackers are low-skilled; just running existing exploits and adding the results to their botnets for spamming or whatever. I followed the discussion all day on Twitter and reddit, and was surprised by how much wrong information was flying around (wrong in the sense of it didn’t accurately describe the bug or the way to exploit it) and for how long.
All that said, if you find something, you probably should scrap the system. You can never really trust a rooted system again, until it’s been reinstalled with a fresh OS. We hate that this happened, and we’re sorry to everyone who does end up having to reinstall…know that we’re in the same boat (all of our servers run Webmin or Virtualmin, too, and we have quite a few), and have been auditing everything since Saturday. We’re just hoping the slow ramp up and getting a new release out minimized the damage. We wish the researcher had responsibly disclosed the bug, but not everyone does responsible disclosure.
Would the mere fact that someone attempted to access that function, even if it failed because password-changing was not enabled, serve as a natural honeypot?
be carefull with GITHUB ( not this one but ) and other such things / places you all.