GTFOBins(gtfobins.github.io)
gtfobins.github.io
GTFOBins
https://gtfobins.github.io/
54 comments
Kind of weird to list every program that reads an input file with higher privleges under sudo or suid. That's like almost every program, and kind of the entire point of sudo/suid.
There is a feature of sudo to allow only certain user/command combinations. E.g. User M can only run "apt" under sudo.
The site explains how User M can exploit such situations to bypass this restriction. User M can thus effectively run anything under sudo.
The site explains how User M can exploit such situations to bypass this restriction. User M can thus effectively run anything under sudo.
But with sudo you can specify which parameters are allowed for that binary (or the whole command line). But TBH IDK if this applies to I/O redirections as well.
Every time I look at this, my conclusion is that sudo is a great tool for limiting coworker access and a terrible tool for limiting adversarial access.
This is one of those spots where "everything is a string" fails miserably. Sure, you can encode anything into a string, but that means your ACL system now needs to know how to decode all those formats. Or you do what we have now; regex and hope no one is clever enough to spot the bugs.
That's not even getting into the fact that shells can get input from all over. I.e. passing vars via stdin or variables.
Off the top of my head, you can open full root shells from basically any editor, I believe less can do it. You'll also have to ensure that none of the programs can crash to a debug REPL (i.e. if I can get a Python program to crash to a REPL, I can open bash or run my own Python as root).
This is one of those spots where "everything is a string" fails miserably. Sure, you can encode anything into a string, but that means your ACL system now needs to know how to decode all those formats. Or you do what we have now; regex and hope no one is clever enough to spot the bugs.
That's not even getting into the fact that shells can get input from all over. I.e. passing vars via stdin or variables.
Off the top of my head, you can open full root shells from basically any editor, I believe less can do it. You'll also have to ensure that none of the programs can crash to a debug REPL (i.e. if I can get a Python program to crash to a REPL, I can open bash or run my own Python as root).
I've always thought that sudo was almost totally useless.
One way or another it is going to be possible to exploit the permissions that are given to break out into a root shell.
As far as the idea that it "makes you think", given that I've absolutely typed it without thinking at all and rebooted prod, I'd say that's worthless as well.
Then there's all the silly tricks you need to learn in order to deal with shell redirection and handling of files that just get in the way of doing your job.
The only thing it does usefully is log all the commands executed, but you can hack up bash with honeypot logging patches to syslog every command executed and achieve the same thing.
One way or another it is going to be possible to exploit the permissions that are given to break out into a root shell.
As far as the idea that it "makes you think", given that I've absolutely typed it without thinking at all and rebooted prod, I'd say that's worthless as well.
Then there's all the silly tricks you need to learn in order to deal with shell redirection and handling of files that just get in the way of doing your job.
The only thing it does usefully is log all the commands executed, but you can hack up bash with honeypot logging patches to syslog every command executed and achieve the same thing.
There is a sort of narrow applicability of it so that you can grant some unprivileged operator the ability to run a script -- hopefully well audited with very limited number of knobs that it exposes -- to run with elevated privs. But the common use of it to give out access to nearly everything other than shell to system admin roles is pretty pointless and annoying.
Interactive `sudo` is good for awareness: "look, you are running this command with elevated privileges, unlike normal".
If an adversary got a shell with typical developer sudo access, the game is effectively over.
You can still use `sudo` with limited accounts to prevent escalation. Let such an account run under `sudo` only a fixed set of scripts which take no parameters, and which it cannot even read (but the privileged user can). Additionally, run them from within a chroot where only needed binaries are mapped. This may not stop the most sophisticated attacker, but will thwart a number of less-sophisticated.
If an adversary got a shell with typical developer sudo access, the game is effectively over.
You can still use `sudo` with limited accounts to prevent escalation. Let such an account run under `sudo` only a fixed set of scripts which take no parameters, and which it cannot even read (but the privileged user can). Additionally, run them from within a chroot where only needed binaries are mapped. This may not stop the most sophisticated attacker, but will thwart a number of less-sophisticated.
Yes. That's why this isn't a "these are exploits" list, but a "this is where you need to be careful" list.
If configured properly, it's safe, but there's a number of gotchas, like indirect privilege escalation through improper $PAGER: https://gtfobins.github.io/gtfobins/apt/
If configured properly, it's safe, but there's a number of gotchas, like indirect privilege escalation through improper $PAGER: https://gtfobins.github.io/gtfobins/apt/
You are viewing the list from a position of great privilege, due to your greater knowledge. Many devs don’t understand how sudo or setuid binaries even work, some may not even know that sudo itself is a setuid binary. Asking interview questions like “how does sudo work” yields interesting results ranging from “magic/witchcraft” to “it’s part of the Linux kernel”, even in some very senior engineers. As an educational/training tool, including at least one example of the unintended consequences of ill-formed sudo configurations and setuid binaries in GTFOBins makes sense to me.
Heck, IMO, we shouldn’t have a single role with all the privileges, opting instead for a capabilities-like system with specific admin roles for different domains of control. There are other *nixes where this was the case historically.
Heck, IMO, we shouldn’t have a single role with all the privileges, opting instead for a capabilities-like system with specific admin roles for different domains of control. There are other *nixes where this was the case historically.
You are viewing the list from a position of great privilege
sudo lynx --dump https://gtfobins.github.io/ | grep https://gtfobins | tail +3 | grep -v # | sed 's/^.*\/\(.*\)\/$/\1/' | sudo lessThat first sudo was probably not necessary. Thanks for the laugh. :)
slow clap
You don't need to understand how sudo works to know what it does. If you didn't know that running `sudo cat someFile` will leak the contents of the file, then this list is at the wrong level, and probably won't help you.
I'm not hating on people for not knowing things - it just seems like either its already obvious and this won't help you or its not obvious and it still won't help you because its not really teaching you the right thing. Either way, it seems kind of silly.
I'm not hating on people for not knowing things - it just seems like either its already obvious and this won't help you or its not obvious and it still won't help you because its not really teaching you the right thing. Either way, it seems kind of silly.
Linux has capabilities(7), as I'm sure you know, but security is complicated, and the practical thing to do is still to turn off selinux and apparmor if you're running into weird problems. There are absolutely use cases for them, but "complicated" is a bug, not a feature.
capabilities(7) is pretty useless in practice because most of those capabilities can be escalated into full root access. The man page does a terrible job of explaining the security implications.
I'm pretty sure he was taking about something completely unrelated to the stuff you're thinking of (capabilities(7), selinux, and apparmor): https://en.m.wikipedia.org/wiki/Capability-based_security
Here's what an implementation of capabilities looks like: https://capnproto.org/rpc.html
I'm pretty sure he was taking about something completely unrelated to the stuff you're thinking of (capabilities(7), selinux, and apparmor): https://en.m.wikipedia.org/wiki/Capability-based_security
Here's what an implementation of capabilities looks like: https://capnproto.org/rpc.html
True, yet in a few cases the not-dropping of privileges is a real risk, like with `less` [0], which allows for arbitrary shell access despite being meant for for just paging. Also, it's useful to know that a program is sloppy with permissions in case any bugs are found in it; a CS prof I once had always insisted we dropped permissions and capabilities as soon as we were done with them so that any calls to other libraries or our own buggy code could do the least damage possible, just like how it's good practice to not run every command as root.
[0]: https://gtfobins.github.io/gtfobins/less/
[0]: https://gtfobins.github.io/gtfobins/less/
> a CS prof I once had always insisted we dropped permissions and capabilities as soon as we were done with them
Only once?? Doing this should be muscle memory for working devs.
Only once?? Doing this should be muscle memory for working devs.
Indeed, if you trust somebody enough with a login on your system, you presumably have an expectation of some kind of good faith. If you further grant them sudo to run binaries like these with arbitrary args, that implies some even greater level of trust, and that user presumably understands the social contract at play. They should know to abide by the intent of the sudo restriction (rather than trying to work around it with clever invocations).
I was a sysadmin in a former life, and I didn't usually expect 'sudo' to provide a thorough technical defense against a user intent on wreaking havoc. As typically configured, with blanket access to one or more tools that allow arbitrary file manipulation, it's more like a subtle nudge than a real guardrail. You hope and assume the user respects you and their access level in a way such that they don't work around obvious intent.
It's of course possible to limit the use of 'sudo' carefully (i.e., restrict it to invoking wrapper scripts around specific functions which accept minimal user input) but it's often not expedient to do so, and often expedience rules the day.
I was a sysadmin in a former life, and I didn't usually expect 'sudo' to provide a thorough technical defense against a user intent on wreaking havoc. As typically configured, with blanket access to one or more tools that allow arbitrary file manipulation, it's more like a subtle nudge than a real guardrail. You hope and assume the user respects you and their access level in a way such that they don't work around obvious intent.
It's of course possible to limit the use of 'sudo' carefully (i.e., restrict it to invoking wrapper scripts around specific functions which accept minimal user input) but it's often not expedient to do so, and often expedience rules the day.
You still need to make sure that these programs are set up such that they don't accidentally allow more access than you expected them to.
This list is completely useless to someone that doesn't know base64 reads files.
Before reading this list I didn't know that base64 can read files. So it's useful in the respect that a novice can get a better understanding of their attack surface (I think, I'm a novice to this after all) :)
A lesser known trick, which is not listed here, is that you can use dd to get arbitrary code execution by writing to /proc/<pid>/mem.
Woah - can you expand on this a bit? I don't have a system to test atm, but I'm curious how that works. Are you sure privileges/security boundaries are circumvented?
If YAMA is disabled, you can use it to migrate laterally into processes owned by the same user. See [1].
It only really crosses a security boundary if, for some reason, dd is configured to run as root (e.g. via setuid bit, or sudo config). At that point, you could use it to patch the filesystem directly anyway, but keeping things in-memory is much stealthier (and less risk of bricking hardware, if your working with an embedded device or similar).
For a description of using dd to gain file-less native code execution, see [2].
As a concise (golfed) example (x86-64 /bin/sh shellcode):
[1] https://www.kernel.org/doc/Documentation/security/Yama.txt
[2] https://blog.sektor7.net/#!res/2018/pure-in-memory-linux.md
[3] https://twitter.com/David3141593/status/1386678449604108289
It only really crosses a security boundary if, for some reason, dd is configured to run as root (e.g. via setuid bit, or sudo config). At that point, you could use it to patch the filesystem directly anyway, but keeping things in-memory is much stealthier (and less risk of bricking hardware, if your working with an embedded device or similar).
For a description of using dd to gain file-less native code execution, see [2].
As a concise (golfed) example (x86-64 /bin/sh shellcode):
cd /*/$$;read a<*l;exec 3>mem;base64 -d<<<McBIu9GdlpHQjJf/SPfbU1RfmVJXVF6wOw8F|dd bs=1 seek=$[`cut -d\ -f9<<<$a`]>&3
[1] https://www.kernel.org/doc/Documentation/security/Yama.txt
[2] https://blog.sektor7.net/#!res/2018/pure-in-memory-linux.md
[3] https://twitter.com/David3141593/status/1386678449604108289
No one would be that insane to set dd as setuid.
>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.
Wat. If you add someone to wheel, they may abuse those privileges. Is this really something that needs pointing out? There are many other useful tidbits that you may not necessarily know but this one struck me as a bit odd.
Wat. If you add someone to wheel, they may abuse those privileges. Is this really something that needs pointing out? There are many other useful tidbits that you may not necessarily know but this one struck me as a bit odd.
You're kind of missing the point of sudo if that's all you use it for. sudo can also be used to whitelist specific user+program+argument combinations, so e.g. unprivileged users can run system updates, but not install new programs. These users can use sudo, but should not be able to reach full root privileges from it.
But if such a setup is indirectly exploitable because the default $PAGER allows arbitrary code execution, that's definitely a gotcha you need to be aware of.
But if such a setup is indirectly exploitable because the default $PAGER allows arbitrary code execution, that's definitely a gotcha you need to be aware of.
I remember reading about this use case ~10 years ago. I always found it super weird and I've never had a chance to use it. Even back then, people didn't share computers unless they fully trusted each other.
If a program running as an unprivileged user wants to trigger something like a software update, I'd just write a daemon that reads the trigger command over a unix socket or a signed message over a TCP socket and then runs the update. I guess you'd lose the automatic audit logging of sudo, but pretty much any programmer can verify correctness.
If a program running as an unprivileged user wants to trigger something like a software update, I'd just write a daemon that reads the trigger command over a unix socket or a signed message over a TCP socket and then runs the update. I guess you'd lose the automatic audit logging of sudo, but pretty much any programmer can verify correctness.
> Even back then, people didn't share computers unless they fully trusted each other.
Or you're in a big enterprise or university that has a ton of shared machines. sudo wasn't really designed with single-user machines in mind, `su -l` is good enough for those.
Or you're in a big enterprise or university that has a ton of shared machines. sudo wasn't really designed with single-user machines in mind, `su -l` is good enough for those.
I've only ever seen people use sudo to prevent accidents (by running most commands unprivileged), not malicious use.
I also found this a bit overly obvious at first, yet when considering it from an unintended side effects/uses perspective it's actually a valid thing to consider. For example, `less`[0] might be used with `sudo` to view a file owned by another user. This is all good until you remember that you can run arbitrary commands by just hitting '!' in the paging view, which are also runs with `sudo` privileges. Though that might seem like a bit of a contrived example, through unintended features otherwise safe tools can be unexpectedly dangerous (the entire point of this site).
For a real-ish world example of this effect, one of the OverTheWire wargame challenges [1] (spoilers for bandit) has a user login "shell" be a message saying login was prohibited, printed with `less`. When you resize your console window to a point where scrolling is needed and then attempt login, you can then interact with `less` and use '!' to run commands as the current user and print the key. Now you may say this isn't relevant to the `sudo` category of risk since who runs `sudo less` without also being able to run `sudo anything`, but many other apps use less as their pager, and some of those make much more sense to allow for general use with sudo (like say allowing all users to update apps, or any of hundreds of other insignificant things).
In short, I think the `sudo` and `setuid` notices might be better considered as "permission transparent", i.e. any permissions or access you hand to the listed tools are handed directly to the user as well. There are secure ways to not do this when writing programs, like by setting all of the real, effective, and saved uids [2] to something non-root (or the original calling user, if available) and totally wiping the capabilities sets before `exec()`ing anything, yet that's just what I remember from a computer security class a few years ago, you would probably be best off looking into it further if you're writing anything security sensitive.
[0]: https://gtfobins.github.io/gtfobins/less/
[1]: https://overthewire.org/wargames/bandit/
[2]: https://man7.org/linux/man-pages/man2/setresuid.2.html
For a real-ish world example of this effect, one of the OverTheWire wargame challenges [1] (spoilers for bandit) has a user login "shell" be a message saying login was prohibited, printed with `less`. When you resize your console window to a point where scrolling is needed and then attempt login, you can then interact with `less` and use '!' to run commands as the current user and print the key. Now you may say this isn't relevant to the `sudo` category of risk since who runs `sudo less` without also being able to run `sudo anything`, but many other apps use less as their pager, and some of those make much more sense to allow for general use with sudo (like say allowing all users to update apps, or any of hundreds of other insignificant things).
In short, I think the `sudo` and `setuid` notices might be better considered as "permission transparent", i.e. any permissions or access you hand to the listed tools are handed directly to the user as well. There are secure ways to not do this when writing programs, like by setting all of the real, effective, and saved uids [2] to something non-root (or the original calling user, if available) and totally wiping the capabilities sets before `exec()`ing anything, yet that's just what I remember from a computer security class a few years ago, you would probably be best off looking into it further if you're writing anything security sensitive.
[0]: https://gtfobins.github.io/gtfobins/less/
[1]: https://overthewire.org/wargames/bandit/
[2]: https://man7.org/linux/man-pages/man2/setresuid.2.html
I used to work for a company where launching a shell from within vim was the way we got privileged access on some of the customers boxes (which ran code we developed). Pretty crazy looking back on it..
It's not referring to having sudo ALL permissions, but to users having sudo permissions for individual applications.
So if you are trying to privilege escalate a linux box and sudo -l returns:
(root) /usr/sbin/tcpdump
You check gtfobins for tcpdump and see that you can get a root shell with sudo access.
So if you are trying to privilege escalate a linux box and sudo -l returns:
(root) /usr/sbin/tcpdump
You check gtfobins for tcpdump and see that you can get a root shell with sudo access.
If the server admin was dumb enough to allow executables on $HOME, or anywhere where the user has write access.
Why would the attacker need to set the execute bit on the file they want to execute?
Can't they just run "tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z /lib64/ld-linux-x86-64.so.2" and then swap the tcpdump savefile with the file they want to execute? That will run "ld-linux-x86-64.so.2 ./savefile" after a few seconds which is the same thing as running "chmod +x savefile; ./savefile"
https://unix.stackexchange.com/questions/400621/what-is-lib6...
Anyway this whole discussion of "What if the admin was silly enough to think the execute bit did something?" is academic. If the attacker can run any binary that's already on the system as root, you've already lost.
Can't they just run "tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z /lib64/ld-linux-x86-64.so.2" and then swap the tcpdump savefile with the file they want to execute? That will run "ld-linux-x86-64.so.2 ./savefile" after a few seconds which is the same thing as running "chmod +x savefile; ./savefile"
https://unix.stackexchange.com/questions/400621/what-is-lib6...
Anyway this whole discussion of "What if the admin was silly enough to think the execute bit did something?" is academic. If the attacker can run any binary that's already on the system as root, you've already lost.
For that they have to have the rights to actually replace tcpdump, so it is already owned anyway.
No, the stock tcpdump works just fine for this attack. You were replying to a guy talking about this scenario where the attacker can run tcpdump as root:
>So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump
>So if you are trying to privilege escalate a linux box and sudo -l returns: (root) /usr/sbin/tcpdump
Except you missed the part "swap the tcpdump savefile", which one then needs to execute somehow.
Complicated, when not given the rights to do so.
Complicated, when not given the rights to do so.
Swapping the file is as easy as running "mv ./evil_binary ./savefile".
This is all happening in the home directory. evil_binary can written using "echo -n -e"
You can take as much time as you want to do the swap. tcpdump will only run the log-rotate program you specified after the time limit you specified has passed.
I find it baffling that you think this is a complicated exploit. It's literally the first thing I thought of, and I'm just a random programmer. A real attacker would have a lot more tricks up their sleeve and all the time in the world to google solutions to problems like this. Does your threat model assume that the attacker doesn't know how to use a terminal?
This is all happening in the home directory. evil_binary can written using "echo -n -e"
You can take as much time as you want to do the swap. tcpdump will only run the log-rotate program you specified after the time limit you specified has passed.
I find it baffling that you think this is a complicated exploit. It's literally the first thing I thought of, and I'm just a random programmer. A real attacker would have a lot more tricks up their sleeve and all the time in the world to google solutions to problems like this. Does your threat model assume that the attacker doesn't know how to use a terminal?
Home is mounted as noexec.
Sure when there is a will, there is a way, however it seems many here lack the experience to work on properly locked down UNIX servers, where a user is really a plain user that dances to IT music tune.
Sure when there is a will, there is a way, however it seems many here lack the experience to work on properly locked down UNIX servers, where a user is really a plain user that dances to IT music tune.
Man, not so long ago it was trivial to get a shell from a restricted one on a pretty infamous pubnix...
> Home is mounted as noexec.
Dude we just had a whole conversation about why this does fuck-all if you allow users to run commands like tcpdump as root. Your "properly locked down UNIX servers" are just placebo.
I gotta wonder if I'm responding to an elaborate reenactment of the 90s. In what universe are "plain users" running commands on a unix server, let alone a server run by a BOFH that blocks +x, but is totally fine with root escalation?
Dude we just had a whole conversation about why this does fuck-all if you allow users to run commands like tcpdump as root. Your "properly locked down UNIX servers" are just placebo.
I gotta wonder if I'm responding to an elaborate reenactment of the 90s. In what universe are "plain users" running commands on a unix server, let alone a server run by a BOFH that blocks +x, but is totally fine with root escalation?
The savefile is not the tcpdump executable.
Preparing for the OSCP exam I make extensive use of GTFOBins.
Also LOLBAS (Living Off The Land Binaries and Scripts (and also Libraries)
:) https://lolbas-project.github.io/#
Also LOLBAS (Living Off The Land Binaries and Scripts (and also Libraries)
:) https://lolbas-project.github.io/#
When I played hackthebox.eu I made extensive use of this :D
And that's when you realize how many websites there are out there that make simple attacks so much easier.
And that's when you realize how many websites there are out there that make simple attacks so much easier.
Also if you haven't already, check out some of the OverTheWire wargames [0]. I sure wish I had found this site before trying some of them.
[0]: https://overthewire.org/wargames/
[0]: https://overthewire.org/wargames/
Sounds like fun! I don't have the copious amount of time I had when I did hackthebox, but when I feel the need to hack, I'll check it out. Thanks!
I never heard about Hackthebox; do you recommend it? What is their business model?
Their business model is simple:
* You can hack free boxes and get a mediocre VPN connection to their boxes (that are playable as free). It's doable, but I got annoyed by certain things.
* You can get a subscription for (I forgot) like ... 10$ per month? And then you get a good VPN connection to an entirely different set of servers. It also opens up many more boxes to hack!
* You can hack free boxes and get a mediocre VPN connection to their boxes (that are playable as free). It's doable, but I got annoyed by certain things.
* You can get a subscription for (I forgot) like ... 10$ per month? And then you get a good VPN connection to an entirely different set of servers. It also opens up many more boxes to hack!
A few others:
* pro labs, which are more in depth than the regular boxes and likely have multiple targets
* job postings, which I assume employers pay to post
* academy, which is more guided training than the regular boxes
* T-shirts and swag: https://hackthebox.store/collections/all
* pro labs, which are more in depth than the regular boxes and likely have multiple targets
* job postings, which I assume employers pay to post
* academy, which is more guided training than the regular boxes
* T-shirts and swag: https://hackthebox.store/collections/all
Also, from nethack, too. If your build has set to read mail, you can fire up the mail reader by reading an ingame scroll (I am not kidding), and then spawning a shell from mail(1)/nail(1) or mutt with urlview it's really easy.
the answer is all of them. This website can be replaced by `ls /**/*bin`. any program which does anything nontrivial that you call with sudo is going to let you do something with root privileges you couldn't otherwise do.