The Security Skeptic

The Domain Name System is arguably the most critical of all Internet applications. DNS is the network corollary to the automobile ignition system: if DNS isn’t available, users are unable to resolve host names to IP addresses and thus cannot connect to Internet servers.

Our dependence on domain name service makes the DNS a prime target for attackers. For example, many pharming and identity theft attacks poison name server records so that responses to DNS queries direct unsuspecting users to bogus websites. Other attackers try to disrupt name service by launching distributed denial of service (DDoS) attacks against top-level domain and root name servers.

Authentication, confidentiality and integrity protection would make it difficult for attackers to exploit the DNS for pharming and identity theft purposes, but these security measures weren’t among the original DNS design objectives and protocol. For some time, the Internet community has been developing—and deploying—measures to make DNS secure. Let’s look at why these are important and how they can help mitigate several types of attacks.

Read the rest of this article at Business Communications Review.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID587 by Dave Piscitello  

When the question, "Can anyone point me to some good documentaion as why NEM is better then Standard IPSec VPNS?" was posed on the Firewall-Wizards mail list, colleague Tina Bird offered this insightful and vendor-agnostic answer.

Network Extension Mode is Cisco-specific terminology, so I'll assume you're talking about Cisco VPN gear. Cisco's site is the only place you'll find doc. They've got a white paper on enterprise VPN deployments which might help out.

One of the big problems for IPsec deployments is making sure that the VPN peers on both sides of the connection are configured with the same parameters for session negotiation and management. In The Beginning, we had to do that manually, which was annoying but feasible for site-to-site VPNs. For remote access VPNs, where you've typically got a single machine connecting from a random external IP address into a corporate environment, it was a complete pain in the, uh, ethernet jack, because a lot of the negotiations are managed based on things like IP address. Hence the need for certs and dynamic client management (but we'll ignore that tangent).

Despite IPsec's support for multi-vendor deployments, in *practice* now, the vast majority of organizations using IPsec for remote access have deployed single-vendor VPN servers and clients. The biggest reason for this IMO is because vendor have frequently deployed proprietary features that make managing IPsec for remote access *much* simpler. Cisco is the premier example of this. Their "EZvpn" technology (based on a proprietary mechanism of theirs called the Unity protocol) creates a mechanism for the server to control all aspects of session negotiation and traffic management, leaving a minimal amount of configuration required for the client itself.

As I said above, most remote access connections require a single client to connect into the enterprise network. Cisco IPsec assumes this in their "basic" VPN config. The VPN concentrator need only connect that single machine in -- the corporate network does not need to connect back into the remote environment. In this case, the VPN server assigns a local corporate IP address to the endpoint connection, and has no visibility into any other machines in the remote environment.

But there are some situations -- for instance, when the remote user is an engineer with a development LAN that needs access into the corp network -- where corporate machines have legitimate reasons to connect into the remote location. Cisco supports this using its "Network Extension Mode." In this mode, the VPN server provides a unique range of addresses for the machines in the remote subnet (usually via a DHCP server on the remote end), and manages traffic back and forth through the tunnel. This mode is more complicated, because you have to manage a larger set of network addresses and routes, but it works a charm for branch offices and telecommuters with lots of machines.

Neither one is better or worse, they fulfill different requirements.

--Tina Bird

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID585 by Dave Piscitello  

I am very fortunate to count a large number of network and security experts and practitioners as friends and colleagues. Since we share interests, we exchange mail regularly. We also frequent the same mail lists, and I often find myself thinking, "gee, everyone should read this!" So I've created a new category at my security blog: Guest Experts. Hereafter, when I find something I feel is worth sharing in a more convenient manner than a mail list archive, I will (with attribution) create a blog entry on behalf of the author.

Tina Bird has graciously agreed to be the pilot contributor. I hope to provide you with many more.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID586 by Dave Piscitello  

A MAC (medium access control) address is a 48-bit unique identifier for a LAN or WLAN adapter. The most common format of a MAC address is the universlly administered address, which is composed of a organization identifer (OUI, 24 bits) and a station identifier (24 bits). OUI-composed MAC addresses have long been "hard wired" into adapter cards, but modern operating systems make it possible to change a MAC address.

Many reasons exist to change a MAC address. Some are evil and some good. For example, by changing a MAC address, an attacker can impersonate a "trusted" MAC address to fool intrusion detection systems, evade traffic filters applied to LAN protocol headers, and receive LAN traffic intended for the station legitimately identified by the impersonated MAC address. By impersonating a trusted MAC address, an attacker can also obtain an IP address from a DHCP server that is supposed to be assigned to a different host and this allows the attacker to impersonate not only a host on a LAN but a host in an IP network as well.

