“Deanonymising alt anonymous messages”

https://www.youtube.com/watch?v=l5JBMyxvuH8

The accompanying blog post is here:

https://ritter.vg/blog-deanonymizing_amm.html

The inherent security of the technique is actually quite strong. The tooling is terrible and many other problems exist with AAM, but in general the idea of having a shared “inbox” is good for anonymity. There is no way to tell which message is intended for whom. Receiving messages is unlinked, which is obviously good for anonymity. Sending requires a different set of technologies to ensure that the message delivery is unlinked. Tor solves part of this problem.

AAM had serious limitations. Things fall down a bit with the underlying technology for newsgroups and PGP and so on not being designed for anonymity, “fail closed” security, or ease of use (and difficulty of misuse).

A bespoke system could work, but the limiting factor is selecting an “inbox” that is widely distributed and heavily used (the anonymity is directly correlated to how many people access the inbox/inbox container.)

# Case Study: YardBird’s group (mostly) escapes arrest

A similar method for secrecy was used by a CSAM group. It was penetrated by the police when they arrested a member who turned informant to reduce his sentence. The police monitored the group from inside for months (I remember it being over a year). Despite having complete access to all the communications and technical surveillance data and international cooperation between police forces, the majority of the group evaded arrest.

There was a set of operating rules that the group followed and everyone who did so escaped the net. I wrote about it in 2013 if anyone is interested in digging deeper into the story.

https://grugq.github.io/blog/2013/12/01/yardbirds-effective-...

— George Washington.

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.

The context of this post is somewhat important. It is a direct response to a post titled: Symbiote Deep-Dive: Analysis of a New, Nearly-Impossible-to-Detect Linux Threat

Userland rootkits are not “nearly-impossible-to-detect.” They are not novel, they are not impossible to detect, and they are not the pinnacle of hacker techniques.

I felt that it was worth pointing out that the history of userland rootkits goes back a ways and that they were very easy to detect because they rely on proxying all access to the system. If you bypass the hook they use to enter their proxy, they you evade them entirely.

Forensic and incident response guides used to advise using static linked binaries for exactly this reason. There are guides from the 1990s telling people to do this because userland rootkits were an issue (before kernel rootkits everyone used userland rootkits.)

Here is an example from 2013 which points out that you can’t trust any binaries/libraries on the potentially compromised machine and should use statically linked tools. [0]

LD_PRELOAD rootkits are not new and they are not nearly-impossible-to-detect to detect. My post listed a number of ways to detect them, all of which have been known for decades.

[0] https://www.forensicfocus.com/forums/general/trusted-static-...

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())

"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."

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.

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.

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.

Exactly 20 years ago I wrote and released userland exec().

https://seclists.org/bugtraq/2004/Jan/2

Good to see that the technique is still viable after two decades.

On a related note, this sort of issue (difficulty researching the origins of techniques, and hacking history in general) is a problem that will only get worse. As a community we haven’t created an institutional memory beyond “the oldest hacker you know.”

If the guy who did it wants to come forward, that is his decision. [edit: I won't name names.]

He did provided me the full story. He told me with the understanding that the story would go public, so I will dig it up and post it.

I also interviewed the sysadmins who were running the box at the time.

1. it was not an NSA operation, it was done by a hacker.

2. it was discovered by accident, not because of clever due diligence.

Basically, there was a developer who had a flakey connection and one time his commits didn't go through. To detect this in future he had a script that would download the entire tree from the server and compare it against his local copy to make sure that his changes had been committed.

It was discovered because of the discrepancy between his local working copy and the upstream copy. Which was checked not for security reasons, but because sometimes the two were out of sync. That's all. Just dumb luck.

The sysadmins are still quite bitter about it. I know how it feels when your box is hacked and you really take it personally.

The code wasn't added by hacking the CVS, as far as I remember, but rather through a hacked developer with commit rights.

that's the story as I was told

I wrote the code because someone asked how to do this and it was easier to implement it than to explain it in detail. The whole thing is based on what I learned from “Linkers & Loaders,” a great book. (I still have my copy)

Later that year I wrote a wrapper around ul_exec() that used an automated interactive session with gdb to load a process, replace it with another binary (delivered over STDIN) and then execute that. This would prevent the binary ever being written to disk.

Remote exec was documented in phrack 62, along with the more advanced theory of counter forensics. Interestingly, the techniques I discussed in rexec() are now common APT tradecraft. Using common tools to limit the chance of detection and reduce evidence, aka living off the land, is now standard practice. I explained why about 20 years ago :)

http://phrack.org/issues/62/8.html

It seems easier to load the whole issue from here: https://www.exploit-db.com/exploits/42873