Hi this is new… It seems my openfire server got hacked and infected by a ransomware… Server runs on Centos I’m not so sure what happened but as I checked the hacker was able to access the server without using root logins … Perpetrator gained access on OpenFire Admin console and installed Plugins “Monitor.jar” and Openfire.Jar . They created additional logins with Admin privilege. The website crashed and all system files got encrypted. I was able to restore it and leave it and turn into a honeypot server I’ll observe what will happen…
I’m sorry to hear this, Mike. This is most likely a result of the vulnerability that we’ve reported a while ago. Please find an analysis, mitigations and solutions in https://discourse.igniterealtime.org/t/cve-2023-32315-openfire-administration-console-authentication-bypass
In the last few days, we’ve seen an uptake of exploits of this vulnerability popping up in the wild.
I’d appreciate it if you could share the malicious plugins in a private message to me. That will help us analyze things.
Would be curious of the following?
- Version of Openfire?
- Linux version and variant?
- Was Openfire running as the root user or daemon or some non-root user?
Hi here’s the server specs
Centos 7 (Patched)
Version: Openfire 4.6.0
OpenFire is part on service runs on Non - root user
Found some unknown plugsin on the server
I was trying to decompile the jar to see what will be the impact but its a no go
Thanks. They must have used some other Linux exploit to gain
root access. Just getting access to Openfire would not have been sufficient.
I did trapped this IP on my servers upg to 4.7.5
Trying and unknow account same trial done on several Free-Solutions Openfire servers from same china IP
You have to update the openfire 4.7.5 , as the previous versions have some glitches, and there are multiple users has been created with admin access. and you will see random plugins installed in your Openfire.
My openfire server got hacked too. I had 3 plugins with hash names and new users with admin access. I deleted the foreign user, the names in admin console and all plugins I didn’t install. I updated to 4.7.5 and everything seemed to be okay. Portrouting to 9091 was stoped, 9090 I never had.
A day later, I was locked out of the administrator console myself. So I had no choice but to uninstall the server and purge it.
I still have the database, but I don’t know if it is compromised and how to clean it so that I only have the desired users again. Or do I have to do everything from scratch?
I’m sorry to hear that, Frank. It’s sadly nearly impossible to tell what a malicious user might have done to your system after they acquired access. Typically, this is relatively benign (they typically install crypto miners), but strictly speaking, they would have had opportunity to access most resources on the host. Obviously, the installation of ransomware, as described in this topic, is very troubling, but if you still have access to your files, that probably has not happened to you.
The database itself should not hold much compromisable material, apart from user accounts with credentials that are now known to the outside world. You can relatively easy identify them in a database dump. Furthermore, by adding firewalls, you can limit access to the admin console. When you have cleaned up all installed malware, having updated to the latest version of Openfire should prevent malicious users to upload new malware through Openfire.
From a security perspective, I’d recommend starting over: re-install the host or replace it with a fresh virtual machine, and install Openfire from scratch. You could, however, consider re-using a curated copy of your database to re-populate your new instance.
Openfire was installed on ubuntu server. The ubuntu server is not compromised. It is just a hack on openfire inside. I have database backup from start. It was only a familiy chat.
How can i prevent users from creating a new account via xmpp?
Through the hacked Openfire server, the will have had access to the entire host.
Typically, regular users cannot create accounts in Openfire, unless the In-Band Registration feature is enabled. In modern versions of Openfire, this is disabled by default. You can configure this feature in the Admin Console.
I recommend that Frank instead scan for malware, update Openfire, reset passwords, enable 2FA, restrict access, and implement a firewall. If needed, he should consult with a security professional.