Very few users ever encounter situations where they must change a MAC address. Today, I'll offer a scenario where you might, and I'll identify some software you might find helpful.

You register as a guest in a hotel. The hotel offers broadband Ethernet in your room, and wireless Internet service throughout the property. Both services are for fee, and are offered by the same provider. You arrive in your room, register and pay for service using your Ethernet adapter. This particular service provider (and many others) use your MAC address as your customer identity. You work in your room for a while. At 1:30 a.m., you take your laptop to the bar to "work" with others, only to discover that the service provider doesn't recognize you as a customer and wants you to pay another fee. Assume that for this example, the service provider's AUP and the registration page say "unlimited Ethernet *and* wireless service for 24 hours" (typically noon until noon). You explain your circumstance to the front desk, then to the concierge, and eventually, to a help desk operator at a remote NOC who tells you, "there's nothing I can do about this right now but I'll open a ticket and we'll look into it".

If only your WLAN adapter had the same MAC address as your Ethernet adapter, your problem might be solved!

If you have admin privileges on your laptop, you can change your WLAN adapter's MAC address, temporarily - but do remember to change it back! And before you change the address, copy down the MAC address of your Ethernet adapter and disable it. Now, to change the MAC address in Windows XP/2000 and I imagine Vista, you must change the sub key that corresponds to your WLAN adapter under the Registry Key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}\

Modifying the Registry is iffy territory for even experienced users, so I recommend that you use one of the following freeware. Technitium MAC Address Changer and KLC Consulting's SMAC are free/shareware MAC address changers with graphical UIs that tell you the existing MAC Address (remember to write this down so you can restore it later), IP configuration, etc. For folks who favor DOS command line utilities, there's Mike Fratto's EtherChange.

If you are a MAC OS X or Linux/BSD type, visit Irongeek.com for a long list ofways to change MAC addresses on these OSs, including how to modify the Windows Registry for those who dare.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID584 by Dave Piscitello  

I found an article at TechRepublic entitled 9 things IT managers should think about in 2007 (you may need to subscribe to download the pdf). I like the concept of giving IT managers cues for 2007, but of the nine Shannon offers, these in particular need sharpening.

• Bigger is not better. Shannon suggests that "the ability to mask problems by overbuilding hardware does not mean we've solved the issue--it just hides the problem for a time. Similarly, the ability to build a data center in a rack doesn't mean that doing so is a good idea." I'm inclined to take issue with this point because it only considers overbuilding in one context. Other principle reasons for overbuilding are to provide "extreme case" capacity, to assure capacity is present in situations where measuring or estimating capacity, need, and growth are difficult, and even to simply invest for the future with budget you presently have that may not be available at a future time. Bigger may not always be better, but I'd rather err on the side of bigger than smaller.

• New does not mean stable. True, however early adopters are often faced with a problem no current technology or practice solves and so are forced to endure bleeding; simply put, they have no choice. Perhaps a corollary to this observation might be, "bleeding edge adopters should understand and factor triage into their planning".

• Virtual devices still reside on physical hardware. Shannon suggests that "at the end of the day, all those virtual servers live on a physical box somewhere. That box needs the same maintenance and support it always did and more, now that we've added yet more layers of complexity." I'm not certain why maintenance and support are harder with one box than many, but I think Shannon's latter point is more important: the *conceptual* and configuration complexity we add are often overlooked when we virtualize. I still find it useful to diagram networks and server farms as if they were all self-standing units, scribble the configurations for each, and draw a big fat box labeled "chassis" around them:-)

• Follow-through matters as much as execution. This is cleverly put, but I think some steps are absent in this missive and we should tease these out carefully. If I understand Shannon correctly, she's suggesting that you "Define an objective. Define an implementation plan that satisfies the objective. Execute the implementation plan. And finally, verify that the plan meets the objective."

• One-size-fits-all never fits anyone at all. Shannon claims that "Boilerplates, best practices, and the fabled “industry leaders” all suggest that one solution will fit every situation. We just have to ram it into our environment and everything will magically transform into rainbows and bluebirds." I think this is way off mark. Perhaps fabled marketing wonks and analysts who are paid to create and push markets make such claims, but no respected practitioner or consultant believes this. (Boilerplates) templates offer *examples* of how one might design a solution and those hasty or lazy enough to adopt a boilerplate without a careful analysis of the implications reap what they sow. Similarly, best practices are codicils of "what appears to work for a good many folks in similar situations to yours". The key words here are "appear" and "similar" - simply put, best practices should be treated as adaptable methods and not as exacting standards.

