10 ms·

List of Unix binaries that can be used to bypass local security restrictions

201 points by janisz 3y ago

commandersaki 3y ago
I found this list helpful for clearing the first module of pwn.college.
NoZebra120vClip 3y ago
So if I understand correctly, one of the most common flags is "sudo" and it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. I suppose that's a fundamental design flaw in POSIX setuid operations. Setting real/effective UID/GID in a process is persistent, and tools don't normally keep checking to see whether they have/need elevated privileges, and so this happens. Now I expected this tag to mean something else. I expected there to be a list of tools that are commonly granted to ordinary users in the sudoers configuration, like the operator being able to kick off a backup. For example, "less" has a shell escape, and when running under sudo, it was possible to simply shell out and have an unrestricted root shell. I think that's fixed, but the moral of the story is not to grant sudo access to any tool that has shell escapes or arbitrary command execution.
- Arch-TK 3y ago
  In my experience, if you see * or more rarely ? in a sudo command configuration then there's a good chance there's a problem. I once saw a bunch of systemctl start someprefix* being allowed in a sudoers configuration (likewise for stop). systemctl can start more than one service at a time and the way that the sudoers configuration is checked is by glob matching the concatenated command. If your command is literally: "systemctl" "start" "someprefix" "sshd" this gets concatenated to "systemctl start someprefix sshd" which matches the glob "systemctl start someprefix*".
  - opk 3y ago
    If you want to grant particular systemctl start/stops to normal users, that can be done with policykit,
    - BenjiWiebe 3y ago
      Thanks, I didn't know that!
- deathanatos 3y ago
  > it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged. Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?
  - ElectricalUnion 3y ago
    > Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? The `sudo` tag means, if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.
    - deathanatos 3y ago
      > if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea. It might be a bad idea, but that's not "bypassing local security restrictions", that's explicitly changing the local security restrictions such that that's not a restricted command for the user you're granting it to. If you don't want someone to be able to read any file on the system, no, you shouldn't grant them the ability to run "cat" as root! But "I granted them X" "they ran X" → "they bypassed local security restrictions" is non sequitur.
gumballindie 3y ago
I am not entirely sure what to make of this list. Naturally if a binary or script are given sudo rights then that will elevate privileges, and by default anything should be considered as potentially vulnerable, malicious or misuse-able, particularity tools that can write or read files or execute other binaries or scripts, making this list ... obvious?
- Tepix 3y ago
  No. If you have a program that does a particular task you may be inclined to let users run it with sudo rights. This list shows how these rights can be used to - for example - read arbitrary files and show them to the unprivileged user. The "mail" entry is a good example: https://gtfobins.github.io/gtfobins/mail/ https://gtfobins.github.io/gtfobins/mail/ Did you know you can get a shell easily by letting users use "mail"?
  - mrweasel 3y ago
    I still don't get the issue, that's going to be true for any program you run, unless it explicitly check if it's running using sudo. That however assumes that the program should never run with elevated privileges, which may be equally wrong. Unless a program is designed for a very specific task and should always run as a given user, I'd argue that having it check privileges is both surprising and wrong. It's not the job of the individual programs to check permissions. Edit: I see what you're saying. Having mail being a program that a user is allowed to run with sudo, it basically the equivalent for giving them a sudo access to a shell, because mail can spawn a shell, but with the same privileges as the mail command had.
  - mindwok 3y ago
    The lesson here is just don't rely on sudo to give restricted permissions. I have been a Linux admin for 6 years and never had to do this, and pretty much every use case I've heard of has easily solved with a better method. If you need to give people access to certain files, make a group. If you need them to have certain capabilities of another user, let them switch to that user but not run privileged commands.
