Illuminations

Apple exploits instead of Apple pie on Thanksgiving

I was asked recently by some prospective customers how our 24/7 global support coverage works?  The inference being that they expect that we log calls and then wait 5 or 6 hours to start Engineering working on it.

Since a zero-day Apple QuickTime vulnerability was published on Thanksgiving day with associated exploit code, I thought that would make a good example of the benefits a truly global engineering team can have.

Apple QuickTime RTSP Response Header Remote Stack Based Buffer Overflow Vulnerability

Apple QuickTime RTSP Response Header Content-Length Remote Buffer Overflow Vulnerability

Apple has not released any patches/updates so far. However, the exploit code is publicly available, which puts users at risk.

This vulnerability, if successfully exploited by the attacker, would allow full control of the victim's computer. The attack can be as easy as convincing the user to browse a website.  Nevis Labs has tested the exploit and it works pretty consistently, and, as per the reports, it also works for Windows Vista.  I'm happy to report that our customers are well protected because our Nevis Labs offices are global and work 24/7, so we developed a threat protection signature to cover this threat while everyone else in the US was enjoying their Apple pie.

//Dom

It's Patch Tuesday again....

So I thought I'd share an example of the timely updates that our customers receive on a daily basis from our Nevis Labs service.  Subscribers obviously get a lot more information, and access to the Threat Encyclopedia that we maintain, but I've received a few requests to give a taste of the service, so thought today was a good day to do exactly that.

Vulnerabilities

MS07-061

Windows URI Handling Remote Code Execution Vulnerability

Description

Windows URI Handling Remote Code Execution Vulnerability refers to a vulnerability which exists in the way the Windows shell handles specially crafted URIs that are passed to it. An attacker could exploit this by including a specially crafted URI in an application or attachment, which could potentially allow remote code execution

This vulnerability can be exploited through a variety of applications, including Adobe PDF Reader, mIRC, Firefox, Outlook, Netscape Navigator, and others.

Impact

Windows XP Service Pack 2

Windows XP Professional x64 Edition and Service Pack 2

Windows Server 2003 Service Pack 1 and Service Pack 2

Windows Server 2003 Service Pack 1 and Service Pack 2

Windows Server 2003 x64 Edition and Service Pack 2

Windows Server 2003 with SP1 for Itanium-based Systems and SP2

Severity

Critical

Solution

On LANenforcer, update the CEI profile to the latest version

To check for CEI profile version, type “show version” on the CLI prompt of the LANenforcer.

MS07-062

DNS Spoofing Attack Vulnerability

Description

DNS Spoofing Attack Vulnerability refers to a vulnerability which exists in Windows DNS Servers. It could allow non-administrative users to send malicious responses to DNS requests, thereby spoofing or redirecting Net traffic from legitimate locations.

Impact

Microsoft Windows 2000 Server Service Pack 4

Windows Server 2003 Service Pack 1 and Windows Server 2003 Service Pack 2

Windows Server 2003 x64 Edition and Windows Server 2003 x64 Edition Service Pack 2

Windows Server 2003 with SP1 for Itanium-based Systems and Windows Server 2003 with SP2 for Itanium-based Systems

Severity

High

Solution

On LANenforcer, update the CEI profile to the latest version.

To check for CEI profile version, type “show version” on the CLI prompt of the LANenforcer.

Can we detect sleeper cell bots?

Think of a botnet as a terrorist sleeper cell. A terrorist sleeper cell consists of a group of terrorists that blend themselves into the society without attracting the attention of organizations such as the FBI. When they get commands to strike, they go blow up planes, disrupt power plants, detonate dirty bombs, etc. Similarly, a botnet sleeper cell sneaks silently into computers; stays inactivated and undetected, until the botnet owner issues orders to attack. These orders can be anything including sending spam, performing a DDoS attack, or recruiting more bots.

