The Security Skeptic

Source address spoofing - the act of submitting IP packets with a source address other than one you are authorized and expected to use - is high on my list of unforgivable behavior. Failing to validate source addresses is also high on my list of unforgivably poor operating practices. Mostly, I hate the fact that telephone networks do something better than data networks, and every telco service I've ever used and helped design (e.g., SMDS) has source address validation.

Rik Farrow wrote an excellent and timeless article describing ways to spot source address spoofing. You can find this classic TISC Insight column here.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID497 by Dave Piscitello  

I followed a recent WatchGuard Wire report, Oracle fixes 37 security vulnerabilities to the actual Oracle Critical Patch Update. Mildly curious, I looked at the products and releases affected. Something about ORACLE 9i Database reminded me of a Larry Ellison quote regarding ORACLE Security. A Google search led me to a January 2002 interview in ORACLE Magazine. Excerpt follows:

ORACLE MAGAZINE: You've said that Oracle 9i is the last database. What does that mean, and what do you think is next for databases?

LARRY J. ELLISON: This isn't the first time I said Oracle was the last database. What I mean is that Oracle9i introduces a new standard for data management. Oracle9i is an unbreakable system. You can't break it, and you can't break in. It's very secure.

We've passed 14 different certifications to prove our database is secure.

So much for certifications...

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID496 by Dave Piscitello  

One visit to NirSoft.net and you understand exactly why Nir Sofer is respected as one of the most and prolific developers of useful freeware. Nir's developed dozens of useful password cracking and recovery utilities, and dozens of network and administrative utilities as well.

Two utilities I found to work well are WhoisThisDomain and WhosIP. WhoisThisDomain differs from other domain checking utilities in that it always checks the authoritative Whois for the top level domain under which a name is registered, and it allows you to fill a text box with multiple domains before submitting queries. A sample output window follows:

WhosIP is a DOS command line program that queries IP address registries to identify the organization to whom an IP number or block is assigned. A sample WhosIP output follows:

E:\program files\WhosIP>whosip.exe 65.37.52.11
WHOIS Source: ARIN
IP Address: 65.37.52.11
Country: USA - Washington
Network Name: ELI-3-NETBLK99
Owner Name: Electric Lightwave Inc
From IP: 65.37.0.0
To IP: 65.37.127.255
Allocated: Yes
Contact Name: Electric Lightwave Inc
Address: 4400 NE 77th Ave, Vancouver
Email: support@eli.net
Abuse Email: abuse@support.eli.net
Phone: +1-800-622-4354
Fax:

These are handy tools for firewall, content proxy administrators and generally, anyone who examines log entries containing IP addresses and needs a quick and convenient way to identify blocks where malicious traffic originates. Both are worth a look. While you're looking browse the entire freeware inventory.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID495 by Dave Piscitello  

It's unusual to see three SIP-related posts on BugTraq in the span of less than a week. Perhaps it's an anomaly, but last week, exploit code for two vulnerabilities and a new SIP war dialing tool were announced. The exploits are (predictably) buffer handling problems in SIP softphones. The war dialing tool is actually a set of enhancements to a PSTN (ahem) auditing tool, iWar, that allow you to scan IP PBX and voice mail systems for active SIP URIs. The tool also captures banners for remote system identification and several other rudimentary scanning functions.

These posts suggest that there are enough SIP UAs to make attacking interesting and that traditional scanning and information gathering tools can and are being extended to probe SIP-based applications. It's also no coincidence that SIP softphones are attracting early attention. They are cheap or free, require only a LAN to server as an attack network and tool development environment. At least some if not many of vulnerabilities revealed from softphone experimentation are likely to apply to SIP phones, SIP network adapters, and core VOIP network equipment.

Whether attackers begin by disrupting subscribers of public VOIP services like Vonage, Packet8, SunRocket, and the major players like AT&T, or target enterprise SIP installations probably depends on the mindset and objectives of the attackers. I can't help but believe that we are entering another interesting time in the history of Internet-based communications.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID494 by Dave Piscitello  