hulitu 3y ago
> su Sudo Sudo If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. sudo su So it is su or sudo ? Anyway, this is in the spirit of "to install a linux virus: ./configure; make; sudo make install".
DougBTX 3y ago
There are quite a few comments here questioning why a list like this might exist, the focus should be on this in the intro: > bypass local security restrictions in misconfigured systems. Someone may think that they can give users restricted access, but this is likely not the case as it is easy to misconfigure the system to give full access. That's the takeaway for me: any access is probably all access. A very clean example is `aws help`: an admin may think that allowing a user to run the help command just grants them access to help, but the example shows that the user could then run any command: aws help !/bin/sh https://gtfobins.github.io/gtfobins/aws/ https://gtfobins.github.io/gtfobins/aws/
- wzdd 3y ago
  Still, most of these commands will also have bugs. Even if they didn't have convenient built-in ways to escape a restricted shell, I would not expect that these command-line programs, which weren't built to be run in an adversarial environment, weren't vulnerable to buffer overflows or logic errors. The lesson appears to be that if you want to put users in a restricted environment, don't rely on unaudited unix command-line programs to enforce it. Instead do something at a level below that, such as using a kernel-enforced mechanism. This is also the problem with sudo of course.
mrspuratic 3y ago
The "suid" and "sudo" terms are not the conventional meanings, which to my mind sensationalizes this list, which is otherwise useful. Real "sudo" has "noexec" which (mostly) prevents issues by way of .so injection to override libc exec() functions (see the "awk" sudo issue for example). setuid/setgid are not to be used lightly, the problem isn't with the program if an admin overrides the permissions it gets. This used to be one of the first things I'd run hardening a linux system: find / -type f -a $ \( -user root -a -perm +4000 $ -o $ -group root -a -perm +6000 $ \)
- zokier 3y ago
  > Real "sudo" has "noexec" which (mostly) prevents issues by way of .so injection to override libc exec() functions LD_PRELOAD hacks are ugly though.. seccomp filter would be nicer, but apparently you can't really block execve with seccomp. Best thing I found was to ptrace the child, and inject seccomp policies after startup. That is not exactly pretty either, but what other options are there that would also work with static executables? This whole lkml thread is bit depressing, not because the responses are wrong or bad, but because of the hodge-podge nature of unix prevents any easy solutions to fairly reasonable feature request https://lore.kernel.org/all/202010281500.855B950FE@keescook/T/ https://lore.kernel.org/all/202010281500.855B950FE@keescook/...
  - zokier 3y ago
    > Best thing I found was to ptrace the child, and inject seccomp policies after startup huh, apparently according to sudo manual that is exactly what sudo NOEXEC does
  - jart 3y ago
    You're both half right. The trick is to use LD_PRELOAD to inject a SECCOMP filter. Then you can block execve(). See https://justine.lol/pledge/ https://justine.lol/pledge/ and https://github.com/jart/cosmopolitan/blob/master/tool/build/dso/sandbox.c https://github.com/jart/cosmopolitan/blob/master/tool/build/...
    - 3y ago
oblio 3y ago
I'll start the cognitive dissonance train: Unix is the system where, quoting: "programs do one thing well." :-)))
quench 3y ago
most of the shell exploits are prevented by including NOEXEC: in the sudo permissions. IDK why this is not the default. This prevents the sudoed command from running any other commands
- themerone 3y ago
  This would break most package managers and many other system tools.
- PeterisP 3y ago
  For me, I quite often use sudo to run scripts that install or reconfigure something, and they obviously do need to execute other commands.
TacticalCoder 3y ago
Most of them by very far rely on sudo. I've got a system without sudo. The only way to execute something as root on my system is to log in, using a U2F security key, from a second system (typically a small laptop sitting next to my workstation). That second system is connected to my workstation on a dedicated LAN only used by these two machines. Firewalls on both (for example my workstation only allow SSH in from that one LAN and only from the IP of my laptop on that LAN etc.). The laptop has no Internet access, WiFi disabled (modules prevented from loading, firewall preventing network access, etc.). The laptop's sole purpose is to run command as root on the workstation: it's its sole purpose. The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation. I think no sudo even installed on the machine beats the "never allow root SSH" mantra but YMMV. (to set up the system I install the system offline, from a Debian installation medium whose checksum and signature I've verified, do my thing as root on the workstation, set up the login using U2F from the laptop, then I "lock myself out" from login as root directly at the workstation by entering a password so long I'll never enter it, something like "neverenterthisrootpasswordanymoreusethelaptopu2fkeyinstead#$bey8rUtIopTY6"*. A bit of pain to enter twice but then I'm good to go)
- simonblack 3y ago
  I've got a system without sudo Yes, I hate sudo's unwieldiness too. The very first thing I do after installing one of those distros that default to no-root-login (Ubuntu, Mint, etc) is to give root a password. The downside is that I allow "root SSH", contrarily to every single best practice out there. Why can't you log in via SSH as a 'normal' user, and then "su -" to become root? I use that method, and it obviates both the use of sudo and the allowance of "root SSH".
