Category Archives: Security

10 Days of Rain Mistakes: McAfee Whitepaper

McAfee Labs has released an interesting analysis of recent DoS attacks that targeted South Korea. They criticize the code for numerous mistakes; and they speculate the mistakes were caused by multiple teams working together and unsuccessful at developing a cohesive product. Here are a few examples of the criticisms.

Short-term objectives

While highly destructive code like this was common with early malware, it has long since given way to bots that allow for long-term command and control. Cybercriminals realized that compromised computers under their full control are much more valuable to them for sending spam, proliferating malware, and for harvesting valuable data from the compromised device.

Lack of flexibility

Unlike many other botnets, the malware installed as these C&C clients lacked command interpreter functionality. This results in very limited flexibility in how the bots are used.

Inconsistent use of encryption

While the C&C application also decrypts the configuration’s filename with 128-bit AES, the initial dropper contains this filename in plain text. This design hints at multiple authors that were not all aware of this filename being encrypted in other parts of this attack.

Typos from cut/paste in the code

The code to check file extensions suffers from some mistakes due to copy and paste; for example, not only .java but .javanything files will be deleted.

Inconsistent execution

…the code then utilizes a huge C++ CAB file implementation to create a new CAB file per overwritten file and adds the already zeroed-out file to the CAB. This is another indicator of multiple engineers working on this codebase without everyone understanding the entirety of the code.

Despite all the criticism, McAfee analysis still rates this as “sophisticated”.

The level of technical sophistication behind Ten Days of Rain, being used for the relatively simplistic act of a DDoS attack, doesn’t track.

What are those levels of sophistication? They don’t say but they give us this simile.

DDoS, malware-leveraging encryption, and multitier botnet architectures are not new. Nor are attacks against South Korea that suspiciously align with North Korea’s agenda. However, the combination of technical sophistication juxtaposed with relatively limited execution and myopic outcome is analogous to bringing a Lamborghini to a go-cart race.

On the one hand their analysis pushes us to consider the engineering flaws and disconnected “myopic” work, while on the other hand it concludes with the imagery of a Lamborghini.

I suspect they do not mean bringing a Lamborghini hat to a go-cart race. They must mean the car, and a modern one at that.

Lambo Hat

Ooops, I meant the other imagery of a Lamborghini.

Lambo Shoes

Ah, well, maybe they are making a more subtle point. If you see someone show up to a go-cart race wearing a pair of shiny red suede Lamborghini slippers…

It also is worth noting that although almost 20% of the command and control servers they tracked were in the US, far more than the next country, McAfee steps away completely from any mention of motives tied to national interests.

Beyond the threat mitigation, the questions of how, who, and why still remain.

They did a very nice job in this whitepaper on the how, and they admit to speculation (based on an odd assumption about collaboration instead of plagiarism) about the why, but they basically don’t touch the question of who.

Too bad they did not go for the who too; I had fun writing Operation Sloppy Night Dragon.

2011 BSidesLV: A Cloud Odyssey

I will be presenting at the 2011 BSidesLasVegas conference:

“2011: A Cloud Odyssey”

When: August 3 or 4, 2011
Where: The Artisan Hotel, 1501 West Sahara Avenue, Las Vegas, NV 89102
Cost: Free (as always!)

Are you ready to fly into the clouds? This presentation takes the audience on a humorous review of technology and progress since the 1968 American epic science-fiction film by Stanley Kubrick and Arthur C. Clarke. It explores a philosophical evolution as it relates to technology and proposes some surprising new answers to four classic questions about managing risk:

  1. What defines human nature
  2. How can technology change #1
  3. Does automation reduce total risk
  4. Fact, fiction or philosophy: superuser

2011 a cloud odyssey

This is the next installment in my series of 1960s-film themed presentations. The last one (“Dr. Stuxlove”) was at BSidesSF 2011.

Copy of Presentation: 2011acloudodyssey.75dpi.PDF

NIST SP 800-63 Rev. 1

Comments have been requested by NIST (until July 29, 2011) for the latest revision of their DRAFT Electronic Authentication Guideline

…technical guidelines for the design of electronic systems for the remote authentication of citizens by government agencies. The revision represents an expansion and reorganization of the original document, broadening the discussion of technologies available to agencies, and giving a more detailed discussion of assertion technologies. Changes intended to clarify the pre-existing requirements are also included in the revision.

NIST SP 800-63 Rev. 1

Comment Template

Submit comments to eauth-comments@nist.gov.

Enterprise Key Management for Cloud

EKMI is dead, long live EKMI. It was more than two years ago that I reached a proud milestone as a member of the open-source key management group for Oasis EKMI (Enterprise Key Management Infrastructure) — we released the SKSML (Symmetric Key Services Markup Language) in January 2009.

It was a culmination of projects I had been working on for years with StrongAuth to provide an easy and inexpensive encryption solution for the Payment Card Industry (PCI). SKSML did not get a warm welcome from some big name vendors but it did generate some industry attention.

Encryption represents a final level of protection. Even if data is lost or stolen, it’s of no value to the holder without the decryption key. EKMI is a valuable component in the operational and management aspects of encryption, and organizations with complex encryption requirements ought to start putting pressure on their application and security vendors to support the initiative.

The SKSML protocol had been available since 2006. Yet just a couple months after the OASIS specification was final and public we watched vendors step forward to form a separate and competing committee at OASIS: the KMIP (Key Management Interoperability Protocol).

It was weird to see a competitive standard formed from within OASIS instead of from a competing organization (e.g. the IEEE P1619.3 or DSKPP from KEYPROV/IETF) as illustrated by ISACA in 2009.

On the other hand we were pushing an open-standard that emphasized ease of deployment and configuration. These concepts may have challenged the philosophy of some vendors to the point where they felt compelled to try and reboot the OASIS committee. The chair of EKMI stepped-down rather than fight on all fronts.

Our goal was to push forward an enterprise key management protocol into the industry. To that end it was a success, even if our open and easy philosophy to key management was not adopted.

Today I was asked if I have heard of KMIP and asked whether it is a good idea. Not only do I think it is a great idea to have key management, I think we’re long overdue for a practical implementation in a multi-tenant environment (whitepaper forthcoming).

Cloud providers I’m working with need a solution that allows them to provide self-managed encryption to their customers. EKMI was definitely up to the job. In 2009 single-tenant storage encryption was said by some to be the real game in town, which EKMI saw as a subset of enterprise encryption (end-to-end and file-level encryption was also offered) rather than the entire focus. KMIP is an option and it seems now to be getting some attention but its more closed approach as well as limitations with multi-tenancy may resurrect interest in the original aims of EKMI.