3 ms·

Hah! I was just referencing this paper the other day when mucking with the linker for an unrelated reason. I probably should have chosen a better name for my ar

by joe_v 3y ago

Hah! I was just referencing this paper the other day when mucking with the linker for an unrelated reason. I probably should have chosen a better name for my article - I am trying to cover the cases of "you have Linux command execution, how do you run native code?" as opposed to your approach which as I understand is more: "you are running native code, how can you load a separate ELF in-process?" Agreed about institutional memory; zines/blogs are very important; but at the end of the day I usually end up just asking in some corner of IRC.

codethief 3y ago
> "you have Linux command execution, how do you run native code?" I was going to ask you what the precise situation is in which you'd apply the ideas from the blog post as I don't know what exactly is meant by "process injection". I think the article would benefit from providing a little bit more background for us non-hackers / non-pentesters. Still, very interesting article – thank you! PS: The article says > you need a writable location on disk; this is not always true in e.g. read-only chroots, filesystems, containers, etc Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it?
- joe_v 3y ago
  Apologies it's a little scattered. Roughly it's about dealing with situations where you can execute a command but now want to run a native executable, and how much noise such a thing will make in the presence of monitoring. > Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it? It all depends on how your environment is set up: whether a tmpfs or shm device is mounted and writable by your user is up to the admin. For example, on many embedded devices you often want to avoid writes to prevent any sort of filesystem wear, or because you have a write-once media like a ROM; so the whole fs will be mounted readonly. With chroots it's best practice to provide a minimal environment - unless tempfiles are needed there will usually not be a /tmp. Try `docker run --read-only -ti ubuntu bash` as another example: ``` root@9302f159e0e0:/tmp# touch a touch: cannot touch 'a': Read-only file system ```
  - codethief 3y ago
    My apologies for the delay, Joe, I was on vacation. Now that I'm home, I gave this a try but at least on my machine writing to /dev/shm/ works as I remembered, even with --read-only: $ docker run --read-only -ti ubuntu bash root@3dfdab770505:/# echo "bar" > /dev/shm/foo root@3dfdab770505:/# cat /dev/shm/foo bar So, again, couldn't you just write your binary to /dev/shm and execute it?
    - infotogivenm 3y ago
      It is fairly common to have noexec on /dev/shm; filesystem configurations are always up to the admin so they could feasibly set anything.
      - codethief 3y ago
        Thanks for reminding me of noexec; I'm no Linux security expert by any means, so I was merely trying to figure out what's possible and what's not. It looks like mounting /dev/shm with noexec is not that common, though, is it? See e.g. https://unix.stackexchange.com/questions/670362/mounting-dev-shm-with-noexec https://unix.stackexchange.com/questions/670362/mounting-dev... More generally, it regularly blows my mind how hard it is to harden a Linux installation, and how many pitfalls and caveats there are.
grugq 3y ago
Ah, so, in 2005 I wrote about that when I implemented rexec() — remote exec() — which takes a binary and then copies it over an arbitrary text only link (like ssh) and executes it completely in memory without touching disk. http://phrack.org/issues/62/8.html http://phrack.org/issues/62/8.html The idea was that if you have access to a box via a shell and you want to run your own binary without leaving evidence behind, you’d use rexec() to do that.
- joe_v 3y ago
  That is a really useful implementation and a good way to use gdb to "live off the land". It is interesting how ops changes like moving to containers/VMs affect pentesting techniques; over the last decade I find myself relying less and less on live-off-the-land in a lot of engagements. When you can use them though they have a lot of advantages. Also never realized that others have implemented (and I guess patented?) syscall proxying, I have heard that idea discussed before for offensive tooling and wondered how well it works in practice.
  - grugq 3y ago
    Syscall proxying was very old even when I wrote that article. The problem with syscall proxying is that it is slow. Take any process and imagine adding network latency to every single syscall. On a local network is incredibly slow, but over any sort of real distance it is just impossible. That’s why I pushed everything to the target system. Run it local as much as possible. Back then there were no containers or VMs to use. These days I think you should be bringing your environment with you. Unless there are serious reasons not to.
    - joe_v 3y ago
      That makes sense, something like `grep $USER /etc/passwd` would shuffle the whole passwd file over the wire, etc; for a lot of post-exploitation stuff I could see it causing more trouble than it's worth.
      - 3y ago

by joe_v 3y ago

codethief 3y ago

> "you have Linux command execution, how do you run native code?" I was going to ask you what the precise situation is in which you'd apply the ideas from the blog post as I don't know what exactly is meant by "process injection". I think the article would benefit from providing a little bit more background for us non-hackers / non-pentesters. Still, very interesting article – thank you! PS: The article says > you need a writable location on disk; this is not always true in e.g. read-only chroots, filesystems, containers, etc Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it?

joe_v 3y ago
Apologies it's a little scattered. Roughly it's about dealing with situations where you can execute a command but now want to run a native executable, and how much noise such a thing will make in the presence of monitoring. > Couldn't you create a temporary file in-memory (e.g. in /dev/shm or in some tmpfs), make it executable (+x) and then execute it? It all depends on how your environment is set up: whether a tmpfs or shm device is mounted and writable by your user is up to the admin. For example, on many embedded devices you often want to avoid writes to prevent any sort of filesystem wear, or because you have a write-once media like a ROM; so the whole fs will be mounted readonly. With chroots it's best practice to provide a minimal environment - unless tempfiles are needed there will usually not be a /tmp. Try `docker run --read-only -ti ubuntu bash` as another example: ``` root@9302f159e0e0:/tmp# touch a touch: cannot touch 'a': Read-only file system ```
- codethief 3y ago
  My apologies for the delay, Joe, I was on vacation. Now that I'm home, I gave this a try but at least on my machine writing to /dev/shm/ works as I remembered, even with --read-only: $ docker run --read-only -ti ubuntu bash root@3dfdab770505:/# echo "bar" > /dev/shm/foo root@3dfdab770505:/# cat /dev/shm/foo bar So, again, couldn't you just write your binary to /dev/shm and execute it?
  - infotogivenm 3y ago
    It is fairly common to have noexec on /dev/shm; filesystem configurations are always up to the admin so they could feasibly set anything.
    - codethief 3y ago
      Thanks for reminding me of noexec; I'm no Linux security expert by any means, so I was merely trying to figure out what's possible and what's not. It looks like mounting /dev/shm with noexec is not that common, though, is it? See e.g. https://unix.stackexchange.com/questions/670362/mounting-dev-shm-with-noexec https://unix.stackexchange.com/questions/670362/mounting-dev... More generally, it regularly blows my mind how hard it is to harden a Linux installation, and how many pitfalls and caveats there are.

grugq 3y ago

Ah, so, in 2005 I wrote about that when I implemented rexec() — remote exec() — which takes a binary and then copies it over an arbitrary text only link (like ssh) and executes it completely in memory without touching disk. http://phrack.org/issues/62/8.html http://phrack.org/issues/62/8.html The idea was that if you have access to a box via a shell and you want to run your own binary without leaving evidence behind, you’d use rexec() to do that.

joe_v 3y ago
That is a really useful implementation and a good way to use gdb to "live off the land". It is interesting how ops changes like moving to containers/VMs affect pentesting techniques; over the last decade I find myself relying less and less on live-off-the-land in a lot of engagements. When you can use them though they have a lot of advantages. Also never realized that others have implemented (and I guess patented?) syscall proxying, I have heard that idea discussed before for offensive tooling and wondered how well it works in practice.
- grugq 3y ago
  Syscall proxying was very old even when I wrote that article. The problem with syscall proxying is that it is slow. Take any process and imagine adding network latency to every single syscall. On a local network is incredibly slow, but over any sort of real distance it is just impossible. That’s why I pushed everything to the target system. Run it local as much as possible. Back then there were no containers or VMs to use. These days I think you should be bringing your environment with you. Unless there are serious reasons not to.
  - joe_v 3y ago
    That makes sense, something like `grep $USER /etc/passwd` would shuffle the whole passwd file over the wire, etc; for a lot of post-exploitation stuff I could see it causing more trouble than it's worth.
    - 3y ago