Security Curve Weblog

Alan on Aetna

I received this via email from Alan Borack (a friend and colleague) about the recent disclosure by Aetna about losing member data, and with his permission am posting his comments here.

How long do you think it will take for the 2 companies impacted to notify
their employees they are among the 38,000 names on the laptop?

More and more banks are moving towards replacing desktop computers with what
we used to call 'dumb terminals' to lower costs and to prevent users from
saving information to the hard drive, cdrom or usb drives. Laptops too, are
being issued only to key personnel - namely technical support and officer
types - the kinds of people who don't have or need direct access to personal
information of employees or clients.

All good questions from a seasoned veteran of financial services; why indeed do all these folks have our personal data on their laptops?

Great Post over at Spire

There's a great post by Pete Lindstrom over at Spire today about Michal Zalewski and his recent disclosure of a zero-day IE vulnerability without notification to Microsoft. Pete takes the "devils advocate" position by saying that Zalewski's actions are pretty much OK in Pete's view:

Here's the interesting thing about Zalewski's approach: if it inspires a lot of "shock and awe" in you, then you are nowhere near able to protect your environment in a reasonable manner. The fact that he didn't provide enough time for a little song and dance before publishing is pretty much what I'd expect from an attacker, too...

True enough. Anyway, I highly recommend giving this post a read. Just for the record, I don't share his opinion about the evils of "white hats": it seems to me that bugs will always be present in software. White hats find those bugs and ultimately they get fixed; of course they do it because they are incented - either by the press or (more recently) for monetary remuneration. As communism taught us, people are less likely to do things without some kind of benefit to them (i.e. "greed is good".) It seems to me that the current "de facto" process ("flawed though it may be") does lead to bugs getting fixed - and I think that's a good thing.

Thoughts about McAfee's Rootkit Report

I noticed this morning a brief article over at Xatrix about rootkits on the rise, which sounded interesting. As it turns out, McAfee has put together some research indicating that "In the first quarter of 2006, the number of rootkits increased by 700 percent" and "Windows-based stealth components dominate the landscape, with an increase of 2,300 percent from 2001 to 2005". Wow! 2300 percent? Double-wow! Needless to say, these numbers seemed so astronomically high that I just had to dig into the methodology to see why that is.

After deliving pretty deep, I'm convinced that this whitepaper, like much of the research coming out of the AV industry, suffers from a common flaw: namely, results that are reflective of a given vendor's product are being used as a benchmark for interpreting broad events. What do I mean by that? Let me take you through an example of what I mean; take a look for a moment at the following startling graph from the McAfee whitepaper:

Seems pretty straightforward, right? Maybe, maybe not. Look closely at where the majority of the rootkit "growth" is coming from and you'll see that the lion's share is due to a relative small handfull of programs including "Backdoor-CKB", "Backdoor-BAC", and "W32/Feebs". To illustrate, let's do some digging on that huge spike of rootkit activity - the biggest one of the bunch - "Backdoor-CKB". Looking at the details, we find out that McAfee added detection capability for this rootkit somewhere between 10/2004 and 2/2005*. Looking again at the graph, we see that in 2005 we see an astronomical spike in the number of infections during that time period. It goes from nothing to the most popular rootkit (by far) within that same time window. Coincidence?

So which is it? Did this rootkit came out in 2004 and spread across the Internet faster than any other rootkit before or since *OR* was this rootkit there all along and the spike on the chart is reflective of when McAfee added the ability to detect it? To find out, we need to do a bit of backtracking to try and estimate when the rootkit came out. "Backdoor-CKB" is, of course, not called that by the folks writing and using it; they call it "PCShare" of which the current version seems to be PCShare 3.11. The earliest reference I can find on the Internet to a version of PCShare that we can be sure was classified as "Backdoor-CKB" (using the presence of pcclient.dll in the rootkit to make sure) is from late 2003 ("PCShare 2.0 Beta1".) We don't have a file listing for earlier versions to ensure that they would still fall under the same McAfee classification, but even so - since rootkits are not generally available on major hacker sites for a few months after being written, we can conservatively estimate that this rootkit was around at least since late 2002.