We live in an age where the Internet is the de facto media for publishing, collaboration, and information distribution -- whether in traditional on-screen data and print formats, or voice and video formats. This is likely to be a wonderful thing. "Everything over IP" is a decades old mantra. When everything is over IP, "everything" will include phone and fax calls, video conferencing, broadcast television and radio.

Enterprises have the ungainly task of reconciling traditional and emerging policies across different media. Content inspection technology for packetized data is bleeding edge when compared to how we might go about monitoring telephone calls, fax transmissions, and snail-mail. This creates a conundrum: You can impose more stringent rules for appropriate use of one media than for others, or you can strive for consistency in policy across all media. The real-time nature of Internet communications tempts organizations to impose stricter policies. In the long run, consistent policies will be easier to manage and enforce.

If you are dealing with these problems *today*, it may surprise you that my first Watchguard Live Security column discussed exactly these issues.

Then again, it may not surprise you at all.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID493 by Dave Piscitello  

For several years, Core Competence and Mactivity presented The Internet Security Conference (TISC). We also published a bi-weekly newsletter, Insight. At the end of 2005, we retired the domain names of the TISC conference. I am now hosting the 100+ newsletters published between 2000-2003 at a new domain, www.tisc-insight.com.

At the moment, all the articles are rehosted, indexed, and available for viewing. Over time, I will edit the columns and remove the hundreds of broken links and stale email addresses. I'll also (eventually) remove conference information that is no longer relevant. I may even create an RSS feed.

If you authored a column for Insight and find your contact information is incorrect, be patient and contact me with correct information.

During the migration process, I read quite a few of the articles. Many are still quite useful reading. Others have enduring entertainment value. I will periodically include pointers to such articles in my blog.

If time permits, I may resume publication of Insight. Several Insight authors have offered to publish again. Stay tuned for more information.

Enjoy, be safe, and happy reading!

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID492 by Dave Piscitello  

My daughter attends a private school about 18 miles "off island" in the neighboring town of Bluffton. Traffic returning to Hilton Head Island all funnels onto a single multi-lane highway which is riddled with intersections and traffic lights and constantly congested. Volume alone is only one of the factors causing this congestion.

Driving or idling in traffic can be frustrating. The driver of cars adjacent to mine look catatonic, panicked, or ready to shoot someone (given the ratio of gun racks to vehicles here, this is seriously disconcerting). I deal with the frustration and boredom by petting my dog, who accompanies me on my round trip, by observing people, and thinking about writing topics for my blog.

I spent many years involved in the development of routing protocols. Routing and traffic management are close relatives, so trying to isolate the causes of congestion when I'm stuck in traffic is almost second nature. Each morning, I watch the random acts of braking, noted the weather, observed merging from intersections which are often manually controlled from Beaufort County Sheriff Department cruisers (with little observable improvement). Observing the braking patterns this morning, I confirmed a growing suspicion that they were not random but fairly predictable. I'll give you some hints.

• It's a bright sunny morning.

• Eastbound traffic on the highway runs predominantly East.

• It's winter, and the sun is low on the horizon in the morning.

• The giveaway: when traffic turns directly into the sun, the majority of drivers touch their brakes. The back pressure effect persists for more than a mile. .

Yes, the majority of braking occurs when drivers are temporarily blinded when they face the sun. A casual sampling of the drivers I pass reveals that only one in four are wearing protective sun glasses. I'm wearing sun glasses. I'm not tapping brakes when I turn into the sun, and neither are the handful of drivers I spotted wearing sun glasses. Could we actually abate congestion on Highway 278 through Bluffton by requiring drivers to wear sun glasses? Perhaps an experiment is in order. Law enforcement agents could buy several gross of sun glasses and hand them out to drivers.

There's a hidden PR benefit for the local law enforcement as well: deputies handing something other than traffic violations to drivers on Highway 278 unquestionably breaks the stereotype:-)

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID491 by Dave Piscitello  

I wrote a review of Windows XP Security Solutions in my BlogID 485. Today, I received a note from author Dan DiNicolo that confirms some of my speculations:

Hello Dave,

