Well that’s been a while. I almost forgot my WordPress password. My last post wasn’t really informative so I thought let me just post one of the projects I’m currently working on. It’s far from finished and I doubt if I’ll release it ones it’s finished. So for the moment being I’ll only share my alpha POC which should be enough to build upon.

Have you ever had the need to get stuff of vmdk files without using any of the visual VMWARE products? Well I have!! Now luckily VMWARE also has detected that there are a lot of people with that need and they have released an excellent API the Virtual Disk Development Kit 1.1. Now that stuff is sexy, quote from it’s website:

The Virtual Disk Development Kit (VDDK) is a collection of C libraries, code samples, utilities, and documentation to help you create or access VMware virtual disk storage. The kit includes:

• The Virtual Disk and Disk Mount libraries, a set of C function calls to manipulate virtual disk files.
• C++ code samples that you can build with either Visual Studio or the GNU C compiler.
• The Disk Mount utility to access files and file systems in offline virtual disks on Windows or Linux guest virtual machines.
• Documentation about the VDDK libraries and the command-line utilities.
• The Virtual Disk Manager utility to manipulate offline virtual disk on Windows or Linux (clone, create, relocate, rename, grow, shrink, or defragment).

I assume that after reading the above you’ll also agree that the possibilities are endless. Now let’s get cooking.

First of all here are a variety of reasons why I got interested into the subject of messing with vmdk files(or like Joey from Friends would say, they are threefold):

• People always assume malware wants to break out of a VM
• Currently advise is being given to do financial stuff inside an VM, instead of properly fixing the issue
• It’s fun to mess with new stuff

So with the above reasons I started to mess around with the VDDK API. The API boils down to two things in my opinion:

• raw read/write of the VMDK file
• mount the VMDK and perform read/write operations

So let’s mix the reasons with the possibilities and see what kind of probable attacks you could expect from malware:

• Infect the MBR aka port the stoned bootkit to support VMDK infection(thanks to an anonymous thinker for this idea)
• Have the malware insert itself into all VMDK files present on a system
• Have the malware steal important file(registry files,sam file,private keys…etc)
• Bypass full disk encryption on VMDK files using for example the Evil Maid
• Disable all kind of protection software like AV/FW

For the moment being I’m only releasing the alpha code to steal stuff from a VMDK file. There are several reasons why it’s alpha code, so if it doesn’t work in your own situation or if it breaks things it’s all your OWN responsibility. This code has only been tested on a virtual machine with 1 disk, no partitions, no snapshots, known configuration. At the moment the code only works if the virtual machine is powered off.

Oh and you DO need to have the VDDK installed for this to work. The mounting of the VMDK file is done through a driver which needs to be installed. This can all be solved and malware won’t have this problem cause they will just supply the driver them self. Also don’t forget to configure your programming environment properly to include the VDDK headers and libraries.

Alpha POC

just busy… or on a more detailed note:

- real life hogging my online time

Hope to post some interesting stuff soon

Another old paper

DOWNLOAD

Another old tool

DOWNLOAD.

Another old tool

DOWNLOAD

Another old tool.

DOWNLOAD

This time it’s actually an afternoon thought. So let’s say you will be traveling from one country to another and you have stored your truecrypt container on a remote site. There is a chance someone might steel it and try to brute force it. Usually if you are paranoid enough a brute force on a truecrypt container is well…useless. Because you are THAT paranoid you actually also want to make sure that a brute force on your container really is futile. So how about corrupting the container in a controlled way? Check out the file format specifications: http://www.truecrypt.org/docs/?s=volume-format-specification.

A good option would be to change the 4bytes of the encrypted TRUE string to some random bytes. Make sure u have a backup of the original bytes(preferably memorized). This should prevent the successful decryption of the container even if someone has the correct password.

It’s security by obscurity but hey…you can never have enough layers of security. Another interesting idea is to modify the truecrypt source/binary on your hard disk to use the string FOUR instead of TRUE for the whole decryption verification. So unless they also steel your modified version of the truecrypt binary they will not be able to open it.

Just to make sure…the above ideas are only an ADDITIONAL security layer and it CAN be broken if detected by an adversary. I just thought it would be fun to have an additional layer of security on my truecrypt containers.

