Monday, September 27, 2010

Ping -TCP (no service, wrappers, filters)

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 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

No comments:

Post a Comment

hacking tools