- tiffanyh 3y ago
  OpenBSD sudo replacement, “doas”, plus them reworking the need for root to run services - address above. https://man.openbsd.org/doas https://man.openbsd.org/doas
- GuB-42 3y ago
  These bypasses are typically not for when are the only user and also the administrator. Sudo here is not really for securing your machine: as others have said, if an attacker gets to your personal account, it is game other. It is mostly a tool for you to avoid fucking up your system by mistake. These bypasses are useful if you want to get root access on a machine you are given some, but not all administrative rights, like a shell and a few sudo commands, for example to restart a service.
blueflow 3y ago
For `tee`, because thats the most hilarious: > If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. LFILE=file_to_write echo DATA | sudo tee -a "$LFILE" Yes... this is how it works? What does the author expect? Sudo executing programs with root privileges resulting in not using them or what? I'm certain the author has bogus expectations here.
- creatonez 3y ago
  > It is important to note that this is not a list of exploits, and the programs listed here are not vulnerable per se, rather, GTFOBins is a compendium about how to live off the land when you only have certain binaries available.
  - blueflow 3y ago
    You can directly map most of the tags into a libc function clall combination, like the "Command" tag is just programs that run user input into a system() call. Even for programs where this is their primary function. It has nothing to do with "bypassing". The author is making a security theater out of nothing for posing.
    - creatonez 3y ago
      The point is to get to these functionality from a limited set of shell commands, not to get to this functionality from an arbitrary executable. > The author is making a security theater out of nothing for posing. Again, the author is not making accusations of security flaws. I don't know how they could have described it better, but the author was going for something very narrow and specific.
dathinab 3y ago
this listing is kinda misleading as most cases of sudo/SUID are not "it calls sudo" / "has SUID set" but "if called with sudo/suid it will not drop the elevated privileges" (or refuses to run). this doesn't mean the table hasn't it's uses but most of the things in it don't allow you to bypass security restrictions by themselves at all even if supper buggy implemented, you always need to already be able to do some privileged operations, like setting suid root, to be able to bypass anything
- planede 3y ago
  I think the point is that an admin shouldn't configure these executables to be run at a different privilege level, as they are not written with that kind of security consideration in mind at all.
  - dathinab 3y ago
    I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability". SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that. Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind". Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that). Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so. Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly. Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).
fargle 3y ago
this list is rather silly. the "*shell","command","read/write/upload/download" lists are plausible. it's slightly non-obvious that running gdb also allows you to drop into a shell. you could envision a restricted account at a university lab or maybe a web-based system like godbolt give access to gdb, but forget about the "!". but it'd be a careless mistake. anyone who'd miss that really shouldn't be messing around with privilege separation in the first place. the rest of it is hogwash: news flash - if you give access to bash, you've given shell access. any tool that allows you to provide a filename to be read/written to can be used to read or write over arbitrary files. so let's make a list of programs that can read/write files. just about every entry under the other categories "sudo","su","setuid", "capabilities",etc. simply involves chaining sudo, su, suid etc. with a shell breakout which is already listed under "shell". the issue is still the shell breakout (or read/write/etc.) the problem is that this list is inverted. here's my curated list of programs that are safe to run under sudo/su/setuid/etc. without being explicitly designed to do so, in all conditions, without knowing what you are doing: {}. there are over 50,000 packages in Debian. why not just list them all here? this reads like junior admin with introductory knowledge of cyber and UNIX trying to make a typical, useless, prescriptive list/recipe for something that instead requires specific engineering to accomplish something given the actual use-case and specific threat model.
- nikau 3y ago
  I dunno, I was pretty shocked to see cat can read a file
- dns_snek 3y ago
  I think you're confused about the purpose of this project. From the website: > It is important to note that this is not a list of exploits, and the programs listed here are not vulnerable per se, rather, GTFOBins is a compendium about how to live off the land when you only have certain binaries available. This website is essentially a lookup table that teaches you how to break out of programs that you find on a system, but aren't intimately familiar with, e.g. during CTF challenges.
  - fargle 3y ago