I just came across your blog entry on my new book. I'm glad you enjoyed it, and was happy to see the positive review. As you mentioned, the book is aimed at the average end-user rather than the in-the-know professional. My decision to write the book was largely born of frustration - the fact that an avalanche of information is available on the topic, and yet the majority of home users' Windows XP systems remain infected.

Anyhow, I just thought I'd drop you a line to say thank you. I hope that people get the message, be it from my book or otherwise.

All the best,

Dan

So now you have another reason to buy the book. Support Dan, he's a nice guy:-)

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID490 by Dave Piscitello  

If you have children, you'll probably recall the pull-string figure Wild West Woody from the Pixar movie, Toy Story. Among the handful of fun phrases Woody would say when you pulled his string were, "There's a snake in my boot!" and "Someone's poisoned the water hole!" If Hasbro were to release a "virtual" Woody today, he'd warn us of a similarly serious threat, DNS cache poisoning. The analogy is simple: in the Wild West, a poisoned well spelled disaster; on the Internet, a poisoned DNS cache is no less a calamity. More...

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID489 by Dave Piscitello  

I received several comments shortly after boasting that I had successfully blocked DoubleClick. There are many ways to block advertisers. I have used cookie blocking, manipulating domain name resolution, and configuring a "blocked site" policy in a firewall.

Blocking Ad cookies is simple and can be done by configuring a browser to block 3^rd party cookies, which are often written to your computer by ad tracking companies. Read how to do this in IE 6.0 here. The same feature is available in Firefox via the Cookies tab of the Privacy Option under Tools. Many antispyware software also provide cookie blocking. (An interesting feature of Firefox allows remove a cookie and block a site from ever setting it again).

An advertiser must open connections to its ad server to collect the information it stores in the cookie it has placed on your computer. These connection attempts are programmed into web pages you visit (the site hosting pages with such hidden connections pays the advertiser for its tracking and targeted marketing services, and is called an affiliate). Fortunately, an advertiser must use the DNS to resolve the domain name of its ad server to an IP address. By modifying your PC's hosts file so that ad server names resolve to localhost (127.0.0.1), you redirect connection requests to your own PC. These will fail quickly. The rest of the page you visit will load. You may see an error similar to the one I captured in BlogID #487, but this depends on how the page is programmed. Either way, DoubleClick can't collect information from you. You can point domain names of all the ad servers you wish to block to localhost, including DoubleClick, AdTech, Honesty, Profero, ValueClick, and hundreds of others. Find lists of ad server lists here. If you run Active Directory on your network and want to block ad servers uniformly across all client PCs, create a group policy to replace the user host file at logon. This trick may also thwart hijacking spyware that alters the user host file.

You can also block ad sites by including the domain names or IP addresses of the ad servers in a blocked site list at your firewall. Your firewall may drop attempts to connect to the blocked site, or it may return an "unreachable" error. Both will cause an 404/http error (page not found). Firewalls and proxies that block sites can also be configured with custom 404 errors, so an admin can advise users that ad blocking is in effect.

But admins shouldn't expect users to go out of their way to thank them.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID488 by Dave Piscitello  

Evidence that targeted advertisers like DoubleClick are frustrated by my content filtering efforts is always heartwarming. This image from a Network World web page I recently visited made me smile:

The site *isn't* temporarily unavailable, dudes, it's permanently blocked, as in "you will never EVER connect to it from any host behind my firewall while I remain mentally able to configure an egress filtering policy".

Too busy? An interesting interpretation, and a equally telling measure of the conceit of Internet marketeers. Try again in a few moments? Can they seriously imagine that someone will actually refresh a web page for an advertisement?

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID487 by Dave Piscitello  

John Dix wrote an article summarizing the security concerns and recommendations he considered most important from my opening and closing keynotes for the Fall 2005 Network World Security Tour. I've been remiss in not mentioning this article. If you didn't attend the tour and are curious enough to spend 5 minutes, read John's article, Lessons learned from The Network World security tour.

I have to give John a call to thank him. He got every quote right:-)

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID486 by Dave Piscitello