CanSecWest – Day 2 Part 1

This morning we started off with a talk on Mobitex from a Toolcrypt guy (OlleB).  Olle was a very relaxed speaker with very good English (given that he hails from Stockholm) although the talk was a bit dry and not super interesting for me.  Mobitex as it turns out is a wireless data protocol that's been around for decades that is used by things like emergency response agencies and things like this.  Olle has managed to write some cool software for sniffing the data using COTS hardware and software.  I asked him if he was at all interested in GSM and if he was familair with H1kari's work / presentation at BH Federal and he was indeed.  I asked him how he got into hacking Mobitex and the answer was to have been expected - "I was waiting for paint to dry and I was bored". 🙂

The next talk was on cold memory attacks from two presenters from Intelguardians.  They started off by giving mad props to the Princeton / Wind River for their research report that generated a press cycle or two a few weeks ago.  They explained that they were interested in these types of attakcs from a penetration testing perspective where they have physical accesss to machines.  They've basically done a bunch of testing and have tried 4 different approaches to dumping RAM on freshly rebooted machines and they've created some Perl scripts that you can run to find passwords in memory.  They are working on making a compiled EXE you can run from a USB thumb drive that will scan memory (vs. dumping it) for passwords and dump only that information to the USB drive since USB drives are slow (it turns out when booting off a USB 2.0 drive on a USB 2.0 machine - it will probably only use USB 1.1 speeds).  At the end of their talk they gave the floor to the Princeton / Wind River guys and they demo'd an iPod mini they had converted into a RAM dumper. 🙂  The iPod mini was a bootable device (he used FreeBSD to repartition the hard drive - and he even managed to keep the iPod functioning while having this second bootable partition).  You plug in the iPod and boot off it and it begins dumping.  Pretty slick.

 After this presentation I managed to flag down Oded Horovitz from VMWare and he was very glad to meet me.  It turns out - as I suspected - I was very wrong with some information in my blog post yesterday.  Here's the scoop - VProbes are very similar in functionality to DTRACE for Solaris.  That was not what he was demonstrating - he was talking about VMSafe.  VMSafe as a technology, for now, gives 'security agents' access to a guest OS's 'physical pages of memory'.  These 'security agents' will run in a VM themselves and this VM will be running Linux.  These security agents will link against a VMWare provided library and they will talk to the hypervisor so that they can read the pages of memory of a VM they are configured to monitor.  So say you are running ESX Server and you have 4 Windows VMs that you want to monitor via security agents.  You could have a single VM (for a total of 5 VMs) that runs a given 3rd party security agent inside.   This VM will be 'allowed' to access the hypervisor via supported APIs and this will be configured by the admin.  So a security agent in a VM will not be able to read pages of memory for any VMs that have not been authorized by the admin.  I believe you can have a 1:many or a 1:1 relationship between the security agent VM and the other guest VMs that it's monitoring (i.e. 1 security agent VM per guest OS VM or 1 security agent VM for many guest VMs).  So my obvious concern with this model, now that I understand it better - still stands.  The obvious customers for this new technology are going to be AV vendors who want to be able to scan physical pages of memory for guest VMs they are configured to protect.  Even though these security agents are not running inside the VM being monitored - they are basically going to be reading pages of memory provided by the hypervisor and scanning them using signatures etc.  So this moves the vulnerable parsing code form the guest OS VM running say Windows - to the 'security agent' VM running Linux.  So let's assume the bad guys manage to get code execution in the security agent running in the Linux VM . . . they can now theoretically talk to the hypervisor and read physical pages of memory for any VMs that the security agent VM is configured to protect.  Still need to give more thought to this - but it still seems slightly scary and is still cool.  One thing is for sure - Oded rocks .  . I really admire his passion and enthusiasm - I finally met someone who talks faster than me - and English doesn't even seem to be his native language making that an even more impressive feat! 🙂

As a result of talking to Oded I missed most of the Snort 3.0 talk . . . so I don't have much to report.  Snort 3.0 seems like a pretty impressive improvement over 2.8. 🙂

Comments (0)

Skip to main content