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 :)

The Human Factor

When you go to some security conferences, especially those targeted for management staff, you might get the impression that the only problem in the security field that mankind is facing today is… that we’re too stupid and we do not know how to use the technology properly. So, we, use those silly simple passwords, allow strangers to look at our laptop screens over our shoulders, happily provide our e-bank credentials or credit card numbers to whoever asks for them, etc… Sure, that’s true indeed – many people (both administrators and users) do silly mistakes and this is very bad and, of course, they should be trained not to do them.

However, we also face another problem these days… A problem of no less importance then “the human factor”. Namely, even if we were perfectly trained to use the technology and understood it very well, we would still be defenseless in many areas. Just because the technology is flawed!

Think about all those exploitable bugs in WiFi drivers in your laptop or email clients vulnerabilities (e.g. in your GPG/PGP software). The point is, you, as a user can not do anything to prevent exploitation of such bugs. And, of course, the worst thing is, that you don’t even have any reliable way to tell whether somebody actually successfully attacked you or not – see my previous post. None of the so called “industry best practices” can help – you just need to hope that your system hasn’t been 0wned. And this is really disturbing…

Of course, you can chose to believe in all this risk assessment pseudo-science, which can tell you that your system is “non-compromised with 98% probability” or you can try to comfort yourself because you know that your competition has no better security they you… ;)

The Game Is Over!

People often say that once an attacker gets access to the kernel the game is over! That’s true indeed these days, and most of the research I have done over the past two years or so, was about proofing just that. Some people, however, go a bit further and say, that thus there is no point in researching ways to detect system compromises and, once an attacker got in, you should simply assume everything has been compromised and replace all the components, i.e. buy new machine (as the attacker might have modified the BIOS or re-flashed PCI EEPROMs), reinstall OS, all applications, etc.



However, they miss one little detail – how can they actually know that the attacker got access to the system and that the game is over indeed and we need to reinstall just now?

Well, we simply assume that the attacker had to make some mistake and that we, sooner or later, will find out. But what if she didn’t make a mistake?

There are several trends of how this problem should be addressed in a more general and elegant way though. Most of them are based on a proactive approach. Let’s have a quick look at them…

1. One generic solution is to build in a prevention technology into the OS. That includes all the anti-exploitation mechanisms, like e.g. ASLR, Non Executable memory, Stack Guard/GS, and others, as well as some little design changes into OS, like e.g. implementation of least-privilege principle (think e.g. UAC in Vista) and some sort of kernel protection (e.g. securelevel in BSD, grsecurity on Linux, signed drivers in Vista, etc).
   
   This has been undoubtedly the most popular approach for the last couple of years and recently it gets even more popular, as Microsoft implemented most of those techniques in Vista.
   
   However, everybody who follows the security research for at least several years should know that all those clever mechanisms have all been bypassed at least once in their history. That includes attacks against Stack Guard protection presented back in 2000 by Bulba and Kil3r, several ways to bypass PaX ASLR, like those described by Nergal in 2001 and by others several months later as well as exploiting the privilege elevation bug in PaX discovered by its author in 2005. Also the Microsoft's Hardware DEP (AKA NX) has been demonstrated to be bypassable by skape and Skywing in 2005.
   
   Similarly, kernel protection mechanisms have also been bypassed over the past years, starting e.g. with this nice attack against grsecurity /dev/(k)mem protection presented by Guillaume Pelat in 2002. In 2006 Loic Duflot demonstrated that BSD's famous securelevel mechanism can also be bypassed. And, also last year, I showed that Vista x64 kernel protection is not foolproof either.
   
   The point is – all those hardening techniques are designed to make exploitation harder or to limit the damage after a successful exploitation, but not to be 100% foolproof. On the other hand, it must be said, that they probably represent the best prevention solutions available for us these days.


