Booting your Dual-boot OS in a virtual machine

In my previous post I showed how to boot from a USB device in a virtual machine by directly connecting a physical disk from the host to the VM. Just to see how far you can go with that I tried to boot my dual-boot OS in the same way.

Note: directly accessing your boot-disk from a VM can seriously mess up things. You are warned :)

Note: simultaneously running your host OS in a virtual machine is most definitely going to result in disaster; I strongly advise not to do that.

The process is basically the same as for attaching your USB stick, but this time you have to select PhysicalDrive0 in QEMU or VMWare player.



In VMWare player you have the option to select the partions the VM is allowed to access. The bootsector/MBR is always accessible, so you can use this option to prevent the VM from accessing your host OS. On my disk I have Samurai WTF installed next to my windows OS. I have 2 NTFS partions, 1 FAT32 partition and 2 ext partitions. In this example I booted in windows and want to have the VM boot the dual-boot linux so I only selected the ext partitions in the VM properties:



Booting the VM first shows the bootloader



And after selecting the Linux option it will boot without problems.



Attempting to boot from a partion not selected in the VM properties will result in an error, so you can use this option to prevent accidentally selecting the wrong OS:

Booting from USB flashdrive in virtual machine

The last weeks I have been playing a bit with bootable USB flashdrives and bootloaders/managers. One of the annoyances in doing that is testing if your changes work. The easiest way is to do this in a virtual machine of course, but not all virtual machine solutions support booting from a USB device. Many solutions found on the internet suggest booting an iso with a bootmanager (like plop) first, but there is a more direct solution in VMWare player and QEMU (maybe also in other products). A big advantage of this method is that directly accessing the disc is a lot faster than by using the USB stack of the virtual player.

Both VMWare player and QEMU support booting from "Physical Drives", which basically is nothing more that booting from a disk that is already present in the host.

When you are using QEMU with QEMU Manager the option can be found on the Drives tab:



The booting device of the host is typically PhysicalDrive0. Your USB devices should be PhysicalDrive1 or higher. Make sure you select the right one.

In VMWare the option is not directly available when creating a new VM. First you have to create a virtual hd of any size and finish the VM. After that edit the properties and delete the created HD. Now add a new hard disk and select the option "use a physical disk (for advanced users)":



Just as in QEMU the booting device of the host is typically PhysicalDrive0. Your USB devices should be PhysicalDrive1 or higher. Make sure you select the right one.



There is also a selection for using the whole drive or individual partitions, but for USB flashdrives you can leave this on "use entire disk" (as partitions on USB flashdrives are hardly supported and unusual).

A screenshot of a proof-of-concept running the miniXP from Hiren's BootCD in VMWare player. In this case the USB flashdrive was formatted as FAT32, but for me it also worked when it was formatted as NTFS. I used grub4dos as the bootloader/manager.



and the properties of the virtual machine in VMWare Player:



Update: to prevent the VM from hijacking the USB flashdrive remove the "USB controller" from the VM properties.

How to protect yourself from Firesheep (and other wolves in disguise)

About a month ago codebutler released a firefox plugin called firesheep and shook the world (or at least the internet using part of it). Firesheep makes it possible to sniff unencrypted networks for credentials and take over someones identity; the HORROR !

The vulnerability that firesheep (ab)uses is not new, known for a very long time, widely spread, and called "session hijacking". A very simple overview can be found at the OWASP page about it.

In fact, the problem is so big that a tool like firesheep was necessary to finally create some awareness for it and according to the website that was also the main reason for releasing it:
Websites have a responsibility to protect the people who depend on their services. They've been ignoring this responsibility for too long, and it's time for everyone to demand a more secure web. My hope is that Firesheep will help the users win.


Unfortunately the problem resides on the web server side and can only be solved there but the solutions are known.

So, where does that leave us? Are we completely helpless? Luckily not. Over the last few weeks several solutions were posted all over the internet, but I felt none of them provided a complete overview, so that's why I wrote this post.

