Hacker News Reader

Comment by kelnos | Hacker News Reader

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/

View on HN

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.

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

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.

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.

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.

Reply on news.ycombinator.com