Razor-Thin Hypervisors

I just came back from Stockholm where I attended the Virtualization Forum, and saw several, quite interesting vendor presentations. One that caught my attention was a talk by VMware, and especially the part that talked about the new ESX 3i hypervisor and presented it as "razor-thin". This "razor-thin" hypervisor will have, according to VMWare, the footprint "of only 32MB".

My regular readers might sense that I’m a bit ironic here. Well, 32MB of code is definitely not a "razor-thin" hypervisor in my opinion and it’s not even close to a thin hypervisor... But why am I so picky about it? Is it really that important?

Yes, I think so, because the bigger the hypervisor the more chances that there is a bug somewhere out there. And one of the reasons for using virtual machines is to provide isolation. Even if we use virtualization because of business reasons (server consolidation), still we want each VM to be properly isolated, to make sure that if an attackers "gets into" one VM, she will not be able to 0wn all the other VMs on the same hardware… In other words, isolation of VMs, is an extremely important feature.

During my presentation I also talked about thin hypervisors. I first referenced a few bugs that were found in various VMMs in the recent months by other researchers (congrats to Rafal Wojtczuk of McAfee for some interestingly looking bugs in VMWare and Microsoft products). I used them as an argument that we should move towards very thin hypervisor architecture, exploiting hardware virtualization extension as much as possible (e.g. Nested Paging/EPT, IOMMU/DEV/NoDMA, etc) and avoiding doing things "in software".

Nobody should be really surprised seeing VMMs bugs – after all we have seen so many bugs in OS kernels over years, so no surprise we will see more and more bugs in VMMs, unless we switch to very thin hypervisors, so thin that it would be possible to understand and verify their code by one person. Only then we would be able to talk about security advantage (in terms of isolation) offered by VMMs comparing to traditional OSes.

I couldn’t refrain myself from mentioning that the existence of those bugs in popular VMMs clearly shows that having a VMM already installed doesn’t currently prevent from the "Blue Pill threat" – a point often expressed by some virtualization vendors, who notoriously try to diminish the importance of this problem (i.e. the problem of virtualization based malware).

I also announced that Invisible Things Lab has just started working with Phoenix Technologies. Phoenix is the world leader in system firmware, particularly known for providing BIOSes for PCs for almost 25 years, and currently is working on a new product called HyperCore that would be a very thin and lightweight hypervisor for consumer systems. ITL will be helping Phoenix to ensure the security of this product.

HyperCore hypervisor will use all the latest hardware virtualization extensions, like e.g. Nested Paging/EPT to minimize the unnecessary complexity and to provide negligible performance impact. For the same reasons, the I/O access will go through almost natively, just like in case of our Blue Pill...

Speaking about Blue Pill – Phoenix is also interested in further research on Blue Pill, which will be used as a test bed for trying various ideas – e.g. nested virtualization, which might be adopted in the future versions of HyperCore to allow users to use other commercial VMMs inside their already-virtualized OSes. Blue Pill’s small size and minimal functionality makes it a convenient tool for experimenting. Phoenix will also support The Blue Pill Project which means that some parts of our research will be available for other researchers (including code)!

In case you still feel like having a look into my slides, you can get them here.

Thoughts On Browser Rootkits

Petko D. Petkov from GNUCITIZEN wrote a post about Browser Rootkits, which inspired me to give some more thoughts on this subject. Petko is an active researcher in the field of client-side exploits (e.g. recent Adobe Acrobat PDF flaw), so it’s not a surprise that he’s thinking about browsers as a natural environment for rootkits or malware. Also it’s quite common to hear an opinion these days that browsers become so complicated and so universal that they are almost like operating systems rather than just standard applications.

Petko in his post gives several ideas of how browser-based malware could be created and I’m sure that we will see more and more such malware in the near future (I would actually be surprised if it didn’t exist already). His main argument for creating “Browser Rootkits” is that they would be “closer to the data”, which is, of course, undisputable.

