Los dominios colombianos (mil.co, gov.co, edu.co, org.co, com.co, net.co [+] nuevo) están preparados para el día del cambio mundial en los sistemas DNS que entrará a regir a partir del primero de febrero de 2019 y el cual es soportado por grandes servicios de DNS gratuitos como los ofrecidos por Google, Cisco OpenDNS, y CloudFlare.
Existe sin embargo una oportunidad de mejora en algunos de estos dominios, que según ciertas condiciones, podrán presentar problemas de servicios como interrupción en el acceso a sitios web y fallas en los sistemas de correo.
El análisis fue realizado sobre un total de 16.470 176.868 dominios colombianos, en donde 10.023 77.129 se encuentran configurados adecuadamente, 6.148 96.713 sin respuesta, y 299 3.026 no cumplen con las exigencias técnicas del estándar.
El siguiente listado contiene los dominios colombianos afectados por el cambio en los sistemas DNS:
Two-Channel Auto-Type obfuscation is a security mechanism from KeePass to protect auto-typed passwords from being captured by "standard" keyloggers. It uses clipboard and keyboard emulation as primary channels to transfer passwords to their final input:
This scheme is secure while none or just one channel is compromised. We are going to focus on clipboard protection, the following section from KeePass TCATO FAQ was removed after the bug was reported and rejected:
The old way
Clipboard protection is heavily based on the old clipboard viewer chain from Windows, the diagram shows the windows message flow in the viewer chain, the flow must be followed by all the applications that want to listen to clipboard changes. The operating system sends a message to the first window, then each window is required to pass the message to the next one until there is no window left:
Here comes into play the Clipboard Event Blocker from KeePass, it first calls SetClipboardViewer to add himself as the first window in the viewer chain, and then when the WM_DRAWCLIPBOARD message is received it blocks this message from being passed to the next window:
There are two ways to bypass this protection:
Add a window to the viewer chain after KeePass protection is executed
Use newer API functions to listen to clipboard changes
The new way
A clipboard listener was introduced in Windows Vista as a new way to listen to clipboard changes, developers are encouraged to use the system-mantained clipboard format listener instead of the old one. The operating system is now responsible for sending the message to each window, preventing the flow to be blocked by applications:
KeePassLogger
Using the new clipboard listener and a standard keylogger we can retrieve the content of both channels and reassemble the secret. The next video shows a proof of concept for the "specialized" keylogger:
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:
When the user sets a password, a new element called Property is added to the HardDisk element inside the machine configuration:
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:
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:
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.
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);
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:
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):
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.
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 }
Twenty two files are created, it is time to decompress them using python:
importbz2 importsys
for i inxrange(0,22): try: file = bz2.BZ2File(str(i), "r") printfile.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: