Category list

Chapter 7: Network Devices

OVERVIEW

Networks are the backbone of every company. Miles of copper and fiber- optic cable lines provide the groundwork for communication. Typical corporate local or wide area networks (LANs or WANs, respectively) are far from secure. Network vulnerabilities are no small matter, because once attackers take control of your network, they control how your data travels and to whom. In most cases, controlling the network means listening to sensitive traffic, such as e-mail or financial data, or even redirecting traffic to unauthorized systems, despite the use of Virtual Private Networking (VPN) or firewall technology.

Network vulnerabilities, although not as abundant as system vulnerabilities, increase in both quantity and potential devastation every year. Everything from MIB (Management Information Base) information leakage, to design flaws and powerful SNMP (Simple Network Management Protocol) read/write manipulation, when combined, can create a wild world of confusion for network administrators. In this chapter, we'll discuss how attackers find your network, discover devices, identify them, and exploit them to gain unauthorized access to your sensitive data.

Because virtually every commercially available networking device works "out of the box" in an insecure , factory-default state, without the need for any further configuration, there is ample opportunity for a motivated hacker to gain access to a target host. It is on this network level that the most potential information breaches could occur. Whether it is through default passwords/configurations, flaws in application or protocol design, or just accidental configurations, security issues almost always arise from human error. In this chapter, we will discuss the means by which a target may be selected, profiled, and subsequently compromised, with little more than some simple tools and a healthy dose of patience.

DISCOVERY

Within the vast sea of the Internet, targets are easy to find. Most all networks advertise the Internet service provider (ISP) they depend on as well as their design, configuration, hardware types, and potentially vulnerable holes. Keep in mind that most of the normal discovery techniques for information gathering are noninvasive and usually are no more illegal then rattling door handles to check whether doors are open . Depending on the attacker's intensions and the target's legal resources, most find these will be hard, if not impossible , to prosecute .

Detection

Methods of detection can vary; primary detection consists of gathering privileged information without alerting the target. Depending on the target, many techniques will go unnoticed.

Profiling

Partially unobtrusive profiling via port scanning can be performed with a variety of tools, most of which we have discussed in previous chapters. traceroute, netcat, nmap, and SuperScan are some recommended tools to detect and identify devices on your network. Depending on the target of the detection process, many discovery techniques can be seen and logged by an intrusion detection system (IDS). Keep your detection footprint simple and to the point. Most information can be found from the simplest of sources.

dig

Popularity:	10
Simplicity:	10
Impact:	3
*Risk Rating:*	3

dig is an updated replacement for nslookup primarily in the UNIX environment. dig is a very simple tool. Using the easy command-line parameters, one can gather wonders of information about a target's domain names . Here, we can see http://example.com relies on bigisp for its DNS service. We can see http://example.com has redundant e-mail servers. Both mail server entries seem to point to the same IP address. This could be some type of mail server load balancing or custom setup, although it's more likely an administrator misconfiguration. dig gives us a nonintrusive and mostly undetectable look into http://example.com and its dependents.

root@irc.example.com:~# dig -t mx example.com

; <<>\> DiG 9.1.3 <<>\> -t mx example.com
;; global options: printcmd
;; Got answer:
;; ->\>HEADER<<opcode: QUERY, status: NOERROR, id: 5278
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;example.com.                        IN      MX

;; ANSWER SECTION:
example.com.                 34      IN      MX       0 mx2.serv.net.
example.com.                 34      IN      MX       0 mx1.serv.net.

;; AUTHORITY SECTION:
example.com.                 34      IN      NS       dns2.bigisp.com.
example.com.                 34      IN      NS       dns.bigisp.com.
;; ADDITIONAL SECTION:
mx1.serv.net.         86176  IN      A       172.32.45.7
mx2.serv.net.         86151  IN      A       172.32.45.7
dns.bigisp.com.       172534 IN      A       192.168.15.9
dns2.bigisp.com.      172534 IN      A       192.168.15.9

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Mon Nov 24 1:00:01 2002
;; MSG SIZE rcvd: 188

