Webmin 1.930 and Usermin 1.780 released

I think so to while function disabled we see these kind of calls in that miniserv error log to

ON some forum they write such kind of replys so…

here the webmin one http://www.webmin.com/exploit.html

@JOE

no matter running which version in the past running >= 1900 now , is this enough for beeing safe for the scriptkiddies? ( password change option was alway disabled in GUI)

Alternately, if running versions 1.900 to 1.920, edit /etc/webmin/miniserv.conf, remove the passwd_mode= line, then run /etc/webmin/restart.

You write here:
http://www.webmin.com/security.html

Okay, thanks. Later on I think I’ll take a look at that file and figure out how to capture those attempts, report them, and add them to a blocklist I maintain. This server would be ideal for that because I’m the only human user, so it can’t be a genuine lost password reset request from a client.

First day starting 14-08-2019

Here a short list of trying ip’s at 1 of our boxes. last 2 days

csf is not blocking probable i don’t know or manual or automatic trys from kiddies and…?

[21/Aug/2019:16:19:25 +0200] [176.67.80.61] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[21/Aug/2019:18:50:27 +0200] [144.217.207.30] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[22/Aug/2019:06:50:20 +0200] [88.99.146.161] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[22/Aug/2019:06:50:20 +0200] [88.99.146.161] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[22/Aug/2019:06:50:53 +0200] [18.224.72.187] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[22/Aug/2019:06:50:54 +0200] [18.224.72.187] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[22/Aug/2019:08:31:12 +0200] [191.101.63.23] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

First day starting 14-08-2019
[14/Aug/2019:08:34:23 +0200] [89.248.171.57] Document follows : This web server is running in SSL mode. Try the URL https://ip-199-.:10000/ instead.

[14/Aug/2019:08:34:23 +0200] [89.248.171.57] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[14/Aug/2019:10:11:27 +0200] [89.248.171.57] Document follows : This web server is running in SSL mode. Try the URL :10000/ instead.

[14/Aug/2019:10:11:27 +0200] [89.248.171.57] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[14/Aug/2019:13:20:53 +0200] [85.25.118.188] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

[14/Aug/2019:13:22:22 +0200] [85.25.118.188] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

some more bad ips trying:
103.231.92.23
51.38.184.92
37.252.122.212
193.42.221.14
89.248.171.57
34.200.237.162
124.47.191.14
95.222.60.31

And mine:

[17/Aug/2019:16:53:05 -0400] [62.210.110.80] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [18/Aug/2019:19:13:04 -0400] [140.143.210.34] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [20/Aug/2019:17:03:28 -0400] [192.3.70.143] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [20/Aug/2019:17:03:29 -0400] [192.3.70.143] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [20/Aug/2019:17:03:30 -0400] [192.3.70.143] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [20/Aug/2019:20:46:44 -0400] [207.38.89.142] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [20/Aug/2019:20:46:44 -0400] [207.38.89.142] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [22/Aug/2019:01:02:30 -0400] [50.116.18.236] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12. [22/Aug/2019:01:02:31 -0400] [50.116.18.236] /password_change.cgi : Perl execution failed : Password changing is not enabled! at /usr/libexec/webmin/password_change.cgi line 12.

Actually, I have another box running Virtualmin that’s not in production use yet. I think I’ll use that one as a sandbox. My Perl skills are less-than-wonderful. But I do love setting honeypots.

On test box running shorter time 4 months now only few domains doesn’t have this logs
so they didn’t find yet!

Or as JOE says be carefull, i am not sure???

I see this log entries at all of my servers except one: a virtualmin installation not using standard port 10000.

glad to hear this was fixed

While updating

warning: file /usr/libexec/webmin/authentic-theme/unauthenticated/js/codemirror/mode/meta.js: remove failed: No such file or directory

Can someone tell me how to know if a server was compromised…

What do I look for?

//Leffe

Webmin -> System -> System Logs

For both File /var/usermin/miniserv.error and File /var/webmin/miniserv.error:

  1. Click “View”.
  2. Set “Last __________ lines of…” to some high number (2000, 20000, whatever).
  3. Paste “Perl execution failed” into box “Only show lines with text _____________”.
  4. Refresh.
  5. Look for lines containing something like “Perl execution failed - Your password has expired…”

