Broadly speaking, there are two complementary approaches to determining what hosts are on a network—you can sweep the entire network using scanning tools as described in Chapter 10, or you can find sources that will tell you what hosts are available. Both approaches have merit—information sources such as DNS, LDAP directories, WINS, and NetBIOS enable you to quickly determine which hosts play important roles. By sweeping a network, you often find hosts that are hidden or considered unimportant, but you’re also much more likely to be noticed. This chapter focuses on using common network databases to discover the available hosts. Network sweeping techniques are the subject of Chapter 10.
First, let’s take a look at how DNS works. This is only a brief overview; DNS is a complicated subject and the topic of several good books. Generally, the better someone is at administering and running networks, the better he or she will be at penetration testing and security. After all, hacking is just administering systems you’re not supposed to be able to!
More Info
The classic reference is DNS and BIND, Fourth Edition, (O’Reilly & Associates, 2001) by Paul Albitz and Cricket Liu. You can also find multiple DNS RFCs at http://www.dns.net/dnsrd/rfc/.
Since the release of Windows 2000 Server, Microsoft operating systems have been increasingly reliant on DNS, and there are DNS record types that will always be found on a Windows 2000 (or later) domain. Several books focus on the implementation of DNS in Microsoft products, as does the Microsoft Resource Kit series. Also helpful (and cheap) is to Read The Fine Manual (RTFM) pages—pull the MMC DNS snap-in, and click Help. The Help topics on my Windows 2000 Server for DNS are exceptionally thorough.
The DNS protocol allows for a number of different record types, and each has important implications for a penetration test. In this section you’ll look at the most common types. Although the examples use nslookup, nslookup is an older tool; on many UNIX systems you’ll find that dig and host are also used. Dig has also been ported to Windows and can be obtained from ftp://ftp.isc.org/isc/bind/contrib/ntbind-9.2.3/BIND9.2.3.zip.
A Start of Authority (SOA) record is required for every domain and must be the first entry in all forward and reverse lookup zones. It states which DNS server is authoritative for any given domain. To obtain an SOA record for a domain, start a command prompt, and type nslookup with no additional arguments. This opens an nslookup prompt, and a number of useful queries are possible. Here’s an example using Microsoft.com:
C:>nslookup
Default Server: mydns.mynetwork.local
Address: 192.168.0.7
> set type=SOA
> microsoft.com
Server: mydns.mynetwork.local
Address: 192.168.0.7
Non-authoritative answer:
microsoft.com
primary name server = dns.cp.msft.net
responsible mail addr = msnhst.microsoft.com
serial = 2003091901
refresh = 300 (5 mins)
retry = 600 (10 mins)
expire = 7200000 (83 days 8 hours)
default TTL = 3600 (1 hour)
microsoft.com nameserver = dns1.cp.msft.net
microsoft.com nameserver = dns1.tk.msft.net
microsoft.com nameserver = dns3.uk.msft.net
microsoft.com nameserver = dns1.dc.msft.net
microsoft.com nameserver = dns1.sj.msft.net
dns1.cp.msft.net internet address = 207.46.138.20
dns1.tk.msft.net internet address = 207.46.245.230
dns3.uk.msft.net internet address = 213.199.144.151
dns1.dc.msft.net internet address = 64.4.25.30
dns1.sj.msft.net internet address = 65.54.248.222
>From the results, you can tell that Microsoft has its main DNS servers located in five different data centers, and you might guess (correctly) from the naming conventions that they are distributed geographically as well. This information gives you an idea of what networks Microsoft might use for important data centers, and if you wanted to try a zone transfer, an authoritative server gives you the best information. Give it a try—the nslookup command to obtain all the records is ls –d DOMAIN:
> server dns1.cp.msft.net Default Server: dns1.cp.msft.net Address: 207.46.138.20 > ls -d microsoft.com [dns1.cp.msft.net]
You should still be waiting for the reply—it seems that the people running the Microsoft DNS servers have prohibited zone transfers by blocking traffic to TCP 53, probably in addition to disallowing zone transfers at the servers.
Name server (NS) records list the name servers for a particular domain—for the most part, NS and SOA records will be the same. You might find instances where secondary name servers are listed as an NS record but not as an SOA record.
An address (A) record is the most familiar type of record—it is the one you use when you want to map a host name to an IP address. An address record looks like this:
Host A 192.168.0.1
When you type nslookup host or ping host, you are requesting an address lookup. It is also possible that you’ll end up resolving an alias, which will be covered next. If you’re dealing with Windows systems, an IP address also might be resolved with NetBIOS. One way to tell the difference is that nslookup can use only the DNS resolver to obtain information, but ping can use all available methods. If a name resolves with ping, but not with nslookup, the information was provided using NetBIOS.
A canonical name (CNAME) record is also known as an alias. A CNAME is used when you want to provide a server with different names or a well-known name, or to map several physical servers to the same name. Two common examples are www.example.com and mail.example.com. A CNAME record might look like this:
www CNAME realname
A pointer (PTR) record enables a reverse lookup. A reverse lookup starts with an IP address and resolves back to a host name. Whether a DNS server supports reverse lookups can be a matter of preference—some servers can be configured to deny access unless a reverse lookup succeeds. This is a weak security measure and certainly a nuisance if the FTP server you’re trying to get the files from won’t let you log on. Disabling reverse lookups can reduce information leaks for your domain by not allowing an attacker to accomplish what amounts to a zone transfer by reverse lookup. Here’s how it works if reverse lookups are available:
C:>for /l %d in (1, 1, 10) do nslookup 192.168.0.%d C:>nslookup 192.168.0.1 Server: mydns.mynetwork.local Address: 192.168.0.7 Name: host1.mynetwork.local Address: 192.168.0.1 C:>nslookup 192.168.0.2 Server: mydns.mynetwork.local Address: 192.168.0.7 *** mydns.mynetwork.local can't find 192.168.0.2: Non-existent domain [more non-existent systems omitted] C:>nslookup 192.168.0.6 Server: mydns.mynetwork.local Address: 192.168.0.7 Name: mydc.mynetwork.local Address: 192.168.0.6 C:>nslookup 192.168.0.7 Server: mydns.mynetwork.local Address: 192.168.0.7 Name: mydns.mynetwork.local Address: 192.168.0.7 C:>nslookup 192.168.0.8 Server: mydns.mynetwork.local Address: 192.168.0.7 Name: host2.mynetwork.local Address: 192.168.0.8 C:>nslookup 192.168.0.9 Server: mydns.mynetwork.local Address: 192.168.0.7 *** mydns.mynetwork.local can't find 192.168.0.9: Non-existent domain C:>nslookup 192.168.0.10 Server: mydns.mynetwork.local Address: 192.168.0.7 Name: host3.mynetwork.local Address: 192.168.0.10 C:>
If you set type to mail exchange (MX), and query a domain name, you’ll get a listing of the primary external mail servers for the domain. If you’re dealing with a small network, it is possible that the mail server actually belongs to the Internet service provider (ISP), which won’t be very happy to find you checking the security of its server. Larger companies run their own mail servers. If you’re doing an external penetration test, it’s important to include the mail servers.
The primary reason to include mail servers in your penetration tests is that e-mail often contains proprietary information. One company experienced a situation where the competition’s representatives kept showing up at customers’ offices at about the same time as their own did. It turned out that the company’s mail server had been compromised. Coincidence? Or industrial espionage?
A secondary reason to include mail servers is that mail servers are often dual homed between the Internet and internal networks and sometimes have a firewall rule that allows direct access to an internal mail server. If this isn’t bad enough, it is all too common for that firewall rule itself to be misconfigured, allowing access to much more than it should. Chapter 12, explains how to check for misconfigured firewalls. Getting e-mail in and out of networks, especially if the company allows external access to mail, almost always results in trade-offs between usability and security. The proper way to mitigate the risk is to use a heightened level of security administration on the systems involved, but this is why you’re checking, right?
Take a look at the results from a typical MX query:
[assumes we're already at a nslookup prompt] > set type=MX > microsoft.com Server: mydns.mynetwork.local Address: 192.168.0.7 Non-authoritative answer: microsoft.com MX preference = 10, mail exchanger = mailb.microsoft.com microsoft.com MX preference = 10, mail exchanger = mailc.microsoft.com microsoft.com MX preference = 10, mail exchanger = maila.microsoft.com microsoft.com nameserver = dns1.cp.msft.net microsoft.com nameserver = dns1.tk.msft.net microsoft.com nameserver = dns3.uk.msft.net microsoft.com nameserver = dns1.dc.msft.net microsoft.com nameserver = dns1.sj.msft.net mailb.microsoft.com internet address = 131.107.3.122 mailb.microsoft.com internet address = 131.107.3.123 mailc.microsoft.com internet address = 131.107.3.121 mailc.microsoft.com internet address = 131.107.3.126 maila.microsoft.com internet address = 131.107.3.124 maila.microsoft.com internet address = 131.107.3.125 dns1.cp.msft.net internet address = 207.46.138.20 dns1.tk.msft.net internet address = 207.46.245.230 dns3.uk.msft.net internet address = 213.199.144.151 dns1.dc.msft.net internet address = 64.4.25.30 dns1.sj.msft.net internet address = 65.54.248.222 >
This sample shows that the Microsoft mail servers are named maila, mailb, and mailc. The preference field allows an administrator to tell the server on the other end which servers are preferred—in this case, all three servers are equally preferred. Lower numbers indicate a higher preference. Finally, the names of the mail servers are mapped to their IP addresses.
The service locator (SRV) record type shows where services are located. It tends to be an unusual record type, except where there’s a Microsoft Windows 2000 domain controller. Let’s take a look at what some common SRV records look like:
> ls -t SRV mynetwork.local [mydc.mynetwork.local] _kerberos._tcp.Default-First-Site._sites.dc._msdcs SRV priority=0, weight=100, port=88, mydc.mynetwork.local _ldap._tcp.Default-First-Site._sites.dc._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _kerberos._tcp.dc._msdcs SRV priority=0, weight=100, port=88, mydc.davenet.local _ldap._tcp.dc._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _ldap._tcp.b8ffe4e1-13ec-4571-a336-e3d2a8b1cea1.domains._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _ldap._tcp.Default-First-Site._sites.gc._msdcs SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _ldap._tcp.gc._msdcs SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _ldap._tcp.pdc._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _gc._tcp.Default-First-Site._sites SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _kerberos._tcp.Default-First-Site._sites SRV priority=0, weight=100, port=88, mydc.mynetwork.local _ldap._tcp.Default-First-Site._sites SRV priority=0, weight=100, port=389, mydc.mynetwork.local _gc._tcp SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _kerberos._tcp SRV priority=0, weight=100, port=88, mydc.mynetwork.local _kpasswd._tcp SRV priority=0, weight=100, port=464, mydc.mynetwork.local _ldap._tcp SRV priority=0, weight=100, port=389, mydc.mynetwork.local _kerberos._udp SRV priority=0, weight=100, port=88, mydc.mynetwork.local _kpasswd._udp SRV priority=0, weight=100, port=464, mydc.mynetwork.local >
The fields have the following syntax:
service.protocol.name ttl class SRV priority port target
Service. A name such as _ldap for an LDAP server, _smtp for mail, or _telnet for a Telnet server. These are defined in RFC 1700.
Protocol. Indicates the transport type; typically either TCP or UDP, though technically any transport can be used.
Name. The DNS domain name referenced by this record.
Priority. The preference for this record, similar to the MX records. Weight is used as a secondary input for load balancing reasons.
Port. The port number for the service. Usually, but not always, a well-known port number.
Target. The host that provides the service.
In the previous query, you saw that mydc.mynetwork.local provides LDAP, Kerberos, and GC (global catalog). This type of lookup is how Windows 2000 and later systems find a domain controller on a domain join. One obvious thing to check for during an external test is whether SRV records are available externally—you getting to them indicates anything from an internal information leak to an externally exposed domain controller. If you’re working on an internal network that has native Windows 2000 or later domains, running an SRV query is a quick way to find the domain controllers. In the previous example, you used a zone transfer listing, but you can query directly on individual services:
> _ldap._tcp.dc._msdcs
Server: mydc.mynetwork.local
Address: 192.168.0.6
_ldap._tcp.dc._msdcs.mynetwork.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = mydc.mynetwork.local
mydc.mynetwork.local internet address = 192.168.0.6
mydc.mynetwork.local internet address = 192.168.1.1
>Reading the results carefully, you can learn some things about the network. So far, you’ve seen a few systems ranging from 192.168.0.1 to 192.168.0.10, but now you also see that the domain controller is dual homed into a 192.168.1.x network and is probably acting as a gateway. It doesn’t actually go anywhere, but you do end up chasing a lot of loose ends when conducting network audits.
There are a number of less common record types—see the RFC, or look for the topic "resource records reference" in the Help system on a Windows 2000 DNS server. One record type you should start seeing more of is the AAAA record—this maps names to Internet Protocol version 6 (IPv6) addresses. It’s sometimes worthwhile to poke around in odd corners of protocol specifications—the less-used features often help you determine what software (and often what type of host) is running a certain service. A good source for finding protocol specifications in a well-organized manner is http://www.rfc-editor.org.
Another interesting record type to try is:
set class=chaos type=txt version bind
If the system is running BIND, it will give you the version type. There have been a large number of vulnerabilities in BIND, so this is useful information. Other DNS implementations might or might not support this feature. Microsoft’s DNS service does not leak version information, but knowing the version of a Microsoft DNS server isn’t very interesting because there have been very few vulnerabilities in the Microsoft implementation. Chapter 12, goes into more detail about determining the type of operating system.
If a zone transfer is available, you can use it to learn a lot about the network you’re examining. You obtain a zone transfer by using the ls (list) command from an nslookup prompt. There are three options: –a lists only CNAME and A records, –d gets all records, and –t TYPE gets all records of the specified type. Because many domains are very large, you can also append > filename to dump the results to a file. Take a look at the results:
> ls -d mynetwork.local [mydc.mynetwork.local] mynetwork.local. SOA mydc.mynetwork.local admin. (27042 900 600 86400 3600) mynetwork.local. A 192.168.1.1 mynetwork.local. A 192.168.0.6 mynetwork.local. NS mydc.mynetwork.local c47a8d61-4e8a-429b-a6dd-23d99af3d979._msdcs CNAME mydc.mynetwork.local _kerberos._tcp.Default-First-Site._sites.dc._msdcs SRV priority=0, weight=100, port=88, mydc.mynetwork.local _ldap._tcp.Default-First-Site._sites.dc._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _kerberos._tcp.dc._msdcs SRV priority=0, weight=100, port=88, mydc.mynetwork.local _ldap._tcp.dc._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _ldap._tcp.b8ffe4e1-13ec-4571-a336-e3d2a8b1cea1.domains._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local gc._msdcs A 192.168.1.1 gc._msdcs A 192.168.0.6 _ldap._tcp.Default-First-Site._sites.gc._msdcs SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _ldap._tcp.gc._msdcs SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _ldap._tcp.pdc._msdcs SRV priority=0, weight=100, port=389, mydc.mynetwork.local _gc._tcp.Default-First-Site._sites SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _kerberos._tcp.Default-First-Site._sites SRV priority=0, weight=100, port=88, mydc.mynetwork.local _ldap._tcp.Default-First-Site._sites SRV priority=0, weight=100, port=389, mydc.mynetwork.local _gc._tcp SRV priority=0, weight=100, port=3268, mydc.mynetwork.local _kerberos._tcp SRV priority=0, weight=100, port=88, mydc.mynetwork.local _kpasswd._tcp SRV priority=0, weight=100, port=464, mydc.mynetwork.local _ldap._tcp SRV priority=0, weight=100, port=389, mydc.mynetwork.local _kerberos._udp SRV priority=0, weight=100, port=88, mydc.mynetwork.local _kpasswd._udp SRV priority=0, weight=100, port=464, mydc.mynetwork.local mydc A 192.168.1.1 mydc A 192.168.0.6 host1 A 192.168.0.1 host1xp A 192.168.0.8 host2 A 192.168.0.7 proxy CNAME host2.mynetwork.local host3 A 192.168.0.10 mynetwork.local. SOA mydc.mynetwork.local admin. (27042 900 600 86400 3600)
You’ve examined all the record types already, but an interesting CNAME record shows up here. It seems that "proxy" maps to host2. You didn’t explicitly add that entry—the Microsoft Internet Security and Acceleration Server (ISA) firewall helpfully did it for you. It is nice that new hosts on the network can automatically discover where their proxy is, but it is also good to be aware of the information your system is generating. Information like this underscores why you do not want to mirror your entire internal DNS information to your external DNS servers.
Until fairly recently, Windows networks did not use DNS as a primary mechanism to perform name resolution. One of the problems with DNS is that you need at least one central server and a way to update it. Those requirements are easily met on most moderate and large networks but can be difficult if there is no central administration. The NetBIOS functions were also developed for a time when most networks were small and disconnected. Unlike DNS, NetBIOS name resolution is transport-independent and works much the same whether the underlying network is NetBEUI, IPX, or TCP/IP. Rather than discuss the benefits and drawbacks of such a system, this section focuses on how you can use it to gather information.
There are two primary repositories for NetBIOS information—the browser and the WINS database. The NetBIOS namespace is flat, meaning that you should not have two hosts with the same base name. The names are limited to 15 characters, and there is a sixteenth character that describes the type of record. Chapter 11 takes a closer look at this along with the information you can extract from an individual host. NetBIOS names also can have a scope to allow for multiple instances of the same name, but NetBIOS scopes are rarely used and are discouraged.
The Computer Browser service is responsible for implementing browser functionality on a Windows system. An important issue to be aware of when conducting a penetration test is this: if you have increased the security of your system by disabling NetBT (NetBIOS over TCP/IP) or disabling the Computer Browser or Messenger services, you won’t be able to gather information using these services. It is always important to be sure that the system used to collect security-sensitive data is secure, but there are trade-offs to consider. You might prefer to run your systems with these services disabled—and if you have Windows 2000 and later, disabling the services can be done with little loss of functionality—however, there have been few security patches for these services and you won’t be taking much risk by enabling them on your testing system, especially if you keep your patches up to date.
There are three types of providers for browser information—Domain Master Browser, Master Browser, and Backup Browser. On each subnet there is one system that performs the Master Browser role, and all other Windows servers are Backup Browsers unless specially configured not to perform the role of Browser. These systems each keep a copy of all the browser information for their subnet, which is gathered when all systems on the subnet announce themselves. The Domain Master Browser is the primary domain controller (or PDC emulator when the domain is running on Windows 2000 or later), and periodically collects browse lists from all the Master Browser systems, merges the lists, and then pushes the merged list back to the Master Browser systems. As you might imagine, this system is fairly inefficient and chatty on the network.
WINS is a name-resolution service designed to make the NetBIOS name resolution somewhat more efficient. Instead of relying on local browse lists, a system is configured to register names with a central server and to first query that server to resolve names. It is possible to launch specific queries to find certain types of services—all the domain controllers or all the systems that are running Microsoft SQL Server, for example.
Now, let’s take a look at how all this works. If you prefer a graphical interface, just open My Network Places (or Network Neighborhood on versions earlier than Windows 2000). Double-click Entire Network and then Microsoft Windows Network. At this point, you’ll be presented with a list of domains. Further analysis or "drilling down" on a domain yields a list of systems that participate in the browser system—for example, your ISA server doesn’t show up because you selected the higher security setting on installation, and it disabled a number of services. Further drilling down on a single system yields a list of the nonhidden shares, any shared printers, and scheduled tasks.
Using a graphical interface is nice for just poking around, but if you want to create a script to perform a security audit on a number of systems, it is more convenient to use the command line and redirect the output to a file:
C:>net view /domain Domain ---------------------------------------------------------------- MYDOMAIN The command completed successfully.
If there are several domains, each one that participates in the browser system is listed. Now for a list of systems in each domain:
C:>net view /domain:MYDOMAIN Server Name Remark ----------------------------------------------------- \HOST1 \HOST2 \MYDC The command completed successfully.
Some systems also return comments, which can be interesting. I have heard of passwords ending up in the comments. You can finally drill down on each system with:
C:>net view \mydc Shared resources at \mydc Share name Type Used as Comment ------------------------------------------------------------------- ftp Disk HPLaserJ Print HP LaserJet 4L/4ML PostScript NETLOGON Disk Logon server share SYSVOL Disk Logon server share updates Disk The command completed successfully.
Successful penetration tests can be conducted using little more than batch files and command-line tools that ship with the operating system. If you pipe the output of these commands into a file, and delete the header and footer information, you can invoke any command you like on each host using the FOR command. Here’s an example:
C:TEMP>for /f %d in (hosts.txt) do net view %d C:TEMP>net view \MYDC Shared resources at \MYDC Share name Type Used as Comment ----------------------------------------------------------------- ftp Disk HPLaserJ Print HP LaserJet 4L/4ML PostScript NETLOGON Disk Logon server share SYSVOL Disk Logon server share updates Disk The command completed successfully. C:TEMP>net view \HOST1 Shared resources at \HOST1 Share name Type Used as Comment ----------------------------------------------------------------- install Disk The command completed successfully. C:TEMP>net view \HOST2 System error 5 has occurred. Access is denied.
You can even check for blank passwords by issuing this command:
for /f %d in (hosts.txt) do net use %d /user:administrator ""
The Lightweight Directory Access Protocol (LDAP) is used to create directories of many different resources used by several different operating systems and services. The structure of these databases varies from one implementation to another, and there isn’t room here to discuss all of them. If you can gain access, or are granted access to an LDAP directory, you can often list users, computers, printers, and much more. Active Directory as implemented in Windows 2000 Server uses LDAP as a communication protocol, and you can query it directly with ordinary LDAP client tools, as well as VBScript. By default, you won’t get much information from a query against Active Directory without being an authenticated user.