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.

There has been some research done on this particular anonymous newsgroup.

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

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

Author here.

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

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.

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

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.

The history actually goes back quite a bit further.

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

he was more specific, but I (a) don't remember the name off the top of my head, and (b) don't think it is beneficial to put them on blast. It isn't their fault they got hacked 20 years ago.

No. The CVS exploit was widely shared, particularly after lorian found and killed the bug.

What is there to say about the hack? Like everything back then it was probably accomplished by exploiting trust relationships. I can ask him, but it is not at interesting 20 years later.

this.

the hacker. I interviewed the sysadmins about it.

Am I missing something? That seems to link to a Linux backdoor, not a backdoor in Linux.

I have the full story on that incident. It is actually really funny.

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

It didn’t exist when I wrote this.

The original date for this is actually 2004. Maybe 2003, but I can’t find an archival link.

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

It is actually from 2004. :)

I invented it, as far as I know. There was no publicly available code on doing this and so I wrote it.

I’m not sure what the terminology is these days, but I called it userland exec() because it was an implementation of execve in userland…

I wrote it in, 2003 or 2004? I can’t find an original link anymore, but I posted it to bugtraq the week after I finished it.

What they’re talking about is called “apparent cover.” That is, a cover story which you don’t have to tell anyone, they make it up in their head from the clues you provide.

For example, if you see someone at dawn on the docks with a tackle box, a fishing pole, and dressed for fishing, you don’t think “spy come to take photos of ships.”

Providing a plausible identity is a good practice for hiding your identity.

I wouldn’t suggest the AI face though. Firstly, it makes the face picture unique in that you can’t (currently) get other pictures of the same “person.” If you have a single picture of yourself it looks weird. Facebook without any pictures? Instagram with nothing? No other pictures of yourself, ever? Definitely weird. Better to just avoid it and use the plausible identity as a layer behind your online handle. Then use an avatar, but don’t hide your name. George Howell, aka “17forty” ‘from college, when I used to drink a lot of 40s, 17 was my personal best lol. Just dumb stuff.’

It used to be worse under Pierre. His personal mission in life was to make sure no one dodgy ever got a license and to hunt down every possible source of a cracked copy. My manager had purchased a license for me because it was cheap enough that he could approve it… a year later I tried to renew by emailing Pierre about it. He never replied, instead he contacted my manager to tell him that the license was being pirated and blah blah blah. Was very annoying to sort out.

Related. Here is a good lecture on project modul, the initial work looking at sound propagation in the atmosphere.

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

Creating a long fake is riskier than a short fake. Making mistakes is a risk, and so the more content the more risk.

As for the “reality” of working as an analyst in FSB it seems pretty accurate. Even if not true, it carries a certain truth.

The general analysis is consistent with what most people I’ve spoken with think. Russia is in a bad spot. They need to turn the narrative on Ukraine (one idea we thought of was a dirty bomb from waste)… I don’t think the content can prove it is authentic or not. Maybe when the author is found an punished we’ll hear about it.

The intelligence war has been amazing. The early game of leaking operational plans was incredible. To say “we have so much access we can burn it with abandon” is a huge flex.

The real time intelligence enabling the Ukrainians to respond precisely has also been incredible. From OSINT analysis to the OSINT crowd sourced collection using geolocation tagged videos and photos. Truly a new operational environment for an army to fight in.

Then all the perception management. Truly remarkable achievement. This will be in the textbooks as a case study, if… you know, we make to a point where we still have textbooks