yrro 3y ago
Huh $ sudo -l Matching Defaults entries for yrro on wintermute: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, env_keep+=COLORFGBG, use_pty, !fqdn User yrro may run the following commands on wintermute: (ALL : ALL) NOPASSWD: /usr/bin/etckeeper unclean, /usr/bin/ss (ALL : ALL) !/usr/bin/sudo, !/usr/bin/su, !/bin/su $ sudo -a -F /etc/shadow Error: an inet prefix is expected rather than "root:$6$9mkIdP/HzXdF0bn6$.aUdPCsZFfm0NJ9Wse.8EowMDION0tvzApDy7X09HQwNIJX9ckvCxoDuYCxzY1uCEvUdODRCVCSoWNVMSgC9a.:16545:0:99999:7:: Darnit
- pengaru 3y ago
  $ sudo -a -F /etc/shadow bash: sudo: command not found
- selfmodruntime 3y ago
  Hello fellow Gibbson fan. My hostname is "wintermute" as well.
- yrro 3y ago
  Double darnit. The command that let me read /etc/shadow was supposed to be: sudo ss -a -F /etc/shadow
pizzalife 3y ago
This list is incredibly contrived.
TechBro8615 3y ago
There is a lot of misunderstanding of context in the comments here. This is a list intended for penetration testers in the privilege escalation phase of exploiting a system, after they've obtained access (the ability to execute with arbitrary parameters) to some "restricted" binary on the possibly misconfigured system. It's commonly used in CTF competitions. For practical examples of when it's been useful, search for something like "gtfobins tryhackme writeup." As a defender, the lesson should really be that you shouldn't assume a binary only does one task. As always, you need to be extremely careful passing untrusted user input to a binary, especially if invoking it via a shell.

201 points by janisz 3y ago

I found this list helpful for clearing the first module of pwn.college.

So if I understand correctly, one of the most common flags is "sudo" and it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. I suppose that's a fundamental design flaw in POSIX setuid operations. Setting real/effective UID/GID in a process is persistent, and tools don't normally keep checking to see whether they have/need elevated privileges, and so this happens. Now I expected this tag to mean something else. I expected there to be a list of tools that are commonly granted to ordinary users in the sudoers configuration, like the operator being able to kick off a backup. For example, "less" has a shell escape, and when running under sudo, it was possible to simply shell out and have an unrestricted root shell. I think that's fixed, but the moral of the story is not to grant sudo access to any tool that has shell escapes or arbitrary command execution.

Arch-TK 3y ago
In my experience, if you see * or more rarely ? in a sudo command configuration then there's a good chance there's a problem. I once saw a bunch of systemctl start someprefix* being allowed in a sudoers configuration (likewise for stop). systemctl can start more than one service at a time and the way that the sudoers configuration is checked is by glob matching the concatenated command. If your command is literally: "systemctl" "start" "someprefix" "sshd" this gets concatenated to "systemctl start someprefix sshd" which matches the glob "systemctl start someprefix*".
- opk 3y ago
  If you want to grant particular systemctl start/stops to normal users, that can be done with policykit,
  - BenjiWiebe 3y ago
    Thanks, I didn't know that!
deathanatos 3y ago
> it means that the tool doesn't bother detecting whether it's operating with elevated privilege, and doesn't bother dropping those privileges when it doesn't need them, so you might coax it into doing other stuff while it's running. No, it doesn't seem to mean even that. It just means that … the thing might do something construed as privileged, if the user running it is privileged. Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? This is solidly on the wrong side of the airtight hatch: I'm not "bypassing security restrictions", I've been granted access to read a file otherwise restricted with sudo. If you grant someone access to running `cat` as root, I can't imagine how it would be a shock that they can then read files that only root can read?
- ElectricalUnion 3y ago
  > Like, cat is on this list. And it's like, "you could `sudo cat` a file!" … well … yes? The `sudo` tag means, if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea.
  - deathanatos 3y ago
    > if you're naively messing with /etc/sudoers, that allowing passwordless "command" with sudo might be a bad idea. It might be a bad idea, but that's not "bypassing local security restrictions", that's explicitly changing the local security restrictions such that that's not a restricted command for the user you're granting it to. If you don't want someone to be able to read any file on the system, no, you shouldn't grant them the ability to run "cat" as root! But "I granted them X" "they ran X" → "they bypassed local security restrictions" is non sequitur.

