This comes as welcome news by the cyber security community as EstDomains.com has been used by cyber criminals for years to hide their identities and conduct various malicious activities such as using domains for bot command & control servers, drive-by downloads as well as spamming.

Here are some links of interest that provide more information on this story:

1. F-Secure Weblog - “Case EstDomains” 
2. The Washington Post Company – “ICANN De-Accredits EstDomains for CEO’s Fraud Convictions”
3. Notice sent to EstDomains.com by ICANN (pdf)

The above two modules require you run Metasploit Framework from the “trunk” development branch which is currently only supported on the Linux platform.

Here’s more from the official blog:

The first flaw is that since DNS (over UDP) is connectionless, it can easily be spoofed. The original primary mitigation against this was to make use of a 16-bit transaction ID which is used to correlate requests and replies that the attacker would have to guess in order to correctly spoof a reply packet. This makes spoofing harder, but not an insurmountable task; you just need to be able to send a whole lot of packets to eventually get one right at match the transaction ID chosen for the request packet.

The second flaw was that additional records would be inserted into the cache which were included in replies from another nameserver. This is core protocol functionality, however the original problem was somewhat mitigated by creating the in-bailiwick constraints that essentially limits the domain space for additional records that could be sent in the replies to hostnames from a given domain. Sounds reasonable; this prevents nameservers from doing malicious things to records in domains that they weren’t queried for or aren’t authoritative for, while still allowing nameservers who are authoritative for a domain to update the records they need to.

When you combine the attacks for these two flaws however, and introduce nameserver query recursion, an attacker can essentially cause the target nameserver to make as many queries as the attacker wants while also pretending to be the authoritative nameserver and spoofing the responses, achieving the birthday attack against the transaction ID and successfully updating the nameserver record for a domain to point to a malicious nameserver address. You can also use this trick to inject cache entries for individual hostname records as long as those hostnames are both not already cached, and also in-bailiwick.

Update - both the above mentioned Metasploit modules have been updated for improved reliability (and effectiveness!). Support for FreeBSD, NetBSD, BSDi and Mac OS X has been added. Here’s more from the official blog:

The bailiwicked modules (host and domain) were updated today to include the ability to predict the time window between the outgoing request from the target nameserver and the response from the real nameserver(s). This measurement is used to tune the number of spoofed replies sent by the exploit. The result is a big increase in exploit reliability, especially when the target domain has a ton of nameservers (Yahoo has eight) or changes its responsiveness during the test (BIND tends to slow down when it has a full cache). The new self-tuning code is activated with the XIDS option is set to ’0′, which is now the default. FreeBSD and Mac OS X support are still in the works, but should be functional sometime this weekend. The timing analysis feature can also be access through a new command (‘racer’). In the examples below, the first command tests the timing between the nameserver at 192.168.0.2 and the metasploit.com DNS servers. The second command tests the timing between the nameserver 4.2.2.3 (a public DNS server) and the metasploit.com DNS servers. You can see by the results that the timing differences are significant:

msf auxiliary(bailiwicked_host) > racer 192.168.0.2 metasploit.com
[*] race calc: 50 queries | min/max/avg time: 0.05/0.23/0.09 | min/max/avg replies: 6/121/49

msf auxiliary(bailiwicked_host) > racer 4.2.2.3 metasploit.com
[*] race calc: 50 queries | min/max/avg time: 0.02/0.17/0.05 | min/max/avg replies: 1/29/6

In the first case (192.168.0.2), the average number of queries we can send before the real server replies is around 49, which means about 80 fake responses. In the second example, the average is only 6, which means about 12 fake responses. To be conservative, these modules take the average, multiple it by 1.5, then divide it by the number of nameservers. This leads to a fairly accurate timing estimate and quicker attacks.

Update (July 29 – 11AM +4GMT) – I just saw a demo of ISR-evilgrade by Infobyte Security Research, a toolkit that works in conjunction with the above mentioned Metasploit exploit modules, to exploit software products that carry out automatic updates of the binaries over insecure channels, using MITM techniques (Hint: DNS!).

The first release of the toolkit contains exploits for Sun Java, Winzip, Winamp, Mac OS X, OpenOffice, iTunes, Linkedin Toolbar, DAP, Notepad++, and Speedbit.