The other argument is the complexity of a typical browser like e.g. Firefox or Internet Explorer. It seems like we have a very similar situation here to what we have with "classic" operating systems like e.g. Windows. Windows is so complex that nobody (including Microsoft) can really spot all the sensitive places in the kernel where a rootkit might "hook" – thus it’s not possible to effectively monitor all those places. We have a similar problem with Firefox and IE because of their extensible architecture (think about all those plugins, add-ons, etc) – although we could examine the whole memory of firefox.exe process, we still would not be able to decide whether something bad is there or not.

I’m even quite sure that my little malware taxonomy could be used here to classify Firefox or IE infections. E.g. the browser malware of type 0, would be nothing else then just additional plugins, installed using official API and not trying to hide from browser reporting mechanisms (in other words they still will be visible to users when they will ask the browser to list all the installed plugins). And we will have type I and type II infections, the former would be simply modifying some code (be that a code of a browser or maybe of some other plugin) while the latter would be hooking some function pointers or changing some data only – this all to hide the offensive module.

BTW, there is a little problem with classifying JIT-generated code – should it be type I or type II infection? I don’t know the answer for now and I welcome all the feedback on this. And we can even imagine type III infections of browsers, but I will leave it as an exercise for my readers :)

So, should we expect the classic, OS-based rootkits to die and the efforts in the malware community to move towards creating Browser-based rootkits? I don’t think so. While the browser-based malware is and will definitely be more and more important problem, it has one disadvantage comparing to classic OS-based malware. Namely it’s quite easy to avoid, or at least minimize the impact from browser-based rootkits. It’s just enough to use two different browsers – one for sensitive and the other one for non-sensitive operations.

So, for example, I use IE to do all my sensitive browsing (e.g. online banking, blogger access, etc), while Firefox to do all the casual browsing, which includes morning press reading, google searching, etc. The reason I use Firefox for non-sensitive browsing doesn’t come from the fact that I think it’s more secure (or better written) then IE, but because I like using NoScript and there is no similar plugin for IE...

Of course, an attacker still might exploit my non-sensitive browser (Firefox) and then modify configuration or executable files that are being used by my sensitive browser (IE). However this would require write-access to those files. This is yet another reason why one should run the non-sensitive browser with limited privileges and technologies like UAC in Vista help to achieve it. I wrote an article some time ago about how one can configure Vista to implement almost-full privilege separation.

Of course, even if we decide to use 2 different browsers - one for sensitive and the other one for non-sensitive browsing, an attacker still might be able to break out from account protection via a kernel mode exploit (e.g. exploiting one of the bug that Alex and I presented in Vegas this year). However this would not be a browser malware anymore – this would be a good old kernel-mode malware :)

A solution to this problem will probably be the use of a Virtual Machine to run the non-sensitive browser. Even today one might download e.g. the Browser Appliance from VMWare and we will see more and more solutions like this in the coming years I think. This BTW, will probably stimulate more research into VM escaping and virtualization-based malware.

Of course, the very important and sometimes non-trivial question is how to decide which type of browsing is sensitive and which is non-sensitive. E.g. most people will agree the online banking is a sensitive browsing, but what about webmail? Should I use my sensitive or non-sensitive browser for accessing my mail via web? Using a sensitive browser for webmail is dangerous, as it’s quite possible that it could be infected via some malicious mail that would be in our inbox. While using the non-sensitive browser for webmail is also not a good solution, as most people would like to consider mail as sensitive and would not like to allow the possibly-compromised browser to learn the password for the mailbox.

I avoid this problem by not using a browser for webmail and by having a special account just for running a thunderbird application (see again my article on how to do this in Vista). It works well for me.

Of course, one could also do the same for browser – i.e. instead of having 2 browsers (i.e. sensitive and non-sensitive), one could have 3 or more (maybe even 3 different virtual machines). But the question is how many accounts should we use? One for email, one for sensitive browsing, one for non-sensitive, one for accessing personal data (e.g. pictures)...? I guess there is no good answer for this and it depends on the specific situation (i.e. different configuration for home user that uses computer mostly for "fun" and different for somebody using the same computer for both work and "fun", etc...)

On a side note – I really don’t like the idea of using a web browser to do "everything" – I like using browser to do browsing, while to do other things to use specialized applications. I like having my data on my local hard drive. It’s quite amazing that so many people these days use Google not only for searching, but also for email, calendaring and documents editing – it’s like giving all your life secretes on a plate! Google can now correlate all your web search queries with a specific email account and even see who are you meeting with next evening and also know what a new product your company will be presenting next week, as you prepared you presentation using Google Documents. I’m not sure whether it’s Google or the people’s naivety that disturbs me more...

