SMM Rootkit: Old, Obscure, and Unnecessary

Be mindful that you don't overreact to the 'new' SMM exploit (properly, reported by Loic Duflot, a very accomplished low level hardware researcher, at the recent cansecwest conference). The exploit itself is really a documented 'feature' of the Intel 5100 Memory Controller chipset, and has been a known issue with SMM for quite some time. See the 5100 data sheet:

In order to make cacheable SMM possible, the chipset must accept EWB’s and must absorb IWB data regardless of the condition of the SMMEM# pin. The Intel® 5100 MCH Chipset will not set the error bit EXSMRAMC.E_SMERR in this case. Because of this, care must be used when attempting to cache SMM space. The chipset/platform cannot protect against processors who attempt to illegally access SMM space that is modified in another processor’s cache. Any software that creates such a condition (for example, by corrupting the page table) will jeopardize the protective properties of SMM.

You might ask why it hasn't received more attention until now? Stated simply, such low level tactics are simply unnecessary for a real rootkit to be effective. Remember that you need to be in ring-0 (kernel) before you can even attempt installing into 'ring -1', and being at ring 0 is plenty of privilege for even the most stealthy of rootkits.

There are other reasons that an SMM rootkit is best left to the science fair: to make one that is effective across more than a select hardware platform, you would need to invest boat loads of development dollars in testing. At worst, someone might build an SMM rootkit that works on a well-known and distributed model of laptop and post that for publicity - but the real criminals don't build stuff like this, nor do they have to.

The majority of malware threats today are, in fact, usermode. The bad guys simply don't need to go any lower to get their work done. Remember, the lower you go, the less re-usable code you can leverage. That is, lower means no libraries, no API's. Lower means you write all the device, memory, and hardware logic yourself. It approaches the complexity of device driver development and operating system design. This all translates into expensive and non-ubiquitous. Malware avoids this development cost by simply installing itself like any other program, re-using the existing API's and libraries under windows that already provide network access, memory management, file access, and the like.

The modus operandi of real malware authors is: Write once, use many times. An SMM rootkit is a really neat science experiment and excites technical curiosity, but such an approach is not useful in practice. Let's stay focused on our Day Job, tackling real threats.

Digital DNA - Numerical Expressions to Describe Malware Behaviors