It is interesting to note that Mac OS X does not have a patch for the DNS vulnerability as of this writing.

ITAF^TM consists of compliance and good practice setting guidance:

• Provides guidance on the design, conduct and reporting of IT audit and assurance assignments
• Defines terms and concepts specific to IT assurance
• Establishes standards that address IT audit and assurance professional roles and responsibilities, knowledge, skills and diligence, conduct, and reporting requirements

Figure 1: The ITAF Structure

More info here

There is help available and it comes in the form of automation tools that can make our life easier. I will discuss a couple of tools that I have worked with and how they can support in auditing and vulnerability assessment activities.

FireSec (v1.1), a Windows-based commercial application, is primarily targeted as a firewall rule base analysis tool for medium to large enterprises. FireSec is priced at US$1000 per installation and requires a SQL Server database access to function. MSDE or SQL Server 2005 Express Edition will work just fine.

FireSec comes strong on the features – supporting removal of redundant rules, grouping similar rules, and detecting potentially vulnerable rule patterns by means of analysis. All of this can be achieved for a wide range of firewall devices from Cisco, Juniper (NetScreen) and Secure Computing (CyberGuard). NII Consulting (India), the developers of FireSec also claim support for a generic ruleset allowing support for CheckPoint, Fortinet and others.

To get started, the device configuration file needs to be imported in to the SQL Server database which is handled by the application itself. The configuration file can be supplied as a flat text file and loaded as a “Firewall” in to FireSec. The loading process is slow as it took about five minutes to load a PIX configuration file with just over 900 lines of configuration data, on an above-average performance machine (2GB DDRII, Core2 Duo 2GHz, 160GB 7200RPM HDD). Once loaded, everything else is a breeze and there is good documentation supplied to walk you through the application.

Figure 1: FireSec GUI

FireSec sports a poor GUI though – main window cannot be maximized, left firewall selection pane cannot be adjusted and even worse is the progress bar that, at random, just stares at you even after processing the requested tasks. It took me a while to work my way through the various functions.

Interface issues aside, FireSec is a very capable product that can let you clean up your configuration (Figure 2), generate a comprehensive analysis report (Figure 3) and even do an analysis of how your rules perform against a given set of source and destination addresses (Figure 4). I was only able to test it with a PIX configuration and it worked as expected.

Figure 2: Generate commands based on given criteria

Figure 3: Report generation is limited to HTML format. Click here for a sample report.

Figure 4: Rule analysis

There is also a firewall comparison function that can assist in change management as well as ensuring rule base integrity and change management.

Overall, FireSec has lot of potential for improvement and I would be keeping my eye on it and watch it grow. For now, I have settled for open source alternatives.

Nipper (v0.11.8) is a cross-platform open source tool that processes network device configuration and generates a customizable report. Nipper reports device configuration details, vulnerabilities and recommendations for mitigating the risks. This command line tool supports a wide array of network devices:

Cisco Switches (IOS)
Cisco Routers (IOS)
Cisco Firewalls (PIX, ASA, FWSM)
Cisco Catalysts (NMP, CatOS, IOS)
Cisco Content Service Switches (CSS)
Juniper NetScreen Firewalls (ScreenOS)
CheckPoint Firewall-1/ VPN-1
Nortel Passport devices (Multiservice Switch- MSS)
SonicWALL SonicOS Firewalls
Bay Networks Accelar Routing Switch devices (now Nortel)
Nokia IP Firewalls

Nipper can take a flat ASCII text file as input for processing data or connect to the device directly and retrieve the configuration through SNMP. Unlike FireSec, Nipper does not import the configuration to a database and report generation is almost instant. I was able to test Nipper’s capabilities using a standard configuration from a Cisco IOS 12.3 router and a PIX 6.3 firewall device.

Figure 5: Using nipper for IOS router analysis

Figure 6: Using nipper for PIX firewall analysis

Within seconds of executing the above commands, Nipper was able to decode my Cisco Type 7 password for the IOS router, parse over 900 lines of PIX configuration and deliver a comprehensive report in the default HTML format (XML, Latex and ASCII text are supported too). Reports can further be customized and there is also an option to replace Nipper references with your own company name along with a range of other options.

