Security Through Obscurity: cat, escape characters, ls
Welcome back to my 2nd iteration of this blog series. In this series we’re growing our cybersecurity knowledge starting from the very basics using the overthewire.org challenges as a guide. First, I’d like to thank everyone for their feedback based on the last post! I’ll do my best to implement it and as always, more feedback is always welcome. Now let’s start!
Last week we learned about SSH, pivoting, and a few other linux commands. Today we’ll dive a little deeper by learning about linux directories (folders), traversing the directory structure, and reading files in the CLI.
We had stopped at logging into bandit1 so let’s log back into bandit1 again:
The over the wire challenge tells us that the password for bandit2 is present in the home directory of bandit1 (which we should automatically be in) so let’s make sure that is actually where we are using pwd:
Great, so let’s check what files are here using ls:
Sure enough we have something and it’s called “-”. overthewire.org already gives us the hint that we will probably need cat. cat is a program that prints the text contents of a file in our CLI window. It prints it as the stdout.
Let’s take a second here to explain stdout, stdin, and cat. Put simply, stdout is the “standard output” of the CLI. It simply prints information on the screen and once it’s done, it exits and gives control back to you. This can become problematic if we’re trying to view a very large file or the volume of information produced in the stdout format is very large. Most CLIs have a default “line limit” of 500 or less; meaning that it only stores the last 500 lines in memory for you to scroll back up through. This is inconvenient from a user standpoint but is great in terms of security. Since stdout is very simple and not very interactive, we can’t abuse it to break into a system. On the other hand, programs such as less, more, vim, and nano are full of features that make them convenient for users but exploitable (we’ll use more and vim later as an example). stdin is the opposite of stdout and is the “standard input” program. It takes input and passes it to whatever is running and expecting an input. For example, entering commands into the CLI is using stdin. We can also use stdin and stdout to pass things into programs without actually providing either manually ourselves. To do that we use the > for stdout and < for stdin. We’ll use these later but for now, let’s get back to our challenge.
Now that we know cat will print out the contents of a file, let’s use it to get the password for bandit2:
Well, that’s not what we expected. Instead of giving us the output of the file named “-”, cat is now just repeating whatever we type into the the CLI. If we look at the man page of cat, we see that it has an option to run without any arguments and that it “copies standard input to standard output”. We can also see that the arguments given to cat are preceded by the “-”. So essentially by doing cat — , cat thinks we passed it no arguments and as such it’ll just “copies standard input to standard output” and echo back what we type.
Let’s take this moment to discuss linux directories and viewing their contents. We already know about pwd at this point, which shows us the current PATH to our location. There is also the command ls which we used earlier but let’s dive a little deeper into it and what arguments it takes (and thus options it has). The command ls displays the contents of a directory. If we run ls without any arguments (as we did before), it’ll display the “normal” contents of the directory we’re in. We can also run ls and pass a directory PATH to it and view that directory’s contents without being “in it” (as the pwd). Running ls without any arguments in a directory with multiple files or directories also just lists the contents side by side. The man page of ls also shows us a few interesting options: -a and -l.
ls -a shows all the contents of a directory and ls -l shows us the contents in an organized (but “taller”) format. Let’s use the two together and take a look:
Wow! There’s a few more things in here than just the “-” file we saw earlier. Let’s break that list down so we can understand the information we’re being given. At the top of the list we see the “-” file which we already knew about, so let’s discuss the other fields. The first column of “-rw-r — — -” are called the “ file system permission bits”. These specify what kind of entity this is (file or directory) and who it’s accessible by at the different levels of access. The first dash is the “entity” bit: a d means that this is a directory, a — means that it’s a file. If we look at the file system permission bits of the other entities we can see that after the first bit, there’s a repeating pattern. These are permission bits specific to user access. They are the rwx bits and the first set is the permissions for the owner, the second set is permissions for the group, and the last set is the permissions for “other” or “world”. We’ll get back to this.
The 2nd column is the number of links; we’ll talk about this later. The 3rd and 4th columns are the entity owner and entity group respecitively. The entity owner specifies who “owns” this entity. Similarly, the entity group specifies which group owns the entity. This works in tandem with the file system permission bits: the entity owner in this case is bandit2 and has read and write access to this file called “-”. The group called bandit1 also owns this file and only has read access to it. Since the 3rd set is all “-”s, anyone other than the owner and the group has no access to this file at all.
The rest of the entities in this directory were all hidden before we used ls -a and they all have something in common: they all start with “.” in their name. Linux systems keep links for directories inside the directories themselves. As such, the “.” directory is really referring to this directory we’re in right now: /home/bandit1. The “..” directory is a link to its parent directory which would be: /home. Since it’s not important to list these links in the normal listings of director contents, they’re usually “hidden”. By convention, any file or directory whose name starts with “.” also then becomes hidden. This explains why only the “-” file showed when we only used ls without any arguments.
So how do we tell cat that we’re not trying to pass it arguments when trying to view the contents of “-”? Well, we already know two ways of doing this! First, we can use the stdin function of < to pass the file “-” to cat as an input. This way, cat isn’t confused by the name of the file and doesn’t try to accept our input as an argument. We can also use the PATH of the file “-” and pass it to cat and that way (again), cat isn’t confused by the unconventional name of the file and thinks we’re trying to pass it an argument. We can use the PATH in two ways: to use the absolute PATH of the file which is /home/bandit1/- or use the link ./- . Since we’re already in the directory of /home/bandit1, specifying ./ carries the same meaning.
To use the stdin method we can do: cat < -. To use the file PATH method we can use: cat ./- :
Success!
We now have the password for bandit2 so let’s head over there ssh bandit2@bandit.labs.overthewire.org -p 2220:
The next hint says that the password for bandit3 is again in the home directory and is in a file called “spaces in this filename”. We already know what to do:
Sure enough, it’s here. So let’s pass this to cat:
That didn’t work but the error messages are very helpful in understanding why: cat thought that each word of the filename were different files. Since it is only one file and those filenames don’t exist separately, there was nothing for cat to print as stdout. If we look at the man page of cat again, we can see that cat does indeed accept multiple files at once and all we have to do is separate the filenames with spaces. This challenge will introduce 3 new concepts to us: escape characters, strings, and tab completion.
Let’s tackle escape characters first: escape characters produce an alternative function to the original. In this case, spaces in the input for cat has the function of being a separator of different file names. The character “\” is almost universally the start of escape characters. In this case, if we use \ before putting in the spaces, cat will ignore the spaces as filename separators and use the spaces as part of the filename itself. The “\” character “escapes” or ignores the original function of the character that immediately follows it. In this case, the character following the “\” would be the space and would be ignored as a file separator. So one way to solve this is to try: cat spaces\ in\ this\ filename . There are more ways to use the “\” and more escape characters but we’ll cover them as we come across them.
The second concept here is strings. Strings are entities that computer programs take literally without trying to interpret. Strings can be stored as variables or used without being stored but they must always be enclosed within quotes. In this case, we can pass the filename of the file as a string to cat and that way the program won’t try to look for separators or arguments within that string. By enclosing the file name in quotes, cat also takes the whole name as one argument; this is important because this method woudn’t have worked to read the file “-” since cat would have still accepted the — as the precursor to argument letters. So the second solution to this is to try: cat “spaces in this filename” .
The last concept here is tab completion. This is more so a feature of the CLI and shell in use and won’t always be available. The idea of tab completion is both really simple and infinitely useful. Tab completion works by trying to “guess” what your input would be. As such, once we start typing spaces and then hit the “tab” key on the keyboard, it will autofill the filename. Notice that tab completion uses escape characters instead of strings. Tab completion will autofill only what is unique. So if there are filenames that share words in their names, tab completion will only fill until it comes to the point where the names become similar. For example if we have another file in this directory called “spaces in this file”, tab completion will autofill until “file” and stop: spaces\ in\ this\file. You can now use this file called “spaces in this file” or add “n” and use tab completion again to autofill the rest of the other file’s name. So the final (situational) solution is: cat spa (then hit the tab key) -> cat spaces\ in\ this\ filename .
Congratulations! We now have the password for bandit3.
In conclusion, this file and directory naming method is very inconvenient for day to day usage but the extra steps necessary to access these files can be leveraged for security purposes. This method of “making things inconvenient” is often referred to as Security through Obscurity. The principle behind “security through obscurity” is mainly to keep inexperienced or unknowledgeable attackers at bay. As we observed through these exercises, however, they’re not particularly hard to circumnavigate and don’t do much to oppose experienced attackers. Still, as part of the defense in depth layering method, it can be used as extra layer of security. In fact, applying the principles of “Defense in Depth” and “Security through Obscurity” together can have a potentiating effect and significantly slow down attackers and should not be discounted as trivial.