Tricky Tricks

I want to make a short philosophical comment about how some approaches to building security are wrong.

Let’s move back in time to the last decade of the XX century, to the 90’s... Back in those days one of the most annoying problems in computer security was viruses, or, more precisely, executable file infectors. Many smart guys were working on both sides to create more stealthy infectors and also better detectors for those infectors…

Russian virus write Z0mbie with his Mistfall engine and Zmist virus went probably closest to the Holy Grail in this arm race – the creation of an undetectable virus. Peter Szor, a Symantec’s chief antivirus researcher, wrote about his work in 2001:

Many of us will not have seen a virus approaching this complexity for a few years. We could easily call Zmist one of the most complex binary viruses ever written.

But nothing is really undetectable if you have a sample of the malware in your lab and can spent XXX hours analyzing it – you will always come up with some tricks to detect it sooner or later. The question is – were any of the A/V scanners back then ready to detect such an infection if it was a 0day in the wild? Will any of the today’s scanners detect a modified/improved Zmist virus, or would they have to count on the virus author being nice enough to send them a sample for an analysis first?

Interestingly, file infectors stopped being a serious problem a few years ago. But this didn’t happen because the A/V industry discovered a miracle cure for viruses, but rather because the users’ habits changed. People do not exchange executables that often as 10 years ago. Today people rather download an executable from the Web (legal or not) rather then copy it from a friend’s computer.

But could the industry have solved the problem of file infectors in an elegant, definite way? The answer is yes and we all know the solution – digital signatures for executable files. Right now, most of the executables (but unfortunately still not all) on the laptop I’m writing this text on are digitally signed. This includes programs from Microsoft, Adobe, Mozilla and even some open source ones like e.g. True Crypt.

With digital signatures we can "detect" any kind of executable modifications, starting form the simplest and ending with those most complex, metamorphic EPO infectors as presented e.g. by Z0mbie. All we need to do (or more precisely the OS needs to do) is to verify the signature of an executable before executing it.

I hear all the counter arguments: that many programs out there are still not digitally signed, that users are too stupid to decide which certificates to trust, that sometimes the bad guys might be able to obtain a legitimate certificate, etc...

But all those minor problems can be solved and probably will eventually be solved in the coming years. Moreover, solving all those problems will probably cost much less then all the research on file infectors cost over the last 20 year. But that also means no money for the A/V vendors.

Does it mean we get a secure OS this way? Of course not! Digital signatures do not protect against malicious code execution, e.g. they can't stop an exploit from executing its shellcode. So why bother? Because certificates allow to verify that what we have is really what we should have (e.g. that nobody infected any of our executable files). It’s the first step in ensuring integrity of an OS.

The case of digital signatures vs. file infectors is a good example of how problems in security should be addressed. But we all know that the A/V industry took a different approach – they invested zillions of dollars into research on polymorphic virus detection, built advanced emulators for analysis of infected files, etc. The outcome – lots of complex heuristics that usually work quite well against known patterns of infection, but are often useless against new 0day engines and also are so complex that nobody really knows how many false positives they can produce and how buggy the code itself is. Tricks! Very complex and maybe even interesting (from a scientific point of view) tricks.

So, do I want to say that all those years of A/V research on detecting file infections was a waste time? I’m afraid that is exactly what I want to say here. This is an example of how the security industry took a wrong path, the path that never could lead to an effective and elegant solution. This is an example of how people decided to employ tricks, instead looking for generic, simple and robust solutions.

Security should not be built on tricks and hacks! Security should be built on simple and robust solutions. Oh, and we should always assume that the users are not stupid – building solutions to protect uneducated users will always fail.

Virtualization Detection vs. Blue Pill Detection

So, it’s all over the press now, but, as usual, many people didn’t quite get the main points of our Black Hat talk. So, let’s clear things up... First, please note that the talk was divided into two separate, independent, parts – the first one about bypassing vista kernel protection and the second one about virtualization based malware.

