For example, the first "issue" for yum 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: 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?
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 LOLBAS github has good definitions:
> 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.
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?
python -c 'import os; os.mknod("/tmp/yow", 0060000, 2048); os.chmod("/tmp/yow", 0777)'
this list is great.
This one surprised me, though: https://gtfobins.github.io/gtfobins/whois/
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.
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.
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)
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.
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.
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...
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).