Contenido principal

VirtualBox Disk Image Encryption password cracker

Julio 15, 2015

VirtualBox 5.0 was released the past July 9 with a new built-in disk image encryption feature which allows the user to encrypt virtual hard disk transparently.

With this feature a new tab is enabled in General configuration for each machine:

VBOXDIE Configuration

When the user sets a password, a new element called Property is added to the HardDisk element inside the machine configuration:

<HardDisk uuid="{b9f72e2c-7dde-412d-be98-6f07dbcabd41}" location="Encrypted.vdi" format="VDI" type="Normal">
  <Property name="CRYPT/KeyId" value="Encrypted"/>
  <Property name="CRYPT/KeyStore"
value="U0NORQABQUVTLVhUUzEyOC1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
MjU2AAAAAAAAAAAAAAAAAAAAAAAAACAAAAAJwd3SksjYgaKyVqNkFvSNya8SkGiz
kfuKYCB2xJk67SAAAACbTjDwMkoPESRduJWBXP4U+Tmtm3lj1k6kBlgeB42/NtAH
AACdTMPxXmuA+fiTrKHvuS+xFrYcbGj6SDa4uiUWV9WCU9AHAAAgAAAAq/tmzFGv
wmcIaYYgDxJidNRFk71JTjqUaKXS2wMuDVQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA=="/>

</HardDisk>

The KeyStore is encoded using Base64, and it contains the information needed by the machine to verify the password each time the user wants to start a machine or change its password.

I made a tool called VBOXDIECracker as a proof of concept to crack weak passwords used in this new feature of VirtualBox, you can download it from:

https://github.com/sinfocol/vboxdie-cracker/

Following is a detailed explanation of how this new feature works:

KeyStore Format

First, we need to identify in someway the fields within the decoded keystore:

