The techniques explained in this chapter could cause warning lights to dimly flash. An alert sysop might notice traces of activity, but as we are legally not doing anything wrong at this stage, it is hard to make a lot of noise about it. We are going to do our best to minimize our level of exposure.
Unrouted nets, NAT
The output of the previous section is lot of IP numbers. We are still not sure that these are all the IP numbers involved - we suspect that it is used. We have netblocks - blocks of IP numbers. Within that block there might be only one host that is even switched on. The first step here is thus to try to find out which machines are actually alive (its of no use to attack a machine that is not plugged into the 'net). The only way to know that a host is actively alive on the 'net is to get some sort of response from the machine. It might be a ICMP ping that is return, it might be that the IP is listed in a bounced mail header, it might be that we see a complete telnet banner.
Companies spend thousands of dollars hiding machines. They use unrouted/experimental IP blocks (10.0.0.0/8 type of thing) and use NAT (network address translation) on their outbound routers or firewalls. They have fancy proxies that'll proxy anything from basic HTTP request to complicated protocols such as Microsoft Netmeeting. They build tunneling devices that will seamlessly connect two or more unrouted/experimental subnets across the Internet. In many cases the main concern for the company is not the fact that they want to hide their IP numbers - the driving force might be that they are running out of legal IP numbers, and the fact that they are hiding the IP blocks is a nice side-effect.
The ratio between legal and illegal IP blocks varies from company to company and from country to country. The South African Telecom use 6 class B networks - all their equipment has legal IP numbers. On the other hand a very well known European telecom used a single IP and NAT their whole network through that IP. As a general rule (very general) one can assume a ratio of legal to illegal netblocks of 1:10. Given that Citibank has over 60 legal netblocks, one can safely assume that they should have many times more illegal netblocks.
The problem with illegal IP blocks is that one cannot discover if machine on an illegal IP number is alive - not directly in anyway. The packets that are suppose to trigger a response simply does not arrive at the correct destination. I have seen many wannabe "Security experts" scanning their own private network whilst thinking that they are in fact scanning a client (with a very worried look in their eyes they then tell the client that they have many problems on their network:)). Other problems that arise are that a client might be using a legal netblock, but that the netblock does not actually belong to them. Some legacy sysop thought it OK to use the same netblock as the NSA. Scanning this client "legal" netblock might land you in a spot of hot water. When conducting any type of scan, make sure that the netblock is actually routed to the correct location. Another note - if an IP number is connected with a DNS name is does NOT mean the IP number is legal (or belongs to them. Many companies use internal IP numbers in their zone files - for secondary MX records for instance.
Ping - ICMP
Keeping all this in mind, where does one begin to discover which machines are alive? One way might be to ping all the hosts in the list. Is this a good idea? There are pros and cons. Pinging a host is not very intrusive - ping one machine on the 'net, and chances are that no-one will notice. Ping a class B in sequential order, and you might raise some eyebrows. What if ICMP is blocked at the border router, or on the firewall? Not only wont you get any results, but also all your attempts will be logged. If a firewall's "deny" log increase tenfold overnight, you can bet on it that it will be noticed. In many cases ICMP ping requests is either blocked completely, or allowed completely. There are exceptions of course (say an external host is pinging a internal host every X minutes to make sure it is alive, and sends alerts when the host is dead), but generally ICMP is either blocked or allowed. I have not seen any hosts that log ICMP ping packets. Thus, if ICMP ping is allowed to enter and leave the network, you can safely ping the whole netblock without anyone noticing. That is - if there are no IDS (intrusion detection system) in place.
An IDS is a system that looks for suspect looking packets - it will pick up on any known signature of an exploit. It then reacts - it might notify the sysadmin, or it might close the connection. Any IDS worth its salt also looks for patterns. If you portscan a host an IDS located between you and the host would pick up that you are trying to open sequential ports on the same IP - portscanning it. So - if you are pingscanning a big network the IDS might spot a pattern and might react. The "signature" that the IDS would pick up is that the IMCP flags are set to "ping request", and that these are coming in at a rapid rate to many machines (see, that is how an IDS picks up on floodping for example).
If we can counter most of the above obstacles, a ping sweep/scan might be a first good indication of hosts that are alive on the netblock. We counter the obstacles by doing the following - we first ping a few random hosts in the netblock (manually) to see if ICMP are allowed to the inside (yes - I know - this is a hit and miss method because in the whole of the class C there can be one IP that is alive, but rather safe than sorry). If we see ANY ICMP reply we assume that ICMP is allowed to the inside, and proceed to ping scan the network very carefully. In this case very carefully mean very slowly, and not in sequence. We also want to try confuse the sysadmin as to who we really are. If we could send packets with fake (or spoofed) IP addresses we could "cloak" ourselves among the other fake IP addresses. Packets with fake IP numbers will be returned, just as the packets to our IP address, but the "non-suspecting" hosts would simply ignore them, as it never knew that it was "sending" it out. How does one go about scanning stealthy and very slowly?
Enter Nmap (www.insecure.org/nmap). Nmap is a scanner tool build by the good Fyodor of Insecure.org. It is the preferred scanning tool for many security people (good and bad). It has recently been ported to Windows NT as well (by the people at Eeye.com). Without going into the detail of all nmap's option (there are a lot), we find that the command
nmap -sP -PI -Tpolite -D10.0.0.1,172.16.1.1 --randomize_hosts <netblock>
would do the thing. Let us have a quick look at the different parameters and what they mean. -sP -PI mean that we want to ping sweep with ICMP only, -D10.0.0.1,172.16.1.1 mean that we want to send decoys 10.0.0.1 and 172.16.1.1, -Tpolite means that we want to scan slowly, and --randomize_hosts tells nmap to shuffle the destination. Now, obviously you would not use 10.0.0.1 and 172.16.1.1 - that is stupid as the sysadmin will quickly spot your (legal) IP between the rest of the (illegal) IP numbers. A further note - don't be stupid and put Microsoft and the NSA's IP numbers in the decoys - it can be spotted easily. Instead try to use IP numbers that are assigned to public mailservers, and add a public webserver here and there. The more decoys you add the safer you are. There is a balance of course - remember that if ICMP request could be logged. To use or not to use decoys can open large debates - an argument against using decoys could be that if a sysop sees a decoyed pingsweep (it pretty obvious when a large number of IPs starts pinging your hosts all of a sudden) it means that someone has spent the time to cloak him/herself - and this on its own is reason for concern. This concern could lead to investigation, something the sysop would normally not do.
Let us see how well this works in a real life. Let us choose a Citibank netblock that we have discovered - we take a small block in Argentina 200.42.11.80-200.42.11.87. We first do a manual ping of a few machines, and find that 200.42.11.81 is alive...and then it hits like a ton of bricks - this method is not that well designed! Imagine the sysop seeing a failed ping request from MY IP number, then a successful ping request, and after two minutes a "storm" of ping requests from all over the world to the rest of the netblock...and that "storm" containing my IP number. It does not take a rocket scientist to figure out what happened. So - I either have to ping from a totally remote site to establish if ICMP is allowed in, or do use the decoys right from the start.
We choose the first method, and proceed with another netblock. This time we choose the block 63.71.124.192-63.71.124.255 in the US of A. We first manually ping some IPs in the block - from a (undisclosed) offsite location. 63.71.124.198 is found to be alive (I hear you saying - why not do the whole of the ping sweep from the "other" location - well, maybe that "other" location does not have the capabilities to run my carefully crafted scanner, or I do not want to attract ANY attention to that site). We now fire up nmap as mentioned. The complete command is (decoys X-ed out):
>nmap -sP -PI -Tpolite -D199.x9.68.1x0,216.1x7.52.33,15x.43.128.26,196.x.160.8 --randomize_hosts 63.71.124.193-254
The output is:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (63.71.124.193) appears to be up.
Host (63.71.124.197) appears to be up.
Host (63.71.124.198) appears to be up.
Nmap run completed -- 62 IP addresses (3 hosts up) scanned in 46 seconds
Aha! ICMP is allowed into the network, and there are 3 machines responding to it. What do we do if we find or suspect that ICMP is blocked?
Ping -TCP (no service, wrappers, filters)
Method1 (against stateful inspection FWs)
The idea is to find machines that are alive. The way we do this is by sending data to the host and looking if we can see any response. If our data were blocked at the router or firewall it would look as though the machine is dead. The idea is thus to find data that is allowed to pass the filters, and that would trigger a response. Per default just about all operating systems will listen on certain ports (if TCP/IP is enabled). Computers are likely to be connected to the Internet with a purpose - to be a webserver, mailserver, DNS server etc. Thus, chances are that a host that is alive and connected to the Internet is listening on some ports. Furthermore it is likely (less but still) than the firewall or screening router protecting these hosts allows some for of communication to these hosts - communication is less likely to be a one-way affair. Packetfilters uses source IPs, source ports, destination IPs and destination ports (and some flags) as parameters to decide if a packet will be allowed to enter the network. Normally a firewall will allow the world to communicate to some host or hosts in some form or the other - thus not looking at the source IP address.
The idea would thus be to send a TCP connect on well-known ports and hope that 1) the firewall passes it through 2) the host is listening on the specified port. Given the response of the host, one can determine which of 1) and 2) happened. If we get no response we know that the firewall is blocking us - if we get a response from the server telling us that the port is not open we at least know that it was not filtered by the firewall. Hereby two examples:
>telnet wips.sensepost.com 22
Trying 160.124.19.98...
telnet: connect to address 160.124.19.98: Connection refused
telnet: Unable to connect to remote host
The host responded by telling us that it is not listening on port 22. It also tells us that there is nothing between us and the host (on port 22). So, if we find that for a certain block a number of hosts returns a "connection refused" while other are return a SSH version (port 22 is SSH) we can safely assume that the firewall is configured to allow anyone to connect to port 22 (anywhere in the netblock). Another example:
>telnet wips.sensepost.com 44
Trying 160.124.19.98...
telnet: Unable to connect to remote host: Connection timed out
Here the connection to port 25 is timing out - telling us that there are something blocking the packet to arrive at the final destination. Let us assume that we scan a netblock for port 25 and we find that certain hosts answers with a SMTP greeting, while others simply time out. This tells us that the firewall is configured to only allow packets with a certain destination port on a certain destination IP to enter the network. If we find a "connection refused" answer in a the same net we know that someone probably screwed up - the service is not running, but the config on the firewall has not been updated to close the "hole".
A machine that is dead will respond in the same way as a machine that is protected by a firewall that does not allow anything through. Thus, getting no response from a server does not mean that it is heavily firewalled - it might just be switched off, or unplugged.
Thus, getting back to the original argument - sending TCP requests to a number of well known ports might tell us if the machine is indeed alive. This might be useful in a situation where ICMP ping requests or replies are blocked on a firewall. We have no way to know if any hosts are alive but the connect to well-known ports and hope that 1) it is not firewalled and than 2) we get some response (be that "connection refused" or some service response).
The more ports we test for, the more our requests will look like a port scan (it is in fact a port scan - with just a limited amount of ports that are tested), and will trigger an IDS. It the therefore very tricky to decide if this action can be executed without triggering alarms - more so when we are scanning a large netblock. As a general rule, the number of IPs tested times the number of ports tested should not exceed 15. Testing 15 hosts for port 80 is OK, testing 5 IPs for 3 ports are OK etc. This is a very general rule and really depends on your target, the competency level of their technical staff and how anonymous you want to stay (and how lucky you feel).
Let us stay with Citibank (Citibank - I REALLY mean no harm - you are just such a good example network). Using the previous ping technique it seems that a device is blocking ICMP to the 192.193.195.0/24 netblock. We will thus proceed to do a "TCP ping" to 30 hosts (I feel lucky) in the block. I choose this block because it has interesting reverse DNS entries (see previous section):
120.195.193.192.IN-ADDR.ARPA domain name pointer global120.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2-a.citicorp.com
121.195.193.192.IN-ADDR.ARPA domain name pointer global121.citicorp.com
122.195.193.192.IN-ADDR.ARPA domain name pointer global122.citicorp.com
123.195.193.192.IN-ADDR.ARPA domain name pointer global123.citicorp.com
124.195.193.192.IN-ADDR.ARPA domain name pointer global124.citicorp.com
125.195.193.192.IN-ADDR.ARPA domain name pointer global125.citicorp.com
132.195.193.192.IN-ADDR.ARPA domain name pointer ld1-www.citicorp.com
140.195.193.192.IN-ADDR.ARPA domain name pointer mango1.citicorp.com
141.195.193.192.IN-ADDR.ARPA domain name pointer mango2.citicorp.com
150.195.193.192.IN-ADDR.ARPA domain name pointer fw-a-pri.ems.citicorp.com
Choosing which ports to scan for can be a tricky business. The best way is trying to choose ports that you think might generate a response. Looking at the reverse (or forward) DNS entries sometimes gives one a clue as to which ports to test for. Looking at the hosts reverse entries I am choosing my ports to be 80 (HTTP), port 443 (HTTPS) and port 264 (I hope the fw-a-pri is a FW1 with management port 264 open).The actual command issued looks like this:
#nmap -sS -P0 -Tpolite --randomize_hosts -D20x.195.1x0.5x,19x.3x.90.1x8,x04.x2.x53.18 192.193.195.120-150 -p 80,264,443
Let us have a quick look at the command. -sS means we are doing a half-open SYN scan, -P0 mean don't stop if you can't ping the host (nmap only scans pingable hosts by default, and we know that these cannot be pinged), -p 80,264,443 means only look at ports 80,264 and 443. Note - you have to be root to do SYN scanning. The output looks like this (somewhat manipulated to save the rain forest):
Interesting ports on global121.citicorp.com (192.193.195.121):
[same on 121, .122, .126, .128, .133, .134, .143, .148] sample A
Port State Service
80/tcp filtered http
264/tcp filtered bgmp
443/tcp filtered https
Interesting ports on (192.193.195.147):
[same on .131, .136, .141., .150] sample B
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
264/tcp filtered bgmp
Interesting ports on global120.citicorp.com (192.193.195.120):
[same on .132, .123] sample C
Port State Service
80/tcp open http
264/tcp filtered bgmp
443/tcp open https
What can be deduced from the output? First of all this - hosts in sample A is filtered on all three ports. This does not mean that the hosts are not alive - it simply means that we do not know. Hosts in sample B is alive - we are 100% sure of this - although port 264 is filtered, these hosts answered that they are not listening on ports 80 or 443 (state "closed"). Sample C is the more interesting of the lot - both machines in sample C is listening on ports 80 and 443. It is most likely that they are running some form of (HTTPS-enabled) webserver.
From this scan we also see that IP numbers that does not have reverse DNS entries are not necessarily down, and visa versa. It would thus make no sense to only scan hosts with reverse entries (sometimes companies would do this - why no one would know). We also see that our scan on port 264 was unsuccessful in all cases (bummer!). From this part of netblock we can thus compile a list of hosts that we know is alive:
fw-a-pri.ems.citicorp.com (192.193.195.150)
192.193.195.127
mango2.citicorp.com (192.193.195.141)
global123.citicorp.com (192.193.195.123)
192.193.195.131
ld1-www.citicorp.com (192.193.195.132)
global120.citicorp.com (192.193.195.120)
192.193.195.136
(and possibly others - the scan was prematurely ended because we got the needed output)
The worth of mapping the network carefully now pays off. We know that the 192.193 network is not routed to the same place. This means we can have a "alive" run against many parts of the 192.193 network without raising the alarm - parts of the network (class Cs) are protected (or not protected) by different firewalls/routers, and changes are slim that these different firewalls are logging to a common place.
Method2 (against stateless Firewalls)
What is the difference between stateful and stateless firewalls really? Well to understand the difference, you got to understand how a TCP connection looks like: the client sends a TCP packet with the SYN flag set, the server responds with a TCP packet with the SYN and the ACKL flags set. Thereafter the server and the client send TCP packets with the ACK flag set. To ensure two-way communication, stateless firewalls usually have a rule (the very last rule) that states that “established” connections are allowed; packets with the ACK flag set. How does this help us? Well, if I send a packet to a server with only the ACK flag set, the server will respond with a RST (reset) flag. This is due to the fact that the server does not know why I am sending a packet with only the ACK flag set (in other words it says: “hey! We haven’t performed a 3 way handshake – bugger off”). Thus, if the machine is alive we WILL get a response – a RST packet.
How do we do it? Simple – there a nifty tool called hping that does this (and a lot more). Let us see how. Lets send a packet with only the ACK flag set- hping will detect if anything comes back. We run hping against a machine that sits behind a stateless firewall: (first we ping it to show you what happens)
# ping -c 3 196.35.xxx.12
PING 196.35.xxx.12 (196.35.xxx.12): 56 data bytes
--- 196.35.xxx.12 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Now hping:
# hping 196.35.xxx.12 -c 3 -A
HPING 196.35.xxx.12 (ep0 196.35.xxx.12): A set, 40 headers + 0 data bytes
46 bytes from 196.35.xxx.12: flags=R seq=0 ttl=115 id=20664 win=0 rtt=2088.2 ms
46 bytes from 196.35.xxx.12: flags=R seq=1 ttl=115 id=20665 win=0 rtt=2180.1 ms
46 bytes from 196.35.xxx.12: flags=R seq=2 ttl=115 id=20666 win=0 rtt=2130.1 ms
--- 196.35.xxx.12 hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2088.2/2132.8/2180.1 ms
Although the machine does not respond to ICMP ping packets, it responds with a RST flag if we send an ACK flag. So – there we go – a real TCP ping. How do we hping a lot of hosts? Here’s a quick & dirty PERL script that will do it for you:
#!/usr/bin/perl
# Usage: perl hpings startip-endip 'parameters_to_hping'
# eg. hpings 160.124.19.0-160.124.19.10 '-A -c 2'
$|=1;
@een=split(/-/,@ARGV[0]);
@ip1=split(/\./,@een[0]);
@ip2=split(/\./,@een[$#een]);
for ($a=@ip1[0]; $a<1+@ip2[0]; $a++) {
for ($b=@ip1[1]; $b<1+@ip2[1]; $b++) {
for ($c=@ip1[2]; $c<1+@ip2[2]; $c++) {
for ($d=@ip1[3]; $d<1+@ip2[3]; $d++) {
print "$a.$b.$c.$d : ";
system "hping $a.$b.$c.$d @ARGV[1]";
}}}}
Summary
The idea in this chapter is to know which machines are "alive". It is of no use attacking a dead machine. There are several techniques to "hide" hosts. Hosts on unrouted/experimental networks cannot be discovered directly. There are ways to determine if a host is "alive". The simplest way is to ping it. If ICMP is blocked this will not work - then a TCP ping should be considered. One should be really careful how an "alive-scan" is executed as it can raise alarms. The tool nmap can be used very effectively in archiving this.
Before we go on
The next step would be to look for what I call "easy money". Before we can go into the details of this, there are some points to understand. There are some major differences between auditing a network and hacking into a network. Let us look at the analogy of a house. On the one hand you have the true blue blood burglar - the objective is getting into the house with whatever means possible. The burglar looks for the easiest and safest way to get into the house and he does not care about all the other means. On the other hand the security officer - it is his job to tell the client of every single little hole in the house. The difference between the security officer and the burglar is that when the security officer finds the front door wide open he notes it, and looks for other problems, whereas the burglar find the front door open and walks straight in, ignoring the other holes. In the cyber world it works the same. So, hiring a hacker (in the criminal sense of the world) to audit a system is a bit worrisome. The hacker will surely help you to find a weakness in your defense, but the idea of an IT security audit is not this - the idea is to find all the holes and fix them. Once you and your security advisor is confident that all holes are closed you might want to hire a hacker (or penetration specialist) to try to penetrate the network. The bottom line - doing penetration testing and doing a comprehensive security assessment of a network is not nearly the same thing.
This document had come to the point where I have to decide which route we are going to follow - the view of the hacker or the view of the IT security assessment officer. Choosing either one of the options I cannot continue with Citibank as an example unless I want to land in potentially serious trouble. The rest of the document - with the focus on either hacking or assessing will thus be looking at actual client networks - networks we every right to penetrate. The techniques can be implemented at Citibank as well - in the exact same way, but I simply cannot do it right here and now as Citibank is not my client (unfortunately).
Unrouted nets, NAT
The output of the previous section is lot of IP numbers. We are still not sure that these are all the IP numbers involved - we suspect that it is used. We have netblocks - blocks of IP numbers. Within that block there might be only one host that is even switched on. The first step here is thus to try to find out which machines are actually alive (its of no use to attack a machine that is not plugged into the 'net). The only way to know that a host is actively alive on the 'net is to get some sort of response from the machine. It might be a ICMP ping that is return, it might be that the IP is listed in a bounced mail header, it might be that we see a complete telnet banner.
Companies spend thousands of dollars hiding machines. They use unrouted/experimental IP blocks (10.0.0.0/8 type of thing) and use NAT (network address translation) on their outbound routers or firewalls. They have fancy proxies that'll proxy anything from basic HTTP request to complicated protocols such as Microsoft Netmeeting. They build tunneling devices that will seamlessly connect two or more unrouted/experimental subnets across the Internet. In many cases the main concern for the company is not the fact that they want to hide their IP numbers - the driving force might be that they are running out of legal IP numbers, and the fact that they are hiding the IP blocks is a nice side-effect.
The ratio between legal and illegal IP blocks varies from company to company and from country to country. The South African Telecom use 6 class B networks - all their equipment has legal IP numbers. On the other hand a very well known European telecom used a single IP and NAT their whole network through that IP. As a general rule (very general) one can assume a ratio of legal to illegal netblocks of 1:10. Given that Citibank has over 60 legal netblocks, one can safely assume that they should have many times more illegal netblocks.
The problem with illegal IP blocks is that one cannot discover if machine on an illegal IP number is alive - not directly in anyway. The packets that are suppose to trigger a response simply does not arrive at the correct destination. I have seen many wannabe "Security experts" scanning their own private network whilst thinking that they are in fact scanning a client (with a very worried look in their eyes they then tell the client that they have many problems on their network:)). Other problems that arise are that a client might be using a legal netblock, but that the netblock does not actually belong to them. Some legacy sysop thought it OK to use the same netblock as the NSA. Scanning this client "legal" netblock might land you in a spot of hot water. When conducting any type of scan, make sure that the netblock is actually routed to the correct location. Another note - if an IP number is connected with a DNS name is does NOT mean the IP number is legal (or belongs to them. Many companies use internal IP numbers in their zone files - for secondary MX records for instance.
Ping - ICMP
Keeping all this in mind, where does one begin to discover which machines are alive? One way might be to ping all the hosts in the list. Is this a good idea? There are pros and cons. Pinging a host is not very intrusive - ping one machine on the 'net, and chances are that no-one will notice. Ping a class B in sequential order, and you might raise some eyebrows. What if ICMP is blocked at the border router, or on the firewall? Not only wont you get any results, but also all your attempts will be logged. If a firewall's "deny" log increase tenfold overnight, you can bet on it that it will be noticed. In many cases ICMP ping requests is either blocked completely, or allowed completely. There are exceptions of course (say an external host is pinging a internal host every X minutes to make sure it is alive, and sends alerts when the host is dead), but generally ICMP is either blocked or allowed. I have not seen any hosts that log ICMP ping packets. Thus, if ICMP ping is allowed to enter and leave the network, you can safely ping the whole netblock without anyone noticing. That is - if there are no IDS (intrusion detection system) in place.
An IDS is a system that looks for suspect looking packets - it will pick up on any known signature of an exploit. It then reacts - it might notify the sysadmin, or it might close the connection. Any IDS worth its salt also looks for patterns. If you portscan a host an IDS located between you and the host would pick up that you are trying to open sequential ports on the same IP - portscanning it. So - if you are pingscanning a big network the IDS might spot a pattern and might react. The "signature" that the IDS would pick up is that the IMCP flags are set to "ping request", and that these are coming in at a rapid rate to many machines (see, that is how an IDS picks up on floodping for example).
If we can counter most of the above obstacles, a ping sweep/scan might be a first good indication of hosts that are alive on the netblock. We counter the obstacles by doing the following - we first ping a few random hosts in the netblock (manually) to see if ICMP are allowed to the inside (yes - I know - this is a hit and miss method because in the whole of the class C there can be one IP that is alive, but rather safe than sorry). If we see ANY ICMP reply we assume that ICMP is allowed to the inside, and proceed to ping scan the network very carefully. In this case very carefully mean very slowly, and not in sequence. We also want to try confuse the sysadmin as to who we really are. If we could send packets with fake (or spoofed) IP addresses we could "cloak" ourselves among the other fake IP addresses. Packets with fake IP numbers will be returned, just as the packets to our IP address, but the "non-suspecting" hosts would simply ignore them, as it never knew that it was "sending" it out. How does one go about scanning stealthy and very slowly?
Enter Nmap (www.insecure.org/nmap). Nmap is a scanner tool build by the good Fyodor of Insecure.org. It is the preferred scanning tool for many security people (good and bad). It has recently been ported to Windows NT as well (by the people at Eeye.com). Without going into the detail of all nmap's option (there are a lot), we find that the command
nmap -sP -PI -Tpolite -D10.0.0.1,172.16.1.1 --randomize_hosts <netblock>
would do the thing. Let us have a quick look at the different parameters and what they mean. -sP -PI mean that we want to ping sweep with ICMP only, -D10.0.0.1,172.16.1.1 mean that we want to send decoys 10.0.0.1 and 172.16.1.1, -Tpolite means that we want to scan slowly, and --randomize_hosts tells nmap to shuffle the destination. Now, obviously you would not use 10.0.0.1 and 172.16.1.1 - that is stupid as the sysadmin will quickly spot your (legal) IP between the rest of the (illegal) IP numbers. A further note - don't be stupid and put Microsoft and the NSA's IP numbers in the decoys - it can be spotted easily. Instead try to use IP numbers that are assigned to public mailservers, and add a public webserver here and there. The more decoys you add the safer you are. There is a balance of course - remember that if ICMP request could be logged. To use or not to use decoys can open large debates - an argument against using decoys could be that if a sysop sees a decoyed pingsweep (it pretty obvious when a large number of IPs starts pinging your hosts all of a sudden) it means that someone has spent the time to cloak him/herself - and this on its own is reason for concern. This concern could lead to investigation, something the sysop would normally not do.
Let us see how well this works in a real life. Let us choose a Citibank netblock that we have discovered - we take a small block in Argentina 200.42.11.80-200.42.11.87. We first do a manual ping of a few machines, and find that 200.42.11.81 is alive...and then it hits like a ton of bricks - this method is not that well designed! Imagine the sysop seeing a failed ping request from MY IP number, then a successful ping request, and after two minutes a "storm" of ping requests from all over the world to the rest of the netblock...and that "storm" containing my IP number. It does not take a rocket scientist to figure out what happened. So - I either have to ping from a totally remote site to establish if ICMP is allowed in, or do use the decoys right from the start.
We choose the first method, and proceed with another netblock. This time we choose the block 63.71.124.192-63.71.124.255 in the US of A. We first manually ping some IPs in the block - from a (undisclosed) offsite location. 63.71.124.198 is found to be alive (I hear you saying - why not do the whole of the ping sweep from the "other" location - well, maybe that "other" location does not have the capabilities to run my carefully crafted scanner, or I do not want to attract ANY attention to that site). We now fire up nmap as mentioned. The complete command is (decoys X-ed out):
>nmap -sP -PI -Tpolite -D199.x9.68.1x0,216.1x7.52.33,15x.43.128.26,196.x.160.8 --randomize_hosts 63.71.124.193-254
The output is:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (63.71.124.193) appears to be up.
Host (63.71.124.197) appears to be up.
Host (63.71.124.198) appears to be up.
Nmap run completed -- 62 IP addresses (3 hosts up) scanned in 46 seconds
Aha! ICMP is allowed into the network, and there are 3 machines responding to it. What do we do if we find or suspect that ICMP is blocked?
Ping -TCP (no service, wrappers, filters)
Method1 (against stateful inspection FWs)
The idea is to find machines that are alive. The way we do this is by sending data to the host and looking if we can see any response. If our data were blocked at the router or firewall it would look as though the machine is dead. The idea is thus to find data that is allowed to pass the filters, and that would trigger a response. Per default just about all operating systems will listen on certain ports (if TCP/IP is enabled). Computers are likely to be connected to the Internet with a purpose - to be a webserver, mailserver, DNS server etc. Thus, chances are that a host that is alive and connected to the Internet is listening on some ports. Furthermore it is likely (less but still) than the firewall or screening router protecting these hosts allows some for of communication to these hosts - communication is less likely to be a one-way affair. Packetfilters uses source IPs, source ports, destination IPs and destination ports (and some flags) as parameters to decide if a packet will be allowed to enter the network. Normally a firewall will allow the world to communicate to some host or hosts in some form or the other - thus not looking at the source IP address.
The idea would thus be to send a TCP connect on well-known ports and hope that 1) the firewall passes it through 2) the host is listening on the specified port. Given the response of the host, one can determine which of 1) and 2) happened. If we get no response we know that the firewall is blocking us - if we get a response from the server telling us that the port is not open we at least know that it was not filtered by the firewall. Hereby two examples:
>telnet wips.sensepost.com 22
Trying 160.124.19.98...
telnet: connect to address 160.124.19.98: Connection refused
telnet: Unable to connect to remote host
The host responded by telling us that it is not listening on port 22. It also tells us that there is nothing between us and the host (on port 22). So, if we find that for a certain block a number of hosts returns a "connection refused" while other are return a SSH version (port 22 is SSH) we can safely assume that the firewall is configured to allow anyone to connect to port 22 (anywhere in the netblock). Another example:
>telnet wips.sensepost.com 44
Trying 160.124.19.98...
telnet: Unable to connect to remote host: Connection timed out
Here the connection to port 25 is timing out - telling us that there are something blocking the packet to arrive at the final destination. Let us assume that we scan a netblock for port 25 and we find that certain hosts answers with a SMTP greeting, while others simply time out. This tells us that the firewall is configured to only allow packets with a certain destination port on a certain destination IP to enter the network. If we find a "connection refused" answer in a the same net we know that someone probably screwed up - the service is not running, but the config on the firewall has not been updated to close the "hole".
A machine that is dead will respond in the same way as a machine that is protected by a firewall that does not allow anything through. Thus, getting no response from a server does not mean that it is heavily firewalled - it might just be switched off, or unplugged.
Thus, getting back to the original argument - sending TCP requests to a number of well known ports might tell us if the machine is indeed alive. This might be useful in a situation where ICMP ping requests or replies are blocked on a firewall. We have no way to know if any hosts are alive but the connect to well-known ports and hope that 1) it is not firewalled and than 2) we get some response (be that "connection refused" or some service response).
The more ports we test for, the more our requests will look like a port scan (it is in fact a port scan - with just a limited amount of ports that are tested), and will trigger an IDS. It the therefore very tricky to decide if this action can be executed without triggering alarms - more so when we are scanning a large netblock. As a general rule, the number of IPs tested times the number of ports tested should not exceed 15. Testing 15 hosts for port 80 is OK, testing 5 IPs for 3 ports are OK etc. This is a very general rule and really depends on your target, the competency level of their technical staff and how anonymous you want to stay (and how lucky you feel).
Let us stay with Citibank (Citibank - I REALLY mean no harm - you are just such a good example network). Using the previous ping technique it seems that a device is blocking ICMP to the 192.193.195.0/24 netblock. We will thus proceed to do a "TCP ping" to 30 hosts (I feel lucky) in the block. I choose this block because it has interesting reverse DNS entries (see previous section):
120.195.193.192.IN-ADDR.ARPA domain name pointer global120.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2.citicorp.com
120.195.193.192.IN-ADDR.ARPA domain name pointer arrow2-a.citicorp.com
121.195.193.192.IN-ADDR.ARPA domain name pointer global121.citicorp.com
122.195.193.192.IN-ADDR.ARPA domain name pointer global122.citicorp.com
123.195.193.192.IN-ADDR.ARPA domain name pointer global123.citicorp.com
124.195.193.192.IN-ADDR.ARPA domain name pointer global124.citicorp.com
125.195.193.192.IN-ADDR.ARPA domain name pointer global125.citicorp.com
132.195.193.192.IN-ADDR.ARPA domain name pointer ld1-www.citicorp.com
140.195.193.192.IN-ADDR.ARPA domain name pointer mango1.citicorp.com
141.195.193.192.IN-ADDR.ARPA domain name pointer mango2.citicorp.com
150.195.193.192.IN-ADDR.ARPA domain name pointer fw-a-pri.ems.citicorp.com
Choosing which ports to scan for can be a tricky business. The best way is trying to choose ports that you think might generate a response. Looking at the reverse (or forward) DNS entries sometimes gives one a clue as to which ports to test for. Looking at the hosts reverse entries I am choosing my ports to be 80 (HTTP), port 443 (HTTPS) and port 264 (I hope the fw-a-pri is a FW1 with management port 264 open).The actual command issued looks like this:
#nmap -sS -P0 -Tpolite --randomize_hosts -D20x.195.1x0.5x,19x.3x.90.1x8,x04.x2.x53.18 192.193.195.120-150 -p 80,264,443
Let us have a quick look at the command. -sS means we are doing a half-open SYN scan, -P0 mean don't stop if you can't ping the host (nmap only scans pingable hosts by default, and we know that these cannot be pinged), -p 80,264,443 means only look at ports 80,264 and 443. Note - you have to be root to do SYN scanning. The output looks like this (somewhat manipulated to save the rain forest):
Interesting ports on global121.citicorp.com (192.193.195.121):
[same on 121, .122, .126, .128, .133, .134, .143, .148] sample A
Port State Service
80/tcp filtered http
264/tcp filtered bgmp
443/tcp filtered https
Interesting ports on (192.193.195.147):
[same on .131, .136, .141., .150] sample B
(The 2 ports scanned but not shown below are in state: closed)
Port State Service
264/tcp filtered bgmp
Interesting ports on global120.citicorp.com (192.193.195.120):
[same on .132, .123] sample C
Port State Service
80/tcp open http
264/tcp filtered bgmp
443/tcp open https
What can be deduced from the output? First of all this - hosts in sample A is filtered on all three ports. This does not mean that the hosts are not alive - it simply means that we do not know. Hosts in sample B is alive - we are 100% sure of this - although port 264 is filtered, these hosts answered that they are not listening on ports 80 or 443 (state "closed"). Sample C is the more interesting of the lot - both machines in sample C is listening on ports 80 and 443. It is most likely that they are running some form of (HTTPS-enabled) webserver.
From this scan we also see that IP numbers that does not have reverse DNS entries are not necessarily down, and visa versa. It would thus make no sense to only scan hosts with reverse entries (sometimes companies would do this - why no one would know). We also see that our scan on port 264 was unsuccessful in all cases (bummer!). From this part of netblock we can thus compile a list of hosts that we know is alive:
fw-a-pri.ems.citicorp.com (192.193.195.150)
192.193.195.127
mango2.citicorp.com (192.193.195.141)
global123.citicorp.com (192.193.195.123)
192.193.195.131
ld1-www.citicorp.com (192.193.195.132)
global120.citicorp.com (192.193.195.120)
192.193.195.136
(and possibly others - the scan was prematurely ended because we got the needed output)
The worth of mapping the network carefully now pays off. We know that the 192.193 network is not routed to the same place. This means we can have a "alive" run against many parts of the 192.193 network without raising the alarm - parts of the network (class Cs) are protected (or not protected) by different firewalls/routers, and changes are slim that these different firewalls are logging to a common place.
Method2 (against stateless Firewalls)
What is the difference between stateful and stateless firewalls really? Well to understand the difference, you got to understand how a TCP connection looks like: the client sends a TCP packet with the SYN flag set, the server responds with a TCP packet with the SYN and the ACKL flags set. Thereafter the server and the client send TCP packets with the ACK flag set. To ensure two-way communication, stateless firewalls usually have a rule (the very last rule) that states that “established” connections are allowed; packets with the ACK flag set. How does this help us? Well, if I send a packet to a server with only the ACK flag set, the server will respond with a RST (reset) flag. This is due to the fact that the server does not know why I am sending a packet with only the ACK flag set (in other words it says: “hey! We haven’t performed a 3 way handshake – bugger off”). Thus, if the machine is alive we WILL get a response – a RST packet.
How do we do it? Simple – there a nifty tool called hping that does this (and a lot more). Let us see how. Lets send a packet with only the ACK flag set- hping will detect if anything comes back. We run hping against a machine that sits behind a stateless firewall: (first we ping it to show you what happens)
# ping -c 3 196.35.xxx.12
PING 196.35.xxx.12 (196.35.xxx.12): 56 data bytes
--- 196.35.xxx.12 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
Now hping:
# hping 196.35.xxx.12 -c 3 -A
HPING 196.35.xxx.12 (ep0 196.35.xxx.12): A set, 40 headers + 0 data bytes
46 bytes from 196.35.xxx.12: flags=R seq=0 ttl=115 id=20664 win=0 rtt=2088.2 ms
46 bytes from 196.35.xxx.12: flags=R seq=1 ttl=115 id=20665 win=0 rtt=2180.1 ms
46 bytes from 196.35.xxx.12: flags=R seq=2 ttl=115 id=20666 win=0 rtt=2130.1 ms
--- 196.35.xxx.12 hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2088.2/2132.8/2180.1 ms
Although the machine does not respond to ICMP ping packets, it responds with a RST flag if we send an ACK flag. So – there we go – a real TCP ping. How do we hping a lot of hosts? Here’s a quick & dirty PERL script that will do it for you:
#!/usr/bin/perl
# Usage: perl hpings startip-endip 'parameters_to_hping'
# eg. hpings 160.124.19.0-160.124.19.10 '-A -c 2'
$|=1;
@een=split(/-/,@ARGV[0]);
@ip1=split(/\./,@een[0]);
@ip2=split(/\./,@een[$#een]);
for ($a=@ip1[0]; $a<1+@ip2[0]; $a++) {
for ($b=@ip1[1]; $b<1+@ip2[1]; $b++) {
for ($c=@ip1[2]; $c<1+@ip2[2]; $c++) {
for ($d=@ip1[3]; $d<1+@ip2[3]; $d++) {
print "$a.$b.$c.$d : ";
system "hping $a.$b.$c.$d @ARGV[1]";
}}}}
Summary
The idea in this chapter is to know which machines are "alive". It is of no use attacking a dead machine. There are several techniques to "hide" hosts. Hosts on unrouted/experimental networks cannot be discovered directly. There are ways to determine if a host is "alive". The simplest way is to ping it. If ICMP is blocked this will not work - then a TCP ping should be considered. One should be really careful how an "alive-scan" is executed as it can raise alarms. The tool nmap can be used very effectively in archiving this.
Before we go on
The next step would be to look for what I call "easy money". Before we can go into the details of this, there are some points to understand. There are some major differences between auditing a network and hacking into a network. Let us look at the analogy of a house. On the one hand you have the true blue blood burglar - the objective is getting into the house with whatever means possible. The burglar looks for the easiest and safest way to get into the house and he does not care about all the other means. On the other hand the security officer - it is his job to tell the client of every single little hole in the house. The difference between the security officer and the burglar is that when the security officer finds the front door wide open he notes it, and looks for other problems, whereas the burglar find the front door open and walks straight in, ignoring the other holes. In the cyber world it works the same. So, hiring a hacker (in the criminal sense of the world) to audit a system is a bit worrisome. The hacker will surely help you to find a weakness in your defense, but the idea of an IT security audit is not this - the idea is to find all the holes and fix them. Once you and your security advisor is confident that all holes are closed you might want to hire a hacker (or penetration specialist) to try to penetrate the network. The bottom line - doing penetration testing and doing a comprehensive security assessment of a network is not nearly the same thing.
This document had come to the point where I have to decide which route we are going to follow - the view of the hacker or the view of the IT security assessment officer. Choosing either one of the options I cannot continue with Citibank as an example unless I want to land in potentially serious trouble. The rest of the document - with the focus on either hacking or assessing will thus be looking at actual client networks - networks we every right to penetrate. The techniques can be implemented at Citibank as well - in the exact same way, but I simply cannot do it right here and now as Citibank is not my client (unfortunately).
No comments:
Post a Comment