* You have a restricted shell or other way to execute a restricted set of commands or binaries, often with arbitrary parameters. You can use GTFOBins in interesting ways to read files, write files, or even execute commands and ultimately break out of your restricted context into a shell.
* Someone allowed sudo access or set the SUID bit on a GTFOBin. Using these tricks, you may be able to read or write sensitive files or execute privileged commands in a way the person configuring sudo did not know about.
I once accidentally gave my claude "powershell" permissions in one session, and after that any time it found it was blocked from using a tool, e.g. git, it would write a powershell script that did the same thing and execute the script to work around the blocked permission.
Obviously no sane system would have "powershell" in a generic allow-list, but you could imagine some discrepancy in allowed levels between tools which can be worked around with the techniques on this page.
And it doesn't stop there.
Yesterday I was trying to figure out some icons issue in KDE plasma (I know nothing about KDE). Both Claude and Codex would run complex bus and debug queries and write and execute QML scripts with more and more tools thrown into the mix.
There's no way to properly block them with just allow- and block lists
Especially not when some harnesses rely on the reliability of the LLM to determine what's allowed or not, pretty much "You shouldn't do thing X" and then asking the LLM to itself evaluate if it should be able to do it or not when it comes up. Bananas.
Only right and productive way to run an agent on your computer is by isolating it properly somehow then running it with "--sandbox danger-full-access --dangerously-bypass-approvals-and-sandbox" or whatever, I myself use docker containers, but there are lots of solutions out there.
Good word of caution though, make sure you actually isolate when you set out to isolate something :)
Glad to see LLM re-discover this trick.
I imagine someone probably wrote very specifically about it in the training data that underwent lossy compression, and the LLM is decompressing that how-to.
So I'd say it's more like "surfacing" or "retrieving" than "re-discovering".
RIP Aaron Swartz, they're generating trillions in shareholder value from the spiritual successors to the work they were going to imprison you for.
So chmod +x file didn't work, now try python -c "import os; os.chmod('file',744)"
Some enterprise security software that is designed to "mediate privilege elevation" includes an allowlist configured by the administrators. My experience seeing this rolled out at one company was that software on the allowlist no longer required a password to run with `sudo`. The allowlist initially included, of course, all kinds of broadly useful software that made its way onto this list (e.g., vim, bash).
I worked from home at this company, and I remember thinking it was a good thing, because this software deployed to "secure" my computer made it drastically weaker to someone walking up to it and trying to run something if I stepped away from the keyboard for a moment and forgot to lock it.
A few years back, our support team needed to do some network capture with tcpdump. The quick and natural way to allow that was to add a sudo rule for it, with opened arguments (I know it's a bit risky, but tcp port and nic could change).
Looks good enough? Well no...
With tcpdump, you can specify a compress command with the "-z" option. But nothing prevents you from running a "special" compress command and completely take over the server:
> sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
This seems trivial, but that the kind of stuff which are really easy to miss. Even if these days, security layers like apparmor mitigate this risk (causing a few headaches along the way), it's still relatively easy to mess it up.
Well, now I feel a little vindicated tinkering so that my backup wouldn't run as root. Instead it runs as a regular user with read-all-files capabilities [0] and no login shell.
Of course, that's still probably overkill on my desktop, and any attacker that got that far would still be able to read basically every file on the computer and sneak backdoors into the backup...
[0] https://man7.org/linux/man-pages/man7/capabilities.7.html
One of those was Word.
In Word you could write macros and use shell to launch other applications.
Suddenly the locked down computer that exposed a handful of applications could run anything (well anything a Windows 3.11 machine in 1995 could run).
It was quite exciting at the time, I don't feel like I have hit the same sort of issues since. Ocassionally I see people say that some touch screen information displays (in shops/shopping centres etc) have ways to escape from kiosk mode (locked to an app) so you can use them for anything, I guess that is similar.
Or is it saying that `base64 /path/to/input-file | base64 --decode` can bypass read file permission flags?
If someone has the power to execute commands, they are already on the other side of the airtight hatch.
https://devblogs.microsoft.com/oldnewthing/20240102-00/?p=10...
Put your meagre and limited resources on keeping them outside the hatch.
If they get through the hatch, that is where you fucked up, not that you didn't remove every conceiveable command from yourself should they get through. If they can remotely get some program to execute a shell, they can quite conceivably get the same program to just read them the files directly by writing different shellcode. Running a shell is just a convenience for them.
The number of setups that are insecure enough to allow remote shells by arbitrary attackers, but are secure because you disabled /bin/cat once they get in, is zero.
So yes, the end result is just `cat` with extra steps.
For example getting a shell with more:
- Setting SHELL to /bin/false before invoking more
- Switching to less in secure mode
- if using more with sudo: NOEXEC flag
A very simple version of this would be if you set a user's default shell to "rbash" but the user can just run "bash" to get a real shell.
Or maybe you give Claude Code permission to run `base64` without review without realizing this lets it read any file, including maybe your secrets in .env or something.
I can't tell you how many times I burned my fingers as a young Unix developer in the 80's by untar'ing things wrongly, or fat-fingering an 'rm -rf /' and thus having a running system that will be catastrophic if I don't fix it before reboot, shell still active and .. what do? Consult this list of great advice and use it to rebuild the system and/or do things that need to be done that otherwise wouldn't be possible ..
GTFOBins is not just for hacking. Its also for system repair and recovery. I'd be as likely to consult this knowledge base after a hacker attack as before, if not more ..
So they're a pretty niche attack vector, and oftentimes crop up as a result of lazy/incompetent sysadmins.
Question from security newbie. Why it is not used to hack all sort of servers all the time then?
It doesn't make it easier to "hack" servers, it's just a list of things that you could use once you're already inside.
It's a pretty niche circumstance. Unless an admin allows users on a server to execute some of these random types of binaries as root, it's not going to be a concern. And, if it wasn't already obvious, distros are almost never configured this way OOTB
I wouldn't say this is the most useful h4x0r tool ever, but I wouldn't say it's particularly niche, either. This kinda stuff is definitely relevant in older large enterprise-type Linux/Unix environments.
But you can't "hack a server" using just these techniques: they would be a (small) part of a chain of exploits.
Systems with capability-based security, such as seL4[0], do not suffer from this category of problem.
Sounds super 1337 and I hope it's actually possible somehow.
$ dd if=shellcode.bin of=/proc/<pid>/mem bs=1 seek=$((target_addr)) ...
LOLBAS (https://lolbas-project.github.io/)