So you have just finished installing the hidden operating system offered by TrueCrypt. You are however stuck with the following problem…you need frequent access to the hidden operating system…which means that you won’t be using the decoy system that much. According to the guidelines offered by TrueCrypt this means that your plausible deniability is a little bit less plausible. How about fixing this? What if you could “work” at the same time in both operating systems?

So there I was thinking I could write a blog posting with screenshots and a extended howto. Unfortunatly I am not able to perform the idea on my computer and I got no spare computer left. So I’m just going to put it out there and maybe someone feels like implementing it and letting me know how well it works.

The whole thing is rather simple, it actually fits in a sentence:

Run your decoy OS inside your hidden OS with the help of virtualization techniques.

Like stated before the claim is simple. It’s a shame I got no spare computer around atm to test it out. In theorie it should work fine. Only thing that worries me is the possible evidence that a virtualization application might leave on the booted decoy system, I’m thinking there is none…but I haven’t been able to test this.

So just to be clear this is NOT an idea to go against the TrueCrypt Security Precautions, it’s just another method to be able to spend more time in a hidden operating system without having to worry that it could be compromised because of forensics on your decoy os. This way all the timestamps and the temp files will be kept up to date in your decoy os while you are working in your hidden os.

To take it one step further…you could even write a few scripts to startup your email, mark them as read at varieng intervals and surf around on the web. If they ask you why you have script to automate things inside your decoy os, you can just answer with a simple answer: I’m lazy.

If I get a spare computer anytime soon I’ll be sure to let you know how this method works out.

So once in a while you hear about some backdoor which was slipped into some source code. Mostly in C applications…so I was thinking how would this be done in Java? Most of the times the backdoors you hear about are very nasty and difficult to track down “bugs” in the source code like buffer overflows, race conditions and the likes. Since Java doesn’t really have buffer overflows(I’m ignoring faulty VM implementations for the moment) I was wondering what an other *hopefully* good way would be to introduce bugs you can exploit?

So after waking up in the middle of the night(no kidding, it was 3.30 am) I remembered something from back in the day when I coded in Java. Most of the time when working with SSL and Java I got all frustrated because the companies we worked with where not capable of delivering a test environment which had a valid certificate…so it sucked. A invalid certificate meant, Java would reject the SSL connection and you’d be wondering why the application didn’t work. If I’m correct .NET has something like this to. Like all lazy programmers I used the following code to bypass that(courtesy of google, thanks to the original author though):

private TrustManager[] acceptAllCerts(){
 TrustManager[] trustAllCerts = new TrustManager[]{
 new X509TrustManager() {

 public java.security.cert.X509Certificate[] getAcceptedIssuers() {

 return null;
 }

 public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType) {
 }

 public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType) {
 }
 }
 };
 return trustAllCerts;
 }

Then just create your SSL socket, which uses the above function to accept all certificates.

SSLContext sc = SSLContext.getInstance("SSL");
 sc.init(null, acceptAllCerts(), new java.security.SecureRandom());

 SSLSocketFactory factory = (SSLSocketFactory) sc.getSocketFactory();
 sslSocket = (SSLSocket) factory.createSocket(iAddr,this.port);

So you are probably wondering why I’m classifying this as a possible backdoor? Well just imagine…some big application which relies upon SSL to be sure it has a secure connection. If you normally man in the middle it, with a self signed certificate it will complain, with the above code in place it will not complain about your mitm attack. So you can sniff all the sensitive information you want. Personally I think it’s best used in combination with a little bit of social engineering, for example add some comments to the code stating one of the following things:

• will be fixed by @author: DO NOT TOUCH
• only used until the acceptance phase has been completed
• hate working overtime? Don’t touch this code
• will be fixed in the next release

It actually works…I’ve seen code floating around with similar comments and nobody seems to care. Of course this will not always work and a programmer which actually does his job will notice this. Still if you get it to work ones it’s a real nice way to get data, without breaching the computer which runs the application and thus leaving less traces around.

Actually I called it GDNS but well…that would be to cryptic as a blog item title. This is also from the KD-Team archives. Enjoy. All it does is *TRY* and find all sub domains for a given domain with the use of google.

http://pastebin.com/f720c4036