0000h: 53 43 4E 45 00 01 41 45 53 2D 58 54 53 32 35 36  SCNE..AES-XTS256
0010h: 2D 50 4C 41 49 4E 36 34 00 00 00 00 00 00 00 00  -PLAIN64........
0020h: 00 00 00 00 00 00 50 42 4B 44 46 32 2D 53 48 41  ......PBKDF2-SHA
0030h: 32 35 36 00 00 00 00 00 00 00 00 00 00 00 00 00  256.............
0040h: 00 00 00 00 00 00 40 00 00 00 12 02 78 97 DA CB  ......@.....x—ÚË
0050h: 3A 4C 4F EE F4 87 62 9D 68 A0 73 00 20 D9 B5 DE  :LOîô‡b h s. ÙµÞ
0060h: 74 94 40 8C 7A F9 9A F0 82 89 20 00 00 00 27 B5  t”@Œzùšð‚‰ ...'µ
0070h: 01 C3 16 F4 9F C2 96 B2 FE 32 85 57 35 16 73 81  .Ã.ôŸÂ–²þ2…W5.s.
0080h: AC 20 9F D1 C0 C8 3E 5E 41 B6 6F F3 C3 5A D0 07  ¬ ŸÑÀÈ>^A¶oóÃZÐ.
0090h: 00 00 8A 8F 4A 94 83 7E EC 1B B4 D6 9A 2E 7C 9F  ..Š J”ƒ~ì.´Öš.|Ÿ
00A0h: FA DC 5E 65 95 36 DF 45 A8 1C 46 66 2C F6 6B E9  úÜ^e•6ßE¨.Ff,öké
00B0h: 5E 58 D0 07 00 00 40 00 00 00 EA A5 55 F2 73 AE  ^XÐ...@...ê¥Uòs®
00C0h: AF 9F 11 57 12 8F D1 C3 51 7D 7C AE F4 3E C9 AA  ¯Ÿ.W. ÑÃQ}|®ô>ɪ
00D0h: A5 40 69 17 CD 13 72 C5 76 8C F8 85 7C 56 59 67  ¥@i.Í.rÅvŒø…|VYg
00E0h: 31 8C E1 81 24 0F C1 43 95 6E C2 FA C3 C4 EF 0E  1Œá $.ÁC•nÂúÃÄï.
00F0h: 62 9C 18 82 5D F2 28 E7 1E C2                    bœ.‚]ò(ç.Â

After some work we are able to identify each field:

VirtualBox KeyStore File Format
Offset Bytes Description
0 4 File header signature = 0x454E4353 (SCNE)
4 2 Version
6 32 EVP algorithm
38 32 PBKDF2 hash algorithm
70 4 Generic key length (used by PBKDF2 and AES-XTS)
74 32 Final hash where comparison is done
106 4 Key length used in the second call to PBKDF2
110 32 Salt used in the second call to PBKDF2
142 4 Iterations used in the second call to PBKDF2
146 32 Salt used in the first call to PBKDF2
178 4 Iterations used in the first call to PBKDF2
182 4 EVP input length
186 64 Encrypted password used in the second call to PBKDF2 (to be used as input in the call to AES-XTS)

VirtualBox Keystore 010 editor template

The following 010 Editor template could be used as a guide:

//--------------------------------------
//--- 010 Editor v6.0.2 Binary Template
//
// File:        VBOXDIEKeyStore.bt
// Author:      Daniel Correa
// URL:         http://www.sinfocol.org/
// Revision:    1.0
// Purpose:     Template for VirtualBox Disk Image Encryption KeyStore
//--------------------------------------

typedef struct vbox_die_keystore {
    int header <bgcolor=0xaabbcc, format=hex, name="Header">;

    if (header != 0x454E4353) {
        SetBackColor(0x0000ff);
        Warning("File is not a valid VBOX DIE KeyStore. Bad signature.");
        return -1;
    }

    uint16 version <bgcolor=0xccddee, name="Version">;
    char algorithm[32] <bgcolor=0x00ffee, name="EVP encryption algorithm">;
    char kdf[32] <bgcolor=0xffbbee, name="Key derivation function hash algorithm">;
    int generic_key_length <bgcolor=0x3399ee, name="Generic key length">;
    char final_hash[32] <bgcolor=0x4444ff, name="Final hash">;
    int pbkdf2_2_key_length <bgcolor=0x3399ee, name="Second PBKDF2 key length">;
    char pbkdf2_2_salt[32] <bgcolor=0x999999, name="Second PBKDF2 salt">;
    int pbkdf2_2_iterations <bgcolor=0xaa9933, name="Second PBKDF2 iterations">;
    char pbkdf2_1_salt[32] <bgcolor=0x999999, name="First PBKDF2 salt">;
    int pbkdf2_1_iterations <bgcolor=0xaa9933, name="First PBKDF2 iterations">;
    int evp_decrypt_input_length <bgcolor=0x3399ee, name="EVP decrypt input length">;
    char pbkdf2_2_encrypted_password[64] <bgcolor=0xff7777, name="Second PBKDF2 encrypted password">;
};

FSeek(0);
LittleEndian();
vbox_die_keystore VBOXDIE;

The result of running the template:

VBOXDIE 010 editor template 1

VBOXDIE 010 editor template 2

VirtualBox password storage algorithm

With the identification of the fields within the keystore we can now have an understanding of how the password storage algorithm works, and it is summarized in this way:


# 32 for AES-XTS128-PLAIN64
# 64 for AES-XTS256-PLAIN64
AES_key_length = 32 | 64
-------------------------
AES-password = PBKDF2(algorithm: SHA256,
password: user_password,
salt: random_salt_1,
iterations: 2000,
output_length: AES_key_length)
----------------------------------------------
PBKDF2-decrypted-password = AES_decrypt(key_size: AES_key_length,
mode: XTS,
data: random_data
password: AES-password,
type: raw,
iv: NULL)
-------------------------------------
Stored_hash = PBKDF2(algorithm: SHA256,
password: PBKDF2-decrypted-password,
salt: random_salt_2,
iterations: 2000,
output_length: 32)

The same process is performed each time the user wants to decrypt the machine disk. The stored hash (the one from keystore) is compared with the computed hash (the one from user input) in order to authenticate the user and let him use the machine.

VBOXDIECracker - the tool

With the appropriate format and algorithm we can emulate the password verification of VirtualBox and make a not-so-fast cracker with PHP (sorry guys, I did not find a standard package on python to use AES XTS), it is just a proof of concept, so you can develop another leet tools.

You can download it from this site or browse it from the repository.

This is a sample of the source code showing the main function which is the one who computes the final hash:

<?php

// redacted

/**
 * crack_keystore
 *
 * Makes a bruteforce to find the final hash contained in the KeyStore
 * Returns the plaintext password used to encrypt de disk of the virtual machine
 */
function crack_keystore($keystore, $wordlist) {
    $fp = fopen($wordlist, 'r');
    if (is_resource($fp)) {
        $hash = get_hash_algorithm($keystore);
        $method = get_openssl_method($keystore);

        while (!feof($fp)) {
            $user_password = trim(fgets($fp));

            $EVP_password = hash_pbkdf2($hash, $user_password, $keystore['pbkdf2_1_salt'], $keystore['pbkdf2_1_iterations'], $keystore['generic_key_length'], true);

            $decrypted_password = openssl_decrypt(substr($keystore['pbkdf2_2_encrypted_password'], 0, $keystore['evp_decrypt_input_length']), $method, $EVP_password, OPENSSL_RAW_DATA, '');
            if ($decrypted_password === false) {
                continue;
            }

            $final_hash = hash_pbkdf2($hash, $decrypted_password, $keystore['pbkdf2_2_salt'], $keystore['pbkdf2_2_iterations'], $keystore['pbkdf2_2_key_length'], true);
            if ($final_hash === $keystore['final_hash']) {
                return $user_password;
            }
        }

        return false;
    } else {
        return false;
    }
}

// redacted

And the final output with a recovered password:

$ php VBOXDIECracker.php
VirtualBox Disk Image Encryption cracker

Usage: VBOXDIECracker.php disk_image.vbox [wordlist]

$ php VBOXDIECracker.php Encrypted.vbox wordlist.txt
VirtualBox Disk Image Encryption cracker

[+] Reading data from: Encrypted.vbox
----------------------------------------------------------------
[+] Checking hard disk encryption for: Encrypted.vdi
[+] Hard disk is encrypted
[+] KeyStore encoded string:
        U0NORQABQUVTLVhUUzI1Ni1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
        MjU2AAAAAAAAAAAAAAAAAAAAAAAAAEAAAAASAniX2ss6TE/u9IdinWigcwAg2bXe
        dJRAjHr5mvCCiSAAAAAntQHDFvSfwpay/jKFVzUWc4GsIJ/RwMg+XkG2b/PDWtAH
        AACKj0qUg37sG7TWmi58n/rcXmWVNt9FqBxGZiz2a+leWNAHAABAAAAA6qVV8nOu
        r58RVxKP0cNRfXyu9D7JqqVAaRfNE3LFdoz4hXxWWWcxjOGBJA/BQ5VuwvrDxO8O
        YpwYgl3yKOcewg==
[+] KeyStore contents:
        Header                        454e4353 (SCNE)
        Version                       1
        Algorithm                     AES-XTS256-PLAIN64
        KDF                           PBKDF2-SHA256
        Key length                    64
        Final hash                    12027897dacb3a4c4feef487629d68a0730020d9b5de7494408c7af99af08289
        PBKDF2 2 Key length           32
        PBKDF2 2 Salt                 27b501c316f49fc296b2fe32855735167381ac209fd1c0c83e5e41b66ff3c35a
        PBKDF2 2 Iterations           2000
        PBKDF2 1 Salt                 8a8f4a94837eec1bb4d69a2e7c9ffadc5e659536df45a81c46662cf66be95e58
        PBKDF2 1 Iterations           2000
        EVP buffer length             64
        PBKDF2 2 encrypted password   eaa555f273aeaf9f1157128fd1c3517d7caef43ec9aaa5406917cd1372c5768c
                                      f8857c565967318ce181240fc143956ec2fac3c4ef0e629c18825df228e71ec2
[+] Cracking finished, measured time: 6.13035 seconds
[!] KeyStore password found: 123
----------------------------------------------------------------
[+] Checking hard disk encryption for: New_Disk.vdi
[-] Hard disk is not encrypted

Archivado en: Sin categoría | Comentarios (0)

Backdoor CTF 2015 - RSANNE

Abril 3, 2015

We are given with two files in this challenge: an encrypted file and a 4484 bit RSA public key. The challenge is to get the plaintext from the encrypted file.

The first step is to get the modulus from the PEM file:

# openssl rsa -inform PEM -pubin -text -modulus < id_rsa.pub
Public-Key: (4484 bit)
Modulus:
    0f:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    ff:ff:ff:ff:ff:fd:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    f8:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
    00:00:00:00:00:01
Exponent: 65537 (0x10001)
Modulus=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFF
FF80000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000001
writing RSA key
-----BEGIN PUBLIC KEY-----
MIICUjANBgkqhkiG9w0BAQEFAAOCAj8AMIICOgKCAjEP////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////
//////////////////////////3////////////4AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAECAwEAAQ==
-----END PUBLIC KEY-----

N is the product of two Mersenne primer numbers, so the second step is to make a script which is used to find them:

#!/usr/bin/env python

mersenne = [2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607, 1279, 2203, 2281, 3217, 4253, 4423, 9689]

for n1 in mersenne:
    for n2 in mersenne:
        m1 = (2 ** n1)  - 1
        m2 = (2 ** n2) - 1
        if m1 * m2  == 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDFFFFFFFFFFFFFFFFFFF80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001:
            print "Match! ", m1, m2

The two prime numbers are: 22281 - 1 and 22203 - 1.

We use rsatool.py from ius to reconstruct the private key PEM file (which is used later to decrypt the content of the file using the OAEP padding scheme):

-----BEGIN RSA PRIVATE KEY-----
MIIKCAIBAAKCAjEP////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//3////////////4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAECAwEAAQKCAjEIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yge
d+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB53
4Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfh
iB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GI
HnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yged+GIHnfhiB534Yge
d9+AgH9/gIB/f4B4YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhh
B574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEH
nvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee
+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574
YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhhB574YQee+GEHnvhh
B6ECggEeAf//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////wKCARQH////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//8CggEeAYCAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CA
f3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/
f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/
gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+A
gH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CAf3+AgH9/gIB/f4CA
f3+AgH9/fwKCARQGWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZ
aaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllp
ppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmm
lllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaW
WWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZaaaWWWmmlllpppZZ
aaUCggEeAKqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqq
qlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVU
qqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpV
VUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqq
pVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVSqqpVVUqqqlVVS
qqpVVUqqqQ==
-----END RSA PRIVATE KEY-----

Final step is to decrypt the file:

# openssl rsautl -decrypt -in flag_d.bin -out plaintext.txt -inkey private.pem -oaep
Loading 'screen' into random state - done

# cat plaintext.txt
the_flag_is_e4972e14...

Archivado en: Criptografía, Retos informáticos | Comentarios (0)

B-Sides Vancouver CTF 2015 - garbage file

Marzo 18, 2015

Description

Your buddy Joey left a USB key with some data he needs your help with. He pulled it from the firewall logs at a 'secure file format'-as-a-Service provider, so he's pretty sure it might be protected or obfuscated somehow.

garbagefile.pcapng.gz

Solution

A PCAPNG file is provided, there we can see some UDP packets where the data is located:

We need to get all the data sent over UDP, we can do it by using tshark:

$ tshark -r garbagefile.pcapng -Y "udp" -T fields -e data
00026163636f756e742d646174612e62696e006f6374657400
00040000
0003000100004edf00002e77789c0173018cfe4435d00b168b...
00040001
00030002803434680f53d41a3d4068007a801a1ea0341a1ea7...
00040002
00030003142dfea2fb389f6ded40c310f8dcc905034127d07f...

Each message is composed by two short integers (first one to indicate which is sending the message + second one an incremental ID), and the data itself. I used this script on PHP to separate data from metadata and create bzip files (based on bzip headers found on the dump):

<?php

$file = file('data.txt');

$out = '';
for ($i = 2; $i < count($file); $i += 2) { // ignore first and second line, then each two
    $out .= hex2bin(substr(trim($file[$i]), 8)); // strip metadata
}

$i = 0;
$bzs = explode('BZh', $out);
foreach ($bzs as $bz) {
    file_put_contents('bzips/' . $i++, 'BZh' . $bz);
}
?>

Twenty two files are created, it is time to decompress them using python:

import bz2
import sys

for i in xrange(0,22):
    try:
        file = bz2.BZ2File(str(i), "r")
        print file.read()
    except:
        sys.stderr.write('file '+ str(i) + ' invalid\n')

There are only three "corrupted" files:

file 0 invalid
file 8 invalid
file 21 invalid

First file does not contain a bzip header, so it was skipped. Second file is the heaviest (20.8KB) and it is possible the file we are looking for. We are making a guess now, the file seems to have a Zlib header:

It is decompressed properly giving us a base64 encoded file:

iVBgMA0KNH0AAC56SUhqJQAALO0AAC4TCAIudwCpR3DoAC53AXN8MEIAgLkc6S53AAleP1lzLncL
Ey53CxMvd5qcNncAQC4+REF6DwHt83C8BWsCMPB7xwsIBH9SBQojRUGjPbH3OPolxPZlTYIDJj8T
Y3saExvhmNgfMRMLBOHERp5W2MAofwgoM9MqKqxXWL7RyXlvwZnM7FMM997V/ez88Ji+2ffuM2fg
... (cropped)
a0ANOm8oMH4XoMBu9tWlbty/38TVNdQQJ2Cg7jeBgSx0BQYkA6fAjrm700S/OVBO18BAr/YCAyuh
KAUoAr5GFRFAa463QIGvdQMFKH10p+7Xzrv9Hcg5fhegwG72gQItctYoK3F1vmhMZkBF18BAr/YC
AytxCnSJt6DOlaRqyBcnYKDuN4GBLHQF1gZyBnWQMTtmbhygwG72gQItcgYKWtDA/ymC2qJiimhr
73cAAC4+RU5q2UJgrA==

Final result is a PNG file encrypted with XOR using "00 00 2E 77" as key:

Flag

key{03087-08351-27H}

Archivado en: Miscelaneo, Retos informáticos, Seguridad | Comentarios (0)

FREAK on Colombian domain names and Heartbleed one year later

Marzo 4, 2015

I am here writing again about some statistics, this time is for the new vulnerability found on SSL/TLS (FREAK Attack) against critical Colombian domain names. Same methogolody of Overview of OpenSSL security bug (CVE-2014-0160) on critical Colombian domain names is used in this post.



FREAK Attack on restricted colombian domain names

Identifying vulnerable domains

A python script was used to identify in a non-intrusive way the affected Colombian domain names (gov.co, edu.co, mil.co, and org.co):

    for domain in domains:
        result = ''
        IP = domain_exists(domain)
        if IP != False:
            if check_connectivity(IP):
                if check_FREAK(IP):
                    result = 'VULNERABLE'
                else:
                    result = 'NOT-VULNERABLE'
            else:
                result = 'SECURE-CHANNEL-UNSUPPORTED'
        else:
            result = 'NON-EXISTENT'

Results

2975 domain names were tested against the vulnerability, the results are impressive, from 1815 domains that support HTTPS only 46 are affected (it is possible to make a man in the middle attack while the domains is using SSL/TLS):



This is the detail of the results classified by each Third-level domain:

:arrow: gov.co, 662 not vulnerable, 18 vulnerable.
:arrow: edu.co, 689 not vulnerable, 15 vulnerable.
:arrow: mil.co, 58 not vulnerable, 1 vulnerable.
:arrow: org.co, 360 not vulnerable, 12 vulnerable.



Finally, we got the distribution of the vulnerable Colombian third-level domains:



Heartbleed a year later

One year later the same script and data were used to test the heartbleed vulnerability (Overview of OpenSSL security bug (CVE-2014-0160) on critical Colombian domain names), this is what I found:

:arrow: Only 2 domain names were found to be free of the Heartbleed vulnerability, 16 are still vulnerable.
:arrow: 177 domain names have implemented HTTPS.
:arrow: 115 domain names were deleted (or DNS A record does not exist).
:arrow: 86 domain names dropped HTTPS support.

Archivado en: Seguridad | Comentarios (0)

Overview of OpenSSL security bug (CVE-2014-0160) on critical Colombian domain names

Abril 10, 2014

* Update on methodology and results: Statistical sample
* Update on methodology and results: Retest

The TLS heartbeat read overrun (CVE-2014-0160) (also known as The Heartbleed Bug) is the hot topic right now on the information security field. While this publication is not about the technical detail of the bug but some statistics of critical affected Colombian domains, I will show you a big picture of the vulnerability and the results of my research.

If you would like to know more about it, please take a look at the following resources: The Heartbleed Bug, Sean Cassidy's technical analysis, Robert Erbes' technical analysis.

Vulnerability summary

The Heartbleed Bug allows an attacker to read sensitive information contained in the memory of the process which depends on the OpenSSL implementation (OpenSSL from version 1.0.1 to 1.0.1f).

Sensitive information such as user credentials, session IDs, data sent to the server and received by the client, private keys, and anything you can imagine could be found by exploiting this vulnerability.

Affected users are recommended to fix the issue as soon as possible by updating to the latest version of OpenSSL (1.0.1g).

Methodology and results

Restricted Colombian domain names

Using domain name searching methods I was able to get a long-enough list of third-level domains (the list does not include subdomains) which are classified by NIC.CO as restricted user domains, this is, the person who register the domain have to meet certain legal requirements to be able to get a restricted domain name (gov.co, edu.co, mil.co, and org.co).

These domains are used by Colombian government agencies or institutions, Colombian educational sector institutions recognized by the Ministry of National Education, Agencies or institutions of the Colombian Armed Forces, and Companies or nonprofit institutions resident in Colombia.

Update note about the statistical sample

Through this methodology, a sample of 2612 domain names were found which is a 99% representative sample for a hypothetical case of 10000 (*) valid and functional domain names.
* Approximate data provided by NIC.CO

Evaluation date

Start time: 08/04/2014 - 22:48
Finish time: 08/04/2014 - 23:30

Identifying vulnerable domains

A modified version of the Jared Stafford's python script was used to identify in a non-intrusive way the affected domains (no data was stored or viewed on the test, the script just only show the status of the server).

    for domain in domains:
        result = ''
        ip = domain_exists(domain)
        if ip != False:
            if check_connectivity(domain):
                try:
                    if check_heartbleed(domain):
                        result = 'VULNERABLE'
                    else:
                        result = 'NOT-VULNERABLE'
                except Exception:
                    result = 'SECURE-CHANNEL-UNSUPPORTED'
            else:
                result = 'SECURE-CHANNEL-UNSUPPORTED'
        else:
            result = 'NON-EXISTENT'

Results

2612 restricted domain names were tested against the vulnerability (perhaps this is not the total number of valid domain names). There are 1592 domains that are not vulnerable and 252 that are (a total of 1844 domains with HTTPS support distributed on 985 different IPs, and 768 not applicable):



This is the detail of the results classified by each Third-level domain:

:arrow: gov.co, 602 not vulnerable (51.99%), 70 vulnerable (6.04%), 486 not applicable (41.97%).
:arrow: edu.co, 639 not vulnerable (68.34%), 104 vulnerable (11.12%), 192 not applicable (20.53%).
:arrow: mil.co, 17 not vulnerable (25.76%), 42 vulnerable (63.64%), 7 not applicable (10.61%).
:arrow: org.co, 334 not vulnerable (73.73%), 36 vulnerable (7.95%), 83 not applicable (18.32%).



Finally, we got the distribution of the vulnerable Colombian third-level domains:



Retest

One month later 252 domains have been tested against the vulnerability, the results are shown:

:arrow: 228 (90.48%) domains do not have the bug anymore.
:arrow: 5 (1.98%) domains turn off their HTTPS support.
:arrow: 6 (2.38%) domains do not have an A record associated on the DNS.
:arrow: 18 (7.14%) domains on 16 IPs are still vulnerable.

Comparison of vulnerable domains one month later:


Final overview of the OpenSSL security bug on Colombian third-level domain names:


Incident handling

:arrow: 08/04/2014 - Start of the security test.
:arrow: 09/04/2014 - colCERT was contacted to coordinate the incident handling and communicate the issue to the affected domains.
:arrow: 10/04/2014 - First contact with colCERT (list of 252 affected domain names was provided), they are taking now all necessary steps to solve the issue on the affected domains.
:arrow: 11/04/2014 - First contact with NIC.CO, they are working together with colCERT to solve the issue on all the affected domains.
:arrow: 08/05/2014 - Start of the security retest.
:arrow: 10/05/2014 - Final update.

Archivado en: Seguridad | Comentarios (1)