Last updated on October 3, 2020
A few days ago I read an article by Leon Juranic that discovered a new world of possibilities for me. The article is called “Back To The Future: Unix Wildcards Gone Wild“, and was published in 2014. Since I wanted to try it for myself, I thought it would be a good opportunity to show you on this blog.
It shows a hacking technique from the old school, which still works today, and I personally think it is fantastic. And what has surprised me most is that I have not read about this technique in any book or security forum until now.
So let’s start by explaining what wildcards are.
Introduction to Wildcards
Wildcards are characters that represent a set or range. They are used to build regular expressions.
Some of the most used wildcards are:
* The asterisk represents any character set of a filename.
? The interrogation represents a single character (whatever it is).
[ ] Brackets represent classes of characters. For example, to search for any character that represents a digit we would put [0-9].
– As we saw in the example above, a hyphen indicates a range of characters.
~ The tilde at the beginning of a word translates as the name of your home directory. If you add a user’s name to it, it translates as the path to that user’s home directory.
That way, if we write in the terminal
# ls *.php Lists all php files.
# rm *.gz Deletes all GZIP files..
# cat backup* Displays the contents of all files that start with “backup”.
# ls test? Lists all files that start with test and have only one additional character (it would show test4 but not test15).
Wildcards hacks
The problem with wildcards is that you can abuse arguments like filename. That is, we can make the system think that one of the arguments that a command receives is actually the filename.
Recursive Delete
Let’s look at the following example. I have created a directory called “dir1“, a text file called “text1” and a file called”-rf“.
Note that to create this -rf file I couldn’t do it with a simple touch -rf, because it gave me an error. But it was enough to enter the complete path (“touch /root/wildcards/-rf”) to create it correctly:
Now we execute the command rm * , so in theory it should delete all files in the directory:
Wow! The”-rf” file is still there. This is because when running rm *, all names have passed as arguments (the command has been translated to “rm dir1 -rf text1”). Since”-rf” is one of the options of the rm command indicating that files should be deleted recursively, the system has interpreted the dir1 and text1 files as having to be deleted recursively, rather than interpreting “-rf” as also being a file to be deleted.
Own files hijacking
Let’s suppose the following case: we have a folder with several files owned by the user. Let’s suppose that the administrator will assign all txt files to the user “resu“. However, the malicious user “toor” wants to get hold of these files, so he creates two files called “cake.txt” and “–reference=cake.txt”:
Next, the root user executes the command “chown -R resu:resu *.txt”, giving the resu user the ownership of these files. Let’s see what happened.
All files are now the property of the user toor!
This is because the chown command has the “–reference=RFILE” option, which assigns the files to the user who owns the RFILE file. Therefore, in reality, root has run “chown -R resu:resu admin.txt cake.txt confidential.txt flag.txt passwords.txt –reference=cake.txt thecakeisalie.txt veryimportantfile.txt”, and when you specify a file with the “–reference” parameter, the system ignores which root has assigned them to resu:resu.
But this goes further: it is not only possible to get hold of the files in the same folder. If we create a symlink, we can take ownership of any file or directory on the system, such as the shadow where the passwords are located.
If the administrator assigns the documents in that folder to the user, as before, all the documents will become toor.
However, the user toor has not only obtained the permissions of those files. The symbolic link route is now also yours….
And therefore, the toor user has access to the shadow file.
In the RFC there are even more examples of this technique applied to chmod, tar and rsync, so in a few days I will do a second part explaining them, because I found it really interesting that there is no countermeasure to prevent this kind of attack.
Lethani.
Be First to Comment