gumballindie 3y ago

I am not entirely sure what to make of this list. Naturally if a binary or script are given sudo rights then that will elevate privileges, and by default anything should be considered as potentially vulnerable, malicious or misuse-able, particularity tools that can write or read files or execute other binaries or scripts, making this list ... obvious?

Tepix 3y ago
No. If you have a program that does a particular task you may be inclined to let users run it with sudo rights. This list shows how these rights can be used to - for example - read arbitrary files and show them to the unprivileged user. The "mail" entry is a good example: https://gtfobins.github.io/gtfobins/mail/ https://gtfobins.github.io/gtfobins/mail/ Did you know you can get a shell easily by letting users use "mail"?
- mrweasel 3y ago
  I still don't get the issue, that's going to be true for any program you run, unless it explicitly check if it's running using sudo. That however assumes that the program should never run with elevated privileges, which may be equally wrong. Unless a program is designed for a very specific task and should always run as a given user, I'd argue that having it check privileges is both surprising and wrong. It's not the job of the individual programs to check permissions. Edit: I see what you're saying. Having mail being a program that a user is allowed to run with sudo, it basically the equivalent for giving them a sudo access to a shell, because mail can spawn a shell, but with the same privileges as the mail command had.
- mindwok 3y ago
  The lesson here is just don't rely on sudo to give restricted permissions. I have been a Linux admin for 6 years and never had to do this, and pretty much every use case I've heard of has easily solved with a better method. If you need to give people access to certain files, make a group. If you need them to have certain capabilities of another user, let them switch to that user but not run privileged commands.

hulitu 3y ago

> su Sudo Sudo If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. sudo su So it is su or sudo ? Anyway, this is in the spirit of "to install a linux virus: ./configure; make; sudo make install".

DougBTX 3y ago

There are quite a few comments here questioning why a list like this might exist, the focus should be on this in the intro: > bypass local security restrictions in misconfigured systems. Someone may think that they can give users restricted access, but this is likely not the case as it is easy to misconfigure the system to give full access. That's the takeaway for me: any access is probably all access. A very clean example is `aws help`: an admin may think that allowing a user to run the help command just grants them access to help, but the example shows that the user could then run any command: aws help !/bin/sh https://gtfobins.github.io/gtfobins/aws/ https://gtfobins.github.io/gtfobins/aws/

wzdd 3y ago
Still, most of these commands will also have bugs. Even if they didn't have convenient built-in ways to escape a restricted shell, I would not expect that these command-line programs, which weren't built to be run in an adversarial environment, weren't vulnerable to buffer overflows or logic errors. The lesson appears to be that if you want to put users in a restricted environment, don't rely on unaudited unix command-line programs to enforce it. Instead do something at a level below that, such as using a kernel-enforced mechanism. This is also the problem with sudo of course.

mrspuratic 3y ago

The "suid" and "sudo" terms are not the conventional meanings, which to my mind sensationalizes this list, which is otherwise useful. Real "sudo" has "noexec" which (mostly) prevents issues by way of .so injection to override libc exec() functions (see the "awk" sudo issue for example). setuid/setgid are not to be used lightly, the problem isn't with the program if an admin overrides the permissions it gets. This used to be one of the first things I'd run hardening a linux system: find / -type f -a $ \( -user root -a -perm +4000 $ -o $ -group root -a -perm +6000 $ \)

zokier 3y ago
> Real "sudo" has "noexec" which (mostly) prevents issues by way of .so injection to override libc exec() functions LD_PRELOAD hacks are ugly though.. seccomp filter would be nicer, but apparently you can't really block execve with seccomp. Best thing I found was to ptrace the child, and inject seccomp policies after startup. That is not exactly pretty either, but what other options are there that would also work with static executables? This whole lkml thread is bit depressing, not because the responses are wrong or bad, but because of the hodge-podge nature of unix prevents any easy solutions to fairly reasonable feature request https://lore.kernel.org/all/202010281500.855B950FE@keescook/T/ https://lore.kernel.org/all/202010281500.855B950FE@keescook/...
- zokier 3y ago
  > Best thing I found was to ptrace the child, and inject seccomp policies after startup huh, apparently according to sudo manual that is exactly what sudo NOEXEC does
