The Security Skeptic

IPv6 addresses are already included for Top Level Domain Name Servers in the root zone file. Several root name server operators have assigned IPv6 addresses to their servers but these are not included in the root hints file and the root zone at this time so IPv6 or "AAAA" address records of root name servers are not returned in responses to DNS queries sent by recursive name servers. In particular, they are not returned during what is known as a "priming exchange".

Little documentation exists regarding hints and priming. Typically, resolvers are pre-configured with the addresses of at least one root name server, and they initially rely on this "hint" information to provide recursive name service. A recursive name server may also perform a process called priming to ensure that it has an up-to-date and accurate list of root name servers. A priming query is sent to one or more of the root name server addresses configured as "hints" and asks for (QNAME=".", QTYPE="NS", QCLASS="IN"). The priming response contains NS records in the authority section and the corresponding A records in the additional section.

Priming messages are exchanged using UDP, and the DNS protocol RFCs specify a 512 byte maximum for UDP-encapsulated DNS messages. If more than two type AAAA records are added to the root hints and root zone files, the DNS priming response will exceed this maximum; in fact, when all 13 root name servers are assigned IPv6 addresses, the priming response will be 811 bytes. This changes the conditions needed to assure that a priming exchange will succeed. Firewalls must be configured to allow DNS messages containing IPv6 addresses and they must be configured to forward UDP-encapsulated DNS response messages that exceed 512 bytes and that may arrive in multiple IP fragments. Resolvers must be able to bootstrap with hints containing AAAA address records (even when IPv4 transport is used for priming) and they must be able to use DNS Extensions to notify root name servers that they are able to process DNS response messages larger than the 512 bytes.

In SAC018, my RSSAC and SSAC colleagues and I examine the problems that might arise if AAAA resource records of root name servers were added to the root hints and root zone file for the DNS. We describe and report the results of testing performed by committee members and the community at large, including recursive name server operators as well as commercial vendors of security systems and DNS name server products, to determine the extent to which these problems are likely to be encountered. T

I had a great deal of fun testing both firewall and name server software for this project, and discussing name server implementation quirks with developers and vendors who willingly participated in reporting results (see SAC016 and SAC016 for results). The test results figure prominently in the recommendations we propose to ICANN and IANA. We conclude with a roadmap the community can follow to assure that the inclusion of AAAA records in the root hints file and DNS priming responses from root name servers has minimum impact and maximum benefit.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID603 by Dave Piscitello  

Determining whether a device is actively protected from malicious code, running personal firewall software and correctly configured to use VPN adapters before admitting that endpoint to a network are common features of endpoint security. Many WLAN, switch and security system vendors are implementing variations on this theme today. These, however, are merely mile markers along the endpoint security highway. Future incarnations of admission control may check to see that an appropriate seurity policy is enforced at the endpoint, that critical files have not been altered, that no restricted access files have been copied to the endpoint, and that any sensitive data that resides on the endpoint are encrypted.

Read the full article at endpoint security or listen to the 5 minute podcast.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID602 by Dave Piscitello  

Happy coincidence! Having just published a podcast that casts a harsh light on the vulnerability disclosure practices and motives of certain "ethical hackers", I was intrigued to find an invited editorial by Professor Ric Steinberger on the subject of disclosure in Mich Kabay's 03/08/07 Network World's Security Strategies Newsletter . Professor Steinberger suggests that "there is no 'always correct' response that vulnerability researchers should follow" when they discover a flaw in a software product. Steinberger makes a case for tempering full disclosure in situations where a vendor is seemingly non-responsive. Steinberger argues that forcing a vendor response by going public with a vulnerability may indeed force a large software vendor with ample resources to respond in a more timely manner, but the same course of action may prove onerous or disastrous for a smaller company or startup that has fewer resources and may need more time to provide a patch or workaround.

Steinberger is suggesting that vulnerability researchers act with a degree of charity, an ounce of forgiveness. While I am certain that legitimate vulnerability researchers may consider this suggestion, I worry that the less than legitimate (ahem) researcher who only seeks attention may not have a charitable bone in his body.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID601 by Dave Piscitello  

