Metasploit-framework: Feature Request - In-memory elf execution

[mubix]

Found this a few weeks ago and thought that it would be some cool additions to Metasploit's functionality

• https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html

It's written in perl but not perl dependent. I'm probably not the best to try to attempt integrating this but I bet there are Nix people out there that would jump at this.

[mubix]

I see this being really useful for local exploit execution where compiling might not be possible or steal is something that would be nice to have. As well as maybe a lazy loader for web_delivery, or a shell script generator that would write linux/meterpreter into memory from a .sh like we have for sct and powershell files.

[wvu-r7]

This has been on my want-to-do list for a bit! I'm sure @busterb and @acammack-r7 would love to work on it, too.

[wvu-r7]

Here's another: https://0x00sec.org/t/super-stealthy-droppers/3715. Also have been toying with https://github.com/XiphosResearch/netelf.

[acammack-r7]

Does this evade anything vs. dropping in /tmp or /dev/shm? I don't think it helps when those places are marked noexec since /proc usually inherits those permissions, and just _having_ a memfd entry in /proc is pretty sketchy (recent pulseaudio seems to use it, but nothing else on my boxes). I guess it could work as a way of pivoting out of a scripting language with syscall support (Ruby, Python, Perl, etc.) in an environment with filesystem crawlers that don't know about memfd_create(2), but is this the best way to get around that?

For in-memory execution I think we would be better off expanding the work we have in mettle leveraging musl/static PIE for process replacement. You do need an unrestricted jump in addition to the syscalls, ptracing optional if you want migration or to makeARGV[0] and the memory maps look super benign. Both Python's ctypes and Ruby's fiddle can be convinced to run code from a memory address, and who knows what XS can do. It would require a special toolchain (which we already build) but all the binaries would be static so target support gets easier. If we had a version of netelf but with the mettle intermediate stager code, for example, we could do the same thing but without the memfd_create(2) or execve(2) syscalls. We would need to cleanup the rwx memory bits to be stealthy, but it's only there since it was convenient to write the shellcode that way.

[acammack-r7]

It also just occurred to me while talking with @wvu-r7 that since the libc on Linux boxes is also going to be static and PIE, we can invoke it directly and pass in the executable we want to run (possibly with modified shellcode to set up a more plausible initial stack). In fact, if my reading of the musl source is right[1], we can even load our own remote binaries in memory to pass them to ld-linux.so in addition to being able to pass a file name.

[1] Other implementations on Linux presumably have the same capabilities since they all work, musl is just easier to read. https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1498

[fsacer]

something dropped for this https://github.com/fbkcs/msf-elf-in-memory-execution

[bcoles]

Blog post associated with the above repo: https://blog.fbkcs.ru/en/elf-in-memory-execution/

[timwr]

@fbkcs is there a reason you didn't send us a pull request? Great work!

[github-actions[bot]]

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.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[acammack-r7]

mettle uses libreflect now to work correctly with execute -m now, so I think this can be closed. The results of my research can be seen in https://blog.rapid7.com/2019/01/03/santas-elfs-running-linux-executables-without-execve/. Thanks for the push @mubix!