The message of the first part was that we don’t believe it’s possible to implement effective kernel protection on any general purpose OS based on monolithic kernel design.

The second part, the one about virtualization, had several messages...

1. The main point was that detecting virtualization is not the same as detecting virtualization based malware. As hardware virtualization technology gets more and more widespread, many machines will be running with virtualization mode enabled, no matter whether blue pilled or not. In that case blue pill-like malware doesn’t need to cheat that virtualization is not enabled, as it’s actually expected that virtualization is being used for some legitimate purposes. In that case using a "blue pill detector", that in fact is just a generic virtualization detector is completely pointless.
   
   Obviously in such scenarios blue pill-like malware must support nested hypervisors. And this is what we have implemented in our New Blue Pill. We can run tens of blue pills inside each other and they all work! You can try it by yourself, but you should disable comport debug output to do more then twenty nested pills. We still fail at running Virtual PC 2007 as a nested hypervisor (when it’s guest switches to protected mode), but we hope to have this fixed in the coming weeks (please note that VPC’s hypervisor doesn’t block blue pill from loading – see our slides for more info).
   
   In other words, if somebody announces to the world that they can fight virtualization based malware using generic virtualization detectors, it’s like if they said that they can detect e.g. a botnet agent, just by detecting that an executable is using networking!


2. We have also decided to discuss how blue pill could potentially cheat those generic virtualization detectors, even though we don’t believe it would be necessary in the coming years, as everything will be virtualized anyways (see previous point). But, we still decided to look into some of the SVM detection methods. First, we found out that many methods that people described as a way to detect virtualization do not work in the simple form as they were described. We took a closer look e.g. at the TLB profiling methods that were suggested by several researchers as a reliable method for virtualization detection. However all the papers that were describing this method missed the fact that some of the caches are not fully associative and one needs to use special effort (which means additional complexity) to make sure to e.g. fill the whole TLB L2 buffer. Obviously we provided all the necessary details of how to write those detectors properly (we even posted one such detector).
   
   In other words - we believe that it will always be possible to detect virtualization mode using various tricks and hacks, but: 1) those hacks could be forced to be very complex and 2) in case virtualization is being used on the target computer for some legitimate purposes all those methods fail anyway (see point 1).


3. Some people might argue that maybe then we should build these virtualization detectors into all the legitimate hypervisors (e.g. Virtual PC hypervisor), so that they know at least whether they are being run on a native machine or maybe inside blue pill. However this approach contradicts the rules we use to build secure and effective hypervisors. These rules say that hypervisors should be as small as possible and there should be no 3rd party code allowed there.
   
   Now imagine that A/V company try to insert their virtualization detectors (which BTW would have to be updated from time to time to support e.g. new processor models) into hypervisors – if that ever happened, it would be a failure of our industry. We need other methods to address this threat, methods that would be based on documented, robust and simple methods. Security should not be built on bugs, hacks and tricks!

We posted the full source code of out New Blue Pill here. We believe that it will help other researchers to to analyze this threat and hopefully we will find a good solution soon, before this ever become widespread.

Happy bluepilling!

On a side note: now I can also explain (if this is not clear already) how we were planning to beat our challengers. We would simply ask them to install Virtual Server 2005 R2 on all the test machines and we would install our New Blue Pill on just a few of them. Then their wonderful detectors would simply detect that all the machines have SVM mode enabled, but that would be a completely useless information. Yes, we still believe we would need a couple of months to get our proof-of-concept to the level we would be confident that we will win anyway (e.g. if they used memory scanning for some “signature).

BTW, you might be wondering why I introduced the “no CPU peek for more then 1s” requirement? I will leave finding an answer as an exercise from a psychology to my dear readers ;)

We're ready for the Ptacek's challenge!

Thomas Ptacek and company just came up with this funny challenge to test our Blue Pill rootkit. And, needles to say, the Invisible Things Lab team is ready to take their challenge, however with some additional requirements, that would assure the fairness of the contest.

First, we believe that 2 machines are definitely not enough, because the chance of correct guess, using a completely random (read: unreliable) detection method is 50%. Thus we think that the reasonable number is 5 machines. Each of them could be in a state 0 or 1 (i.e. infected or not). On each of this machines we install two files: bluepill.exe and bluepill.sys

