Living Off the Land in Linux | Hacker News Reader

Living Off the Land in Linux

gtfobins.github.io

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/

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

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.

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

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

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

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.

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

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?

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.

That's not really something I expect from an attacker at all.

Agreed. What's actually interesting (and more of a fun experiment) is exploiting and doing something useful with an embedded device running Busybox without persistent storage and a stripped down kernel.

on the other hand you can push docker images with typos from popular ones. harder to target specific targets, but sure to get a good volume.

this list is great.

Of course they're not exploits. They're escalation techniques. Suppose you find a way to get yum executed, maybe through some automated devops tooling. This is a way to parlay that into root access.

https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

But i remember a machine managed by another organisation entirely still whitelisting me to do sudo service invocations. Apparently i could have gotten root on that machine.

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.

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/

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.

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

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.

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)

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

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

"Living off the land" is a technique used by attackers to evade detection. It's easy to monitor for new binaries, or unsigned ones. It's harder to monitor for legitimate binaries that are generally used in your environmet - it requires extra context to determine "is this suspicious".

None of these programs are exploitable, they are useful to attackers. This is great for me, as someone whose job it is to protect a network - I can start thinking about how I can monitor these binaries.

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

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.

Ah I see what they mean now; thanks!

Thing is, with sudo you can limit which commands you're able to run. i.e.: regular users can run `sudo` but just the `mount` binary, because they're expected to mount stuff that's not on the fstab (whatever).

That can look safe at first glance, but then you can exploit that binaries to get some other unexpected results:

Change your mount binary for a privileged shell: sudo mount -o bind /bin/sh /bin/mount

Run a privileged shell from inside vim: sudo vi -c ':!/bin/sh' /dev/null

And so on...

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.

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.

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

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

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

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.

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

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.

Reply on news.ycombinator.com