Quoting Robert Lewis (bob.l...@gmail.com
Since most folks here have seen my analyses of "malware" articles from
the IT press before, y'all know the first question:
1. How does the code get executed?
1a. (Where applicable:) How does process authority then
escalate to system authority?
Why does question 1 matter? Because code that doesn't execute (on some
host) is code that is inert. So, "infecting" a host necessitates some
means of causing that code to be run. No execution, no activity.
So, let's see what we have, here. Researcher calls it "Shikitega".
Nope. Nothing. It's magic. (Actually, the implication is that this is
not an attack tool as such, as in, it is something executed _after_
the intruder gets access via other means entirely. Again, this matters
if you are the sysadmin who wants to avoid having your system get
haxx0red: You want to know how the bad guys _get in_, to make sure they
cannot do so. _That_ is actual security thinking.)
On the other hand, there is some mildly interesting stuff on question
1a (privilege escalation):
To maximize its control over the compromised device, Shikitega
exploits two critical escalation of privileges vulnerabilities that give
full root access. One bug, tracked as CVE-2021-4034 and colloquially
known as PwnKit, lurked in the Linux kernel for 12 years until it was
discovered early this year. The other vulnerability is tracked as
CVE-2021-3493 and came to light in April 2021. While both
vulnerabilities have received patches, the fixes may not be widely
installed, particularly on IoT devices.
So, don't fail to apply patches to old bugs.
_Or_, run a configuration that doesn't include the buggy code.
CVE-2021-4034: Contrary to what the ArsTechnica author said, this
was _not_ a bug in the Linux kernel, but rather in one of
Freedesktop.org's notoriously bug-ridden "desktop" support programs,
PolKit (previously named PolicyKit). PolKit is a Freedesktop.org
facility for managing privilege for Unix processes -- an example of the
Freedesktop.org people (GNOME, etc.) re-inventing the wheel, since
Unix already had perfectly serviceable means for managing privilege in
the form of ownership/groups and rights masks.
Anyway, various parts of PolKit was kind of cruddy bugware, and probably
still are. In this case, a piece of PolKit called pkexec, a tool to
allow users to run processes with elevated privilege, had since 2009 a
memory-corruption vulnerability that let anyone trivially escalate
privileges all the way to root -- an ignominious security failure
discovered by researchers in 2021.
CVE-2021-3493: Unlike the other one, this is actually _was_ in an
(optional) part of the Linux kernel called overlayfs, a kernel module
that allows the system to combine several mount points into one so that
one can access all the files from each within one directory structure --
used rarely in some Linux distributions in some specialised roles such
as having a read-only root file system, and another partition
“overlayed” with that to allow applications to write to a temporary file
system. The reported vulnerability reportedly affected _only_ Ubuntu,
because only Ubuntu (18.04) installed/activated it by default. The
problem was that overlayfs didn't properly validate user namespaces and
the setting of file capabilities on files in an underlying system. Due
to the combination of unprivileged user namespaces and a patch carried
in the Ubuntu kernel to allow unprivileged overlay mounts. An attacker
could then use this to gain elevated privileges.
Note that, if your system didn't have overlayfs activated, it would not
be possible to exploit the buggy code. The bug was found in April 2021,
and the kernel was immediately fixed. Therefore, even a vulnerable
system (an Ubuntu 18.04 one) remained so only if you (1) left overlayfs
enabled, and (2) failed to apply security fixes.
Notice what the ArsTechnica writer said:
While both vulnerabilities have received patches, the fixes may
not be widely installed, particularly on IoT devices.
In other words, if you're running buggy distro code and failing to
maintain it, you are likely to get bitten. Which is, like: yeah?
So, Don't Do That, Then.
To sum up, then:
This new one-day wonder "Shikitega" is a post-attack tool. I.e., it is
_not_ something that penetrates systems and somehow gets automagically
run, but rather something an attacker, or an attacker's software
toolkit, runs _after_ entering a system via other means entirely.
As always, the mischief that can be done by a grunt user on a Unix
system is per-se limited by the fact that users do not (or should not)
walk around yielding system (root) privilege at the drop of a hat, and
thus nor their processes. "Shikitega", however, has a bag of tricks,
that it tries _if_ run, to see if root privilege can be stolen by
attacking bugs in two security-sensitive things, PolKit bugware from
Freedesktop.org, and an optional overlay filesystem. If it cannot
exploit bugs in those areas, the amount of its possible mischief is
1. Those two vital questions about "malware", and
2. The fact that, if you let a process get run with your user
authority, it can do any damage you can do, so, if that happens,
it's basically on you, so watch what you run.