JOE JAMIE you can ask here why the are scanning for this exploit starting at on of our box 14-09-2019 maybe the know more and why?! https://www.abuseipdb.com/check/89.248.171.57 ISP Incrediserve Ltd
Usage Type Data Center/Web Hosting/Transit
Hostname(s) scanner20.openportstats.com
Domain Name incrediserve.net
Country Netherlands
City Den Haag, Zuid-Holland
For the rest i don’t know if it helps here but this audit / scanner can give more info is also free version available https://cisofy.com/lynis/
The other error I mentioned (password is expired) is indicative of a likely successful attack (or a probe by a researcher that is counting exploitable hosts). The code path that produces the Password changing is not enabled! error is not exploitable, and is behaving as intended.
If you only see “Password changing is not enabled!” messages, you’re probably fine. Though it’s hard to be 100% sure. I recommend doing all the other stuff one would do in an “am I compromised?” situation. rkhunter and similar tools, verify your packages (rpm -Va on CentOS) looking for modified sensitive binaries (ps, passwd, pam and login-related libraries, in particular), if you have backups, compare /etc between them, check /root/.bash_history for suspicious stuff, etc. You’re looking for crumbs, as most attackers are sloppy and leave them lying around. This is what we’ve been doing on our servers that can’t be re-installed easily (we’re in the midst of migrating a bunch of stuff into cloud-based services, so some stuff was already scheduled for retirement).
You also want to watch for outward signs of abuse: high network usage (meaning it’s sending spam or otherwise participating in a malicious botnet), mysteriously high CPU usage (mining Bitcoin, or whatever), in particular.
We leave old versions available for archival purposes. But, you should never use an old version. They are not modified, and are exploitable.
If you use apt or yum, you’ll always get the latest available version. You’d have to go out of your way to install an old version…it won’t happen accidentally.
The default configuration of 1.890 was exploitable; i.e. root-level access to anyone who knew how to trigger it. The default configuration of later versions was not exploitable. Most people with later versions will not be impacted, as most people will not have modified that option.
Ok somewhere on the web sorry can’t find it now complaining about having such online and saying… about webmin because of that
Have bad experience with companys using not accidentally very to old insecure versions of software, because they can still download such from platforms as github and so on.
To have a more secure CYBERworld everything known unsafe should be deleted where possible, OK is my Opinion.
We only know what we’ve discussed. The researcher who released the exploit did not disclose it to us before releasing it. We didn’t hear about it until the 17th, which is when we released an update.
We can’t go back in time and change anything. This is the situation we’re all in. It’s the most serious security issue in Webmin in more than a decade, and all we can do about it is try to make sure nothing like it ever happens again. I don’t know why the researcher didn’t responsibly disclose the bug to us in advance of announcing it. And, I don’t know why news of it didn’t trickle down to us sooner (I have Google alerts setup for webmin, virtualmin, etc., but it wasn’t until it became bigger news on Saturday that Ilia pointed it out to us and we started researching it).
I don’t have any way to say, “Your servers are fine. Forget about it.” We all have to poke around and look for signs of trouble. We’re sorry it happened. It’s not a great feeling. But, we’re doing everything we can to prevent similar situations in the future.
Is Usermin wasn’t running it definitely couldn’t have been exploited. We don’t now of any published exploits of Usermin, but I think it would be subject to the same problem, as the build environment for Usermin links to shared files in Webmin, including this password_change.cgi file. I haven’t tested whether modifying the existing exploit in metasploit or via curl or whatever would work in Usermin, but I suspect it would.
OK fair,
We have some work and scanning todo.
I’m only pointing out some knows from date 10-08-2019 and some 12-08-2019 that is probably why scam scans started before the 17-08-2019. ( on one of ours 14-08-2019)
So and also then for everyone if you look for … on your boxes take in mind those dates to.
The exploit does trigger log events, which I’ve posted in a few messages in this thread and on github, whether successful or not (the code of the exploit is very sloppy…a good programmer could have made it not trigger any logs or visible errors, but this one does). But, if a server is rooted, it may not be possible to trust the logs (because root can modify or delete logs).
So, if you find the errors that come from the exploitable code path (expired password error), you probably need to treat the system as if it has been compromised. If you find the other errors, you probably still want to look for breadcrumbs, because a competent attacker would clean up the logs. But, not all, or even most, attackers are competent. Most are just using automated tools to spin up as many nodes on their botnet as possible, and don’t care if some get found out and removed.
Thanks we now know where to search for.
At our box is only the scam scanners trying to, not password is expired
I share some IPS.
Are some or all in abusedip com don’t know or legitimate scanners or scammers, don’t have time for both!
For Richards picking them up is a good idea even if legitimate they are spoiling resources.
I have read trough all posts and what I can see is that we never can be sure that a server is not compromised… in other words, to be 100% sure is to wipe the disks and start from scratch! I’m thinking of doing that since we got a backup server, but can we be sure that a new install will be clean. This is a massive work load to do this but to be honest, I would sleep better after all work is done, knowing that the “not knowing for sure” no longer is an issue… Or do you think this is the wrong path to take!
Only if you know your Server now has also lack of some newer en more modern cyphers , tls protocols and so more.
Then please check out with what apps / software and devices your Customers work and connect.
If possible installing new box then together with more and stricter security and so on makes more sense then only looking for this thing.
The Job if now on older such specs, must be done once in near future , so you spare that time and research to in one new clean install.
The Basic virtualmin webmin installation you have to change and update some.
in stead of 1024 / 2048 bit you could have new more future proof 4096 and so on.
Check you box with these sites for upto date protocols and more modern future proof settings:
The box that i’m thinking of reinstalling is a brand new hi end dedicated server, raid, and all possible security, IPMI for remote control as the server is in a secure data center 1000km from me. The box is fresh installed 4 month ago with the best possible security, r1soft backup twice a day, only “real” certificates, not LE certs… and dedicated IP’s for every customer! I have been working on this box some time now to have it fine tuned and tightly secured… so it’s not that fun to wipe it! But… i’m no a linux guy and for me to try to find what has (maybe) been compromised… no I don’t think so! For 15 years I have used and trusted Virtualmin Pro to be my GUI to linux, and they have done the job excellently!!! And I still trust and also will continue to use Virtualmin.
It’s a tough situation and one I’d hate to give the wrong advice about. Is it possible for you to hire a Linux security guru to give it the once-over?
In my own case, I did run all the usual rootkit finders and the like, and they turned up nothing of concern. But all of the sites on the server in question are my own. Also, the timing and the fact that I never had password change enabled make it unlikely that it was affected, anyway. So I’m not 100 percent sure, but I’m 99 percent – and all the data is mine and backed up. I’m not taking chances with other people’s stuff.
Your situation is more difficult. Reformatting and starting over would cause a lot of work for you and at least some inconvenience for your clients, but not as much as a compromised server would. And tools like rkhunter do require a certain amount of interpretation. So it’s a difficult decision.
The only advice I feel comfortable giving is to consider hiring a security guru to check out the server. You can never be 100 percent sure that a server is clean: but that’s true even if you reinstalled it this morning. So if you can find someone who’s willing to say they’re 99 percent sure, maybe that’s the best you can hope for.
The worrying part for me is that the malicious code was around about 3 month before the “password” setting had to be in a specific state, those 3 month before that the code didn’t need the “password” setting, the code worked anyway. And another thing is that almost all our customers is government/state, so I can’t settle for 99% if I can get 100%,
The first time an entry occurred in my webmin log was in January of 2018 on /session_login.cgi.
The next attempt was in July 2018, then 3 times in August of 2018.
After that nothing until August 2019 when there were many attempts on /password_change.cgi
Hi Joe, and others. Thanks for this update. I was on holiday in cyprus using google discover app on my phone and it was around 3 or 4 entries about this. as I was without laptop my hair grown in seconds now its all sorted on my end. I would like to thank you guys for very quick action. You are great!
now its all sorted on my end. I would like to thank you guys for very quick action. You are great!