Invisible Things Lab, Bitlocker/TPM bypassing and some conference thoughts
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...