VBoxmanage | import vs clonevm

Why I am writing this?

I have been using VBoxmanage for some time now and only recently ran into a situation that made me realize I didn't do all my homework.

So I wanted to make sure that no one else makes the same mistake I did with managing virtual machines via the command line.

What is Cloning (clonevm)?

    "This command creates a full or linked copy of an existing virtual machine.[1]"

So what does that mean? well, it means it creates a *.vmdk file within the folder for the new virtual machine.

$ vboxmanage clonevm [existing-vm] --register --name [new-vmname]

The above command will create a new vm in the ~/VirtualBox\ VMs/ folder with the *.vmdk file residing within.

What are the advantages to using clonevm:

• Speed of creation is faster compared to import
• Fewer options to get yourself tripped up on

Possible disadvantages:

• There really are fewer options
• You must already have a base system imported and registered
• This is just more space being taken up by a machine that may not even be running

What is Importing (import)?

Importing is what needs to be done before you can even clone a system.

    "This command imports a virtual appliance in OVF format by copying the virtual disk images and creating virtual machines in VirtualBox.[1]"

So what does that mean? well, it means that if you simply run the following command:

$ vboxmanage import [filename.ova] --vsys 0 --vmname [new-vmname]

you will get a vm that is based off of the base system found within the *.ova.
But, where is the *.vmdk file located?

~/VirtualBox\ VMs/[filename]/[filename]-disk1_[#].vmdk

When importing an image you can actually import multiple VMs based off one *.ova file, and the disk1_[#] number will just continue to increment.

So, what if you want the *.vmdk file in the same directory that your new VM log file will be?
In order to make that happen you will need to include several other options:

$ vboxmanage import [filename.ova] --vsys 0 --unit 10 --disk VirtualBox\ VMs/[new-vmname]/[new-vmname].vmdk --vmname [new-vmname]

When looking up the '--unit' option, I noticed that some people had 11, but you can get this number at the bottom of the following command:

$ vboxmanage import [filename.ova] -n
...
(change target path with "--vsys 0 --unit 10 --disk path";
...

What are the advantages to using import:

• You can import the image from anywhere, it does not have to be an installed and registered machine
• More options so you can setup the machine how you want it and where you want it
• Other than the *ova file you will not need to have another machine running

Possible disadvantages:

• If you neglect to include an option, you will not have the environment you were hoping for
• It does take a little bit longer to import a machine rather than cloning it

I bet you are wondering what it was that I did that caused me to really write this, well, I deleted a folder that contained over 10 VMs because I didn't realize that by importing it would place all of the *.vmdk files into the same folder.
Again, I didn't do all of my homework.

Well, there you have it, clonevm vs import.

----
References:
[1] Chapter 8. VBoxManage; https://www.virtualbox.org/manual/ch08.html

Cisco ASA | SSL VPN | Information Disclosure | CVE-2014-3392 | CSCuq29136

Cisco ASA Clientless SSL VPN Information Disclosure and Denial of Service Vulnerability

The following information is in regards to Cisco's ASA SSL VPN Information Disclosure. It will explain, in no great detail, the result of altering the value of a single parameter, and the data returned by the server. (http://tools.cisco.com/security/center/viewAlert.x?alertId=35916)
(http://www.securityfocus.com/bid/70306)
(http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3392)

Please note that no Cisco ASA SSL VPN equipment is owned by the author, therefore, information concerning the vulnerability is limited to an external perspective.

When testing, the first request made on the login page, of the SSL VPN, was a false username/password combination. The result of the request was a url similar to the following:

https://example.com/+CSCOE+/logon.html?a0=88&a1=5468652061757468656E7469636174696F6E20736696365206973206F66666C696E652E&a2=&a3=1

In the response URL it was noted that the parameter a0 was configured to be a means of displaying login error messages:

As a second request, a hyphen was prepended to the value 88 which resulted in the following error:

https://example.com/+CSCOE+/logon.html?a0=-88

Noting that the error had no direct reference to the login form, additional values were tested to confirm that the server was in actuality displaying “random” information.

After submitting various negative values to the server, the following request appeared to disclose the SNMP MIB (1) version used on the server:

https://example.com/+CSCOE+/logon.html?a0=-99999

With confirmation that negative values were some how being interpreted by the server, an automated process was than used to cycle through negative values.

The vast majority of responses contained data that was not directly readable. However, some requests, such as the following, were clearly understood:

https://example.com/+CSCOE+/logon.html?a0=-21494

Additional information disclosed by the server contained various listings of endpoint.os.hotfix's as noted in the following screen shot:

https://example.com/+CSCOE+/logon.html?a0=-34894

It should be noted that with the exception of -99999 the same request could seldom be made twice. The random data being returned has been confirmed by Cisco (2) as being “random memory locations”.

Contained in various other requests were what appeared to be, vpn certificates, file content, and additional system command USAGE information.

Although the above information is limited, it hopefully shows the potential this issue has in regards to obtaining information from the vulnerable system(s).

*** UPDATE ***
There is now a shell script to test for this issue:
github.com/monsi/CRAM

References:
1. Appendix C - MIB Support (http://www.cisco.com/c/en/us/td/docs/security/nac/appliance/configuration_guide/48/cam/48cam-book/m_apx_mib.pdf)
2. http://tools.cisco.com/security/center/viewAlert.x?alertId=35917

QEMU - VNC - Stupid keyboard issue

So, I ran across an issue that was rather frustrating. Here is the background.

I had installed a plain-vanilla debian machine and then installed libvirt, kvm/qemu and virt-manager (with some other packages but those aren't important).

I had tried to do X11 forwarding on the machine but ran into an issue when trying to use virt-manager to install a guest machine. When ever I would type it would print something other than what I pressed. asdf = abfh.

This wasn't just an issue with X11 forwarding. I also installed tightvncserver and found the same issue. When I would vnc to the Host machine everything would be fine, but when I tried to do an installation through virt-manager I would run into the issue as previously stated.

After looking at everything else I finally took a look at the default keyboard for debian (/etc/default/keyboard) and found that it was "pc105" rather than the plain PC keyboard "pc104" (or pc101).

I know, you are all think "well duh...!" but I didn't know that. After changing the keyboard and rebooting everything started to work fine.

Stupid keyboard layouts.


---UPDATE---
So, I was right but I was wrong. It looks like in Virt-Manager they removed the default keymap for the new guest machines. If you go and delete the current display and add a new one you can uncheck "Keymap [] same as host" and input "en-us". This should fix the issue. (I hope)