In the previous chapter we saw how to know where your target is. As we have seen, this is not such a simple matter as your target might be a international company (or even a country). Mapping the presence of the target on the Internet is only the first part of gaining intelligence on your target. You still have no idea of the operating system, the service(s) running on the server. At this stage we are still not doing any "hacking", we are only setting the stage for the real fun. If the previous chapter was finding the correct houses, this chapter deal with strolling past the house, peeping through the front gate and maybe even ringing the doorbell to see if anyone answers.
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
- 24 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
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 --
- 25 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
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)
To Be Continued............
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
- 24 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
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 --
- 25 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
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)
To Be Continued............
No comments:
Post a Comment