My understanding is finding that line doesn’t mean it was definitely compromised, but it means you need to investigate further. I could be wrong.

@JOE @JAMIE

Why one can still download old version are those cleaned up?

https://sourceforge.net/projects/webadmin/files/webmin/1.920/webmin-1.920.tar.gz/download?use_mirror=vorboss

https://sourceforge.net/projects/webadmin/files/webmin/1.920/webmin_1.920_all.deb/download?use_mirror=netcologne

Thanks Richard,

I have a ton of lines like this on our servers /password_change.cgi : Perl execution failed : Password changing is not enabled! but when reading what Joe wrote is it only on the later Webmin versions that setting had to be enabled for the exploit, and it has been around for a year. How and what else should I look for!? It is a catastrophe for us if we have to reinstall - We can’t do that! We have to buy a new dedicated server first and then start to move customers there, because many of our customers run services as sending text messages, and they send thousands on daily basis!

Regards,
Leffe

You’re welcome, Leffe. And I don’t know. I’m new at Virtualmin and hadn’t used Webmin in years until a couple of months ago. So if I answer a question at 10:00, it’s quite possible that I may have just learned the answer myself at 9:59.

My guess would be that any such lines after you applied the update can be safely ignored, and any before you applied the update would need investigating. But don’t take that as gospel. I’m just basing it on many years of experience as a server admin, not a lot of experience with Webmin.

To be safe, I’d wait until an expert answers. My answer is just an educated guess. I’m no expert.

in 1890 version the exploit was completly possible without the enabled setting because of “bug” or so.

So i guess there you don’t see these text in log files at all.

So not knowing where to look for in the time space when having version 1890 installed in the log files if yes or no hmm.

Problem is how many did know about that the time 1890 version, and did they abuse with … if you read several people find out, even kind off discussing who was first and when trying to selling 0day exploit to some . The buying site didn’t want to buy because it was already known.

As JOE and so are writing a lot of true not true txts on the web and different infos to.

Even at one place a lot of …

https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/

I gues i hope Joe can tell where to look for with systems that had version 1890 installed once

damn jfro stop spamming the thread.

UH only asking and helping out with info’s why is that spamming? ( sorry 'm Dutch and dislexie for my Gramar)

Need for that while fixes are later then exploit known dates, so you have to check your boxes for …

quote Joe: 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,

And the other version was public 10 -08-2019 or known that date so fixes are later!
See here the date
https://www.pentest.com.tr/exploits/DEFCON-Webmin-1920-Unauthenticated-Remote-Command-Execution.html

EDB-ID: 47230
CVE-2019-15107

10 Aug, 2019 • EXPLOIT

So needed how to find out if abuse of exploits on boxes between known dates and fixed dates yes or no?

At our boxes the tryouts to abuse this exploit 0Day started also before fix date of Webmin self namely 14-08-2019
I posted that part of log file starting hacks 14-08-2019 here https://www.virtualmin.com/comment/816085#comment-816085
And no the password option isn’t enabled!

Also if for those who have this had enabled read here what todo, is only an advice from someone, while hacking to eploit this one started before the patch as in our log files 14-08-2019
https://github.com/webmin/webmin/issues/1093#issuecomment-523876740

IN this EXPLOIT DATABASE as of date 12-08-2019 So explains the start of scams after that date https://www.exploit-db.com/exploits/47230

Thanks again Richard,

We have been using Virtualmin Pro for almost 15 years, we was running Pro version already in early adapter period. Virtualmin has been running fine almost all the time, but in the last years all sort of bugs keep coming up! Hopefully they get them fixed! And also tell us what to look for to know if a server have been compromised.

Our customers is mostly Swedish communs (municipality) and they don’t allow downtime for their services! We have backup servers but they have the same software as the main servers.

Regards,
Leffe

My pleasure, Leffe.

Would reinstalling the OS and WMin / VMin on the backup servers, and migrating just the accounts (assuming no problems in UMin), be an option if it came down to it?

Let’s hope none of that is necessary, however.