HBGary unveiled Digital DNA today at the Infosec Conference in Orlando. (I wasn't able to make it down to the show, although I had planned to be there. Last minute stuff and I had to jet back to the West Coast.) The engineering team has been working on Digital DNA for months. In a nutshell, we have automated the reverse engineering of loaded modules in the physical memory snapshot and generate Digital DNA (DDNA) based on the collected data (millions of data points). All of these data points are codified in way that allows them to be matched against rules. The Digital DNA system will "sequence" a software program or document and generate trait-codes based on the behaviors and schematic artifacts found in the software or document. Each trait has a complex rule (think regular expression with boolean logic) associated with it, and if the rule matches the trait is considered "expressed". Expressed traits are concatenated together to make a "sequence". We chose to do it this way because the final DDNA sequence looks and smells like a hash, even though it's not actually a hash at all. But, customers are used to managing hashes, thinking about hashes, and cut-n-pasting hashes - so a hash it would be.

Digital DNA is based on the reverse engineered behaviors, not the specific compilation or packer used with the malware. You can pack the same malware with three different packers and it will still produce the same Digital DNA. Two similar programs will produce similar DDNA. Here is an example of two versions of Rustock.B.



Interestingly, the technology can identify digital objects. Here is an example of tracking Intellectual Property with it.



Digital DNA is a Big Idea. For now, HBGary is going to focus it on detection of zero-day malware threats. We have over 2,000 traits in the DDNA genome currently, and will probably have many more soon. We sort all the traits into Factors, Groups, and Subgroups, defining a "genome" of behaviors that are common to malware. This part plays into a weighting system. I will blog more about this over the coming weeks - dinner is calling.

Your online payments are being sniffed; accept it, live with it

PCI compliance is clearly not enough to protect credit card numbers or account information. It’s about time everyone who uses an account for online payment simply accept the facts: your credit card numbers have been stolen. Check your statements monthly. Why? This isn’t about Heartland or the breach-of-the-week; this is about a constant effort well funded by a criminal underground. The primary tool in the cyber criminal hand, the malware program, keeps getting better. Malware authors are intelligent and focused developers who are well paid for their work. They have developed toolkits so they can generate new malware with little development overhead. They can generate new attack bits in a matter of hours that, to a virus scanner, may as well be a zero day – no signature means no detection, and no protection. Most of this malware decrypts live to memory and never touches the disk. The computing infrastructure is easy prey. It has never been secure, and won’t be secure anytime in the next ten years. Computer security is a constant effort that will never fully work. It’s partial risk reduction, not resolution. The billions of dollars spent since the turn of this century on IDS, firewalls, and virus scanning hasn’t made a more secure Internet. The growth of online technology has far outpaced our ability to secure it. Millions of credit card numbers are being stolen THIS MORNING. They were being stolen yesterday. They are going to continue to be stolen tomorrow.

Melissa Hathaway, on track to make a difference?

Unlike previous cybersecurity czars, Ms. Hathaway has experience. She understands how hard national security can be. Notably, Ms. Hathaway has been working on the Dark Side (think classified) of the government, which means she knows the reality of cyber threats - how effective cyber espionage really is, what is being stolen, and who is stealing it. It also means she knows the definition of a "Funded Threat." And, to combat these funded threats, she understands that it's not just defense, but also offense (think geolocation, trace back to the human, and the money). During his campaign, President Obama stated that he would take cyber attacks as seriously as nuclear or biological. A strong statement like this ultimately translates to budget.

Obama seems to want to dip his toe in the water first. Ms. Hathaway will not have the White House power position, at least not yet - there will be some bureaucracy between her and the president. We will have to see what happens in the next 60 days. But, bureaucracy will be one of Ms. Hathaway's greatest challenges. To her credit, she comes from the right community. She has the relationships in place that can help her succeed.

One of the things I like about Ms. Hathaway is her understanding that cooperation between agencies is required for success. The government is a big place, and the computer networks within it are like little fiefdoms. Coordination is difficult -- not because people lack the will to work together (although that adds difficulty), but because searching through ALL the information is required to find out what's important or critical. Most people want security to be someone else's problem. Those responsible for security want it to be easy. But that is core of the problem. Security is NOT easy. There is no shiny button.

Real security takes work. Ms. Hathaway supports building new technology to address new types of threats that go beyond what yesteryear had. We need to realize that people are out to get us, we are being attacked, and if smart people in the Enterprise say it's an "arms race" you better believe the government knows it is. She needs to be frank with everyone that there is no magic pill. She must require people to step up and do more and not rely on outdated security technology but to supplement with newer technologies.

The 60-day security review may bring back bad news - that things are terrible out there and the Nation's security is worse than it has ever been. We are in tough times, and some tough decisions will likely be made. Ms. Hathaway appears to have the big picture -- finally someone who might actually be able to change security for the better. Hopefully Obama will give her the authority to do so.

Its going to get a lot worse before it gets better

There is an interesting mix of problems going on right now that, when combined, create a sort of "cybercrime" perfect storm. Historically, there is an obvious correlation between economic downturns and the rise in crime. What makes the modern downturn interesting is the ease with which cybercrime can be perpetrated. First, there is the growing and fluid blackmarket for financial data. One doesn't have to browse far to find reports of a rise in phising, drive-by web infections, and advances in bot-net technology. Insiders with access to financial information will find easy money. Large financial institutions are already experiencing a rise of internal investigations. Layoffs in the high technology sector are closely related to intellectual property theft - employees are very likely to download intellectual property that may help them secure a new job - its a simple backup plan that is easy for the human mind to justify. This isn't even that high-tech - it's as simple as USB thumbdrive and an unprotected port. Internationally, high tech workers are losing their jobs, and programmers out of work are willing to take malware development jobs for low pay. IT professionals out of work in Eastern Europe and Asia are already getting roped into the identity theft blackmarket, using toolkits to develop and deploy phising attacks. The endpoint systems within enterprises are frail and easy to attack with malware, they are already infected to a large degree. The virus scanning technology that is the leaning post of enterprise security just doesn't work. The massive investment in security solutions over the last decade hasn't helped at all - enterprises are just as vulnerable and exploited today as they were in the late 90s. I think its an obvious conclusion to be drawn, the malware problem is going to experience a surge over the next 24 to 36 months. Investigators are just now starting to understand that there IS a problem, much less combat it.

64 Bit Analysis - the future is here

64 bit systems are more than 10 years old, but only until recently did they emerge in the market. In the past, 64 bit was found doing the “hard stuff” - complex fluid mechanics, computational modeling, and ultra large databases. Today they are mass market - it’s hard to find a 32 bit machine, and you pretty much have to custom order to get XP. More complex applications are going to demand upgrade - virtual environment collaboration for example - but even more important is just the fact we are dealing with large data - think > 4GB files. If you need an example, think of a DVD movie. Multimedia alone is driving upgrades in the consumer market.

64 bit architecture is just plain faster - it's not so much about the CPU speed - it's more about how much data can be moved. Data movement is more important, IMHO, than Data calculation for most users. With the possible exception of codec's and compression, people just don't USE their CPU's (Video cards with cooling manifolds, GPU's, and "Left 4 Dead" addicts aside :-).