The .sys file is digitally signed, so it loads without any problem (we could use one of our methods for loading unsigned code on vista that we're planning to demonstrate at BH, but this is not part of the challenge, so we will use the official way).

The bluepill.exe takes one argument which is 0 or 1. If it's 1 it loads the driver and infects the machines. If it's 0 it also loads the driver, but the driver does not infect the machine.

So, on each of the 5 machines we run bluepill.exe with randomly chosen argument, being 0 or 1. We make sure that at least one machine is not infected and that at least one machine is infected.

After that the detection team runs their detector.exe executable on each machine. This program can not take any arguments and must return only one value: 0 or 1. It must act autonomously -- no human assistance when interpreting the results.

The goal of the detection team is to correctly mark each machine as either being infected (1) or not (0). The chance of a blind guess is:

1/(2^5-2) = 3%

The detector can not cause system crash or halt the machine -- if it does they lose. The detector can not consume significant amount of CPU time (say > 90%) for more then, say 1 sec. If it does, then it's considered disturbing for the user and thus unpractical.

The source code of our rootkit as well as the detector should be provided to the judges at the beginning of the contests. The judges will compile the rootkit and the detector and will copy the resulting binaries to all test machines.

After the completion of the contest, regardless of who wins, the sources for both the rootkit and the detector will be published in the Internet -- for educational purpose to allow others to research this subject.

Our current Blue Pill has been in the development for only about 2 months (please note that we do not have rights to use the previous version developed for COSEINC) and it is more of a prototype, with primary use for our training in Vegas, rather then a "commercial grade rootkit". Obviously we will be discussing all the limitations of this prototype during our training. We believe that we would need about 6 months full-time work by 2 people to turn it into such a commercial grade creature that would win the contest described above. We're ready to do this, but we expect that somebody compensate us for the time spent on this work. We would expect an industry standard fee for this work, which we estimate to be $200 USD per hour per person.

If Thomas Ptacek and his colleges are so certain that they found a panacea for virtualization based malware, then I'm sure that they will be able to find sponsors willing to financially support this challenge.

As a side note, the description for our new talk for Black Hat Vegas has just been published yesterday.

Invisible Things Lab, Bitlocker/TPM bypassing and some conference thoughts

Invisible Things Lab’s website is now online! However, we still don’t have a cute logo because the company where I order the logo presented me with something completely unacceptable and disappointing after taking a week to prepare it :( Alex is really pissed of by this and I hope we will find something nice really soon...

Anyway, as you can see on the website, we don’t have any product and we focus on consulting and research-on-demand only. We mainly target three groups of customers:

First there are security vendors and OS vendors, to whom we offer our product assessment and advisory services. E.g. we can take a look at the design and implementation of a rootkit detector, host IPS or some custom hardened OS and point out all the weaknesses we see and also give advices what we think should be improved. We can advise about both the design and implementation side, sometimes without requiring all the product internal information being shared with us.

The other group is corporate customers interested in unbiased evaluation of security technology they're planning to deploy. Here we can look at the products they consider to deploy and point out pros and cons of each of them and suggest the best choice. So e.g. we can look at various “information leak protectors” and tell how sophisticated techniques are required to bypass each of them (because, of course, all such products are bypassable). We can also advise about various technical aspects of implementing corporate security policies.

Finally there are law enforcement customers and forensic investigators, whom we can help to stay up-to-date with current offensive technology as used e.g. by modern malware, by running various trainings and seminars. We can also share our experience with advanced stealth malware and covert channels to help investigate more sophisticated incidents.

Ok, so what we don’t do? Well, we do not do classic code auditing, understood as looking for implementation bugs like e.g. buffer overflows or race conditions. We still do implementation analysis, when e.g. assessing a product, but we look only at feature-specific parts of implementation – e.g. how the kernel protection or hooking has been implemented in a given host IDS.

We also don’t do web application security nor database security. There are people who have much more experience in this area then we have, so go to them!

Finally, we do not do penetration testing, simply because I don’t believe this is the best way of improving system security. I can run 101 exploits against your server and even though all of them fail, still it tells nothing about how secure is your system. Maybe there is some little detail I missed which caused all my exploits to fail just because I was tired that day? I would definately prefer to talk to the security team and also to the server admin and ask them what they have done to secure the server in the first place. If I though that their approach has some weakness then I would simply advise them what I think they should improve. Later I would kindly ask them to give me the root/admin access so that I could verify by myself whether the advices have been implemented... This approach has an advantage of being much more complete and usually taking much less time over the standard pen-testing. It has one disadvantage though – it’s not a good material for a Hollywood movie ;)

So, all in all, we focus on OS security in contrast to application security and network security (although we can be helpful with detecting covert channels in a corporate enviroment).

Speaking of OS security (and leaving the subject of my new company for a second) – I recently had a pleasure of giving a keynote speech at the NLUUG conference in the Netherlands, which this year was focused on virtualization technology. The conference was really nice (even though 2/3 of the talks were in Dutch) and there were couple of talks I liked in particular. First, there was a talk about Microhypervisor Verification by Hendrik Tews. Author presented the overview of the Nizza architecture (which was interesting, but in my opinion way too complicated and impractical for using it anywhere outside the lab). He also talked about challenges with formal verification of kernel and microkernel, which was very interesting. I talked to him later about feasibility of verifying the monolithic kernels, like those in Linux or Windows and, not surprisingly, he said it's not really possible these days and in the coming years, because of the cost (I need to mention that he does the verification "manually").

There was also a nice presentation about Kernel Virtual Machine Monitor (KVM) for Linux by one of its developer Avi Kivity. I think in the future it might be a strong competition to Xen, especially after they add support for IOMMU technology (which I think is expected to be introduced on AMD and Intel processors somewhere in 2008). I really like the design of KVM which takes advantage of many features already present in Linux kernel without implementing them from scratch.

Finally there was a presentation by another polish female researcher, Asia (Joanna) Slowinska. She talked about Prospector, a system built on top of a CPU emulator (based on Qemu) to automatically generate generic signatures for buffer overflow attacks (both heap and stack based). On a side note, Asia (which by the way is pronounced “Ashyia” and not like the continent!) is the short form of the name Joanna, so basically almost everybody in Poland calls me Asia as well ;)