Late 2002 - two full years before it appears on the McAfee chart. For two years, it's gaining in popularity, getting more and more users, more and more infections. Then McAfee adds detection capability, bringing with it a tremendous spike in detection volume. Now, two years after that, McAfee is using this spike as part of the evidence to make the claim that rootkit infections are up 2300 percent. Hmmm... If I deleted half the signatures from the AV product on my laptop and I used that AV product's output to collect data for a report entitled "50% less malware this year", would that be accurate? Look, I've no beef with McAfee, and really it's good that vendors are making this type of research available for free - but I really think we need to approach vendor-sponsored research with clear eyes. Especially if the instrument that they are using to collect the data is their own commercial product.

* The "discovered date" is Feb 2005 while the "minimum dat" was published in Oct 2004. Since it's unlikely that protection was offered before it was discovered, we can assume that one of these dates is probably inaccurate.

Live free or die, baby.

I saw today on the EmergentChaos del.icio.us feed that New Hampshire is resisting the national ID strategy. How much do I love living in New Hampshire?

Press Hype about Gartner's "Mac Hype"

Gartner came out the other day to tell us all that any security concerns associated with running Windows on the Intel Mac is crap. According to the analysis:

All users should ignore any hype about the possibility of exposing the Mac OS to more viruses or worms. The Mac software will be located on another partition within a different file system; thus, running Windows on a Mac will not expose the Mac software to more "malware."

Um... Wait a second... Didn't Gartner just tell us two weeks ago A) that spyware for the Mac was a veritable certainty and B) that it was possible to create a Mac-Windows hybrid worm? I mean doesn't the statement "it might be possible to create a hybrid worm that attacks both the Mac and Microsoft Windows operating systems" seem pretty unambiguous to you? Now the reverse is true? Alright, alright, I won't be a nudnick since these statements came from two different sides of the Gartner house...

But mixed messages aside - their first statement, while technically true, is sufficiently limited in scope and vague to be misinterpreted by the press - and "boy howdy" how it has been. Headlines like, "Boot Camp Will Not Expose Macs To Security Risks, Says Gartner", or "XP won't expose Macs to viruses, says Gartner: Boot Camp security risk is just hype…" seem to imply that there is no additional risk associated with dual-booting Windows. Is that really what Gartner said? Parse the statement carefully to see that the answer's "no".

They say: "expose the Mac software to more malware..." Mac Software only. That doesn't address what other aspects of the system other than Mac Apps may or may not be exposed to more malware. The Windows partition, for example, is exposed to the same amount of malware as it was before. True? Sure it is. Isn't Windows running on Apple hardware just as likely to get malware as Windows running on Dell hardware? So, while it's technically true that Mac apps are just as likely or unlikely to be a vector for attack as they ever were, the system as a whole is more likely to be comprimised than it was before BootCamp because of the fact that the attack surface has increased.

In other words, at the same time that Tom Ferris over at the Security-Protocols is posting his 7 new 0-day OS X bugs (no patches, no workarounds) that can be used to attack the Mac side of the host, the Windows side has all the same worms, viruses, and spyware that we already know and love.

So, who's the one "hyping"? The security community who's saying that the attack surface has increased on Mac or the press who's spinning what Gartner said into a "don't worry, be happy" mantra?

Whose fault is the bad software anyway?

There was an article that came around today called Software insecurity: Plenty of blame to go around over at GCN. The article contends that the blame for bad software lies at the feet of either developers or users, but that specifically who is to blame is up in the air. There is, of course, no shortage of opinion; check it out:

Stuart Katzke of the National Institute of Standards and Technology said that standards and guidelines developed by NIST could help... He said the suite of documents produced for the Federal Information Security Management Act effectively establish a level of due diligence for government IT systems.

Keith Beatty of Science Applications International Corp. went out on a limb by praising the oft-criticized Common Criteria program operated by NIST and the National Security Agency.

Do folks really need me to flay this or is the lack of useful dialog already self-evident? Look, Common Criteria certification is not the answer to buggy software. Microsoft's products are common-criteria certified, and they still have plenty of bugs - if that were the answer, I think we would have seen less bugs as more software went through the process as opposed to more. As to the 150-page NIST document - I don't see the connection; sure, it's good to have an assessment program (special pub 800-53), it's good to have checklists for developers (special pub 800-53), and so on. But is more documentation from NIST really what the industry has been missing in order to write bug-free code? I'm thinking probably not.

