[HN Gopher] List of Unix binaries that can be used to bypass loc...
___________________________________________________________________
List of Unix binaries that can be used to bypass local security
restrictions
Author : janisz
Score : 181 points
Date : 2023-07-07 08:41 UTC (14 hours ago)
(HTM) web link (gtfobins.github.io)
(TXT) w3m dump (gtfobins.github.io)
| hulitu wrote:
| > 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".
| TacticalCoder wrote:
| 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 _" neverenterthisrootpasswordanymo
| reusethelaptopu2fkeyinstead#$bey8rUtIopTY6"*. A bit of pain to
| enter twice but then I'm good to go)_
| tureu92 wrote:
| I think at this point you are solving a wrong problem. Getting
| root access through X zero days exploits is not so hard. And if
| you uninstall `sudo` and `su`, and only login as root on
| dedicated TTY, you have very similar security.
|
| I use Qubes OS for stuff like this. Way better security, no
| need to juggle tokens, dedicated lans and so on. Only real
| problem is no graphical acceleration in browser (Google
| Earth...)
| chaxor wrote:
| Doesn't Qubes require like 32GB of RAM just to run?
|
| I would love to use it, but most of the use cases I would
| like to try it for are much more in the realm of SBCs with
| 2-8GB of RAM for running services locally. It would be great
| to have that extra security, but the cost is really really
| high.
| tureu92 wrote:
| systemd-nspawn...
| colejohnson66 wrote:
| > Doesn't Qubes require like 32GB of RAM just to run?
|
| 32 GB minimum, but 16 GB recommended.[0] I think that's
| backwards, so I'd say it's actually 16, not 32 required.
| But yes, that's more than a typical SBC will have. The Pi
| 4, for example, has a maximum configuration of 8 GB, but
| some have modded it to have 16 GB.[1]
|
| [0]: https://www.qubes-os.org/doc/system-requirements/
|
| [1]: https://www.techradar.com/news/a-raspberry-
| pi-4-with-16gb-it...
| idkyall wrote:
| > 32 GB minimum, but 16 GB recommended.[0].
|
| I see Memory: 6 GB RAM under Minimum
| voxadam wrote:
| Do you also disallow su on your system or is it just sudo
| that's been banished?
|
| Edit: I'm curious because if you still allow su on the system
| there seems to be little to no reason to set PermitRootLogin in
| sshd_config regardless of auth mechanism (password, cert,
| token, etc.).
| fuzztester wrote:
| Yes, good question.
|
| Because su was there in Unix before sudo, IIRC. And sudo
| means "su do", meaning do (something) as su, which in turn
| meant "super user" or "substitute user" according to
| Wikipedia, since it can also be used to login as other users
| than root , e.g.:
|
| su - tom
|
| https://en.m.wikipedia.org/wiki/Su_(Unix)
| alufers wrote:
| Out of curiosity: What sensitive things does the root account
| protect on your workstation?
|
| On my desktop (and probably 99% of people's desktops here)
| getting access to the user account is game over. The password
| manager? Runs as my user - one ptrace and the key can be
| extracted. Cookies for all my online services? Sitting right
| there in the home directory.
|
| The only thing root access would give somebody on my machine is
| to uninstall some random packages or corrupt my install.
|
| And don't get me wrong, I don't like this situation - I tried
| running some high-risk programs (browser, Libre Office) under
| flatpak to achieve at least some separation - but it breaks too
| many things.
| westurner wrote:
| > _The only thing root access would give somebody on my
| machine is to uninstall some random packages or corrupt my
| install._
|
| While I agree that compromise of an unprivileged account has
| significant costs, technically superusers do have
| significantly greater access to the system and so there are
| greater levels of risk.
|
| RedoxOS is reimplementing Linux userspace utilities in rust
| in order to avoid C vulns in suid binaries; like ping, which
| requires raw sockets for ICMP (which most of us only need the
| Echo Request capability of)
|
| Superuser: https://en.wikipedia.org/wiki/Superuser
|
| Capability-based security:
| https://en.wikipedia.org/wiki/Capability-based_security
|
| Privilege-based escalation:
| https://en.wikipedia.org/wiki/Privilege_escalation
|
| Principle of least privilege:
| https://en.wikipedia.org/wiki/Principle_of_least_privilege
|
| MAC: Mandatory Access Control:
| https://en.wikipedia.org/wiki/Mandatory_access_control
| kefyras wrote:
| >in suid binaries; like ping
|
| ping hasn't required suid in ages, there's
| net.ipv4.ping_group_range and CAP_NET_RAW.
| TacticalCoder wrote:
| I see that reasoning very often but I don't agree with it
| (note that I'm not saying a local exploit is great).
|
| But first I'll start with a question: why don't you (and
| everybody else for that matter), run _everything_ as root?
|
| Why don't we all search our entire disks for every single
| executable and then execute _chmod 777_ on all of them? I
| mean: that 'd make for a good XKCD...
|
| If the idea is that it's game over anyway if there's a local
| exploit, we may as well just run everything as root right?
| Why even bother with sudo at all?
|
| > Out of curiosity: What sensitive things does the root
| account protect on your workstation?
|
| I'm one of those person using _several_ user accounts on my
| own system. For example my professional account is separated
| from my personal account (and I do use both simultaneously).
| One of my browsers (I run several browsers) is in a throwaway
| user account: clean slate at every launch. Why not?
|
| And a local exploit compromising _one_ user account requires
| a second exploit to access what 's in the other users
| accounts.
|
| > The only thing root access would give somebody on my
| machine is to uninstall some random packages or corrupt my
| install.
|
| Root access could allow the attacker to install a persistent
| backdoor which would be very hard to detect. Installing a
| persistent backdoor that can evade detection is incredibly
| harder to do if all you have is a local exploit.
|
| I take a system on which I have more chances to detect that
| an exploit happened --even if the exploit did already
| happen-- any day over one with less chances to detect that an
| exploit happened.
|
| And even if, for me, a local exploit means it may be too late
| for some stuff (although having U2F/webauthn and soon
| passkeys in many important places should limit damages),
| having a non-compromised root may allow me to detect a local
| exploit and share my findings with the community. Which has a
| lot of value too.
| mike_hearn wrote:
| Probably not 99%, no. It may be worth noting that macOS
| doesn't have these issues. The password manager doesn't run
| as the user, and entries in it have ACLs that restrict which
| apps can read them. In turn that's enforced by the kernel:
| apps can't ptrace each other and they can't tamper with each
| other's files. Browsers, meanwhile, encrypt the cookie store
| using a key stored in the keychain, so you can't read the
| user's cookies either.
|
| All this is true _without_ app sandboxing being activated.
| Apps that are sandboxed get even more protections.
|
| Apple have done the best job of incrementally isolating apps
| from each other using different levels of sandboxing. Linux
| and Windows are far behind even with Flatpak. For example, we
| tell people who use Conveyor (our product for deploying
| desktop apps [1]) that one of the most secure platforms to do
| signing on is a Mac laptop, because the signing keys can be
| protected such that only Conveyor itself can read them. Even
| if you execute malware, it would trigger a permission prompt
| if it tried to access the signing keys, and then the process
| doing the signing is also protected in the same way. To get
| the same effect on Linux you'd need to set up dedicated UNIX
| users and the like.
|
| Maybe I should write up a blog post on this stuff. Apple
| tighten things incrementally with each major release and
| don't make much noise about it, so I've found a lot of people
| aren't aware of how advanced their security has actually
| become.
|
| [1] https://hydraulic.dev/
| mcdonje wrote:
| >Maybe I should write up a blog post on this stuff.
|
| Please do. And post it to HN. It could inspire some distro
| maintainers.
| mistrial9 wrote:
| security so advanced that an individual software author
| cannot write a small MacOSX app, add an About box and cool
| icon, and distribute it themselves, as they choose?
| NavinF wrote:
| Why troll? Nothing stops you from distributing a .app
| from your website
| mistrial9 wrote:
| `$xattr -d com.apple.quarantine /path/to/file`
| drbawb wrote:
| On my system the root account is primarily for upgrades, but
| also storage administration! ZFS snapshots protects me
| against silly mistakes like strange permutations of `rm -rf
| ~/` in day to day operations. Not having root all the time
| protects me against `zfs destroy -r nagato/data/home/drbawb`
| which will nuke my home folder, 144 frequent snapshots (15
| minute intervals per 36 hours), 14 daily snapshots, 4 weekly
| snapshots, and 3 monthly snapshots. That would suck. A lot.
| (I have a file called "RIP", where a drive image _used to be
| mounted,_ because I got a little too over-zealous with the
| recursive option on some ZFS commands on a file that had
| `copies=1`. _RAID is not a backup, snapshots are not a
| backup, etc._)
|
| This also means that theoretically ransomware (running
| without root) could encrypt my home directory, but apart from
| doubling the number of blocks used on disk it would have no
| real impact on my data. (If someone writes a virus that can
| encrypt the blocks inside a ZFS partition, without mangling
| ZFS data structures beyond repair, then I'll be more
| impressed than angry. Not even the ZFS devs can rewrite block
| pointers on a running filesystem.[1])
|
| That being said ZFS has an awesome feature called delegation
| which lets you run a subset of commands without root
| permissions. I use it sparingly, mostly to allow unprivileged
| backups. (Each host gets a login on my backup server, and can
| only create/destroy datasets that are children of a _host-
| specific dataset._ So `nagato` can `zfs destroy -r backup
| /hosts/nagato` but not `zfs destroy -r backup/hosts` or `zfs
| destroy -r backup/hosts/someone-else`.)
|
| [1]: https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s
| sigotirandolas wrote:
| Mostly:
|
| * Logs: If my unprivileged user gets compromised, there's a
| much better chance that I can figure out what the attacker
| did if he can't wipe his traces as root.
|
| * Money: I use a different unprivileged user for general use
| and for banking, so a compromise of my general purpose user
| doesn't immediately mean that my banking stuff gets
| compromised.
|
| * Lateral escalation: Similarly I use another user to verify
| the checksums or PGP signatures of Windows/Linux images, so I
| don't end up booting a compromised image even if I download
| it from a compromised browser.
|
| The ptrace issue you mention can be avoided by using the Yama
| LSM.
|
| You mention that you tried Flakpak for isolation. If you set
| up a well-protected root account, along with multiple
| unprivileged users, you can also get isolation, but between
| different security contexts rather than different
| applications. It is less convenient than Flatpak for daily
| use, but is extremely mature and doesn't require any of the
| extra layers (user namespaces, bind mounts, proxies...) that
| Flatpak uses.
| mormegil wrote:
| Yeah, that's the classic https://xkcd.com/1200/
|
| I thought about using Qubes OS on my new computer but it
| seemed like a lot of work and tweaking and still having to
| live with the limitations so I abandoned the idea.
| jacquesm wrote:
| It does guard against someone installing a keylogger or
| network trick. I wonder how Samy's USB stick would fare in
| such an environment.
| ElectricalUnion wrote:
| If you're really paranoid, Qubes has a "USB qubes" vm to
| handle untrusted USB devices. Then you only need to trust
| that the attacker can't tamper with PS/2.
| chasil wrote:
| Did you remove all of these? $ cd /usr/bin
| $ for x in ./*; do [ -u "$x" ] && printf "$x\\n"; done
| ./at ./atq ./atrm ./chage ./chfn
| ./chsh ./crontab ./fusermount ./fusermount3
| ./gpasswd ./mount ./newgrp ./passwd
| ./pkexec ./sg ./staprun ./su ./sudo
| ./sudoedit ./umount ./vmware-user ./vmware-
| user-suid-wrapper $ cat /etc/redhat-release Red
| Hat Enterprise Linux release 8.8 (Ootpa)
|
| I notice that chsh is not on the list of the parent article.
| TacticalCoder wrote:
| > Did you remove all of these?
|
| So if you can't protect versus _all_ the threats, you may as
| well not do anything?
| chasil wrote:
| Perhaps a more reasoned approach would be to rewrite them
| in rust, or some other hardened language for greater
| security.
| sigotirandolas wrote:
| What really matters is not whether you have sudo (or su,
| pkexec, etc.) installed, but rather that you never, ever
| escalate privileges from a less trustworthy user to a more
| privileged one, since at a conceptual level this combines the
| low trustworthiness with the high privileged-ness.
|
| Instead, when you want to elevate privileges, you should do
| so by using a mechanism that takes the control of the machine
| away from less trustworthy user - such as a Secure Attention
| Key or similar mechanism.
| chasil wrote:
| But all of these programs escalate privileges from less
| trustworthy to more. $ ls -l
| /usr/bin/passwd -rwsr-xr-x. 1 root root 33424 Apr 1
| 2022 /usr/bin/passwd
|
| The "s" above indicates that the program is allowed to call
| the setuid() family of functions to alter the real,
| effective, and/or saved user id.
|
| You would not be able to change your password without the
| functionality.
| johnklos wrote:
| Yeah - the whole "sudo" category just seems superfluous since
| the issue is with sudo, not with the individual tools.
|
| OTOH, if people are expecting literally every program to open
| file handles / network sockets, then drop privileges to
| something else, that's a weird expectation.
|
| I'm in the no sudo camp myself.
| jonas-w wrote:
| None of them rely on sudo.
| https://gtfobins.github.io/gtfobins/sudo/ -> Is a 404
| mike_hock wrote:
| They don't _rely_ on sudo. The sudo tag merely indicates that
| _if_ sudo is configured to allow "your" (the pwned) user
| account to run them, they can also be used for privileged
| operations that might not have been intended by whoever
| configured sudo that way.
|
| "Never allow root SSH" together with the strong implication
| that it should be used in conjunction with sudo, has always had
| a very weak rationale behind it, since as soon as you actually
| ever make use of sudo to elevate your privileges, for an
| attacker there is almost no meaningful distinction between your
| user account and plain root.
|
| Looking at the historic reality, the weak rationale more than
| evaporates completely. Due to various CVEs, sudo has, in
| retrospect, been a trojan horse for most of its existence that
| allowed privilege escalation from any user account regardless
| of its configuration. The period for which sudo has had these
| vulnerabilities overlaps rather well with the period for which
| it has been championed as "best practice" along with the
| tenuous justifications based on security by obscurity and to
| avoid "user mistakes."
|
| In that light, your setup seems perfectly sane to me, however I
| don't believe sudo is relevant as a backdoor anymore in 2023
| and the focus has most likely shifted to something else.
| gsich wrote:
| >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.
|
| Allowing root login is fine. The best practice is not to allow
| passwords for root login.
| TacticalCoder wrote:
| > The best practice is not to allow passwords for root login.
|
| My sshd is configured to not allow passwords logins at all:
| it's U2F/Yubikey only.
| gsich wrote:
| I somewhat like smartcards more. Takes use of the slot, not
| wasting rare USB ports on notebooks. I don't why there are
| so few USB ports, but that's another discussion.
| johnklos wrote:
| The even better than "best" practice is to not allow
| passwords for any login. Keys really aren't that hard.
| blueflow wrote:
| 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 wrote:
| > 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.
| DougBTX wrote:
| 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/
| wzdd wrote:
| 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 wrote:
| 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 wrote:
| > 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/...
| zokier wrote:
| > 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 wrote:
| 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/ and https://github.com/jart/cosmo
| politan/blob/master/tool/build/...
| nathants wrote:
| this, or custom lsm modules so they're harder to turn off.
| dathinab wrote:
| 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 wrote:
| 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.
| TechBro8615 wrote:
| 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.
| NoZebra120vClip wrote:
| 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.
| deathanatos wrote:
| > _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 wrote:
| > 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 wrote:
| > _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.
| Arch-TK wrote:
| 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 wrote:
| If you want to grant particular systemctl start/stops to
| normal users, that can be done with policykit,
| BenjiWiebe wrote:
| Thanks, I didn't know that!
| oblio wrote:
| I'll start the cognitive dissonance train:
|
| Unix is the system where, quoting: "programs do one thing well."
|
| :-)))
| pizzalife wrote:
| This list is incredibly contrived.
| quench wrote:
| 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
| PeterisP wrote:
| For me, I quite often use sudo to run scripts that install or
| reconfigure something, and they obviously do need to execute
| other commands.
| themerone wrote:
| This would break most package managers and many other system
| tools.
| gumballindie wrote:
| 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?
| gnfargbl wrote:
| I think the listing of "non-obvious" functionality is
| interesting. For instance, would you have expected to be able
| to use _gimp_ to get a reverse shell? Would you have thought of
| using _lp_ as an exfil tool? Or just bashing your exfil into
| base64-encoded _whois_ requests?
|
| Living off the land is always a fascinating topic, at any
| level.
| VBprogrammer wrote:
| In a previous role we had some access to production web
| servers but definitely not root access. Except for sudo
| access to vim which was widely abused as a way of getting a
| root shell when necessary. Fun times.
| didntcheck wrote:
| If it can perform arbitrary file writes (or even reads) then
| sure, I'm not at all surprised. A program with root access to
| the filesystem should be assumed to be a latent portal to
| arbitrary root execution, unless very thoroughly proven
| otherwise
|
| There's a reason setuid is considered such a dangerous bit,
| and why "get root via this secure- _looking_ setuid program "
| is a common exercise in computer security courses. Gotta look
| out for path traversals, TOCTOU, untrusted environment
| variables etc.
|
| Part of the logical problem is the clash of security models.
| The program may well have been written to guard against
| untrusted input, but considers that to only be input files,
| not the commands the user gives. On the basis that "well if
| the user wants to hurt themselves by writing to /etc/shadow
| then it's their choice". But the situation in practice is a
| confused deputy problem, where the sysadmin wants the user to
| be restricted (despite the process _not_ being restricted)
| but the program doesn 't "know"
| ssklash wrote:
| It was originally compiled for penetration testers/offensive
| security people. You land on a box with low priveleges, check
| around for commonly misconfigured binaries, and get root.
| faiD9Eet wrote:
| For the sake of this argument, lets suppose you run a git
| server. Users $(ssh) into your host and are only allowed to
| execute the command $(git), for instance for submitting a copy
| of their repository. You think: It's fine, the user cannot mess
| up anything on this system since he is restricted to run git.
|
| Allowing any user $(git) access is as powerful as providing the
| user a $(bash)
|
| Suppose you've got a build pipeline. The pipeline executes
| $(zip) at some point. Executing zip is as powerful as providing
| any of the pipelines users a $(bash).
| salawat wrote:
| ....except it isn't if you set up the git user with
| authorized_keys (user public key), and set the login shell
| for the system git user to nologin.
|
| Congratulations. Git without bash. Unless there's another
| escape I'm not aware of.
| feldrim wrote:
| And that is the whole idea of having a list like this.
| These tools by default have some capabilities which can
| easily be executable. You need to mitigate each of those.
| Because they are insecure by default.
| Tepix wrote:
| 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/
|
| Did you know you can get a shell easily by letting users use
| "mail"?
| [deleted]
| mrweasel wrote:
| 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 wrote:
| 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.
| zokier wrote:
| > The lesson here is just don't rely on sudo to give
| restricted permissions
|
| But that is one of the headline features of sudo! For
| example it is the first item on its feature list here
| https://www.sudo.ws/about/intro/
| didntcheck wrote:
| And sudo does its job, executing only that program as
| root. If the sysadmin turns out to not want users to be
| able to use all features of the program as root, that is
| their responsibility. Sudo is just a command executor,
| not a sandbox
|
| It's essentially the same as setuid, which has a well-
| deserved reputation for being a very dangerous tool if
| used on a program without thorough scrutiny
| friendzis wrote:
| > > But that is one of the headline features of sudo! For
| example it is the first item on its feature list here
| https://www.sudo.ws/about/intro/
|
| > The ability to restrict the commands a user may run on
| a per-host basis.
|
| Is it? sudo is literally "substitute user [and] do" and
| it does exactly that: runs a certain program in the
| context of certain user. The only permissions sudo is
| concerned with is which user on what host is to be
| allowed to switch to which user, i.e. invocation
| permissions. Sudo simply does not care what permissions
| user+program combo may have.
|
| Without additional hardening, in unix-like systems local
| user account is _the_ capability boundary and `sudo` is a
| tool to escape those boundaries. Sudo is just doing what
| it was designed to do here
| zokier wrote:
| > The only permissions sudo is concerned with is which
| user on what host is to be allowed to switch to which
| user
|
| And, critically, what commands that user is allowed to
| execute. That is pretty crucial aspect of sudos use-case.
| The _intent_ is to have ability to restrict what code the
| user is allowed to run as the target user, and not allow
| arbitrary code execution.
| hulitu wrote:
| If user can run _only_ mail he won't be able to normally run
| sh. Of course you need to play a bit with permisions.
| titzer wrote:
| One of the listed binaries is `cat` and that `sudo cat file`
| is problematic because "it may be used to do privileged reads
| or disclose files outside a restricted file system."
|
| Like, duh, that is what `cat` does. It's not the problem,
| it's the `sudo` is the problem. WAI?
| fargle wrote:
| 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 wrote:
| I dunno, I was pretty shocked to see cat can read a file
| dns_snek wrote:
| 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.
| yrro wrote:
| Huh $ sudo -l Matching Defaults entries
| for yrro on wintermute: env_reset, mail_badpass, secure_p
| ath=/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.8EowMDIO
| N0tvzApDy7X09HQwNIJX9ckvCxoDuYCxzY1uCEvUdODRCVCSoWNVMSgC9a.:16545
| :0:99999:7::
|
| Darnit
| yrro wrote:
| Double darnit. The command that let me read /etc/shadow was
| supposed to be: sudo ss -a -F /etc/shadow
| j-krieger wrote:
| Hello fellow Gibbson fan. My hostname is "wintermute" as well.
| pengaru wrote:
| $ sudo -a -F /etc/shadow bash: sudo: command not found
___________________________________________________________________
(page generated 2023-07-07 23:03 UTC)