KisMAC is a powerful wireless LAN discovery, security, and network assessment utility. Like the more familiar iStumbler, KisMAC provides information about the WLANs within range of your WLAN adapter card that can be more helpful for identifying available networks and diagnosing common wireless deployment problems. But while iStumbler provides monitoring and analysis capabilities, KisMAC has all that iStumbler offers plus a formidable set of security penetration and testing features. With KisMAC, you can generate de-authentication and encryption key cracking attacks. You can also locate radio sources by integrating a GPS receiver.

KisMAC works with a number of PCMCIA WLAN adapters that can be operated in monitor mode. It will work with Airport and Airport Extreme adapters on the MacBook, but not with the driver that Apple ships. It's easier to get the developer code and compile a driver for use with KisMAC than to find one. To compile a driver, you'll need to install Apple's Xcode developer environment and then get the Kismac source. A secure way to get the source is to use the Subversion Client (I talked about Xcode and Subversion Client (svn) in blog#592). Start a Terminal session and type the following:

/usr/local/bin/svn co https://svn.binaervarianz.de/kismac/trunk/ kismac-source

Verify the source using the KisMAC fingerprint found at the web site. Go to the directory to the directory where you downloaded the source (in my case, I found it in kismac-source) and type ./compile.command to create your own KisMAC.app. You'll find this app in a subdirectory in kismac-source. Since I have an Intel MacBook Pro, I found mine in /build/universal.

Launch KisMAC, identify the driver and mode (active, passive) from Preferences and experiment with KisMAC's many features, as I'm doing on my local WLANs. KisMAC's author, Michael Rossberg acknowledges his software is not for novices. It's also not a utility anyone should use frivolously. Before you use Kismac, make certain that you won't violate your organization's AUP or break applicable laws.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID600 by Dave Piscitello  

It's common knowledge that Intel MacBooks generate LOTS of heat. Using a software called Temperature Monitor, I have measured Core CPU temperatures in excess of 180° F from my MacBook Pro. Overheating is an omnipresent problem, especially when running graphics-intensive applications. Persistent heating can cause permanent and expensive damage. Having my MacBook Pro shut down unexpectedly and observing that the surface of the notebook could easily warm my coffee were sufficient warning signs. I needed a notebook cooler!

I was somewhat skeptical of the results I'd get if I used an external notebook fan. All the reviews I read were either inconclusive or too good to be true. I finally decided to try the Vantec Lap Cool series of notebook coolers, largely because I found more positive reviews online than negative.

I'm really pleased with the results from my Lap Cool 2 trials. This notebook cooler draws power from my MacBook through a USB port (or an external P/S), and the two adjustable fans routinely keep my laptop between 15-20° cooler than when the laptop runs with internal fans alone. The notebook cooler has 4 legs and you can rest the laptop at an inclined or flat orientation.  It also has a 4-port USB 2.0 hub so it can double as a docking station. The fans aren't noticeably noisy but my office has many switches and security appliances with extremely noisy fans so I'm not the best judge.

The Lap Cool 2 is probably light enough to travel for some folks, but it's a bit large and cumbersome for a Spartan traveler. Vantec makes a Lap Cool 3 that's much lighter and smaller, but it still does an adequate job. For under $20, it's a bargain and a no-brainer purchase.

My only gripe with both products is that the plastic fan blades are very fragile. I broke one when I forgot that the fan was attached to the MacBook and it took a header from my desk to my carpeted office floor. The unit still runs months later, absent a single blade.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID599 by Dave Piscitello  

Ethical hacking is the perceived high road of cracking, an organized and sanctioned practice of identifying vulnerabilities in software. In practice, "open community" ethical hacking is a train wreck, widely practiced outside these parameters, by people with ambiguous motives, using few if any formal methodologies and acceptance criteria.

To learn why I have such a dubious opinion of ethical hacking listen to this 8 minute podcast.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID598 by Dave Piscitello  

Frequently quoted, well and not so well known members of the security community are referred to as security experts, practitioners, and professionals, with no real rigor or discrimination applied. In this podcast, I ask, "Am I a security expert?"

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID597 by Dave Piscitello  

Business Communications Review has invited Dr. Stephen Kent and I to publish an article that revisits the topics we discussed in our 2003 article, The Sad and Increasingly Deplorable State of Internet Security. As Stephen and I prepare this article for BCR, I thought you might want to read the original article. BCR has graciously sent me a copy to publish here (pdf).

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID595 by Dave Piscitello