Of course, there were some more helpful suggestions:

Eset LLC ... blamed the problem of buggy software on a disconnect between developers and users. What seems proper and intuitive to a developer often is ignored by users, who do strange and terrible things with their applications.

Although clearly this doesn't address all the problems: bugs can occur even in the default configuration of products. If the Eset assertion were correct, shouldn't the default configuration be bug-free?

Eric Cole of Lockheed Martin Corp. acknowledged that software often has flaws...

At last, an assertion I can agree with. All software has flaws; I'll buy that for a dollar.

DHS continues to not get it done

Remember back in October when we wrote about how the DHS wasn't getting it done in terms of critical infrastructure protection? Well, the other day GCN put out an article about Andy Purdy's discussion at the 2006 International Conference on Network Security where he indicated that... well, things still aren't getting done. He indicated that there's a lack of coordination at the highest levels, a lack of information sharing between the federal and the private sector, and that cybersecurity is too low on the White House priority list. At least they have a reality-based picture of the situation over there.

In apparent answer to this, the National Science and Technology Council issued a 121 page report that basically says the same thing, but at significantly more taxpayer expense. Seems like we really need to start getting things done over there.

By the way the picture is from the Homeland Security On a Roll entry from the "Duct Tape Guys". Yeah, it's that funny.

BootCamp, RebootCamp, and Virtual Security

Along with a bunch of other folks, I've been following the numerous discussions about Apple's Bootcamp with a bit of interest; "dual booting" isn't a particulary new technology for most of us, but it's interesting nevertheless. Today, I cam across a post on Peter O'Kelly's Reality Check that made the topic even more interesting - a technology called "Parallels" that allows a Mac user to run a virtual Windows image. Ok, ok - virtual machines aren't new technology either - but all these discussions about maximizing the flexibility of the new Apple hardware open up interesting possibilities for Mac users. Which leads me to something... Notice this language in the article that Pete references (emphasis mine):

Most people comment that an Intel Mac runs Windows faster than any PC they've ever owned. And if the Windows side ever gets bogged down with viruses and spyware, you can flip into Mac OS X and keep right on being productive.

While this isn't really the point of the article, the obvious subtext is that virtualization technology increases the overall security of the platform. This is a view I hear more and more commonly; for example, Security Focus has an article that came out yesterday about the security advantages of virtualization:

Mike Danseglio, a Microsoft program manager in the company's security group, recently had this to say at a security conference: "When you are dealing with rootkits and some advanced spyware programs, the only solution is to rebuild from scratch. In some cases, there really is no way to recover without nuking the systems from orbit." So it's come to that. Everyone reading this knew it all along, but there it is in black and white - if a Windows machine gets infected, wipe it and start again from a baseline install. Virtualization, however, makes that easy, affordable, and quick.

I think it behooves us to question the assumptions here - is it a given that virtualization will bring with it a corresponding increase in platform security? I used to think so, but now I'm not so sure... but we'll get to that in a minute. Let's start by looking at how some of the products out there enumerate the perceived security benefits.

• VMWare says, "Users protect their PCs against adware, spyware and other malware while browsing the Internet with Firefox in a virtual machine... isolation capabilities to prevent malware downloaded in the browser from propagating to the normal desktop." Point 1: applications are "isolated" from the host operating system.
• IBM says, "The partitioning-capable server is designed so that one partition is isolated from software running in other partitions, including protection against software defects and even deliberate software attempts to break the partition barriers." Point 2: applications are "isolated" from each other.
• Sun says, "N1 Grid Containers are shielded from the outside world and the tenants of a container are assured that no other users of a container on the same system can "see" what they are doing, or derive or compromise information. Additionally, an administrator, such as the traditional 'root' user, inside of a container only has authority over his own container, so if the container is illegally accessed, the container isolates the intruder inside the boundary." Point 3: users are "isolated" from inappropriate resources.