- jart 3y ago
  You're both half right. The trick is to use LD_PRELOAD to inject a SECCOMP filter. Then you can block execve(). See https://justine.lol/pledge/ https://justine.lol/pledge/ and https://github.com/jart/cosmopolitan/blob/master/tool/build/dso/sandbox.c https://github.com/jart/cosmopolitan/blob/master/tool/build/...
  - 3y ago

oblio 3y ago

I'll start the cognitive dissonance train: Unix is the system where, quoting: "programs do one thing well." :-)))

quench 3y ago

most of the shell exploits are prevented by including NOEXEC: in the sudo permissions. IDK why this is not the default. This prevents the sudoed command from running any other commands

themerone 3y ago
This would break most package managers and many other system tools.
PeterisP 3y ago
For me, I quite often use sudo to run scripts that install or reconfigure something, and they obviously do need to execute other commands.

TacticalCoder 3y ago

Most of them by very far rely on sudo. I've got a system without sudo. The only way to execute something as root on my system is to log in, using a U2F security key, from a second system (typically a small laptop sitting next to my workstation). That second system is connected to my workstation on a dedicated LAN only used by these two machines. Firewalls on both (for example my workstation only allow SSH in from that one LAN and only from the IP of my laptop on that LAN etc.). The laptop has no Internet access, WiFi disabled (modules prevented from loading, firewall preventing network access, etc.). The laptop's sole purpose is to run command as root on the workstation: it's its sole purpose. The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation. I think no sudo even installed on the machine beats the "never allow root SSH" mantra but YMMV. (to set up the system I install the system offline, from a Debian installation medium whose checksum and signature I've verified, do my thing as root on the workstation, set up the login using U2F from the laptop, then I "lock myself out" from login as root directly at the workstation by entering a password so long I'll never enter it, something like "neverenterthisrootpasswordanymoreusethelaptopu2fkeyinstead#$bey8rUtIopTY6"*. A bit of pain to enter twice but then I'm good to go)

simonblack 3y ago
I've got a system without sudo Yes, I hate sudo's unwieldiness too. The very first thing I do after installing one of those distros that default to no-root-login (Ubuntu, Mint, etc) is to give root a password. The downside is that I allow "root SSH", contrarily to every single best practice out there. Why can't you log in via SSH as a 'normal' user, and then "su -" to become root? I use that method, and it obviates both the use of sudo and the allowance of "root SSH".
tiffanyh 3y ago
OpenBSD sudo replacement, “doas”, plus them reworking the need for root to run services - address above. https://man.openbsd.org/doas https://man.openbsd.org/doas
GuB-42 3y ago
These bypasses are typically not for when are the only user and also the administrator. Sudo here is not really for securing your machine: as others have said, if an attacker gets to your personal account, it is game other. It is mostly a tool for you to avoid fucking up your system by mistake. These bypasses are useful if you want to get root access on a machine you are given some, but not all administrative rights, like a shell and a few sudo commands, for example to restart a service.

blueflow 3y ago

For `tee`, because thats the most hilarious: > If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access. LFILE=file_to_write echo DATA | sudo tee -a "$LFILE" Yes... this is how it works? What does the author expect? Sudo executing programs with root privileges resulting in not using them or what? I'm certain the author has bogus expectations here.

creatonez 3y ago
> It is important to note that this is not a list of exploits, and the programs listed here are not vulnerable per se, rather, GTFOBins is a compendium about how to live off the land when you only have certain binaries available.
- blueflow 3y ago
  You can directly map most of the tags into a libc function clall combination, like the "Command" tag is just programs that run user input into a system() call. Even for programs where this is their primary function. It has nothing to do with "bypassing". The author is making a security theater out of nothing for posing.
  - creatonez 3y ago
    The point is to get to these functionality from a limited set of shell commands, not to get to this functionality from an arbitrary executable. > The author is making a security theater out of nothing for posing. Again, the author is not making accusations of security flaws. I don't know how they could have described it better, but the author was going for something very narrow and specific.