Let's start with the obvious: "Do not use unencrypted networks"
Although this might seem an "open door" it's not. Many applications run in the background connecting at regular intervals for updates and not only on laptops, but nowadays also on smart-phones. Make sure to disable automatic connections to unsecured networks.

"Only use https"
When you need to access a webpage that requires you to login make sure it supports https. This can be trickier than it looks as many websites only support https on the login page and switch back to http after the login has completed, making sniffing and a successful session hijacking attack possible again. Some websites (e.g. gmail ) allow you to force the use of https in the settings, but more sites don't.

Firefox users can use add-ons like 'https everywhere' or 'noscript' to force the browser to always use https on certain sites, but the problem remains that many sites do not support it on all pages or functionalities (e.g. facebook chat or linkedin). Users of IE, Chrome or Opera cannot even use these plugins.

"HTTPS tunneling"
A better solution is the use of an https tunnel. With a tunnel you basically create an encrypted connection to a trusted location and reroute all traffic over it. Although many SSL supporting web proxies exist, I personally wouldn't trust them with my login data so a better idea it to setup one yourself.
For this you need to have a webserver, but this might be easier than you think. Many home-use devices like a NAS have build-in support for this and you don't need much power if you only use it yourself; a simple apache server with php+ssl support is all you need. Providing a complete guide to set this up for every device or webserver is impossible, but the basic steps to set this up are:

1) install a php based proxy on your webserver (I use phproxy, but alternatives exist)
2) setup ssl in apache
3) i also recommend to at least setup basic authentication to prevent unauthorized access
4) open up the port in your firewall

When everything is running it is as simple as first browsing securely to your proxy after which you can safely have the proxy access insecure sites. This solution does have a few drawbacks though, the biggest one being broken functionality, but security comes at a price... Another drawback is that this solution cannot be used for applications other than the browser.

When you want use other applications securely on an unencrypted network you need more advanced solutions like an SSH tunnel. Again, providing a complete guide to set this up for every device or webserver is impossible, but here and here you can find the basics for setting up an SSH tunneling proxy using putty.

Another solution is using a VPN connection, but that might prove to be more difficult to set up. Fortunately many providers offer these solutions relatively cheap so google a bit around.

Fun with regexes

Last year on one of the dutch OWASP chapters Adar Weidman gave a very interesting presentation about reDOS.

The principle behind a reDOS is feeding a regex input that will cause it to spawn a huge number of treads eventually exhausting all resources on the system. Take a look at the OWASP page for more information.

Ever since the presentation I was intrigued by the vulnerability, but did not really see much of it in the field (or I didn't search hard enough).

I mostly forgot about it until I read this post a few months ago. Apparently these things are more widespread than I suspected...

For those interested in regexes, lacking knowledge, and wanting to play with them:
http://xenon.stanford.edu/~xusch/regexp/analyzer.html
http://www.regular-expressions.info/

New Start

This week I decided to start twittering and thought it was also a good moment to revive my blog. Many things have occupied me the last year, some of which I will share here so stay tuned or follow me on twitter @Dave_von_S

BruCON 2009

This weekend I noticed the schedule for BruCON 2009 is almost complete, so now the hard part begins; deciding what to attend to and what to skip .. Tough decisions have to be made :)

If you're interested in BruCON an want to stay up-to-date; join the linkedin group:
http://events.linkedin.com/BruCON-Security-Conference/pub/31107

Pentest(ing) politics

This week I started on a long term assignment involving the implementation of web application security testing in the SDLC. Although it is fun to do something more structural than the average 'pentest a website and get out' assignment, there's also the element of politics that immediately shows it's head.

For example choosing a scanner .. Although you can get good results with a collection of open-source or freeware tools, sometimes a commercial scanner is the better choice from a political perspective. Especially when there are quite strict regulations about the format of your reporting, choosing a commercial scanner can make your life a lot easier... On the other hand it's absurd to decide on the acquisition of tools based on the format of a report.

It makes you wonder if you should deal with pentest politics or if you should pentest politics.