This means “big” things for memory forensics – and also malware analysis in terms of the 64 bit operating system. While I think malware will continue to be coded in 32 bit (for maximum compatibility if nothing else) the stations they infect are migrating to 64 bit windows.

Simply stated, workstations are the point of penetration into the Enterprise. It’s the place we care most about analyzing. To understand malware from our (that is, HBGary’s) point of view, we need to understand the operating system – and by this I mean Windows Vista 64bit, Windows XP 64bit, Windows 2003 64bit, and Windows 2008 64bit. We follow the OS, we find the malware. Pretty much any pre-2008 rootkit technology just raises its hand “here I AM” in an offline memory analysis. From a rootkit developer’s point of view, things are happening live-action, hooking a function pointer makes sense because the HIDS is going to be totally subverted. Offline, everything changes. Said hook is a big red flag waving “over here – find me over here!” But, of course, this means being able to analyze the OS data structures in the first place. Hence, the importance of 64 bit.

HBGary released the 1.3 version of Responder a few days ago. This is the 64 bit platform upgrade. It includes analysis of 64 bit Windows platforms, and the FDPro dumping utility that can dump physical memory images from 64 bit systems (including those that require signed drivers). This was the longest development iteration for our team so far this year. The 64 bit upgrade was a lot harder and more work that I originally expected – there were upgrades and point-fixes in every part of the product from the GUI controls down to the memory-acquisition routines. Over 1,000 points of code had to be fixed just for 64 bit address and offset support. Yeah, big job. And the testing, wow… So here it is. I think HBGary might be the first to market with 64 bit support (that means analysis AND acquisition, and full shipping non-alpha). The new version of FDPro is pretty nice too, supporting compression and probing, speed upgrades, and nearly 100% reliable memory-page queries even for systems with more than 4GB of RAM.

I am glad this release went out the door and hopefully I won’t spend the rest of the year in a troll-cave. I’m going to be in New York City next week and also a few days in D.C. showing off the new bits. If you’re a current customer you should click the upgrade button in the about box :-) Contact sales@hbgary.com for an eval and the website is www.hbgary.com.

p.s. Thanks to everyone who uploaded me 64 bit memory dumps for QA – you’re the best!

Been working on 64-bit

I'm sorry it has been so long since I have posted. Stated bluntly, I've been scrambling with product releases. Although I hope to rise into a management position deserving of my title at HBGary, -- I am in fact a developer. I code every day, new feature or bug fixes. We made the decision a while back to adopt agile development - a buzz word I know, but one actual hard side effect is the short development iteration. We try to patch our Responder product about once every two weeks. We develop on very short cycles. Even a few bug fixes are good enough to warrant a patch. Even more interesting, we adopted a commerical patching solution used by MMO's (massive multiplayer online games) - we figured the patch-every-2-weeks system was very close to the game industry requirement. I think that model is pretty advanced for a software company. Our upcoming releases are very exciting, least of which is the 64-bit upgrade to our platform. That means analysis of 64 bit windows, running on 64 bit windows, and also imaging 64 bit systems. The acquisition of 64-bit data is much harder than it sounds, it turns out. Not only do we have to analyze physical memory snapshots from vista and 2003 64 bit images, we also have to be able to acquire them. To do this requires a device driver. And, since we are adding pagefile support, we also have to build a parser for raw NTFS filesystems - THAT is a major effort and is non-trivial. Our next patch will add pagefile support for 32 bit systems, and the follow on will add 64 bit. There is a huge amount of engineering going on internally right now. I haven't had time to write about world events.