There was also a talk by Anil Madhavapeddy of XenSource, but in my opinion it was a little bit too much of a “marketing” presentation rather then a technical one (even though Anil turned out as a very technical and knowledgeable guy).

I also had some meetings at the Vrije Universiteit in Amsterdam the following day, where I met with MINIX3 developers and prof. Andrew Tanenbaum (what a fool I was that I didn’t bring one of his famous books to get an autograph:/). I must say really like the design of MINIX3, which keeps all the drivers (and other system components) in usermode, in separated address spaces. This is, however, still problematic today, as without IOMMU we can’t really fully protect kernel from usermode drivers, because of the potential DMA attacks – i.e. a driver can setup a DMA write-transaction to overwrite some part of the micro kernel memory, thus owning the system completely. But I guess we will all have processors supporting IOMMU within the next 1-2 years.

Just two days ago I delivered another keynote presentation, this time at the InfoSecurity conference in Honk Kong, organized by Computer World. My speech was about “Human Factor vs. technology” and basically the message I tried to pass was that the technology is just as flawed as the so called “human factor”, understood here as an user’s unawareness and administrator’s incompetence. I guess this is something perfectly obvious for most of technical security people, who at least once wrote an exploit by themselves. But apparently not for the security management stuff... So, even though it was by far the least technical speech I have every gave in my life, it was received as way too technical for many attendees (who were like “OMG, that was a shock!”). And I didn’t even mention any specific research I’ve done – just some standard stuff about exploits etc...

I also took part in a discussion panel with several C-level executives, some of them being CIOs for some huge institutions, others being C-level marketing guys from several security vendors.

So, I must say I was really struck by the complete lack of understanding of even the basic technical concepts behind IT security shown by some of the management people who were there. I understand, of course, that typical CIO or CSO doesn’t need to know much about technical details about how exploits and malware work, but their naivety was really shocking!

