13 ms·

GTFOBins

324 points by matthberg 5y ago

bawolff 5y ago
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.
- creshal 5y ago
  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.
  - turminal 5y ago
    This list is completely useless to someone that doesn't know base64 reads files.
    - porlune 5y ago
      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) :)
- salicideblock 5y ago
  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.
  - darkwater 5y ago
    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.
    - creshal 5y ago
      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/ https://gtfobins.github.io/gtfobins/apt/
      - idorosen 5y ago
        Exactly! GTFOBins is an educational tool, not an exploit list, in my opinion.
        fragmede 5y ago
        Hopefully, the "education" going on here is that whitelisting 'sudo' command lists is leaky as all hell, and that it is not to be relied on at all to keep a system safe from attack.
    - curryst 5y ago
      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).
      - lamontcg 5y ago
        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.
- matthberg 5y ago
  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/ https://gtfobins.github.io/gtfobins/less/
  - JohnFen 5y ago
    > 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.
- idorosen 5y ago
  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.
  - fragmede 5y ago
    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.
    - NavinF 5y ago
      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 https://en.m.wikipedia.org/wiki/Capability-based_security Here's what an implementation of capabilities looks like: https://capnproto.org/rpc.html https://capnproto.org/rpc.html
  - sokoloff 5y ago
    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 less
    - 5y ago
- JeremyNT 5y ago
  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.
kiryin 5y ago
>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.
- scandinavian 5y ago
  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.
  - pjmlp 5y ago
    If the server admin was dumb enough to allow executables on $HOME, or anywhere where the user has write access.
    - NavinF 5y ago
      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-lib64-ld-linux-x86-64-so-2-and-why-can-it-be-used-to-execute-file 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.
      - pjmlp 5y ago
        For that they have to have the rights to actually replace tcpdump, so it is already owned anyway.
Retr0id 5y ago
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.
- thricegr8 5y ago
  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?
  - Retr0id 5y ago
    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): cd /*/$$;read a<*l;exec 3>mem;base64 -d<<<McBIu9GdlpHQjJf/SPfbU1RfmVJXVF6wOw8F|dd bs=1 seek=$[`cut -d\ -f9<<<$a`]>&3 Source: [3] [1] https://www.kernel.org/doc/Documentation/security/Yama.txt https://www.kernel.org/doc/Documentation/security/Yama.txt [2] https://blog.sektor7.net/#!res/2018/pure-in-memory-linux.md https://blog.sektor7.net/#!res/2018/pure-in-memory-linux.md [3] https://twitter.com/David3141593/status/1386678449604108289 https://twitter.com/David3141593/status/1386678449604108289
    - anthk 5y ago
      No one would be that insane to set dd as setuid.
mettamage 5y ago
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.
- matthberg 5y ago
  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/ https://overthewire.org/wargames/
  - mettamage 5y ago
    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!
- thih9 5y ago
  I never heard about Hackthebox; do you recommend it? What is their business model?
  - mettamage 5y ago
    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!
    - vsareto 5y ago
      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 https://hackthebox.store/collections/all
cygnus-xr1 5y ago
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/# https://lolbas-project.github.io/#
ltbarcly3 5y ago
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.
anthk 5y ago
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.

324 points by matthberg 5y ago

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.

creshal 5y ago
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.
- turminal 5y ago
  This list is completely useless to someone that doesn't know base64 reads files.
  - porlune 5y ago
    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) :)
salicideblock 5y ago
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.
- darkwater 5y ago
  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.
  - creshal 5y ago
    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/ https://gtfobins.github.io/gtfobins/apt/
    - idorosen 5y ago
      Exactly! GTFOBins is an educational tool, not an exploit list, in my opinion.
      - fragmede 5y ago
        Hopefully, the "education" going on here is that whitelisting 'sudo' command lists is leaky as all hell, and that it is not to be relied on at all to keep a system safe from attack.
  - curryst 5y ago
    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).
    - lamontcg 5y ago
      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.
matthberg 5y ago
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/ https://gtfobins.github.io/gtfobins/less/
- JohnFen 5y ago
  > 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.
idorosen 5y ago
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.
- fragmede 5y ago
  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.
  - NavinF 5y ago
    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 https://en.m.wikipedia.org/wiki/Capability-based_security Here's what an implementation of capabilities looks like: https://capnproto.org/rpc.html https://capnproto.org/rpc.html
- sokoloff 5y ago
  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 less
  - 5y ago
JeremyNT 5y ago
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.

kiryin 5y ago

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

scandinavian 5y ago
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.
- pjmlp 5y ago
  If the server admin was dumb enough to allow executables on $HOME, or anywhere where the user has write access.
  - NavinF 5y ago
    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-lib64-ld-linux-x86-64-so-2-and-why-can-it-be-used-to-execute-file 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.
    - pjmlp 5y ago
      For that they have to have the rights to actually replace tcpdump, so it is already owned anyway.

Retr0id 5y ago

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.

thricegr8 5y ago
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?
- Retr0id 5y ago
  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): cd /*/$$;read a<*l;exec 3>mem;base64 -d<<<McBIu9GdlpHQjJf/SPfbU1RfmVJXVF6wOw8F|dd bs=1 seek=$[`cut -d\ -f9<<<$a`]>&3 Source: [3] [1] https://www.kernel.org/doc/Documentation/security/Yama.txt https://www.kernel.org/doc/Documentation/security/Yama.txt [2] https://blog.sektor7.net/#!res/2018/pure-in-memory-linux.md https://blog.sektor7.net/#!res/2018/pure-in-memory-linux.md [3] https://twitter.com/David3141593/status/1386678449604108289 https://twitter.com/David3141593/status/1386678449604108289
  - anthk 5y ago
    No one would be that insane to set dd as setuid.

mettamage 5y ago

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.

matthberg 5y ago
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/ https://overthewire.org/wargames/
- mettamage 5y ago
  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!
thih9 5y ago
I never heard about Hackthebox; do you recommend it? What is their business model?
- mettamage 5y ago
  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!
  - vsareto 5y ago
    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 https://hackthebox.store/collections/all

cygnus-xr1 5y ago

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/# https://lolbas-project.github.io/#

ltbarcly3 5y ago

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.

anthk 5y ago

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.