2. Another approach is to dramatically redesign the whole OS in such a way that all components (like e.g. drivers and serves) are compartmentalized, e.g. run as separate processes in usermode, and consequently are isolated not only from each other but also from the OS kernel (micro kernel). The idea here is that the most critical components, i.e. the micro kernel, is very small and can be easily verified. Example of such OS is Minix3 which is still under development though.
   
   Undoubtedly this is a very good approach to minimize impact from system or driver faults, but does not protect us against malicious system compromises. After all if an attacker exploits a bug in a web browser, she may only be interested in modifying the browser’s code. Sure, she probably would not be able to get access to the micro kernel, but why would she really need it?
   
   Imagine, for example, the following common scenario: many online banking systems require users to use smart cards to sign all transaction requests (e.g. money transfers). This usually works by having a browser (more specifically an ActiveX control or Firefox’s plugin) to display a message to a user that he or she is about to make e.g. a wire transfer to a given account number for a given amount of money. If the user confirms that action, they should press an ‘Accept’ button, which instructs browser to send the message to the smart card for signing. The message itself is usually just some kind of formatted text message specifying the source and destination account numbers, amount of money, date and time stamp etc. Then the user is asked to insert the smart card, which contains his or her private key (issued by the bank) and to also enter the PIN code. The latter can be done either by using the same browser applet or, in slightly more secure implementations, by the smart card reader itself, if it has a pad for entering PINs.
   
   Obviously the point here is that malware should not be able to forge the digital signature and only the legitimate user has access to the smart card and also knows the card’s PIN, so nobody else will be able to sign that message with the user’s key.
   
   However, it’s just enough for the attacker to replace the message while it’s being send to the card, while displaying the original message in the browser’s window. This all can be done by just modifying (“hooking”) the browser’s in-memory code and/or data. No need for kernel malware, yet the system (the browser more specifically) is compromised!
   
   Still, one good thing about such a system design is that if we don’t allow an attacker to compromise the microkernel, then, at least in theory, we can write a detector capable of finding that some (malicious) changes to the browsers memory have been introduced indeed. However, in practice, we would have to know how exactly the browser’s memory should look like, e.g. which function pointers in Firefox’s code should be verified in order to find out whether such a compromise has indeed occurred. Unfortunately we can not do that today.


3. Alternative approach to the above two, which does not require any dramatic changes into OS, is to make use of so called sound static code analyzers to verify all sensitive code in OS and applications. The soundness property assures that the analyzer has been mathematically proven not to miss even a single potential run time error, which includes e.g. unintentional execution flow modifications. The catch here is that soundness doesn’t mean that the analyzer doesn’t generate false positives. It’s actually mathematically proven that we can’t have such an ideal tool (i.e. with zero false positive rate), as the problem of analyzing all possible program execution paths is incomputable. Thus, the practical analyzers always consider some superset of all possible execution flows, which is easy to compute, yet may introduce some false alarms and the whole trick is how to choose that superset so that the number of false positives is minimal.
   
   ASTREE is an example of a sound static code analyzer for the C language (although it doesn’t support programs which make use of dynamic memory allocation) and it apparently has been used to verify the primary flight control software for Airbus A340 and A380. Unfortunately, there doesn’t seem to be any publicly available sound binary code static analyzers… (if anybody knows any links, you’re more then welcome to paste the links under this post – just please make sure you’re referring to sound analyzers).
   
   If we had such sound and precise (i.e. with minimal rate of false alarms) binary static code analyzer that could be a big breakthrough in the OS and application security.
   
   We could imagine, for example, a special authority for signing device drivers for various OSes and that they would first perform such a formal static validation on submitted drivers and, once passed the test, the drivers would be digitally signed. Plus, the OS kernel itself would be validated itself by the vendor and would accept only those drivers which were signed by the driver verification authority. The authority could be an OS vendor itself or a separate 3rd party organization. Additionally we could also require that the code of all security critical applications, like e.g. web browser be also signed by such an authority and set a special policy in our OS to allow e.g. only signed applications to access network.
   
   The only one week point here is, that if the private key used by the certification authority gets compromised, then the game is over and nobody really knows that… For this reason it would be good, to have more then one certification authority and require that each driver/application be signed by at least two independent authorities.

From the above three approaches only the last one can guarantee that our system will not get compromised ever. The only problem here is that… there are no tools today for static binary code analysis that would be proved to be sound and also precise enough to be used in practice…

So, today, as far as proactive solutions are considered, we’re left only with solutions #1 and #2, which, as discussed above, can not protect OS and applications from compromises in 100%. And, to make it worse, do not offer any clue, whether the compromise actually occurred.

That’s why I’m trying so much to promote the idea of Verifiable Operating Systems, which should allow to at least find out (in a systematic way) whether the system in question has been compromised or not (but, unfortunately not to find whether the single-shot incident occurred). The point is that the number of required design changes should be fairly small. There are some problems with it too, like e.g. verifying JIT-like code, but hopefully they can be solved in the near feature. Expect me to write more on this topic in the near feature.

Special thanks to Halvar Flake for eye-opening discussions about sound code analyzers and OS security in general.

Handy Tool To Play with Windows Integrity Levels

