4 ms·

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 abil

by schoen 7y ago

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 7y ago
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 7y ago
  > 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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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.
      - staticassertion 7y ago
        That's not really something I expect from an attacker at all.

by schoen 7y ago

staticassertion 7y ago

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 7y ago
> 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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
    - staticassertion 7y ago
      That's not really something I expect from an attacker at all.