• It's better to invest time than to spend it. This is clever but not that helpful. Let me expand on this since I think it's a hugely important issue. IT must balance three T's: time, talent and technology. Today, the tendency is to throw technology at a problem and in so doing, reduce the need for talent (expertise) and reduce time. I recall my colleague Chris Blask saying, "Computers are fast and people are smart." Invest first in talent. Give them time to plan and choose technology that will allow them to be smart, *fast*, and you'll have spent your own time wisely.

• Failure is always an option, so fail early and often. This is an excellent point. The only thing I'd add is that IT managers should foster an environment where failure is understood as a possible outcome, but failures are treated as opportunities to learn and improve.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID582 by Dave Piscitello  

Bill Hancock, a popular and talented security expert, died January 1^st, 2007. He will be sorely missed, personally and professionally. "Dr. Bill" was a brilliant, humorous, sometimes controversial, and often flamboyant character. I met Bill in the mid 1980s. Years later, he helped me launch my Internet Security Conference (TISC) by keynoting, speaking, and contributing several articles to the TISC Insight newsletter I edited for many years(1, 2, 3). CSO online published a very nice eulogy - Security Community mourns the loss of a CSO - but the community should also remember Bill for his contributions in the worlds of firewalls, forensics, and secure network and data center design. Dr. Bill coined and frequently used the Twinkie as an analog for security. In both TISC and SANS presentations during 1999, Bill explained that, "Security is like a Twinkie: it's what's inside that counts".

If you would like to donate to Hancock's family, they can do so at any Bank of America by contributing to The Landreth Hancock Fund, ACCT 5860 0235 7369. You can also mail checks to: Trustee, The Landreth Hancock Fund, 15302 Hilltop View, Cypress, TX 77429.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID583 by Dave Piscitello  

My wife and I receive on the order of 5-7 offers for credit cards per day. I've been told this is a positive indicator - we pay back what we borrow with interest blah blah blah so everyone wants to be our lender blah blah blah.

I don't feel special. I feel besieged. I have an oversized mailbox that practically explodes when I open it.

My 2007 New Year's resolution is, "Pay back time!" And I'm borrowing a page from Blue Security's antispam campaign to do so.

Today, I took the pre-paid return envelopes from seven credit card offers, filled them with shredded offer letters and applications, and returned them from whence they came. Yes, mine is a small gesture, but if you all join me, we can test the Blue Security model in the real rather than virtual world. I'd love to have life imitate art here. There's a scene in the 1947 movie classic Miracle on 34th Street where New York City postal workers fill a court room with letters addressed to Santa Claus. I'd be delighted to see the same scene repeated in mail rooms at "New Cardmember Services" processing centers.

Perhaps a small effort on all our parts can make a difference. If not, at least you've tried.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID581 by Dave Piscitello  

My ICANN SSAC committee is collaborating with the DNS Root Server System Advisory Committee (RSSAC) to study the matter of including the IPv6 addresses at the root level of the DNS. This involves adding "AAAA" resource records to what is known as the hints file, a file that is typically preconfigured into systems that act as name servers and resolvers. Resolvers do not rely exclusively on the hints file, since this is static information and may change over time. Instead, most resolvers issue a Type NS DNS query to one or more of the root name servers identified in the hints file to verify the accuracy of their local hints file. This query and the associated response from a root name server is called a priming exchange.

The Problem

Currently, five root name servers have been assigned IPv6 addresses. These addresses are not included in the hints file, nor are they returned in DNS priming responses. If the five IPv6 addresses were added to the priming response, the message would increase from the current length of 436 bytes to 576 bytes. Moreover, when all 13 root name servers are assigned IPv6 addresses, the priming response will increase in size to 800 bytes. This imposes two conditions on firewalls and other security systems that protect resolvers.

The first is that any firewalls that are situated between resolvers and root name servers must be able process DNS messages containing Type AAAA resource records. Some DNS proxies and stateful inspection firewalls may be configured (by default or policy) to block DNS messages that do not strictly conform to "pre-IPv6" DNS specifications. The second condition relates to the increased message size resulting from the inclusion of IPv6 addresses in the priming response. Firewalls must