dathinab 3y ago

this listing is kinda misleading as most cases of sudo/SUID are not "it calls sudo" / "has SUID set" but "if called with sudo/suid it will not drop the elevated privileges" (or refuses to run). this doesn't mean the table hasn't it's uses but most of the things in it don't allow you to bypass security restrictions by themselves at all even if supper buggy implemented, you always need to already be able to do some privileged operations, like setting suid root, to be able to bypass anything

planede 3y ago
I think the point is that an admin shouldn't configure these executables to be run at a different privilege level, as they are not written with that kind of security consideration in mind at all.
- dathinab 3y ago
  I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability". SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that. Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind". Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that). Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so. Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly. Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).

fargle 3y ago

this list is rather silly. the "*shell","command","read/write/upload/download" lists are plausible. it's slightly non-obvious that running gdb also allows you to drop into a shell. you could envision a restricted account at a university lab or maybe a web-based system like godbolt give access to gdb, but forget about the "!". but it'd be a careless mistake. anyone who'd miss that really shouldn't be messing around with privilege separation in the first place. the rest of it is hogwash: news flash - if you give access to bash, you've given shell access. any tool that allows you to provide a filename to be read/written to can be used to read or write over arbitrary files. so let's make a list of programs that can read/write files. just about every entry under the other categories "sudo","su","setuid", "capabilities",etc. simply involves chaining sudo, su, suid etc. with a shell breakout which is already listed under "shell". the issue is still the shell breakout (or read/write/etc.) the problem is that this list is inverted. here's my curated list of programs that are safe to run under sudo/su/setuid/etc. without being explicitly designed to do so, in all conditions, without knowing what you are doing: {}. there are over 50,000 packages in Debian. why not just list them all here? this reads like junior admin with introductory knowledge of cyber and UNIX trying to make a typical, useless, prescriptive list/recipe for something that instead requires specific engineering to accomplish something given the actual use-case and specific threat model.

nikau 3y ago
I dunno, I was pretty shocked to see cat can read a file
dns_snek 3y ago
I think you're confused about the purpose of this project. From the website: > It is important to note that this is not a list of exploits, and the programs listed here are not vulnerable per se, rather, GTFOBins is a compendium about how to live off the land when you only have certain binaries available. This website is essentially a lookup table that teaches you how to break out of programs that you find on a system, but aren't intimately familiar with, e.g. during CTF challenges.
- fargle 3y ago

yrro 3y ago

Huh $ sudo -l Matching Defaults entries for yrro on wintermute: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, env_keep+=COLORFGBG, use_pty, !fqdn User yrro may run the following commands on wintermute: (ALL : ALL) NOPASSWD: /usr/bin/etckeeper unclean, /usr/bin/ss (ALL : ALL) !/usr/bin/sudo, !/usr/bin/su, !/bin/su $ sudo -a -F /etc/shadow Error: an inet prefix is expected rather than "root:$6$9mkIdP/HzXdF0bn6$.aUdPCsZFfm0NJ9Wse.8EowMDION0tvzApDy7X09HQwNIJX9ckvCxoDuYCxzY1uCEvUdODRCVCSoWNVMSgC9a.:16545:0:99999:7:: Darnit

pengaru 3y ago
$ sudo -a -F /etc/shadow bash: sudo: command not found
selfmodruntime 3y ago
Hello fellow Gibbson fan. My hostname is "wintermute" as well.
yrro 3y ago
Double darnit. The command that let me read /etc/shadow was supposed to be: sudo ss -a -F /etc/shadow

pizzalife 3y ago

This list is incredibly contrived.

TechBro8615 3y ago

There is a lot of misunderstanding of context in the comments here. This is a list intended for penetration testers in the privilege escalation phase of exploiting a system, after they've obtained access (the ability to execute with arbitrary parameters) to some "restricted" binary on the possibly misconfigured system. It's commonly used in CTF competitions. For practical examples of when it's been useful, search for something like "gtfobins tryhackme writeup." As a defender, the lesson should really be that you shouldn't assume a binary only does one task. As always, you need to be extremely careful passing untrusted user input to a binary, especially if invoking it via a shell.