[HN Gopher] GTFOBins
___________________________________________________________________
GTFOBins
Author : matthberg
Score : 301 points
Date : 2021-10-13 07:08 UTC (15 hours ago)
(HTM) web link (gtfobins.github.io)
(TXT) w3m dump (gtfobins.github.io)
| anthk wrote:
| 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.
| bawolff wrote:
| 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.
| matthberg wrote:
| 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/
| idorosen wrote:
| 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.
| bawolff wrote:
| 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.
| sokoloff wrote:
| 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
| theshadowknows wrote:
| _slow clap_
| fragmede wrote:
| 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 wrote:
| 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
| creshal wrote:
| 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 wrote:
| This list is completely useless to someone that doesn't know
| base64 reads files.
| porlune wrote:
| 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 wrote:
| 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 wrote:
| 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.
| curryst wrote:
| 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 wrote:
| 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.
| lamontcg wrote:
| 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.
| nine_k wrote:
| 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.
| creshal wrote:
| 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/
| idorosen wrote:
| Exactly! GTFOBins is an educational tool, not an exploit
| list, in my opinion.
| fragmede wrote:
| 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.
| cygnus-xr1 wrote:
| 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/#
| Retr0id wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| [2] https://blog.sektor7.net/#!res/2018/pure-in-memory-
| linux.md
|
| [3]
| https://twitter.com/David3141593/status/1386678449604108289
| anthk wrote:
| No one would be that insane to set dd as setuid.
| mettamage wrote:
| 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.
| thih9 wrote:
| I never heard about Hackthebox; do you recommend it? What is
| their business model?
| mettamage wrote:
| 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 wrote:
| 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
| matthberg wrote:
| 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/
| mettamage wrote:
| 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!
| kiryin wrote:
| >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.
| creshal wrote:
| 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.
| NavinF wrote:
| 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.
| creshal wrote:
| > 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.
| im3w1l wrote:
| I've only ever seen people use sudo to prevent accidents
| (by running most commands unprivileged), not malicious
| use.
| scandinavian wrote:
| 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 wrote:
| If the server admin was dumb enough to allow executables on
| $HOME, or anywhere where the user has write access.
| NavinF wrote:
| 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.
| pjmlp wrote:
| For that they have to have the rights to actually replace
| tcpdump, so it is already owned anyway.
| NavinF wrote:
| 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
| pjmlp wrote:
| 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.
| NavinF wrote:
| 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?
| pjmlp wrote:
| 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.
| anthk wrote:
| Man, not so long ago it was trivial to get a shell from a
| restricted one on a pretty infamous pubnix...
| NavinF wrote:
| > 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?
| creshal wrote:
| The savefile is not the tcpdump executable.
| matthberg wrote:
| 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
| VBprogrammer wrote:
| 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..
| ltbarcly3 wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-13 23:02 UTC)