As you can see here, a number of DNS entries have come back that indicate multiple MX, NS, and A records present in the name server. MX records are the DNS entries that map the domain name to a particular mail server. NS records are the name servers that are authoritative for that domain (http://www.example.com). And A records are Address records that map a DNS name (such as mx1.serv.net) to a particular IP address (such as 172.32.45.7). What this tells us is that the various DNS names and IP addresses are associated with this domain (example.com) and they can be targeted for attack.

If the hacker goes after the mail server, he can affect mail traffic. If the hacker goes after the name server, he can affect name resolution services. And in so targeting these systems, the hacker can affect the availability of vital functions within a company. To do this, the attacker could alter the DNS records in the name server and effectively re-route traffic from one IP address to an IP address under his control, thereby redirecting queries for popular websites (such as Microsoft's http://Windowsupdate.microsoft.com or CNN.com) to his own malicious servers instead.

dig Countermeasures

As we noted in Chapter 1, the best countermeasures for DNS inquiries like those performed by dig include securing your DNS infrastructure, such as blocking or restricting zone transfers. Beyond these simple steps, there is little else to do to prevent this information from disclosure, as the designed intent of DNS is to provide it broadly in response to network queries. If you don't want information about a specific host propagated in this way, it probably shouldn't be in your DNS.

traceroute

Popularity:	10
Simplicity:	10
Impact:	3
*Risk Rating:*	8

Using the traceroute or tracert.exe utility included in UNIX or Microsoft Windows, respectively, you can view routers between yourself and a destination host. This provides a good start for targeting a large part of the networking infrastructureroutersand is often the first place attackers will go when targeting the infrastructure. traceroute sends out several packets (UDP and ICMP traceroute packets are used on UNIX and Windows, respectively) to the destination. The first packet's TTL (Time To Live) will be 1 and is increased for each hop discovery. When the packet traverses the router, its TTL is decreased by 1. If the TTL ever hits zero, the packet is dropped. A notification is sent back to the originating source host in the form of an ICMP error packet. Here, we see each hop responding with a TTL- expired ICMP packet, providing us with each hop and the IP address of the network interface closest to the source.

root@irc.example.com:~# traceroute 10.14.208.3
traceroute to 10.14.208.3 (10.14.208.3), 30 hops max, 40 byte packets
 1  64.200.142.202 (64.200.142.202)  0.299 ms  0.33 ms  0.253 ms
 2  sntcca1wcx2-oc48.wcg.net (64.200.151.97)  3.486 ms  3.538 ms 3.989 ms
 3  sntcca4lcx1-pos9-0.wcg.net (64.200.240.126)  3.877 ms  3.795 ms 4.229 ms
 4  p12-1.pr01.sjc03.atlas.psi.net (154.54.10.113)  3.936 ms  3.83 ms 3.852 ms
 5  g9.ba1.sfo1.atlas.cogentco.com (66.28.66.138)  5.916 ms  5.903 ms 5.867 ms

6  customer-2.demarc.cogentco.com (10.14.208.3)  5.955 ms 5.96 ms  6.924 ms

7  z.root-servers.net (7.14.9.50)  6.141 ms  5.955 ms  5.869 ms

Knowing that 10.14.208.3 is the last hop before our target, we can be fairly certain that it is a device that's forwarding traffic. Also, from the reverse DNS received, we can assume this is the target's network start (or demarc , short for demarcation ) point. This is the device (along with every other device in the path ) attackers may target first. But knowing a router's IP address is a far cry from exploiting a vulnerability within it. We'll need to learn much more about this device with port scanning, OS detection, and information leakage before we can take advantage of any known vendor weaknesses.

traceroute Countermeasure

To restrict a router's response to TTL-exceeded packets on a Cisco router, you can use the following ACL:

access-list 101 deny icmp any host 1.2.3.4 11 0 log

For denying traffic directed specifically at a router, the following example is recommended (but may not be appropriate in all situations):

access-list 101 deny ip any host 10.14.208.3 log

Repeat this line, as necessary, for all router interfaces.

Alternatively, you can permit the ICMP packets from a particular trusted network (10.11.12.0/24) only and deny everything else:

access-list 101 permit icmp any 10.11.12.0 0.255.255.255 11 0
access-list 101 deny icmp any host 1.2.3.4 log

For a more in-depth explanation of ICMP restrictions, Rob Thomas's guide is recommended (http://www.cymru.com/Documents/icmp-messages.html).

IP Lookup

The ARIN database at http://www.arin.net is a good information-gathering starting point. As we discussed in Chapter 1, ARIN lookups are very useful to determine what IP ranges a target has, who is in charge, and when the last changes were made. Here's an example:

OrgName:    EXAMPLE
OrgID:      EXAMPLEA

NetRange:   192.168.32.0 192.168.47.255
CIDR:       192.168.32.0/20
NetName:    EXAMPLE
NetHandle:  NET-192-168-32-0-1
Parent:     NET-192-168-0-0-1
NetType:    Reassigned
NameServer: NS1.EXAMPLE.COM
NameServer: NS2.EXAMPLE.COM
Comment:
RegDate:    1999-10-14
Updated:    2001-11-09
AdminHandle: SM0000-ARIN
AdminName: Stuart McClure
AdminPhone: +1-949-555-1212
TechHandle: JS0000-ARIN
TechName:   Joel Scambray
TechPhone:  +1-949-555-1213
TechEmail:  scambrayj@example.com

# ARIN Whois database, last updated 2002-12-03 19:05
# Enter ? for additional hints on searching ARIN's Whois database.

Buy on amazon.com >>

McClure S., Scambray J., Kurtz G.

<< Previous page

Table of contents

Next page >>