On 7/12/25 22:42, Robert J. Hansen wrote:
Both *should* be of concern, since a targeted attacker could
certainly use "drive-by" techniques, both to evade detection and
possibly your defenses, if you are so focused on targeted attacks
that you miss something.
Jacob, please don't tell me what should be of personal and
professional concern to me.
You don't know what my risk environment is. For all you know I'm part
of a security operations center at their APT desk, and the drive-bys
are handled by a different unit. All I said is: my area of personal
and professional interest is in targeted attacks by people who know
what they're doing.
Fair enough; my experience has all been on smaller scales. I have never
had "a different unit" that handled some of the problem. That must be
nice...
That said: yes, professionals and amateurs can run the same exploits.
*Why* they are running the exploits, and their long-term goals in
running the exploits, will differ.
I'm having a hard time thinking of something that would justify a
targeted attacker doing a low-skill smash and grab without
persistence. If the haul is valuable enough to justify that, then
isn't it also enough to do the job *well*, including keeping it under
the radar and persisting?
Persistence and evading detection are a tradeoff for the attacker.
Further, Mallory may not have the goals you assume. If Mallory is a
professional, making the attack look like a low-skill smash and grab
could, for example, be a strategy to avoid raising alarm at the targets
that they *are* targets.
If Mallory only wants a smash-and-grab...
Professional Mallory doesn't want a smash-and-grab.
Professional Mallory wants a haul. There's some trove of data that
justifies the time, resources, and expense of Professional Mallory. If
Professional Mallory has any choice in how to gain access,
Professional Mallory will persist the access: because if this box has
a top-flight haul today, who knows what it will have in six months?
Logically, the box is most likely to have about the same, except that a
second copy of the same haul is valueless to Mallory. Assuming Mallory
is *not* trying to make a splash, keeping as quiet as possible reduces
the chance of the victim realizing that tighter security is needed.
In short, there is no amount of persistence that can save Mallory's
access once the target becomes aware of it and gets serious about
kicking Mallory out.
I agree that many attackers still do not seem to understand this
issue---the xz backdoor was discovered in part because of "Jia Tan"
poorly balancing this tradeoff---but the attackers who *do* understand
it are the ones I most worry about, precisely because of views like the
one you are stating that assume they do not exist.
Professional Mallory persists. Count on it.
That depends on the expected reliability of Professional Mallory's
initial access. (unless Mallory is really stupid...)
If Mallory expects to get back in just as easily six months from now,
why leave something that an attentive admin might notice (like "why are
there two 'syslogd' files in /sbin?" or "why is /sbin/hwclock so
small?") if that can be avoided because the Web app is a security
dumpster fire running on a years-obsolete CakePHP version?
(Those are actual examples from years ago at a past $WORK that is no
longer in business, by the way. The second "syslogd" was actually
'syslogd ' (note the space) and hwclock had been replaced with a shell
script that launched a back door before running the real hwclock that
had been hidden in /lib and disguised as a shared object.)
Client exploits typically do *not* produce log entries in the first
place, so there is nothing to clean up.
Consider the simplest form of drive-by, the stolen credential. Are you
telling me Mallory's connection and exfiltration aren't going to
appear in SFTP logs? Or that these logs don't need scrubbing?
Clients keep SFTP logs? Are you assuming that Mallory steals the user's
password and then connects to sshd on the user's box to make off with
the user's files? I would be more concerned about Mallory "cutting out
the middleman" and simply making off with the user's files instead of
bothering to leave an initial keylogger.
(I am also not considering the case where the user is tricked into
putting their system login credentials into a phishing page,
admittedly. I have never had to support users who were that naive.)
I have been talking about attacks on clients, not servers, because GnuPG
is most typically run on client nodes. Indeed, as far as I know, the
PGP security model is focused on clients---the boxes physically used by
the users. Servers are categorically untrusted in PGP.
-- Jacob
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
