
Living Off the Land in Linux - DyslexicAtheist
https://gtfobins.github.io/
======
kelnos
I find a lot of these to be really contrived and not actually exploits.

For example, the first "issue" for yum[0] shows that you can create a RPM that
will run arbitrary commands when installed, and then shows the example install
command, which requires root access. So, sure, if someone tricks you into
running arbitrary commands as root, you're hosed. I don't find this
particularly novel or interesting.

Then there are several supposed "SUID issues", like the second one for cat[1]:
if you've for some batshit-insane reason decided to mark cat as SUID root (or
ask someone with root access to copy it to your homedir and mark it SUID
root... okay), then people can do nefarious things with it. Um... duh?

[0]
[https://gtfobins.github.io/gtfobins/yum/](https://gtfobins.github.io/gtfobins/yum/)

[1]
[https://gtfobins.github.io/gtfobins/cat/](https://gtfobins.github.io/gtfobins/cat/)

~~~
schoen
I think the intended context for most of these is CTF contest levels in which
you have to break out of a restricted shell. In that context, things like the
ability to run external commands will be a big deal!

But I do think that the SUID marking is confusing, because it seems like most
of these are saying that _if_ a particular program is installed SUID, it would
allow a privilege escalation, without indicating that the program is normally
installed that way (and indeed, most of them are _not_ normally installed that
way).

Edit: probably _all_ of the descriptions of the capabilities you can achieve
with these commands should be edited to start with "if", because they all seem
to be describing circumstances under which the particular tool can be used
with a particular side effect, without a particular implication that it can or
can't be used that way on a stock system.

~~~
staticassertion
The point of LOLBAS is not to identify exploitable programs but to identify
_useful_ programs for attackers. There is no issue of privilege here - if you
are an attacker and you meet the privilege requirements, there you go, you can
do these things.

The LOLBAS github has good definitions:
[https://github.com/api0cradle/LOLBAS](https://github.com/api0cradle/LOLBAS)

> LOLBAS candidates must be present on the system by default or introduced by
> application/software "installation" from a "reputable" vendor or open-source
> entity. Otherwise, LOLBAS determination is subject to scrutiny by the
> (security) community and agreed upon standards.

> Can be used as an attacker tool directly or can perform other actions than
> what it was intended to do (Ex: regsvr32 - execute code from SCT online)

Essentially, what programs on the operating system can an attacker abuse to do
things that a defender will have a hard time monitoring for. The idea is that
"bring your own binary" is dead (it isn't, but that's the idea) because it's
too detectable/ preventable - software whitelisting, detecting unsigned apps,
etc, make it hard. But if you can just leverage what's already on the system
you can avoid detection more easily.

~~~
kelnos
> _There is no issue of privilege here - if you are an attacker and you meet
> the privilege requirements, there you go, you can do these things._

It still doesn't really make sense to me. The SUID examples all show you -- as
root, via sudo -- copying a binary into the current directory, and then
marking it u+s.

If you can do that, then you don't _need_ your new SUID binary... you already
somehow have root access, so you can do whatever you want.

> _But if you can just leverage what 's already on the system you can avoid
> detection more easily._

Outside of a heavily-contrived CTF type situation, what system is going to
have a SUID `cat` lying around? Or really, a SUID anything-that-
isn't-normally-SUID?

~~~
caf
The SUID ones are for cases like _" something you have exploited gives you the
opportunity to execute one command as root; how can you leverage that for
persistent access?"_. So the idea is you make it SUID yourself, which gives
you a partial way back in later.

~~~
jcelerier
but if at some point you were root, you can most certainly install something
in your victim's bootloader which is muuuch more effective

~~~
caf
Not certainly - perhaps there's no device node available to you to open the
device that contains the bootloader, and no mknod to create one?

~~~
schoen
Perhaps then

    
    
      python -c 'import os; os.mknod("/tmp/yow", 0060000, 2048); os.chmod("/tmp/yow", 0777)'
    

But clearly your point is right that a Unix environment could still prevent
someone with root access from accessing the raw disk device, including at the
kernel level.

------
Legogris
I agree most of these are obvious noise, maybe useful for CTF contests where
these scenarios actually happen and you want a dictionary..?

This one surprised me, though:
[https://gtfobins.github.io/gtfobins/whois/](https://gtfobins.github.io/gtfobins/whois/)

~~~
kelnos
I found the whois example interesting from a "huh, didn't realize whois let
you do that" perspective, but... again, found it kinda pointless. If `nc` is
on the box, then you don't need whois to send files around... you can just use
`nc` to do it.

~~~
duckerude
nc is used on the attacker box, not on the box where whois is run.

------
badrabbit
The windows lolbins project is decent as well.

Some suggest these are great for CTFs,but their main use is for defensive
restrictions and monitoring.

Based on these known abusable behaviors of the programs,you can for example
construct auditd rules or selinux/apparmor policies.

And no,these are not exploits or vulnerabilities,they're just ways of
performing post-compromise tasks without having to bring your own malware or
operating within a restricted environment.

------
yalogin
Can someone explain what this list really means? Does it mean that these are
binaries that have vulnerabilities in them that can be exploited? Clicking on
each of them, it just describes what it does in a way but no link to
vulnerabilities of how the binaries could be used to exploit. By that logic a
lot of the binaries on linux fit this list.

~~~
blihp
It's just a list of binaries that have the potential to be used by exploits.
There's nothing inherently wrong with many of the privileges if they are
absolutely necessary to do the job... which often they are unless either
functionality is removed/disabled or the executable or parts of the system
rearchitected.

By keeping track of the potential exposure of such binaries one can 1)
continuously ask the question 'what needs to be done to mitigate/eliminate
these potential attack vectors?' (an example would be the changes to Xorg to
eliminate the need to run with root privileges) and 2) help security conscious
admins keep on top of the risks they are potentially exposing themselves to
when installing/allowing use of said binaries in various situations. (such as
not allowing the use of these binaries in restricted shell scenarios... or at
least being aware of the potential risks and and making an informed decision
vs. inadvertently putting the system at risk)

~~~
Topgamer7
So for example the aria2c application listed. Unless you either have a script
or process that runs it via sudo, or uses chmod +s on it, you're in the clear
(barring other vulns)?

~~~
schoen
An example could be that a user is allowed to run aria2c via sudo in the
/etc/sudoers file (perhaps with certain restrictions described there). If that
user's account is compromised, the attacker could then potentially use the
technique mentioned here to escalate to root or to the user as whom
/etc/sudoers permits aria2c to be run, at least if the sudoers file didn't
forbid the invocation that accomplish the escalation.

One angle you could think about is "if I'm a system administrator writing an
/etc/sudoers file and I want to allow users to do certain tasks, am I then
inadvertently allowing them to do other completely unrelated tasks, perhaps in
an entirely nonintuitive way"?

Edit: a very nice example is
[https://news.ycombinator.com/item?id=20648960](https://news.ycombinator.com/item?id=20648960),
downthread.

------
alexchamberlain
I'm a bit confused by the sudo tag; it seems to imply that commands run with
sudo get elevated privileges... which is kinda the point...

~~~
duckerude
You can give someone permission to run only certain commands with sudo, but
that can be dangerous in non-obvious ways.

As a slightly contrived example, imagine you allow someone to use "apt-get
update" with sudo, reasoning that it only changes a local index and doesn't
alter the system. You don't allow them to use sudo for anything else.

If they run "sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh" they
get a shell that lets them execute any command as root, not just the command
you gave them permission for.

~~~
alexchamberlain
Ah I see what they mean now; thanks!

------
ape4
Normally `date` is just used to display the date. It can set the time or read
a file - but less often. Something like OpenBSD pledge(2) could be used to
limit it after reading the options.

------
newnewpdro
Anyone who thinks it's worth noting that tail can open files as root after
running `sudo chmod +s tail` has no business writing such a document.

~~~
schoen
It feels like the list of programs with this property was autogenerated by a
script from a database field, because they all have the same explanatory text.

So probably the point is that there are _some_ commands for which this is
counterintuitive (really, quite a few are out there), but I imagine that once
they decided to represent the "can read files if run as root" property in the
database, they felt they needed to add this flag even to those commands for
which this is the entire point of the command (like head, tail, cat, or pagers
or editors).

------
GuiA
What is the connection to living off the land? Is it a contrived userland
reference or...?

~~~
forthac
In this context, I believe it is the idea of compromising a system using
nothing but tools/commands available on the target system.

~~~
caf
Which is a reference to the way in which some kinds of military special forces
are trained to operate without the logistics support that regular infantry
rely on.

------
Ocysellus
I'm not sure that this satisfies the general agreed upon definition of
exploits.

------
lidHanteyk
The concept of living off the land is getting to be a big deal; I wonder what
lessons we will learn from developing patterns to counter LOTL designs.