Speaking of conferences, I own apologizes to the organizers of Confidence 2007 conference in Krakow, Poland. After spending several days in the Netherlands, experiencing their rainy weather and also because of the shortage of sleep in the recent weeks due to some traveling (especially lack of my afternoon naps), I got sick and couldn’t make it to the conference. I heard it was very good this year, featuring many international speakers and, of course, Krakow, which is one of the nicest cities in Poland.

Finally, I would like to explain a little confusion around our Black Hat training. Shortly after we announced the training, there appeared some press articles which incorrectly described the kernel attacks that we’re going to present in Vegas. In the original blog post I said that these attacks “work on the fly and do not require system reboot and are not afraid of the TPM/Bitlocker protection”, but some people understood that we were going to actually present ways to defeat Bitlocker Drive Encryption (BDE). This is quite a misunderstanding, because those attacks, which allow for inserting unsigned code into Vista x64 kernel, are “not afraid of TPM/Bitlocker” simply because they can be executed on the fly and thus do not require system reboot, while Bitlocker’s task is to secure the boot process, but not to prevent the kernel against compromises!

However I intentionally mentioned TPM and Bitlocker, just to stress that those technologies have simply nothing to do with stopping rootkits and kernel compromises, provided you’re using kernel attacks which do not require system reboot, even though they’re often advertised as if they had… So, basically, even if we could break the BDE, it still wouldn’t give us any benefit these days. The situation will change within 2-3 years or so, i.e. when Microsoft will eventually come up with their own hypervisor, but that’s a different story...

Understanding Stealth Malware

Ever wondered whether Blue Pill really works or was just a PR stunt? Ever wanted to see how practical are various timing attacks against it? (And can even those “unpractical” be cheated?) Or how many Blue Pills inside each other can you run and still be able to play your favorite 3D game smoothly? Or how deep Alex can hook into Windows NDIS to bypass your personal firewall? Do you want to see Patch Guard from a “bird’s eye view” perspective? Or do you simply want to find out how well the latest Vista x64 kernel is protected? Ever wondered how rootkits like Deepdoor and Firewalk really worked? You can’t sleep, because you’re thinking constantly about how Blue Pill-like malware can be prevented? Does Northbridge hacking sound sexy to you? :)

At the very end of July, during the Black Hat Briefings in Las Vegas, Alex Tereshkin and I will be running a training “Understanding Stealth Malware”, where you should be able to find answers to the above questions plus many more.

The training will feature many previously unpublished techniques, implementation details, and of course lots of brand new code, developed especially for the training. The code will include sample rootkits similar to Deepdoor, Firewalk, Blue Pill and Delusion (but redesigned and rewritten from scratch) as well as some more exotic things, like e.g. anti-hardware-forensic attacks.

As the training will be focused on Windows platform and Vista x64 specifically, we will also present some new kernel attacks against latest Vista x64 builds. These attacks, of course, work on the fly and do not require system reboot and are not afraid of the TPM/Bitlocker protection. (Although they could also be used to bypass Vista DRM protection, this subject will not be discussed during the training).

Attendees will mostly work with kernel debuggers in order to analyze and understand various techniques used in system compromises. The main goal of the training is to help students understand contemporary malware techniques, enable them to see the “bigger picture” over technical details and show possible approaches to compromise detection.

Thus the course is primarily targeted for developers of security products, forensic investigators, pen-testers and OS developers. It’s recommended that attendees have a basic knowledge of OS design and implementation (specifically Windows), C programming, at least basic experience with debugging and ability to understand fragments of assembler code (IA32 architecture).

For ethical reasons we want to limit the availability of this course to only "legitimate" companies, thus we require that you specify your official business email address and company's website when registering for the course.

Pre-configured workstations will be provided, so there is no need to prepare for the course in any specific way. You can find more information and register for the training on the blackhat website. Please note that there will be only 2 public classes of this training this year – both during the Black Hat Briefings (28/29 and 30/31 of July). More classes will be available only in the form of on-site trainings for corporate customers.

Please also note that the number of seats is hard-limited by the number of available workstations, so we encourage registering early.

As for the other news – I have just quit COSEINC last week and I’m in the process of establishing a new security consulting and research company. For now I can only betray the name: Invisible Things Lab - expect more details to be posted here in the coming weeks :)