ditatompel/insights
1
0
Fork 0
mirror of https://github.com/ditatompel/insights.git synced 2025-01-08 03:12:06 +07:00
Code Issues Projects Releases Packages Wiki Activity
insights/content/blog/compromised-zimbra-server-running-zmcat-dblaunchs-malware/index.md

4.5 KiB
Raw Permalink Blame History

title description date lastmod draft noindex featured pinned series categories tags images authors
Compromised Zimbra Server Running zmcat dblaunchs Malware 100% CPU Usage Recent Zimbra XXE / SSRF Vulnerability Disclosure (CVE-2019-9670) being actively exploited and could allow an attacker to RCE on an affected Zimbra system. 2019-05-02T00:21:28+07:00 false false false false
Security
Zimbra
Monero
ditatompel

Recent Zimbra XXE/SSRF Vulnerability Disclosure (CVE-2019-9670) being actively exploited. Security researcher An Trinh details his findings regarding a vulnerability which, if exploited, could allow an attacker to RCE on an affected Zimbra system.

Every time before I'm going to sleep, I always take the time to check my servers status. This morning it seems strange that one of my servers uses 100% of its CPU resources. Suspicious that something happened, I immediately login to my client box (which run Zimbra mail server on it).

The results of observations via the top command indicate that a process with the name "dblaunchs" runs as Zimbra user. Trying to trace system calls and signals of dblaunchs pid give me this: (TL;DR)

connect(11, {sa_family=AF_INET, sin_port=htons(3333), sin_addr=inet_addr("178.xxx.xxx.xxx")}, 16) = -1 EINPROGRESS (Ope
ration now in progress)
epoll_ctl(0, EPOLL_CTL_ADD, 11, {EPOLLOUT, {u32=11, u64=11}}) = 0
epoll_pwait(0, [], 1024, 13, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=11, u64=11}}], 1024, 485, NULL, 8) = 1
getsockopt(11, SOL_SOCKET, SO_ERROR, [111], [4]) = 0
epoll_ctl(0, EPOLL_CTL_DEL, 11, 0x7ffe55873630) = 0

The executable appears to be a Monero (XMR) CPU miner to 178.xxx.xxx.xxx:3333. I tried to find information from the Zimbra community forum and found that security vulnerability affected to many Zimbra versions.

Looking forward to recent trace_log on my client box, I found many suspicious activities, 1 of them refer to /opt/zimbra/jetty/webapps/zimbra/downloads/zimbrapi.jsp.

06:52:33.050:qtp1632392469-180511:https:https://xxx.xxx.xxx.xxx/downloads/zimbrapi.jsp REQUEST xxx.xxx.xxx... GET ZM_ADMIN_AUTH_TOKEN=0_f68b374c4422929086e4370effdbe65e6edc7a7e_69643d33363a65306661666438392d313336302d313164392d383636312d3030306139356439386566323b6578703d31333a313535363739373934353938313b61646d696e3d313a313b747970653d363a7a696d6272613b753d313a613b7469643d393a3736363134303533303b;; python-requests/2.21.0

stat /opt/zimbra/jetty/webapps/zimbra/downloads/zimbrapi.jsp
  File: ‘/opt/zimbra/jetty/webapps/zimbra/downloads/zimbrapi.jsp’
  Size: 387       	Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d	Inode: 1073271     Links: 1
Access: (0640/-rw-r-----)  Uid: (  997/  zimbra)   Gid: (  995/  zimbra)
Access: 2019-05-02 05:16:12.241540485 +0700
Modify: 2019-05-02 03:18:55.562222325 +0700
Change: 2019-05-02 05:26:43.440431393 +0700
 Birth: -

The zimbrapi.jsp file is executing base64 encoded bash script from the remote server and run miner executable file. The main purpose of this script is to download miner executable file with a variation between 32 and 64 bit arch, and ensure the script itself and the executable is always running.

It’s not easy to schedule a downtime for my client, temporary solution in short time which can help me gain time until downtime schedule is approved is block the bots crawler and suspicious IP addresses, but it’s very trivial and might be ineffective.

Reference: