grugq

Bulk reply to all the people replying.

bink is correct. The people who buy exploits are governments. There is very little interest in Wordpress or indeed any target that isn't a browser or a mobile. Browsers and mobiles are the only things that are perennially useful to an intelligence agency. Those two are reliable access vectors for the vast majority of things that interest government organisations.

this is the most accurate summary.

> Even minutiae should have a place in our collection, for things of a seemingly trifling nature, when enjoined with others of a more serious cast, may lead to valuable conclusion.

— George Washington.

In retrospect I really should have included the title with the link.

And you can detect when you are being ptrace()d because a process cannot be ptrace()d twice. Unless they changed Linux again.

There are also timing issues that show up, and you can do any number of anti-debugging tricks which would reveal that the environment is being manipulated. Which is an instant red flag.

In general if the attacker is running at the same privilege level, you can probably evade it or at least detect it. I’m somewhat surprised there isn’t a basic forensics tool that automates all of these tests already.

“sus: [-h] [-v] [-V] [-o file] [-O format]

Sus tests for common indicators of compromise using on generic tests for common methods of implementing userland rootkits. It will check for LD_PRELOAD, ptrace(), inotify() and verify the system binaries match the upstream distribution hashsums. It can be used to dump the file system directly (warning, slow!) for comparison against the output of `find`. See EXAMPLES for more.”

Implementation is left as an exercise for the reader.

Bringing your own static linked busybox will still evade that rootkit.

If the attacker has modified the environment to present a specific view of system state, bringing your own environment defeats it.

There are tricks which are better than modifying things to hide. For example, there is a race condition between opendir() and readdir() which you can win by using inotify(). Then you can unlink() whatever, wait a while, then link() it back in. During that time it will be deleted and thus invisible to any detection. (I saw a demo of this 12 years ago, so I might be misremembering a bit. I know it used inotify() and unlink())

"Prabhakar Raghavan is killing Google"

"Google's Death from Within: Prabhakar Raghavan"

"Blame Prabhakar Raghavan for Google's Crappy Search"

"Google Sucks. Because of Prabhakar Raghavan"

"Prabhakar Raghavan is the man killing Google Search."

"Yahoo Search Killer Prabhakar Raghavan Turns Death Ray on Google"

"Prabhakar Raghavan and the no good very bad Google search."

Oh, it’s far far worse than that. Just the core operation would be:

open() — network round trip fstat() — network round trip brk() — network round trip read() — network round trip Shuffle data over network read() — network round trip Shuffle data over network

Etc etc

For a “grep root /etc/passwd” there are 88 syscalls on a Debian 11. If we assume a very generous 50ms latency for every syscall, that means we’re waiting 4.4s for the result.

The use case for syscall proxying is limited to when you don’t want to upload an exploit onto a target machine, but you need to run the exploit on that machine. So it could be an LPE or something.

It is way too slow for post exploitation work.

Merry OPSEC, and a happy OPSEC Year!

Yup, probably the more robust approach.

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.