Wednesday, July 9, 2008

Productivity: Useful Meetings

Aaron, of the Dumb Little Man blog, just posted a helpful reminder that includes eight tips we all [should] intuitively know in order to keep meetings focussed and useful. I think we've all experienced "those" types of work meetings; whereby hours pass and very little progress, if any, has been made. The result is wasted time, wasted money, and often frustration and confusion.

Aaron writes:

The phenomenon of chronic, pointless meetings is also known as the Dilbert Meeting in some circles. Dilbert Meetings happen every day, wasting people's time and patience.

Meetings can be quite productive, but most organizers simply don’t take the steps to guarantee that a meeting will be useful.
Aaron then lists and expands upon the following eight points:
  • Have a clear agenda
  • Make sure that only attendees are people who need to be present
  • Establish objectives for the meeting
  • Have the attendees prepare in advance (if necessary)
  • Keep it short
  • Record key points and decisions
  • Create action items and assign them
  • Report progress and follow-up
I believe it's important for all of us who propose meetings to incorporate the above points into how we organize and run our meetings. The result will be better for the business, and better for the development and morale of those attending.

Steve Zenone

Security: Thoughts on Latest DNS Vulnerability

While on a quick trail run before work this morning, I was thinking about yesterday's announcement of a serious vulnerability in the DNS protocol. For those that don't know, yesterday Dan Kaminsky announced that there's a fundamental flaw in the DNS protocol. Shortly thereafter the United States Computer Emergency Readiness Team (US-CERT) issued a security advisory titled, "Multiple DNS implementations vulnerable to cache poisoning".

Since we're talking about a fundamental flaw within the DNS protocol itself, many implementations of DNS are considered to be vulnerable. DNS, in a nutshell, is what translates human readable and memorizable names, such as, to IP addresses that can get routed through the Net, such as

BlackHat has made available a recording of the press conference at which Karminsky made the public announcement. Karminsky has also made available an online tool to check whether or not the primary DNS server you're using is vulnerable. A recent post on NANOG has a link to a perl script that allows one to run Karminsky's DNS checker against any nameserver.

I've heard a few individuals state that this latest vulnerability isn't critical in nature. We do know that Karminsky will be releasing full details of the vulnerability at next month's BlackHat in Las Vegas. It is also possible that exploit code could emerge prior since Karminsky did narrow down the area in which the DNS design flaw exists. Though Karminsky has stated, "This is not enough information to reverse engineer the flaw," I believe it's an extremely risky assumption for businesses to base delaying the patching of their vulnerable name servers upon.

Looking at a risk matrix, I see the this DNS vulnerability as a high risk:

Likelihood of exploitation: LOW/MEDIUM [ within 30 days]
Impact of exploitation: HIGH
Risk Rating: HIGH

One individual I know had stated, "In terms of DNS, the world isn't any more dangerous today than it was yesterday." However, we're not just dealing with randomization of source ports which had been known publicly for several years (back in 2005). We're also dealing with the weak entropy in the DNS transfer id (DNS XID). I believe that the risk, or danger, has increased.

In some uncomfortable way, this latest issue with DNS reminds me of the levees in New Orleans that were known to have severe vulnerabilities. Eventually the threat (heavy rain) exploited (broke) the vulnerability (failing levees) resulting in negative impact (flooding, financial loss and loss of life). Ignoring the vulnerability with the levees didn't remove the risk or make things any "safer".

I'm interested to see what Karminsky produces at the upcoming BlackHat.

Steve Zenone

[UPDATE - 7/10/2008]: Yet another option to test your nameserver is to use the dig hack from Duane Wessels; from a unix shell type 'dig +short @nameserver-to-be-tested TXT'.

A vulnerable nameserver will display the following output:
"nameserver-you-tested is POOR: 22 queries in 0.6 seconds from 1 ports with std dev 0.00"

In turn, a better maintained nameserver will return the following:
"nameserver-you-tested is GOOD: 22 queries in 0.6 seconds from 1 ports with std dev 0.00"

Thursday, July 3, 2008

Security: Instant Messaging and Enabling Business

I recently had a colleague ask me about the inherent risks in using Instant Messaging (IM) for business. Certainly, IM is an extremely effective way to communicate with team members and customers who may not be in close physical proximity. However, if used incorrectly, negative impact to the business can be massive.

There's consumer grade and business grade IM solutions. Services such as Yahoo IM are considered consumer grade. All text based IMs can either be routed through a core set of central servers and then on to the recipient, or through peer-to-peer connections. When you combine consumer grade IM services with traffic flowing in the clear (i.e., unencrypted) through central servers outside of the organization's control, you end up with a significantly elevated set of risks. Are these risks worth accepting?

Here are some of the more obvious risks that I see with using consumer grade IM for business:

  • Vulnerable Clients -- advisories for vulnerabilities in chat clients are announced fairly often. Many of these vulnerabilities allow for the remote execution of code on the vulnerable client system
  • Traffic can be viewed ("sniffed") -- by default, consumer grade IM clients send all of their traffic in the clear. There are plugins to provide encryption for some clients, however, all parties involved in the chat will need the crypto plugin enabled and configured correctly
  • Data theft -- a nefarious employee could potentially move critical/restricted data to a location offsite
  • Identity Theft -- The mechanism for consumer grade IM user authentication is weak. Grab the weak authentication traffic and an attacker now has valid login credentials. The stolen credentials can then be used to impersonate the victim and be used as a launch pad to further identify theft
  • Provides IP info to attackers -- if an employee decides to go to an external chatroom with their IM client, their IP is now known to anyone else in the chatroom who may be interested...including a potential attacker. With the IP the attacker can focus their attack to a specific system
  • Privacy...or lack thereof -- see all points above
  • Social Engineering -- more likely to happen if an employee engages in conversations in non-business specific chatrooms
Another risk is in employees using IM for business on their home computers. Imagine, for just a moment, that an employee commits a crime against the business from their home and used IM to enable them to commit the crime. Your business won't have the authority or right to confiscate their home computer for investigation - your hands are tied behind your back. I'm sure you can start seeing where the dangers and risks start to go up.

Additionally, many chat clients will log all conversations to disk. What if confidential or restricted data is logged and stored on an individuals home computer? Other family members, or friends, may have access to that system, or perhaps the home computer is already compromised and under someone else's control (think botnet). Now the attacker can pull the chat logs and have unauthorized access to confidential or restricted data. The impact could be titanic to the business! Of course, confidential or restricted data should never be sent over IM in the first place.

In addition to having policies, procedures, and perhaps even guidelines on the proper use of IM for business, I believe the return on investment by providing an internal and redundant IM service to enable business is compelling and certainly worth considering strategically.

Steve Zenone

Wednesday, July 2, 2008

Security Toolbox: RatProxy

The good folks from Google have released a freely available open-source web application security assessment tool called RatProxy. The tool, which is still in beta, is designed to identify security vulnerabilities within web based applications.

Quoting from the RatProxy project documentation page:

"Ratproxy is a semi-automated, largely passive web application security audit tool. It is meant to complement active crawlers and manual proxies more commonly used for this task, and is optimized specifically for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments."
Earlier this afternoon I downloaded the source code and compiled it to run on Ubuntu 8.04. After posting this blog entry I'll begin experimenting with RatProxy.

RatProxy Documentation Page [link]

Steve Zenone