Mark Minasi wrote to me recently to point out that his new tool, chml, is capable of setting NoReadUp and NoExecuteUp policy on file objects, in addition to the standard NoWriteUp policy, which is used by default on Vista.

As I wrote before the default IL policy used on Vista assumes only the NoWriteUp policy. That means that all objects which do not have assigned any IL explicitly (and consequently are treated as if they were marked with Medium IL) can be read by low integrity processes (only writes are prevented). Also, the standard Windows icacls command, which allows to set IL for file objects, assumes always the NoWriteUp policy only (unless I’m missing some secret switch).

However, it’s possible, for each object, to define not only the integrity level but also the policy which will be used to access it. All this information is stored in the same SACE which also defines the IL.

There doesn’t seem to be too much documentation from Microsoft about how to set those permissions, except this paper about Protected Mode IE and the sddl.h file itself.

Anyway, it’s good to see a tool like chml as it allows to do some cool things in a very simple way. E.g. consider that you have some secret documents in the folder c:\secretes and that you don’t feel like sharing those files with anybody who can exploit your Protected Mode IE. As I pointed out in my previous article, by default all your personal files are accessible to your Protected Mode IE low integrity process, so in the event of successful exploitation the attacker is free to steal them all. However now, using Mark Minasi’s tool, you can just do this:

chml.exe c:\secrets -i:m -nr -nx

This should prevent all the low IL processes, like e.g. Protected Mode IE, from reading the contents of your secret directory.

BTW, you can use chml to also examine the SACE which was created:

chml.exe c:\secrets -showsddl

and you should get something like that as a result:

SDDL string for c:\secrets's integrity label=S:(ML;OICI;NRNX;;;ME)

Where S means that it’s an SACE (in contrast to e.g. DACE), ML says that this ACE defines mandatory label, OICI means “Object Inherit” and “Container Inherit”, NRNX defines that to access this object the NoReadUp and NoExecuteUp policies should be used (which also implies the NoWriteUp BTW) and finally the ME stands for Medium Integrity Level.

All credits go to Mark Minasi and the Windows IL team :)

As a side note: the updated slides for my recent Black Hat DC talk about cheating hardware based memory acquisition can be found here. You can also get the demo movies here.

Confusion About The "Joke Post"

It seems that many people didn’t fully understand why I wrote the previous post – Vista Security Model – A Big Joke... There are two things which should be distinguished:

1) The fact that UAC design assumes that every setup executable should be run elevated (and that a user doesn't really have a choice to run it from a non-elevated account),

2) The fact that UAC implementation contains bug(s), like e.g. the bug I pointed out in my article, which allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.

I was pissed off not because of #1, but because Microsoft employee - Mark Russinovich - declared that all implementation bugs in UAC are not to be considered as security bugs.

True, I also don't like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but I can understand such a design decision (as being a compromise between usability and security) and this was not the reason why I wrote "The Joke Post".

Vista Security Model – A Big Joke?

[Update: if you came here from ZDNet or Slashdot - see the post about confusion above!]

Today I saw a new post at Mark Russinovich’s blog which I take as a response to my recent musings about Vista security features, where I pointed out several problems with UAC, like e.g. the attack that allows for a low integrity process to hijack the high integrity level command prompt. Those who read the whole article undoubtedly noticed that my overall opinion of vista security changes was still very positive – after all everybody can do mistakes and the fact UAC is not perfect, doesn’t diminish the fact that it’s a step into the right direction, i.e. implementing least-privilege policy in Windows OS.

However, I now read this post by Mark Russinovich (a Microsoft employee), which says:

"It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard. Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use."

And then we read:

"Because elevations and ILs don’t define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption."

Oh, excuse me, is this supposed be a joke? We all remember all those Microsoft’s statements about how serious Microsoft is about security in Vista and how all those new cool security features like UAC or Protected Mode IE will improve the world’s security. And now we hear what? That this flagship security technology (UAC) is in fact… not a security technology!

I understand that implementing UAC, UIPI and Integrity Levels mechanisms on top of the existing Windows OS infrastructure is a hard task and it would be much easier to design the whole new OS from scratch and that Microsoft can’t do this for various of reasons. I understand that all, but that doesn’t mean that once more people at Microsoft realized that too, they should turn everything into a big joke? Or maybe I’m too much of an idealist…

So, I will say this: If Microsoft won’t change their attitude soon, then in a couple of months the security of Vista (from the typical malware’s point of view) will be equal to the security of current XP systems (which means, not too impressive).