Exploit Lesson 2
Earlier I wrote an article on first steps in exploiting. Looking for weak directories. At that time I was asked if there would be a series of such articles. I don’t know what the future holds...but here is article two if anyone is interested.
Again I think I can get away with putting this in public because it is basicly harmless. But it can be vital information for understanding how things work.
Exploiting step 2 Directory Transversal
Right...What the hell is that?
It is good at this point to understand a little about directory structures in unix. Why unix? Because most servers holding the information you want will be running it. Unix is often referred to as using a directory tree structure. The root of the tree is / . The location of any file on this tree is described as it’s path. That is what is meant when you put a path in Triton. You are looking for a specific place on a server to see if it is open. So lets say we want the add-pass.cgi of a site. We might find it at this kind of a path /home/somesite.com/cgi-bin/add-pass.cgi. Or in URL form, http://www.somesite.com/cgi-bin/add-pass.cgi. So in Triton you put http://somesite.com as the site and /cgi-bin/add-pass.cgi in the path section.
The next thing that is important to know is that in the unix directory structure . (dot) represents the directory you are in and .. (two dots) represents the next directory back on the tree. This is really the key. You will see how in just a minute. But first.......
What do we ultimately want? Why the passfile of course. But where is it???
The passfile will be kept in a directory that you can’t access directly. It is often called .htpasswd but doesn’t have to be. Now if it couldn’t be accessed then members couldn’t connect to the site and it would soon go out of business. So there is a special file that leads to the .htpasswd file. It is called .htaccess. If we can see this file we will know where the passfile is. But unless the webmaster is a real idiot this file will not be allowed for us to read, so how can we see it??
Let’s look at the URL of a site. http://www.somesite.com. Take out the http:// and this is basicly a path to a place on the server. Think of it as /home/www/somesite.com. Anything added is a new place on the tree, like the members section for instance /home/www/somesite.com/members. Or if the site has some samples on the first page you might see something like this as a URL http://www.somesite.com/sample.php?file=2.
In this example the sample.php is a script that is going to retrieve a picture file for us, file 2.
Hmmmm....If the script will fetch that file for us perhaps it will fetch a different file. Lets try http://www.somesite.com/sample.php?file=.htaccess. Nope, just returns “You are not authorized”. Damn. But wait! We know the .htaccess file is located in the members directory because it has to be world reachable yet at the same time restricted so we can’t see it. (OK this is a simplification. Experienced exploiters need to look the other way here. hehe) So let’s try http://www.somesite.com/sample.php?file=members/.htaccess. Nope, Still didn’t work. But since we understand the directory structure of unix, what if we try http://www.somesite.com/sample.php?file=../members/.htaccess
AHH!!! It worked. What happened? By putting in the ../ we transversed back a directory in the tree and the file was opened.
Now the bad news. It is pretty rare for this to work in real life these days. This fault is well known and has been compensated for long ago. Still the knowlege if the directory structure of unix will be invaluable as you move into higher level exploits and if you obtain access to a server.
Did this seem complex? This is only level 2! It gets a lot harder after this. Best thing to do at this point is find some information about unix, directory structure, and, most importantly, unix commands. Because your going to need those at the next level. CGI exploiting.
__________________
"How do you know I'm mad?" said Alice.
"You must be," said the Cat, "or you wouldn't have come here."
|