allow UDP-encapsulated DNS response messages larger than the 512 byte maximum DNS message size specified in RFC 1035 to resolvers that issued the priming request. Some firewalls may not recognized the DNS extensions (EDNS0), while others may have been configured to block suspiciously long UDP messages to thwart DNS DDOS amplification attacks.

Testing Your Firewall

It's relatively easy to test if your firewall satisfies these two conditions. Several top level domains return IPv6 addresses in DNS response messages today, and several of these responses are larger than 512 bytes. A simple "dig" of the HK TLD using the command "dig hk ns +bufsize=4096 @203.119.2.18" will evoke a 747 byte response message containing AAAA records.

My SSAC/RSSAC colleagues and I hope to capitalize on the ease of this testing by inviting *everyone* to try this dig command and tell us their results. Specifically, you can email me following your test and provide the following information:

• Firewall Product Manufacturer
• Firewall Model
• Firewall software/firmware version
• Action when AAAA RR encountered
• (Optional) A copy of the dig input and output (as illustrated above, this can be obtained by directing the output to a file, e.g., "dig hk ns @203.119.2.18 > digAAAA.txt")
• Action when DNS message larger than 512 bytes received
• (Optional) A copy of the dig input and output (as illustrated above, this can be obtained by directing the output to a file, e.g., "dig hk ns +bufsize=4096 @203.119.2.18 > digEDNS0.txt")

You can read more about this initiative - and see the results we've already complied - by visiting the ICANN web site and reading SAC016.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID580 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID579 by Dave Piscitello  

Having attracted broad media attention in November, one would expect that the egos of the <ahem>researchers</ahem> responsible for the Month of Kernel Bugs, if not sated, might at least remain bloated for more than a month. No such luck. These same crackers intend to disclose a Mac OS X bug daily during the month of January 2007.

The crackers conducting the Month of Apple Bugs project promise a steady stream of zero-day disclosures that will expose the over-hyped Mac OS X Security as a house of cards, humble Apple, and of course, focus attention to the astonishing prowess of the the Lamo/Mitnik de jour.

Zero-day disclosures are self-absorbed, self-serving, narcissistic acts. They benefit no one except the crackers who disclose the vulnerability. You are sad, strange little men, and you have my pity.

How should Mac OS X users prepare for MOAB? Tighten up your OS X Security a bit. Begin by visiting Mac Geekery and review the ten security measures Adam Knight prescribes in Basic Mac OS X Security. Once you are satisfied that you've raised your Mac's defenses to this baseline, and if you are serious, consider disabling Unneeded Services. Then bookmark MacGeekery.com and visit this and other security sites regularly.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID578 by Dave Piscitello  

My family often visits our former Pennsylvania haunts during Christmas break. The trip is a formidable but doable one day, 700+ mile journey by automobile. However, our route forces us through a traffic triple whammy: Northern Virginia, Washington DC and Baltimore. The 1-, 2, and sometimes 3- hour delays we invariably encounter over this nasty 160 mile stretch are exasperating traveling North since we routinely cover the first 400 miles in just over 5 hours (God Bless NASCAR and 70 MPH speed limits). Recently, the delays are even more frustrating traveling South: by the time we begin our return leg, we've vagabonded our way through the Greater Philadelphia and New York areas visiting friends and family and are exhausted from our "vacation".

Today, we encountered abnormally bad traffic and weather, and crossed into North Carolina a good 2 hours later than expected. We stopped for fuel and decided to grab some dinner at a fast food restaurant. While I scanned the menu for something both low-carb and edible while driving (the bun-free, ground beef in a bowl is a fine example of an Atkins entre that cannot be safely consumed while driving), I discovered the following notice on the menu board:

Picture menus are available on request

This struck me as quite a curious and frankly absurd bit of signage.

Anyone who can't read certainly can't know to ask for a picture menu.

If the notice were offered in the spirit of bilingualism, anyone who can't read English can't know to ask for a picture menu.

My son observed, "We're in a fast food chain restaurant. The menu items are already depicted - and numbered!" I agreed, but thought that perhaps the picture menu offers both food and a depiction of a hand(s) with the appropriate number of fingers raised to order the item?

I asked for a picture menu. The manager looked at me and replied, "We don't have any. You speak English, why do you want one?"

I replied, "I was just curious to learn how it differed from the menu."

She paused for a moment and said, "What kind of sauce do you want with those nuggets?"

"No sauce, thanks, just extra catsup..."

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID577 by Dave Piscitello