Hmm... Sounds to me like the hubub is about isolation; in other words, the claim is that virtualization improves security because applications and users can now be grouped in any number of ways at the application level. Hearing no argument, if this type of isolation is the primary goal, what does that mean for us from a security perspective? Let's look at it from the top down - can we make the broader statement that "isolation" in other contexts is always a security benefit? Is it true that segregation in and of itself has a clear security benefit in all cases? Some would argue with me on this, but I happen to think the answer is "no"... I think segregation improves security only to the extent that it is manageable... period. Without management, segregation adds nothing to security (best case) or even detracts from security (worst case).

By analogy, take isolation technology at the network layer. For a long time, a bunch of people thought that buying and deploying firewall technology (thereby isolating portions of their network) would solve a ton of security issues; but we learned over the course of events that it wasn't the isolation itself that brought the benefit, but the broader context of how that isolation is used and maintained. In other words, a firewall won't do anything unless you deploy it in an intelligent way. It's fairly accepted nowadays that firewalls (while a useful tool in most cases) can also decrease security depending on how they are used and deployed.

It seems to me that virtualization is the same thing: use it intelligently as an isolation tool and you increase security - use it without thinking through how it will fit in your current world and you decrease security. Create a well-thought out and manageable set of virtual images/apps/whatever along with a well defined plan for how to maintain them and you probably will (as VMWare, IBM and Sun claim) create an environment in which security thrives. However, create yet another unmanageable mess (e.g. unmaintained VM images, unpatched "disposable" guest OS's, etc.) and the only thing you've done is increased complexity, increased administrator workload, and built new "virtual" pathways to your assets. I guess the moral of the story is the same one I've made countless times: management first, technology second.

Thus endeth the rant.

Metasploit Reversing Toolkit | tiklooT gnisreveR tiolpsateM

The other day, I saw a link to the Metasploit Blog over on Emergent Chaos. Since I'm a regular user of Metasploit, I decided to check out the new blog, and what did I find? An introduction to the Metasploit Reversing Toolkit! Needless to say, I became very excited when I saw this; I remember cutting my teeth "back in the day" - filtering through the torrent of underground literature on the topic (only the smallest fraction of which were readable, let alone truly exceptional.)

I'll spare you the waxing nostalgic about my first copy of SoftIce or my first time I traced through BOZOSLIVEHERE - a name which I remember thinking was particularly apropos at the time (considering, at any rate, why I was tracing through it.) But it does seem to me that the Metasploit folks have it right once again; reverse engineering is even more important and useful today than it ever was, and it's getting harder and harder to do the more complex software becomes. Back in the day, most folks interested in the topic for its own sake were probably interested in cracking software or corporate espionage. Today, there is so much more to do - we have DRM components to find on our music CDs, "drive-by" spyware infestations to analyze, spurious binary components to audit, etc.; all these activities require a set of skills that are difficult to learn and seldom actively encouraged. In any event, I'm filled with optimism that Metasploit can do for reversing what they did for exploit code, although I'm only cautiously optimistic about the fact that they've chosen to develop it in Ruby.

Identity Theft Victims Hit 3%

According to Security Focus, 3.1 percent of American households have now been victims of identity theft as per the National Crime Victimization Survey. To put this in perspective, here are some other things that are 3 percent:

- Percent of Americans leading a healthy lifestyle
- Percent of Americans with a gambling addiction
- Percent of Americans who read blogs on a regular basis
- Percent of Americans with a high school education in 1900
- Percent of Americans who believe we went to war in Iraq to free the Iraqi people
- Percent of Americans who are Atheists
- Percent of Americans who practice Herbal Healing
- Percent of Americans who are underweight

How likely is this really?

A recently discovered piece of malware that infects both Windows and Linux systems has been analyzed by Kaspersky. The media is all fired up about this, giving it international coverage and even inspiring commentary from SANS.

Given the attention, it begs the question, "how likely is it that a cross-platform worm or virus will actually survive and prosper?" Despite what some other folks are saying, I think it's pretty unlikely. Why is that, you ask? Because a tremendous number of folks outside of the virus-writing world are working on maximizing portability and to-date we don't have native code that runs on multiple platforms. That's why we have Java, .NET, and virtualization. Trying to do anything other than very simple tasks increases the overhead requried for portability tremendously. This particular piece of malware, for example, is extremely rudimentary - it manipulates files to replicate and it relies only on the most basic of operating system services. Trying to do anything more complex: opening a socket, embedding itself in the OS, stealth techniques, etc. are all orders of magnitude more complex than basic file manipulation.

So, my advice is not to panic about this. Not that cross-platform malware can't be created (it can - take the iis/sadmind worm), but it's unlikely that this proof-of-concept heralds a new breed of malware as some sources are saying.

From now on, I'm calling it "CHiPs"

Ahem... So, Panda put out a press release last week that (unfortunately for me) intersted me enough to entice me to download and read a marketing whitepaper about TruPrevent. Now, I have nothing against Panda but lest anybody accuse me of endorsing the paper (trust me I don't), let me assure you that the only reason that I'm bringing it up is that it drew my attention to a new acronymn that was used extensively within the paper. The acronymn was "PIPS" or "Personal Intrusion Prevention System". Umm.... Yeah.

So for a while now we've had NIPS (Network Intrusion Prevention System) and HIPS (Host-based Intrusion Prevention System); now apparently, somebody thinks that we need a completely new acronymn. Now, rather than staying with the anatomy motif and choosing something like LIPS (that would have been my pick), they've elected to use "PIPS". I'm not entirely clear on what makes it "personal" - allthough both Panda and Gartner seem to imply that the fact that it's integrated makes it personal... Maybe that's it, although it seems to me that saying "PIPS" is more confusing than saying "suite".

Anyway, given the tendency for people to slap an -IPS suffix on random letters, I wanted to use this humble forum to go on record as reserving the "CHiPs" acronymn for future use. Yep, that's right - "Consolidated Holistic Intrusion Prevention System". CHiPs is the natural evolution of the market, and provides a robust framework for prevention of nefarious activity. You heard it here first. Here are the features that differentiatie a true CHiPs:

- The use of two agents working in tandem
- Uses lightweight, maneuverable "mobile" agents
- Ability to locate and investiate mobile threats
- Designed "to protect and to serve" both consumer and enterprise PC's
- Half the footprint of traditional mobile agents

This is coming, and man is it going to be awesome when it gets here.

Apple - they're killing me

Today, I came across a post on Illuminata called "Apple, Enemy of Reason" discussing the Apple "Boot Camp" technology. Briefly, BootCamp allows OS X to run XP applications on Macs with Intel hardware. Most of the pro-Apple sites that I read tend to view this as a positive development... I'm just ticked cause I have a PowerPC Mac so I'm left in the wake.

No matter what congress says, encryption still isn't a panacea

Last week, the "Energy and Commerce" Committee of the US House of Representatives approved HR 4127, the "Data Accountability and Trust Act". In case you haven't heard of it, this bill basically does what SB1386 did, but at the federal level rather than at the state level - unless, of course, the data is encrypted. So what does that mean? According to the bill:

ENCRYPTION- The term `encryption' means the protection of data in electronic form in storage or in transit using an encryption algorithm implemented within a validated cryptographic module that has been approved by the National Institute of Standards and Technology or another comparable standards body recognized by the Commission, rendering such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data. Such encryption must include appropriate management and safeguards of such keys to protect the integrity of the encryption.

Now, that's interesting. I'm reading the line about to "validated cryptographic module... approved by [NIST]..." to mean FIPS 140-2. In the past, I've been hard on FIPS 140 since I think that in some cases a certification requirement can trump common sense. SB-1386 does not specify what, exactly, "encrypted" means, saying disclosure is required only when "...whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person..." The issue, of course, being that "encrypted" (or "unencrypted" for that matter) can mean different things to different people. Somebody could use EFS under Windows 2000, adding absolutely no security to the data on the machine, but yet claim "safe harbor" under 1386. Not so in this new bill. So, kudos to the House for stepping up to the plate and actually putting in some safeguards to make sure that this provision means something.

Of course, given the fact that not a day week goes by where we don't have some new disclosure about stolen PII, I'm not sure that we're going to see anyone using this new and harder to meet safeharbor requirement. But that's another matter.