Kernel, Hypervisor, Virtualization, Trusted Computing and other system-level security stuff
Friday, April 20, 2007
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 :)
Sunday, April 01, 2007
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… ;)
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… ;)