Terrorist sleeper cells can lead directly to the loss of life as well as great physical and physiological damage, while botnet sleeper cells could cripple network infrastructure and inflict economic losses, or worse. Early this summer, Estonia was pounded by a DDoS. This displayed a tremendous amount of coordination and the destructive power of sleeper cell bots. Today, Storm worm is becoming more powerful by the day, and can easily overpower the world’s top supercomputers. Terrorism prevails when both types of sleeper cells work together. With the rumors of Al Qaeda announcing Cyber Warfare starting this Sunday, and with availability of electronic Jihad 2.0, we have yet to see the impact, but might soon.

Detection of both types of sleeper cells can be done using behavior profiling. In both cases the steps are to understand normal behavior, look for suspicious triggers, narrow down the watch-list, and continue to observe the suspect more closely until the suspect is proven to be guilty or innocent. On the other hand, there are important differences that make detecting terrorist sleeper cells a harder problem than detecting sleeper cell bots.

Total surveillance is the first key component of sleeper cell detection. It is possible to have all the hosts under total surveillance in an enterprise (Nevis does it), however, it is hard to watch every person in a nation 24/7 (even though it is attempted). The FBI has a watch-list and as of today there are about half a million people in there. Watching half a million computers is much easier than watching half a million people. (Perhaps the half a million people are best watched by primarily watching their computers.)

Characterization of behavior is the second key component of sleeper cell detection. The more characteristics you look for, the better the detection mechanism gets. Instead of going after every Muslim-like name (such as mine, but that is another and ongoing story), adding more information such as background, religion, bank and phone records, degree, age, sex, etc. would make the profile stronger and hence less false alarms. But the list of possible characteristics to include is nearly endless. On the other hand, while a few of us use computers in a diverse way, the huge majority do so in ways that are far easier to characterize than a person, even a mundane blog-writing cubical worker.

Correlation across suspected bots is more fruitful than correlation across suspected terrorists. The detection of a single bot in the botnet sleeper cell can often result in the capture of the entire botnet. However, the capture of a single terrorist may not necessarily lead to the capture of the entire terrorist network (even with waterboarding).

The impact of false alarms varies in both cases. False positives in terrorist sleeper cell detection can have a wide range of damage from a cop showing up at your doorstep to a person ending up in Guantanamo. False positives in sleeper cell bot detection can range from a guest user being cut-off from a network for a few minutes to extra work for a sys-admin, or even taking down a large chunk of the network and damaging the enterprise financially. Arguably, false negatives in the case of terrorists are worse than they are in the case of bots; even a single terrorist can lead to substantial loss of life.

While the fundamental theory behind detecting sleeper cells remains the same, the FBI’s job is much more difficult than mine. So, I’ll keep my job as well as cube life which the FBI secretly classifies as: D8DBQFHM6/RERAJ9O7woT0QB7xmpMACbBxfq4pLMkwyUxbOMFglno1gA4ÇGÊPœ/td^ÖÐÚÒÅ%iõÜ/'NO7*‰o{¶ˆ0öp%‑ÎUPuŠ4'ÅÞ©(8¹

//Khushboo Shah, Ph.D.

NAC deployments under scrutiny...

Lisa Vaas over at eWeek is reporting on a new NAC survey coming out of the Aberdeen Group. In Carol Baroudi's "Who's Got the NAC? Best Practices in Protecting Network Access" report (it's free if you discount the sponsor sending bugging you for the next few weeks), she surveys close to 400 NAC adopters and attempts to benchmark who is doing a good job of controlling access to their networks (while also reviewing some the processes and technologies they are using). It's interesting reading and reviewing the deployments rather than the technologies and vendors is a refreshing take on a NAC survey.

Here's the take away for me. Those who are considered Best in Class in the report have a strong focus on a holistic approach to NAC and prioritise the post-connect functionality and the need to persistently monitor and control endpoints and users in a meaningful way after they get on the network (and we're not just talking about doing an endpoint posture check every 10 minutes). They also believe that operational considerations and the end user experience are of paramount importance to success.

Here is what those Best in Class organization say are the most important things to expect out of a NAC solution:

- Prevents unauthorized users from accessing the network
- Causes minimal operational impact on users, help desk and network performance
- Supports/enforces policies specific to different user groups
- Logs all network access events for auditing
- Prevents unauthorized devices from accessing the network
- Centrally records all events
- Can be installed without directly impacting network performance
- Is transparent to the user
- Supports enforcement for remote users
- Can quarantine unhealthy machines without cross-infection
- Assesses endpoint security status

This certainly gels with what our customers are telling us as well. I think point number 2 is where most NAC solutions fall flat on their faces. Most vendors have given very little consideration to getting the solution into the network seamlessly and ensuring there is a transparent user experience. I'm proud to say that our customers have no such worries. If you'd like to read an impartial, blow by blow, daily account of the evaluation and operational deployment of a NAC product into a sizeable production network, head over to Justin Gerharter's blog at www.bumpinthewire.com

//Dom

Why Blacklisting Doesn’t Work

After reading Mike Fratto’s post on “Why Blacklisting Works” I feel some comments are in order.

The default allow (or “blacklisting”) vs. default deny (“whitelisting”) debate seems to go on and on ad infinitum. Let me state up front that I am unabashedly in the default-deny camp, and here’s why.

Sure it sounds easier in principle to just deny the bad stuff, thus avoiding the trouble of figuring out just what the good stuff is (and maybe avoiding a few irate help desk calls in the process), but, as you actually point out, it’s really not good security. But we have to accommodate customers of either persuasion and, truthfully, your NAC product should let you do it whichever way you want.

We opted for default deny.

Why? Because it’s clearly the best security practice, based on many years of many people’s experience. We just couldn’t make a firewall default allow and still think of ourselves as security people.

Besides, when you put an ACL on a file, do you normally make it default allow and blacklist just those who shouldn’t be granted access? I think not.

But, honestly, it shouldn’t be that big a deal to append an allow-all rule if that’s what you really want to do. In fact, we ship our product with an allow-all sample policy configured on all secure interfaces, since we found that most of our evals and deployments want to start out by monitoring what’s happening on their network – since unfortunately, they don’t really know how bad of a problem they have. And this makes it easier to get the box up and running.

And we also ship with a “pre-login” sample policy that allows just enough access to things like Active Directory to let Windows boot and get GPOs, and let users get tickets to login and open browsers, and which of course has to be customized with the specific server addresses for the particular network. I don’t really understand why you couldn’t configure the ConSentry box to do the same thing and whether this was for endpoint compliance or for post-connect, but I suspect it is because they only allow you to set policies for UDP and TCP. So if you had a default deny but want to allow some other IP protocol, such as ICMP or GRE, you can’t do it.

But I digress. On your impossible-to-manage points, we think you can avoid a lot of the headaches inherent in a traditional monolithic perimeter firewall rule set by composing policies for users based on group memberships. This way, the access granted to particular user classes can be more readily managed.

Speaking of managing policies, I wish LAN security could be as simple as you want would like just by blacklisting, but as far as I am concerned it’s only an illusion. If you forget to deny your sales people access to one of those R&D servers, say, nobody might ever know until it is too late. So have you really solved your security problem, or just temporarily made it appear to go away?

I can get behind your thought processes, though. When we were developing the Nevis secure switches I have to confess that even I thought the same as you, at least for a while. I pondered, isn’t LAN security a different species than perimeter security? At the perimeter it’s like at the front door, you only want to let friends in and anyone who is not your friend is clearly SoTE, but on the LAN, it’s like you’re roaming among the cube farm: everyone can pretty much go anywhere they want to because everyone is your friend. Inside, you really only need to make a few places like the CEO’s office off limits and remember to lock up those few file cabinets with sensitive stuff in them when you step out. Most people are honest and adhere to company policies, right? And guests need an escort.

To put it differently, at the perimeter you typically want to deny most ingress but allow most egress, but on the LAN you are more concerned about what different classes of users can or maybe shouldn’t access. And until recently there have been limited options for providing an escort for your guests to keep them from running amok. So how to architect a LAN security firewall, should it default to deny or allow?

-- Joe