Figure 7: HTML report for Cisco IOS router. Click here for the report

Figure 8 : HTML report for Cisco PIX firewall. Click here for the report

Nipper can even output Cisco type 5 passwords to an ASCII text file for later use of John the Ripper for brute force attack; a dictionary-file support is present too. Overall, a great tool and highly recommended!

Other tools to look at:

1. Firemon from Secure Passage that does configuration analysis as well as change management and more;
2. FTester from Inverse Path to test your firewall and IDS from a behavioral point of view and the Router;
3. Router Audit Tool (RAT) from Center for Internet Security that benchmarks router configuration against NSA recommended guidelines for security;
4. RedSeal Security Risk Manager (SRM) from RedSeal Systems is a comprehensive tool for overall network security assessment that can do firewall and router device assessments as well;

To sum up, the tools discussed above can greatly reduce the amount of time you would normally take to assess your network devices, however, I am not recommending that you do not do manual reviews to verify the results. I would never give precedence to a report generated by an automation tool over manual report. It all comes down to the nature of the assessment.

The seller, “dubaigoods1” appears to be persistent about selling as many copies of the database; the item was reposted on eBay as “DUBAI PROPERTY/DEVELOPER INVESTOR DATABASE” without mention of Damac Properties, after the original item was removed by eBay. The below screenshot was taken a few minutes ago:

The highlighted text above appeared as “List includes customers of Damac Properties the middle easts larget private developer!” in the original item description.

This news should not come as a surprise for many of the infosec professionals in the region where data protection laws have a limited territory application; DIFC Data Protection law in Dubai, QFC – Data Protection Regulations in Qatar. Perhaps it is time for more comprehensive laws to steer the need for firmer consumer privacy protection..

Information about the target network is gathered by a software agent, Paglo crawler, which installs on a standard computer connected to the network. The crawler can put together an exhaustive set of information about network hosts with information such as device type, device name, IP address, installed software, disk space usage and so on. The crawler uploads the information to Paglo’s data center for storage and indexing. This information can later be retrieved through a web-based interface.

Let’s take a look at the installation steps.

Figure 1: The Paglo Crawler Install dialog box

Figure 2: Selection of the network segment

Figure 3: Input credentials for network devices

Figure 4: Credential details

Figure 5: Microsoft AD domain admin credential input

Figure 6: Registering the Paglo.com web account

Figure 7: The Dashboard screen
A good usage demo is provided on Paglo.com which can be accessed here.

Paglo even sports its own API which allows custom programs/scripts to search information and to submit additional custom information to the database by means of Paglo’s very own Paglo Query Language or PQL. For those curious about PQL, it is similar to SQL. Here’s an example:

SELECT * FROM /network/device WHERE interface/(name = ‘eth0′ AND oper_status = ’1′)

As far as security of the information hosted with Paglo is concerned, Paglo’s security statement lists sufficient details of the technical and admin controls in place but mentions no details of third-party engagement to verify the claims. It would be good to see them undergo at least a SysTrust audit to get the attention of the more mid-sized organizations.

Paglo’s founders are not clear on how Paglo would make money for them at this stage. I am guessing it is likely to be targeted advertising from the big players in IT directed towards Paglo users, that relate to their respective IT environments.

Although today’s IDS can pick up almost any type of traditional stealth scans, IDS or firewall evasion does exist and is commonly performed by using packet fragmentation or by using proxy hosts. This article looks at how these basic tcp stealth scans work.

Stealth tcp port scanning, involves sending one or more data packets to a target TCP port to avoid the 3-way TCP handshake with the objective of evading firewall/IDS detection.

Let’s take a look at some of the tcp stealth scans:

1.RFC 793 exploitation scans. RFC 793 standard states that if a port is closed on a host, an RST/ACK packet should be sent to reset the connection. This is exactly what is exploited in what I like to call “RFC 793 exploitation scans” (It is not a pretty name though is it?).

Probe packets with either the FIN tcp flag set or with no tcp flag set (NULL scan) or FIN, PSH and URG tcp flag sets (commonly referred to as XMAS probe) are directed towards the target listening for RST/ACKs to calculate open ports.

