bing-ip2hosts - Enumerating All Hostnames/Domains Associated with an IP

While I'm still a Google fan, Andrew Horton/urbanadventurer of MorningStar Security (http://www.morningstarsecurity.com/research/bing-ip2hosts) has written a script to use Bing to enumerate all of the hostnames associated with a particular IP address.

Of course, I love integrating new tools with my Backtrack 4 installation, so I use the following commands to do so:

mkdir /pentest/enumeration/bing
cd /pentest/enumeration/bing
wget http://www.morningstarsecurity.com/downloads/bing-ip2hosts-0.2.tar.gz
tar -zxvf bing-ip2hosts-0.2.tar.gz
cd bing-ip2hosts-0.2

Once "installed", I use the script to search for all domains and hostnames associated with nbc.com as a test ('./bing-ip2hosts nbc.com'). As you can see, the script enumerates quite a number of domains and hostnames, especially of interest for a TV show geek like myself.

A few personal favorites:

chuckmeout.com - For great shows I hope that don't get canceled
votepetrelli.com - For once great shows that I hope get canceled
whoframedcharlie.com - For a great show that did get canceled
princessunicorndoll.com & sensualsexuality.com - All of this from The Office (and links are SFW)
estradaornada.com - The name alone...
greendalecommunitycollege.com - From my favorite new comedy

Of course, one does start to see the pen testing advantages by using a tool like bing-ip2hosts to find additional targets for testing, not just finding geeky TV show sites to play with - though these are good too.

Configuring a Basic Packet Capture for a Cisco FWSM Context

If you maintain a Cisco FWSM (FireWall Service Module) and keep an eye on your logs for security issues that might arise, you're more than likely going to want to quickly configure a packet capture to gain a better understanding of the questionable traffic you have identified on the network.

To configure a basic packet capture for a FWSM context, you must first create Access Control Lists (ACL’s) to identify the traffic that you want to capture. Once the ACL’s have been created, you’ll need to create the packet captures themselves – one for each interface you want to capture traffic on.

1. Create ACLs to Specify Traffic to be Captured
Before configuring and enabling the captures themselves, you first need to identify the traffic you want to capture using an ACL. A simple ACL to capture all traffic (IP, TCP and UDP traffic on all ports) would look like:

access-list capture_all extended permit ip any any

Of course, capturing all traffic passing through a FWSM context could result in a very large capture file very quickly. To limit the size of your capture file, consider creating specific ACL's for the traffic of interest you want to capture. For example, you could use the following capture to record the outbound traffic of an internal host (192.168.1.10) that is attempting to propogate malicious code over TCP port 135 to all available external hosts :

access-list capture_tcp135 permit tcp host 192.168.1.10 any eq 135

For more information on creating Cisco ACL's, please visit http://bit.ly/1aCgkx (at Cisco.com).

2. Create Capture to Record Traffic on the Context Interface(s)
Once the appropriate ACL’s have been created to identify what traffic you want to capture, you’ll need to create the captures themselves which specify which interfaces you’ll want to record the packets on.

More than likely, you’ll want to capture traffic on both the internal and external interfaces when examining network traffic. Additional interfaces might exist as well that should be considered for review.

For example, the following command will create a capture named ‘capin’ to record all traffic that passes through the internal interface that matches the traffic defined in the ACL ‘capture_tcp135’.

capture capin interface inside access-list capture_tcp135

The second capture, named ‘capout’, will capture all traffic that passes through the external interface that matches the pattern specified in the ACL ‘capture_all’.

capture capout interface outside access-list capture_all


Script to Capture All Traffic on Internal & External Interfaces
The following script creates an ACL named ‘capture_all’ to identify all IP traffic for recording. Then, a capture for all internal traffic is created named ‘capin’ along with a capture for all external traffic named ‘capout’. The last statement displays the status of each existing capture within the FWSM context.

config t
access-list capture_all permit ip any any
capture capin interface inside access-list capture_all
capture capout interface outside access-list capture_all
exit
sh capture

Reviewing Packet Captures
Once the captures are created, you can verify their existence using the ‘show capture’ command to list all captures currently active within the FWSM context:

router/CONTEXT# sh cap

capture capin type raw-data access-list capture_all interface inside[Capturing - 0 bytes]
capture capout type raw-data access-list capture_all interface outside[Capturing - 0 bytes]

As data passes through each interface that matches the previously defined ACL’s for capture traffic, you’ll note that the amount of data captured increases as frames are recorded:

router/CONTEXT# sh cap

capture capin type raw-data access-list capture_all interface inside[Capturing - 39792 bytes]
capture capout type raw-data access-list capture_all interface outside[Capturing - 39872 bytes]


Viewing a Packet Capture
To view the packets captured, use the ‘show capture x’ command – where ‘x’ is the name of the capture you wish to view. For example, ‘show capture inside’ will display the contents of the capture named ‘inside’ in a format similar to tcpdump/Windump.

In the below example, we can see a snippet of the traffic between an internal system (192.168.1.50) visiting google.com over HTTP.

109: 11:45:27.1918032530 P0 192.168.1.50.2935 > 209.85.225.113.80: P 2908144803:2908145748(945) ack 3047889605 win 64488
110: 11:45:27.1918032580 P0 209.85.225.113.80 > 192.168.1.50.2935: P 3047889605:3047889954(349) ack 2908145748 win 12311
111: 11:45:27.1918032830 P0 192.168.1.50.2935 > 209.85.225.113.80: . ack 3047889954 win 65535

In the next blog entry, we’ll look at how we can access FWSM captures in Wireshark/Pcap format and use Wireshark features for troubleshooting malicious activity.

Testing for DNS Recursion with Nmap (--script=dns-recursion)

From time to time, I need to test a remote system to determine whether or not its DNS service allows for recursive DNS requests - typically in response to a DNS server being reported for participating in a
DNS Amplification/Recursive/Reflector DDoS attack. For further technical information on DNS Amplification attacks, please visit http://www.securiteam.com/securityreviews/5GP0L00I0W.html.

Using Nmap and one of the pre-built Nmap Scripting Engine (NSE) scripts by Felix Groebert, we can test whether or not a host running DNS will allow for a “non-authorized” recursive query from the Internet. For testing, you’ll want to specify the script (--script=dns-recursion) as well as limit the port to the DNS service port, UDP 53, you are testing (-sU –p53).

In the following example, we use Nmap to test whether or not the remote DNS server at 216.146.35.113 allows for recursion.

C:\>nmap 216.146.35.113 --script=dns-recursion -sU -p53

Starting Nmap 5.21 (http://nmap.org ) at 2010-03-10 18:31 Eastern Standard Time

NSE: Script Scanning completed.
Nmap scan report for 216.146.35.113 (216.146.35.113)
Host is up (0.00s latency).
PORT STATE SERVICE
53/udp open|filtered domain
|_dns-recursion: Recursion appears to be enabled

Nmap done: 1 IP address (1 host up) scanned in 2.66 seconds

Based on the Nmap output above, we are told that “Recursion appears to be enabled” on the remote server.

Using Wireshark, we can view the “quite interesting” packets generated by a DNS Recursion scan performed by Nmap against a DNS server that is advertised on the Internet to allow recursive lookups.



In the sample above (our traffic of interest starts with Packet #3), we can see:

Packet #3: Our first packet from our test system to the target DNS server is an Echo ping request to determine if the remote server replies. Reply seen in Packet #7.
Packet #4: Nmap sends a SYN packet to TCP 443.
Packet #5: Nmap sends an ACK packet to TCP 80.
Packet #6: Nmap sends ICMP Timestamp request.
Packet #7: ICMP Echo Reply received from target host (in response to Packet #3)
Packet #8: Nmap perfoms a reverse DNS lookup using its own DNS server (4.2.2.2).
Packet #9: ICMP Timestap reply to Packet #6 from target host.
Packet #10: External DNS host replies with answer for reverse DNS lookup in Packet #8.
Packet #11: Nmap submits “Server status request”.
Packet #12: Target host ‘rejects’ the “Server status request” from Packet #11.
Packet #13: ICMP ‘Destination Unreachable’ (Type 3, Code 3) message.
Packet #14: Nmap submits a DNS query for www.wikipedia.org to the DNS server.
Packet #15: Nmap receives the successful DNS query reponse for www.wikipedia.org indicating the target host allows for recusive DNS lookups.

REMEMBER – While Port UDP 53 is used to perform DNS resolution, DNS Port TCP 53 is used by DNS servers to exchange records by performing zone transfers. If you use a default Nmap scan without specifying UDP 53, Nmap will perform a default scan of the most common 1,000 TCP ports. With no UDP ports or DNS service to test, there are no results from the script other than the default Nmap output.


C:\>nmap x.x.x.x --script=dns-recursion

Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-10 18:31 Eastern Standard Time

Nmap scan report for x.x.x.x (x.x.x.x)
Host is up (0.00081s latency).
Not shown: 992 filtered ports
PORT STATE SERVICE
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
139/tcp closed netbios-ssn
443/tcp open https
3389/tcp open ms-term-serv

Nmap done: 1 IP address (1 host up) scanned in 7.06 seconds

Locking Down your DNS Services
Keep in mind, your internal DNS server should only be available to your internal hosts. If you do need to host a DNS server on the Internet for outside parties to find your publicly available resources (such as if you were a web hosting company), then make sure to disable your DNS server’s recursive functionality.

"Ethical Hacking": Basics to Advanced Techniques

Back in January, I presented on "Ethical Hacking" at the Upstate SC ISSA Chapter's monthly meeting (www.upstate-issa.org). Not a fan myself of the "Ethical Hacking" term (I think of Jack Daniel and his "reluctant CISSP" label here - blog.uncommonsensesecurity.com), we discussed the evolution of the term over the last five years or so, along with the rise of the Certified Ethical Hacker (CEH) and other similar certifications. The main focus of the presentation was to introduce attendees to the final release of BackTrack 4 and the numerous tools it offers for penetration testing, ethical or not, along with each step of pen testing as outlined within the BackTrack 4 menu itself:

- Information Gathering
- Network Mapping (typically my favorite section as a non-recovering Nmap addict)
- Vulnerability Identification
- Penetration
- Privilege Escalation
- Maintaining Access

While unfortunately our presentation was limited on time and we weren't able to cover some of the great services BackTrack 4 offers like the automated Snort installation or vulnerability assessments using OpenVAS, we were able to wrap up with examples of our friend Metasploit and the Social Engineering Toolkit. I've been a long time fan of BackTrack going back to the Whax/Auditor and BT1 days, when it was easier to say BackTrack than Knoppix 'STD' without someone laughing. BackTrack 4 is by far the most useful release we've seen to date from the Remote Exploit gang (remote-exploit.org) and it makes up for any issues or deficiencies that might have existed in BT3 (not that I'm saying there were any). Such love and incredible craftsmanship went into this distribution without question.

Hint to New BackTrack Users - Just don't forget to enable BackTrack 4's network service using sudo start-network. I can't tell you how many different systems I originally tried using the BackTrack 4 BETA on thinking the newer network cards weren't supported in BackTrack 4. No words of frustration were intentially directed at BackTrack 4 or the Remote Exploit folks during this time.

A copy of the presentation slides can be found at
http://members.nuvox.net/~mholcomb/training/ISSA/Ethical%20Hacking%20-%20Bacics%20to%20Advanced%20Techniques.ppt.