Source           Destination    Summary
----------------------------------------------------------------------------------------
[192.168.0.200] [192.168.0.100] TCP: D=800 S=34211 FIN SEQ=3872678719 LEN=0 WIN=2048
[192.168.0.100] [192.168.0.200] TCP: D=34211 S=80 RST ACK=3872678719 WIN=0

The above mentioned tcp scans can be performed using nmap:

nmap -sF target_ip_address (FIN probe)

nmap -sX target_ip_address (XMAS probe)

nmap -sN target_ip_address (NULL probe)

The above techniques work with most Linux distros but are ineffective against the Windows platform.

2. RST header analysis. Uriel Maimon was the first to describe this technique in Phrack magazine’s issue 49 which highlights a weakness in the implementation of the TCP/IP stack in some operating systems that use the BSD-flavor of the TCP/IP stack implementation.

RST Header - TTL value analysis using Hping2
-------------------------------------------------------------
Packet 1: host 192.168.0.100 port 79: F:RST -> ttl: 130 win: 0
Packet 2: host 192.168.0.100 port 80: F:RST -> ttl: 130 win: 0
Packet 3: host 192.168.0.100 port 81: F:RST -> ttl: 90 win: 0
Packet 4: host 192.168.0.100 port 82: F:RST -> ttl: 130 win: 0

As shown in Figure 3 and Figure 4 (below), the attacker sends ACK probe packet and listens to the incoming RST packets from the target and analyzing the header information contained within.

From the above log, the TTL value for Packet 3 from the target in response to the ACK probe indicates that the TTL or time-to-live value is lower than the ceiling value of 128 (varies from one OS platform to another) which indicates that there is a running service on port 81 on the target host.

RST Header - Window field analysis using Hping2
-------------------------------------------------------------
Packet 1: host 192.168.0.100 port 79: F:RST -> ttl: 128 win: 0
Packet 2: host 192.168.0.100 port 80: F:RST -> ttl: 128 win: 0
Packet 3: host 192.168.0.100 port 81: F:RST -> ttl: 128 win: 512
Packet 4: host 192.168.0.100 port 82: F:RST -> ttl: 128 win: 0

If the Window field of the TCP header of the received RST packet has a value greater than zero, it denotes that a port is open. A zero Window field size denotes a closed port and a no response would denote the port is filtered.

Do note that some TCP/IP stack implementations that the logic is exactly opposite of what is stated here, i.e., zero denotes open ports and non-zero figures denote closed ports. A quick look at the results will help us determine this. 

The above methods are ineffective against firewall that do Stateful Packet Inspection (SPI) that do not let ACK packets pass through that do not meet the conditions of a legitimate connection state. These probing techniques require some creativity to prove useful.

RST header analysis can be performed using nmap:

nmap -sA target_ip_address (for TTL analysis)

nmap -sW target_ip_address (for WINDOW field value analysis)

There’s more to keeping your scans stealth than using the above techniques. Today’s IDS can easily pickup the above including our favorite Snort! Take a look at what Snort picked up when it came across a FIN probe:

 
 Yes, it picked up a FIN scan! What else did we expect? The TCP stealth scans discussed here do not necessarily work for all platforms as we already know. The same goes for how a given firewall or IDS deals with them.

One way to get around and avoid detection is fragmenting the probe packets. Fragmenting the TCP (or even IP) header into smaller fragments gets around firewalls that do not reassemble all the fragments at the perimeter before passing it to the target. Similarly, signature-based IDS devices are often fooled to detecting these fragments as “junk traffic”. It is worthwhile mentioning here that fragmenting can cause the target to crash or result in unexpected behavior.

Using nmap, fragmenting can be done with the “-f” switch. Infact, nmap has a whole suite of “evasion” switches (see nmap documentation):

 -f; --mtu <val>: fragment packets (optionally w/given MTU)
 -D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys
 -S <IP_Address>: Spoof source address
 -e <iface>: Use specified interface
 -g/--source-port <portnum>: Use given port number
 --data-length <num>: Append random data to sent packets
 --ip-options <options>: Send packets with specified ip options
 --ttl <val>: Set IP time-to-live field
 --spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address
 --badsum: Send packets with a bogus TCP/UDP checksum

Other techniques that assist in carrying out a stealth tcp scan include randomizing scan timing to avoid detection, using decoy hosts, botnets, etc.