Uri from Int3pids won the challenge. Congratulations! Eloi, dreyer, earada, kachakil and roman_soft did a great job too, thanks to all the participants.

Now you can find online the solution of Crypto02

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Crypto04 challenge write-up from Campus Party Europe
• Breaking LFSR-based pseudo-random number generators
• Campus Party 2010 – Wargame Leftovers

Go, get them and have fun! First to solve both gets a $30 gift card for Amazon. All the info available at

http://vierito.es/cp2010wargame/

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Breaking LFSR-based pseudo-random number generators
• Crypto04 challenge write-up from Campus Party Europe
• Campus Party 2010 – Wargame Leftovers winner!

El Maligno me lió para dar una charla en el III Curso de Verano de Seguridad en Valencia. El curso ha estado genial, tanto las ponencias como la gente que acudió, sin duda una gran oportunidad para pasar un buen rato con conocidos y nuevas caras.

Mi charla la quise enfocar como una recopilación de fallos comunes (algunos de ellos famosos) cuando nos toca tratar con criptografía. Es un tema un poco denso así que para darle un toque más curioso y divertido en la parte final incluí puntos decisivos a la hora de implementar criptografía en dispositivos embebidos en los que, debido a factores como el side channel, tenemos que tener en cuenta todo tipo de nuevas medidas.

Gracias a Eloi y Bea por echarme una mano

Aquí os dejo la presentación de Historias de la cripta

Si tenéis dudas o preguntas podéis dejar comentarios aquí o usar twitter con el tag #cripta.

Keep hacking!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Cuando no se tiene cuidado con la criptografía…
• Conferencia sobre criptografía y reto
• Ganadores del reto de criptografía

Hey there! I usually write in spanish here but as the attendance at Campus Party Europe was pretty international I’ll do this one in english so anyone can understand it.

All the information to try the challenge is at Eloi’s blog since he released it as challenge a couple of days ago. Before continuing I guess you either have played in the hacking contest at Campus Party Europe or already have read that post, if not… you are being late!

So, we receive 3 files: an AES encrypted file, a  public key file and a readme with some instructions and data.

From the readme, this are some hints to understand what’s going on here:

• It uses a cryptographic device that contains a 1024 bit modular exponentiation accelerator
• A pair of RSA signatures over the same data, one of these signatures contains a fault injection

From those hints we get that it is actually using the RSA-CRT algorithm, which is a RSA variation to reduce computational costs using the Chinese Remainder Theorem. The point is that instead of using the 2048 bit modular exponentation it splits them into two modular operations, aproximately half the size, make the calculations and then recombine the results as needed to obtain the regular RSA result. But here’s the trick, if we inject a fault in one of these two exponentiations, via power glitching for example, there’s a way to recover the private RSA key. The use of RSA-CRT is common in embedded devices such as smart cards, mainly because of the hardware limitations. You can read a post about it at Eloi’s blog, it’s in spanish though: RSA-CRT Fault Injection.

RSA signs a message doing:

• s = m^d (mod n)

RSA-CRT does:

• s1 = m^dq (mod q)
• s2 = m^dp (mod p)
• s = a*s1 + b*s2  (mod n) = m^d (mod n)
• a being congruent to one modulo p and zero modulo q
• b being congruent to zero modulo p and one modulo q

Using the faulty signatures:

• s – s’ = a*s1 – a*s1′ will be congruent to zero modulo q
• s – s’ = b*s2 – b*s2′ will not be congruent to zero modulo p

Then if we calculate the greatest common divisor (using the Euclidean algorithm for example) between c-c’ and n ¡we will obtain the factor q! because c-c’ is multiple of q but not p. Then with p = n / q we will have both prime factors used in RSA

Now we have to implement the attack, we need to deal with really big integers so I first though of using Java and its BigInteger, Matlab or Sage. I do hate Java, Matlab would have been nice, usually it treats big integers as arrays and uses proper algorithms adapted to array calculations but Sage was going to be the easiest and quickest for me.

We have s1, s2 and the encrypted message. First we need to obtain the exponent and the modulus from the public.key file, let’s use openssl:

$ openssl rsa -pubin -text -in public.key
Modulus (2048 bit):
00:e8:52:42:77:0a:66:69:8c:64:49:61:5a:d4:8f:
70:e5:ff:7f:49:ca:45:33:43:7d:85:36:7e:1a:f3:
8f:31:aa:35:94:8e:b3:3f:97:88:f7:16:4a:1d:d5:
c3:87:5b:f8:6b:69:3b:d8:cc:82:e2:cb:cb:d0:1c:
f7:d1:b4:51:ef:67:cb:72:90:fa:79:0e:e1:02:24:
e3:72:5b:37:b6:bc:3d:53:56:da:9d:0f:ba:c1:e0:
6b:b2:6f:f2:43:03:d9:06:d3:c9:66:c8:1b:19:9a:
78:b9:ef:02:2b:0f:b9:28:e5:82:fc:0c:e0:29:57:
f6:b1:64:21:01:f9:2e:83:4a:ab:47:24:9e:e4:08:
c2:91:d3:fc:e8:72:c1:44:69:12:31:37:f4:da:49:
28:00:75:03:36:47:20:69:f4:e2:4b:4a:0e:3e:e5:
15:85:ae:78:68:43:a3:c0:39:61:c2:12:a1:e3:94:
d2:71:e8:26:14:c4:e7:aa:1d:5d:a4:16:01:1f:9b:
40:81:a8:e4:70:65:75:1a:de:de:51:d0:90:97:fb:
8a:41:ac:be:2e:54:5c:b6:d4:04:40:1d:59:16:c3:
f6:86:16:e9:66:79:b3:5f:77:74:a9:e4:42:b1:98:
74:14:b0:22:ee:06:f0:0f:ac:3d:dd:b6:14:19:43:
e5:53
Exponent: 65537 (0x10001)
writing RSA key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6FJCdwpmaYxkSWFa1I9w
5f9/ScpFM0N9hTZ+GvOPMao1lI6zP5eI9xZKHdXDh1v4a2k72MyC4svL0Bz30bRR
72fLcpD6eQ7hAiTjcls3trw9U1banQ+6weBrsm/yQwPZBtPJZsgbGZp4ue8CKw+5
KOWC/AzgKVf2sWQhAfkug0qrRySe5AjCkdP86HLBRGkSMTf02kkoAHUDNkcgafTi
S0oOPuUVha54aEOjwDlhwhKh45TScegmFMTnqh1dpBYBH5tAgajkcGV1Gt7eUdCQ
l/uKQay+LlRcttQEQB1ZFsP2hhbpZnmzX3d0qeRCsZh0FLAi7gbwD6w93bYUGUPl
UwIDAQAB
-----END PUBLIC KEY-----

To copy the modulus it’s easier from here:

$ openssl rsa -pubin -modulus -in public.key
Modulus=E85242770A66698C6449615AD48F70E5FF7F49CA4533437D85367E1AF38F31AA35948EB33F9788F7164A1DD5C3875BF86B693BD8CC82E2CBCBD01CF7D1B451EF67CB7290FA790EE10224E3725B37B6BC3D5356DA9D0FBAC1E06BB26FF24303D906D3C966C81B199A78B9EF022B0FB928E582FC0CE02957F6B1642101F92E834AAB47249EE408C291D3FCE872C14469123137F4DA492800750336472069F4E24B4A0E3EE51585AE786843A3C03961C212A1E394D271E82614C4E7AA1D5DA416011F9B4081A8E47065751ADEDE51D09097FB8A41ACBE2E545CB6D404401D5916C3F68616E96679B35F7774A9E442B1987414B022EE06F00FAC3DDDB6141943E553
writing RSA key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6FJCdwpmaYxkSWFa1I9w
5f9/ScpFM0N9hTZ+GvOPMao1lI6zP5eI9xZKHdXDh1v4a2k72MyC4svL0Bz30bRR
72fLcpD6eQ7hAiTjcls3trw9U1banQ+6weBrsm/yQwPZBtPJZsgbGZp4ue8CKw+5
KOWC/AzgKVf2sWQhAfkug0qrRySe5AjCkdP86HLBRGkSMTf02kkoAHUDNkcgafTi
S0oOPuUVha54aEOjwDlhwhKh45TScegmFMTnqh1dpBYBH5tAgajkcGV1Gt7eUdCQ
l/uKQay+LlRcttQEQB1ZFsP2hhbpZnmzX3d0qeRCsZh0FLAi7gbwD6w93bYUGUPl
UwIDAQAB
-----END PUBLIC KEY-----

Now we have the modulus and exponent. So let’s start Sage and apply what we’ve seen before

Load the values:

sage: s1 = 0x3ae81964c8ecf1524b47c42cb0ecd2a3b6768dccd55960d7ff0a998f839b8c312a2cd821c270ae961777dd4dd50aa631fe823a8afd914911adf69c1c6cfda3b3aed01dad372cfdd6e9f63a4cc39e1a455cbfd04dea72bf07c4790d5fec469198ce28113d6d38a7baced9d3c3695ab27cbc5ab434aa8d2b5f53f66a383e079ddaed485d4a2b446e410eafcadbba9f159494c28c4a19fd416dff90f8c141e96d8260f8e6e0901832e31899c48ce0cbdae6a24595a19a01e490c87e7b48860e09006920d8ef7384217358c6db90638d6e8cbc795a091240f24105d8f3b27fe4b98fe9a507e00590b4cded41777b1b8967b0f752231e0e856b8f0132bde30a6e082e
sage: s2 = 0x391e0340e5931a202012572ddacad877e5af3a1d846b70c1e64e3041f9ac0a3c7e8f82621df908eadca44fe777a6b1c799610be829e13ca233982fd268034addb5a79fa19f984631fdf3a61d32fc75ed77176c7a0b719504e804076dca66f10111aa124a7efe743ada75dda2ec53f3c28882a7724928685918261739f960a3648aa3eadc426181aa146a8ba0ff20f1c53de2113e0196af09595dc2ad1a0fe12096ff681f61363044615a7f72edf1f8c6531055e66c1e5f4498434c731d2308fecae46c779379ea3d7d7a5f1c2a0efeb5bc1b8a4af4fb21fce1dae943c27043e86642b3b1e6b889a31e7c4bc01bc2ebae4dc8432344532567d1d3df8b9bcafcbf
sage: encrypted = 0x19303a82cbc50a56dc22f9aafc554da2ea632e33bee1d33c35edb13269ba0fd2fa791744e86eda7fc1cb15433f1232f86a42afcd5470215ccf0d05096ce1b8f075e6dc45df74896345297fcc145a4765aeaea78babaa6441ead3a2e73b37931dc7c07d4e04b7115284c7c04c85a61c7e555194d0f4ee762d47a8aeec2efcd75ee45e3e6a65f876f9a67aa01016f3ce9552d8f0b50cc150c70333aa6ac3a4ac8860d2879cad8439566f0ffda32612cb75dd9c1b456a4e1828582f05932f495452f19d71f300f2f48b8c1f8cde1b1b8d8ada3f6ff506e10d5d18d91d61402bc36756a88196381ff795980eee932a179525264e3a968f0abe9edbe672560c41833a
sage: exponent = 0x10001
sage: modulus = 0xe85242770a66698c6449615ad48f70e5ff7f49ca4533437d85367e1af38f31aa35948eb33f9788f7164a1dd5c3875bf86b693bd8cc82e2cbcbd01cf7d1b451ef67cb7290fa790ee10224e3725b37b6bc3d5356da9d0fbac1e06bb26ff24303d906d3c966c81b199a78b9ef022b0fb928e582fc0ce02957f6b1642101f92e834aab47249ee408c291d3fce872c14469123137f4da492800750336472069f4e24b4a0e3ee51585ae786843a3c03961c212a1e394d271e82614c4e7aa1d5da416011f9b4081a8e47065751adede51d09097fb8a41acbe2e545cb6d404401d5916c3f68616e96679b35f7774a9e442b1987414b022ee06f00fac3dddb6141943e553

Calculate q and p:

sage: q = gcd(s1-s2,modulus)
sage: p = modulus / q

In Sage to work with modular arithmetics you need to declare a group and then use the variables in that group. First let’s calculate the private RSA key

sage: G1 = IntegerModRing(lcm(q-1,p-1))
sage: private_key = G1(exponent)^-1

And finally working in modulo ‘modulus’ make the decryption to get the message:

sage: G2 = IntegerModRing(modulus)
sage: message = G2(encrypted)^G2(private_key)
sage: message
333277202522695828352578908493424296965
sage: hex(333277202522695828352578908493424296965)
'fabadababecafedeadbeef0102030405'

It’s a fabada password! xD We now have the plaintext which is the AES key. Let’s use again openssl to decipher the file. The readme file says it’s AES in ECB mode with a 128 bit key. The key length it’s obvious but if we didn’t know the operation mode we could just try them all.

$ openssl enc -d -aes-128-ecb -in encrypted.aes -out unencrypted.file -K fabadababecafedeadbeef0102030405
$ file unencrypted.file
unencrypted.file: PNG image, 124 x 124, 8-bit/color RGB, non-interlaced

We can see that it worked like a charm: the file it’s a PNG image. The first thing you think when you see a PNG it’s uhmm… a bit of stego? thumbnails? LSB? Well, this one is just a QR Code.

Using any QR decoder (I used http://zxing.org/w/decode.jspx ) we get:

Key: DoubleCheckYourCryptoResults

Which is a funny final password since one of the common protections against fault injection attacks is to double-check all sensitive computations

Congratulations to Eloi for this challenge! I found it one of best I’ve ever done because it has to do with real world attacks and crypto related maths, so it’s not just another cryptic puzzle where mostly you only have to use tools or need a smart guess.

I hope you liked it!

Many thanks also to SecurityByDefault for an excelent wargame and congratulations to the winners:

1. knx
2. FluxReiners
3. aw3a

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Breaking LFSR-based pseudo-random number generators
• Crackeador de hashes MD5 en C y OpenSSL
• 25C3: Nothing to Hide

He cogido el script para generar los tonos del otro post y lo he cambiado para los pitidos duren 40ms (que se resume a cambiar que use 320 muestras en lugar de 1200 para cada pitido o silencio), para que sea un poco más real. El wav que voy a usar será el siguiente: ring.wav

Empezamos, ¿qué necesitamos? Cada pitido estará compuesto por una pareja de tonos así que para saber qué número es deberemos reconocer las dos frecuencias principales que tienen los pitidos, y conocer la frecuencia viene a ser lo mismo que saber el periodo.

Hace un tiempo hice una práctica de Tratamiento Digital de la Señal en la que se hacían cosas de estas, uno de los códigos no es mío, está indicado. El resto los hicimos Rafa y yo en su día.

Aprovechándonos de la Transformada de Fourier:

function [P,f]=periodograma(x,N)
% [P f]=periodograma(x,N)
% Calcula N muestras del periodograma de las muestras en x
% N debe ser > que length(x)
%
% P: Periodograma propiamente
% f frecuencias correspondientes
 
k=0:N-1;
f=k./N;
 
L=length(x);
P=1/L*(fft(x,N)).^2;

Pero lo propio será usar un programa que use ventanas para su propósito:

function [P,f]=periodmodif(x,ventana,N)
% [P ,f]=periodmodif(x,ventana,N)
%
% Calcula N muestras del periodograma modificado de las muestras en x
% N debe ser > que length(x)
%
% P: Periodograma propiamente
% f frecuencias correspondientes
 
if N <= length(x)
   error('N debe ser > que length(x)');
else
   k=0:N-1;
   f=k./N;
 
   L=length(x);
   m=0:L-1;
 
   U=1/L*(sum(ventana(m+1).^2));
   P=1/(L*U)*abs(fft(x.*ventana,N)).^2;
end

Cargamos el fichero ring.wav

>> [x,fs,nbits]= wavread('ring.wav')
>> t=0:1/fs:1/fs*(length(x)-1);
>> plot(x)

Ahora tendremos que calcular de cuanto es nuestra ventana mínima. La separación mínima entre tonos es de 320 muestras (que además en este caso es la misma entre todos los tonos) luego la frecuencia digital será 320 / fs = 320/8000 = 0.04

Y aquí un poco de teoría sobre ventanas gracias a los Apuntes de Pak:

Pero no voy a aburriros con ella así que nos quedaremos en que vamos a usar una ventana tipo Hamming, luego necesitaremos una longitud de ventana L = 4 / resolución = 4 / 0.04 = 100 muestras

Ahora vamos a determinar los dígitos, y para ello vamos a hacer uso de la siguiente función para búscar máximos:

function p=buscapicosu(x,umbral)
%posi_picos=buscapicosu(x,umbral)
% Busca los máximos locales de un vector mayores que un cierto umbral
% umbral se expresa en % respecto al valor máximo del vector.
% Ej. buscapicos(x,60) buscaria los picos mayores o iguales al 60% del
% pico más alto
%
% posi_picos son los indices del vector de entrada correspondientes a los picos.
 
% (C) Antonio Albiol , 2003
 
%Primero descarto los valores menores que el umbral
 
umbral=max(x(:))*umbral/100;
 
x=x.*(x>umbral);
 
%Ahora buscaré los máximos
 
%Primero creo un vector con dos valores muy pequeños en los extremos
xe=[-inf;x(:);-inf];
 
%Ahora calculo la derivada
d1=diff(xe);
ld1=length(d1);
%Ahora busco valores de la derivada de signo diferente consecutivos y que sean máximos
p=find(sign(d1(2:ld1)).*sign(d1(1:(ld1-1)))<0 & sign(d1(1:ld1-1))>0);

Cada pitido y cada silencio dura 320 muestras luego calculamos periodos en esas zonas. Vamos a por el primer dígito, con ventana Hamming de 100 y usando 1024 puntos:

>> [P,f]=periodmodif(x(320:320+99),hamming(100),1024);
>> buscapicosu(abs(P),50)
 
ans =
 
   110
   190
   836
   916

En el espectro digital, de 0 a 1, veremos que las frecuencias se repiten en espejo a partir de 0.5. Luego la frecuencia 110 se corresponde con la 916, igualmente ocurre entre la de 190 y 836, son lo mismo. Así que sólo tenemos que ver a qué corresponden 110 y 190.

Nota a tener en cuenta: en las FFTs (Fast Fourier Transforms) el cálculo se hace mucho más rapido cuando N es una potencia de 2, por eso la elección de hacerlo en 1024 puntos no ha sido del todo al azar.

>> 110/1024*fs
 
ans =
 
  859.3750
 
>> 190/1024*fs
 
ans =
 
  1.4844e+003

Nos vamos a la tablita y vemos con qué 2 valores más cercanos concuerdan 859.375 y 1484.4 Hz. Claramente sería con 852 y 1477 Hz que juntos corresponden con el dígito 9.

Y así con cada uno de los dígitos

Sé que estaría mucho mejor un script que hiciera todo el proceso entero y obtuviera qué número es de la tabla pero últimamente necesito días de 30 horas así os tendréis que conformar con esto. ¿A qué número he llamado?

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Llamando por teléfono con Matlab
• Cuestión de optimización

Port-Knocking

Cuando nosotros tenemos un servicio en un servidor, éste, escucha en uno o varios puertos las peticiones externas. Este puerto deberá estar abierto en el firewall para que se puedan efectuar estas conexiones. La idea del Port Knocking es que el puerto del servicio permanece cerrado y sólo se abrirá bajo una petición externa basada en un paquete o grupo de paquetes específicos, previamente conocidos por el cliente, que serán enviados al servidor. Es decir, yo tendría mi servidor ssh con el puerto 22 cerrado y cuando un cliente envíe un paquete con ciertas características a otro puerto entonces el puerto 22 se abriría temporalmente para ese cliente. De este modo permanecería escondido antes escaneos de puertos e intentos automatizados de fuerza bruta, por ejemplo. Este sistema se podría ir mejorando:

• que tenga que ser una secuencia de puertos y no uno sólo
• que además tengan que ser unos puertos de origen específicos
• combinarlo con otras herramientas: Portsentry, denyhost, fail2ban (destaco la primera herramienta  ya que es una forma fácil de banear intentos de escaneos sin el uso de un IDS completo ni cortafuegos)
• jugar con las FLAGs TCP y opciones poco comunes de los paquetes
• abrir el puerto sólo para la IP llamante, no todas
• <paranoic>requerir una temporización determinada (algo elástica, claro está) entre en el envío de los paquetes</paranoic>
• y mil cosas que se nos puedan ocurrir

Para estos menesteres existen varias herramientas pero todo suelen terminar siendo scripts que escuchan los puertos y van cambiando reglas del cortafuegos y los servicios. Pero no todo es bonito e ideal, imaginad que no tienes una puerta trasera, ¿qué ocurre si cae el servicio encargado de escuchar el portknocking? Te quedas tú sin poder acceder. Deberías dejarte una IP blanca por ejemplo, que siempre tuviera acceso al puerto sin mayor barrera. O tener otro servicio que compruebe si el primer servicio está online y haga de watchdog xD.

Pero ¿cuál es la debilidad clave un sistema así? Replay Attack. Me explico, si mi máquina está en una subred y otra máquina de esa subred ha sido comprometida, ésta podría estar usando un sniffer (tcpdump, wireshark) y capturar la secuencia usada para la apertura de puertos. Y aquí es donde entra lo que he venido a contar.

Crypt-Port-Knocking

Vamos a cortar por lo sano esa debilidad: Single Packet Authentication. Esta manera de proceder difiere en que vamos a llamar a un puerto aleatorio cada vez y la conexión con el servicio también se hará en un puerto aleatorio cada vez pero lo que es más importante añadiremos información cifrada en el paquete gracias a OpenSSL con lo que se quiera hacer (en este caso usando 256-bit AES-cbc, se podría mejorar para ultraparanoicos™  usando un cifrado asimétrico con GPG, por ejemplo). Podríamos pensar que para evitar ataques replay en la información cifrada se podría incluir datos variantes en el tiempo, cambios preacordados de la clave de cifrado, usar iteraciones en una función de hashing pero se complica el tema cuando hay muchos usuarios. Para ello, es mejor opción aprovechar que podemos tener 16bytes de datos aleatorios en el paquete que luego podemos identificar gracias a un hash del mismo e ignorar todos los paquetes duplicados. Para crear los paquetes a medida podremos usar hping.

Para hacer uso de las características del Single Packet Authentication el autor del post, BoneKracker, ha creado una serie de scripts en bash, formados por un cliente y un servidor de una forma bastante clara y transparente. Echadle un vistazo que ahí está todo el código y con una explicación más extensa.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Para los amantes de XKCD llega…
• Cuestión de optimización
• Crackeador de hashes MD5 en C y OpenSSL

Primero de todo vamos a hacer un programa que nos permita calcular el hash md5 de un string que se le pase y luego ya pasaremos al crackeador.

Sería más fácil hacer un script en bash o perl gracias a la utilidad CLI de OpenSSL, a la hora de calcular un solo hash no importa mucho la velocidad pero si luego queremos hacer un pequeño crackeador no podemos partir de algo que ya sabemos que va a ser mucho más lento. Así que lo que vamos a usar es C y la librería de OpenSSL.

Si no sabemos por donde empezar un extracto del man:

$ man md5
...
SYNOPSIS
 
#include <openssl/md2.h>
 
        unsigned char *MD5(const unsigned char *d, unsigned long n,
                         unsigned char *md);
 
        int MD5_Init(MD5_CTX *c);
        int MD5_Update(MD5_CTX *c, const void *data,
                         unsigned long len);
        int MD5_Final(unsigned char *md, MD5_CTX *c);
...
DESCRIPTION
...
Applications should use the higher level functions EVP_DigestInit(3) etc. instead of calling the hash functions directly.
...

Vemos que podríamos añadir esa librería y usar las funciones MD5_Init(), MD5_Update y MD5_Final pero ya nos avisan que deberíamos usar unas funciones de más alto nivel así que: EVP_DigestInit

$ man EVP_DigestInit
...
SYNOPSIS
        #include <openssl/evp.h>
 
        void EVP_MD_CTX_init(EVP_MD_CTX *ctx);
        EVP_MD_CTX *EVP_MD_CTX_create(void);
 
        int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
        int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *d, size_t cnt);
        int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md,
               unsigned int *s);

De paso, aprovecho para desaconsejar el uso de MD5 a día de hoy y como mínimo usar SHA1 o incluso dejarte de monsergas y pasar a SHA256, SHA512.

He intentado que el programa sea bastante fácil de entender y seguir, ahí va:

#include <stdio.h>
#include <string.h>
 
#include <openssl/evp.h>
 
#ifdef DEBUG
#define DBG 1
#else
#define DBG 0
#endif
 
#define MAX_SIZE_WORD 200
 
unsigned char *simple_digest(char *algth, char *buffer, unsigned int len, int *olen){
 
	EVP_MD *m;
	EVP_MD_CTX ctx;
	unsigned char *ret;
 
	OpenSSL_add_all_digests ();
	if (!(m = (EVP_MD*) EVP_get_digestbyname(algth)))
		return NULL;
 
	if (!(ret = (unsigned char *) malloc(EVP_MAX_MD_SIZE)))
		return NULL;
 
	EVP_DigestInit(&ctx, m);
	EVP_DigestUpdate(&ctx, buffer, len);
	EVP_DigestFinal(&ctx, ret, olen);
 
	return ret;
}
 
void hex_print(unsigned char *buff,int len){
	int i;
	for(i=0;i<len;i++)
		printf("%02x",(unsigned char)(buff[i]&0xFF));	
}
 
int main(int argc, char **argv){
 
	unsigned char buff[MAX_SIZE_WORD];
	int olen;
	char *out;
 
	if(!argv[1]) {
	        printf("Usage: mymd5 word\n");
        	exit(1);
	}
 
	// copy arg string into a buffer
	if (strlen(argv[1]) < MAX_SIZE_WORD ){
 
		strncpy(buff, argv[1], strlen(argv[1]));
 
		// calculate string's md5 hash
		out = simple_digest("md5",buff,strlen(argv[1]),&olen);
 
		// print results	
		if (DBG){
			printf("Word: %s\n",argv[1]);
			printf("Hash: ");
		}
		hex_print(out,olen);
		printf("\n");
 
		return 0;
	}
 
	printf("\nNot computing hash\n");
	printf("\nI can feel your dark side... ;)\n");
 
	return -1;
}

Compilamos y probamos:

$ gcc mymd5.c -o mymd5 -l ssl
$ ./mymd5 passworddeelite
5b4f50aa173b977e4cd0850cf7c52bd0

Podemos comprobar su correcto funcionamiento comparando con webs online que ofrecen utilidades para calcular hashes MD5 [1], [2].

Y ahora a por el crackeador. No vamos a intentar buscar colisiones sino a partir de un diccionario sacar la clave. Le pasaremos como parámetros un fichero con el hash y un diccionario con una palabra por línea.

#include <stdio.h>
#include <string.h>
 
#include <openssl/evp.h>
 
#ifdef DEBUG
#define DBG 1
#else
#define DBG 0
#endif
 
#define MAX_SIZE_BUFF 200
 
unsigned char *simple_digest(char *algth, char *buffer, unsigned int len, int *olen){
 
	EVP_MD *m;
	EVP_MD_CTX ctx;
	unsigned char *ret;
 
	OpenSSL_add_all_digests ();
	if (!(m = (EVP_MD*) EVP_get_digestbyname(algth)))
		return NULL;
 
	if (!(ret = (unsigned char *) malloc(EVP_MAX_MD_SIZE)))
		return NULL;
 
	EVP_DigestInit(&ctx, m);
	EVP_DigestUpdate(&ctx, buffer, len);
	EVP_DigestFinal(&ctx, ret, olen);
 
	return ret;
}
 
void hex_print(unsigned char *buff,int len){
	int i;
	for(i=0;i<len;i++)
		printf("%02x",(unsigned char)(buff[i]&0xFF));	
}
 
void strtohex(unsigned char *in, unsigned char *out,int len){
	int i;
	char tmp[3];
	tmp[2]=0;
	for(i=0;i<len/2;i++){
		tmp[0]=in[2*i];
		tmp[1]=in[2*i+1];
		out[i]=strtol(tmp,NULL,16);
	}
}
 
int main(int argc, char **argv){
 
	int tries=0;
	unsigned char buff_words[MAX_SIZE_BUFF];
	unsigned char hash[16];
	unsigned char *line=NULL;
	int len=100,read;
	int olen;
	char *out;
 
	if(argc<3) {
	        printf("Usage: mymd5crack /path/to/hashfile /path/to/dictfile\n");
        	exit(1);
	}
 
	FILE *hashfile;
	hashfile = fopen(argv[1],"r");
	if(!hashfile){
		perror(argv[1]);
	return -1;
	}
 
 
	FILE *dictfile;
	dictfile = fopen(argv[2],"r");
	if(!dictfile){
		perror(argv[2]);
	return -1;
	}
 
	read = getline(&line, &len, hashfile);
	if(strlen(line)!=33){
		fprintf(stderr,"ERROR: Invalid hash length %d\n",strlen(line));
		return -1;
	}	
 
	strtohex(line,hash,32);
 
	if(DBG){
			printf("Input hash: %s\n", line);
			printf("Input buffer from hash: ");
			hex_print(hash,16);
			printf("\n\n");
	}
 
	//Read words in a loop
	while((read = getline(&line, &len, dictfile)) != -1){
		if( strlen(line) < 200){
			tries++;	
 
			//Copy word into buffer
			strcpy(buff_words,line);
 
			if(DBG)
				printf("Input buffer from dict: %s \n",buff_words);
			// compute md5
			out = simple_digest("md5",buff_words,strlen(line)-1,&olen);
 
			if(DBG){	
				printf("For password %s MD5 is: ",line);
				hex_print(out,olen);
				printf("\n\n");	
			}
 
			//Compare computed md5 with hash
			if(memcmp(out,hash,16) == 0){
 
				printf("PASSWORD FOUND!! in %d tries: %s\n",tries,line);
 
				fclose(hashfile);
				fclose(dictfile);
				free(out);
				if(line)
					free(line);
 
				return 0;	
			}
			free(out);
		}else{
			printf("\nWords from dict too long... cough*, cough*...\n");
		}
	}
 
	printf("Password not found in %d tries!\n",tries);
 
	if(line)
		free(line);
 
	fclose(hashfile);
	fclose(dictfile);
 
	return 0;
}

Y comprobamos su funcionamiento metiendo en /tmp/hash el hash obtenido anteriormente:

$ gcc mymd5cracker.c -o mymd5cracker -l ssl
$ ./mymd5cracker /tmp/hash /tmp/dict
PASSWORD FOUND!! in 6 tries: passworddeelite

Premio! Podéis ir en paz.

Para descargar mymd5.c y mymd5cracker.c

Gracias a TuXeD que siempre está ahí para echar una mano.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Descifrando un reto del FBI
• Soluciones del reto de criptografía – Parte 2
• Port-Knocking y Crypt-Port-Knocking

A día de hoy contamos con ordenadores chorrecientas veces más rápidos que hace pocos años y cuando se programa haces pruebas con sistemas de 3GHz, varios MB de cache y 2GB de RAM mínimo y todo tira para adelante. Bueno, todo tira hasta cierto punto, tus programas luego se van a estar ejecutando juntos con otras decenas de programas o simplemente se van a estar ejecutando constantemente y vas a perder un gran porcentaje de la capacidad de proceso de cómo lo podrías estar haciendo.

Bueno, y es normal, cosas de la comodidad, yo el primero. Ahora te quedas tranquilo con que funcione, en los 80 tenía que funcionar y caber en 64kB de RAM. No digo que se programe peor (seguramente sí xD) pero ya no nos fijamos en muchos detalles que antes eran totalmente necesarios (la de trucos que usaba la gente para poder aprovechar el 100% del hardware del Commodore64) y ahora desperdiciamos por todos lados y al final sí que pasa factura. La gente que programe sistemas embebidos lo tiene muy claro aunque casi se va a acabar el asunto también ahí porque ya los procesadores de los móviles/PDAs/cosas_pequeñas tirán mucho.

Me he encontrado con programas que están al 100% de CPU en idle, con programas que daban su salida en unos 12~15 minutos cuando otro para el mismo propósito lo hacía en aproximadamente 1 segundo (no daré nombres xD), programas en los que notas el ‘refresco’ de los elementos cuando lo usas cuando te sobra CPU para hacerlo bien, etc. Hay que intentar evitar marañas de bucles for anidados!

Al final todo pasa por conocer muy bien el lenguaje que usas, haber pasado horas y horas, pensar las cosas antes de hacerlas, incluso un poquito de sentido común, cosa que creo que es difícil de abstraer a veces cuando se programa.

Por ejemplo, en matlab es muy importante reservar el espacio para las variables antes y crear los vectores del tamaño que van a ser al final de las operaciones porque si aumentamos el tamaño de un vector[n], internamente lo que siempre hace es crear un nuevo vector[n+1] y copiar los datos del antiguo.

Hace unos meses me comentó un amigo que en el trabajo tenían un método númerico que disminuyó su tiempo de ejecución en más de un 20% (siendo su tiempo varias horas) al sustituir un resultado de una operación que siempre era el mismo por el valor guardado en una variable! Es de cajón pero hay que caer.

Y ahora vienen algunos ejemplos, por no meterme en un lenguaje tipo C en el que hay muchas posibilidades de hacer las cosas y hay que currarse más los ejemplo iré a algo más sencillo como es hacer scripts cerdos para administrar un máquinas o similares.

Un ejemplo sería un uso poco adecuado de las órdenes cat, grep, ls, awk y similares. Cuando manipulamos algo pequeño no pasa nada pero cuando se trata de varios ficheros logs y son decenas de MB pues la cosa empieza a tomar importancia.

Respecto a grep cuando una persona empieza y se plantea buscar una cadena lo primero que piensa es ‘muestro el archivo y luego saco las líneas coincidentes’:

# cat tinyproxy.log | grep remote
real    0m55.071s
user    0m24.477s
sys     0m0.727s

Luego descubres que en realidad lo puedes hacer ‘todo en uno’ y es bastantes más rápido:

# grep remote tinyproxy.log
real    0m36.024s
user    0m22.550s
sys     0m0.527s

Luego, sin querer, entras en el man y te das cuenta de que existen varios tipos: grep, egrep (similar pero no idéntico a grep -E ) y  fgrep (idéntico a grep -F). Así que pruebas:

# egrep remote tinyproxy.log
real    0m55.122s
user    0m25.029s
sys     0m0.659s

Joder, vuelve a ser lento a pesar de no hacer un cat. ¿Por qué? Porque es una función más compleja.

• grep: soporta expresiones regulares básicas.
• fgrep: no soporta expresiones regulares => el más rápido.
• egrep: soporta expresiones regulares avanzadas => el más lento.

Para los curiosos, el nombre grep viene de g/re/p y significa lo que hace tal cual, buscar una expresión regular y hacer print de las coincidencias. En realidad a una escala grande ni siquiera deberíamos usar grep sino sed que es más rápido.

Lo mucha gente desconoce es que hay otra manera de evitar el cat de antes y ganar tiempo, y es que en realidad las concatenaciones siempre están ahí… así que lo podríamos hacer del siguiente modo:

# <tinyproxy.log grep remote
real    0m43.931s
user    0m22.338s
sys     0m0.578s

Del mismo modo estos conceptos se puede usar en otras órdenes

# cat tinyproxy.log | wc -l
104265

real    0m0.088s
user    0m0.021s
sys     0m0.053s

# wc -l tinyproxy.log
104265 tinyproxy.log

real    0m0.021s
user    0m0.013s
sys     0m0.006s

Y del mismo modo:

# cat tinyproxy.log | tail -n 200
real    0m0.121s
user    0m0.026s
sys     0m0.056s

# tail -n 200 tinyproxy.log
real    0m0.010s
user    0m0.000s
sys     0m0.003s

Cambiando de tercio también solemos usar echo más veces de las que toca. Por ejemplo si tenemos :

var="valor_o_resultado_de_una_evaluacion"
command -options `echo $var`

en la mayoría de los casos podremos sustituirlo por:

var="valor_o_resultado_de_una_evaluacion"
command -options $var

Y así mil chorradas. Por cierto, el que sólo se conozca la opción de awk para coger columnas le recomiendo que se mire manules que termina siendo muy útil.

Creo que este post lleva más de 6 meses en drafts y no he añadido nada (de hecho tampoco tengo ganas), así que aunque es un tema que da mucho de sí ha quedado bastante descafeinado técnicamente, pero ajo y agua!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Descodificar tonos DTMF usando Matlab
• Port-Knocking y Crypt-Port-Knocking
• Para los amantes de XKCD llega…

¿Qué son las CFLAGS/CXXFLAGS?

Son unas variables de entorno o unas variables en un Makefile que se le pasan al compilador para que compile el software aplicando un serie de optimizaciones. Herramientas como autoconf las cogerían del entorno para añadirlas a la sentencia que se usa al compilar. Las CFLAGS se usarían en C, y las CXXFLAGS en C++.

Según usemos un set distinto de CFLAGS los binarios de salida que nos dé el compilador podrán ser distintos partiendo de un mismo código fuente. Gracias a ellas podremos adecuar o intentar mejorar características de los binarios, ya sea para que sean más pequeños, más rápidos en ciertas arquitecturas u otras opciones. Para ello se podrán usar instrucciones específicas disponibles un procesador, podremos especificar por ejemplo que se “desenrrollen” bucles, etc.

Un ejemplo del primer caso sería usar instrucciones SSE3 disponibles en procesadores actuales pero no disponibles en un Pentium IV de primera generación. Para ello le pasaremos -msse3

Un ejemplo del segundo caso sería, yo tengo un bucle que se ejecuta 1000 veces. Cogeríamos y, en ensamblador, tenemos un registro que se va decrementando, comprueba si lo ha hecho 1000 veces y si no, hace un salto para ejecutar el bucle de nuevo. Pues vamos a cambiar eso por “pegar” consecutivamente el código de dentro del bucle 1000 veces. Con eso nos ahorramos recodificaciones de punteros y cosas similares pero tendremos como inconvenientes que el binario será más grande. ¿Qué se ejecuta más rápido? ¿El código optimizado por no hacer esas recodificaciones o el código inicial porque se tarda menos en cargarlo al ser más pequeño? Eterna pregunta… pues depende, a veces uno, a veces el otro.

Por comodidad, para que no tener que pasarle 8 lineas de optimizaciones, de las cuales más de una no sabremos lo que hace y que algunas implican o excluyen otras, existen sets de optimizaciones: -O, -O1, -O2, -O3, -Os, etc. Eso es la letro “o” mayúscula seguida de un número, más allá del 3 no existe, se usaría -O3.

Por otro lado, a las arquitecturas existentes se les pone un nombre, para que cuando digamos qué arquitectura tiene nuestra máquina el compilador le aplique automáticamente lo que toca: -march=athlon64, -march=pentium2, -march=pentium4, -march=prescott, -march=core2, … Esta opción dependerá mucho de la versión de GCC que tengamos instalada, ya que dependiendo de lo nueva que sea tendrá soporte para nuevas arquitecturas o no, e incluso para una misma arquitectura dependiendo de si instalas un sistema de 32 o 64bits el nombre cambiará. Además está opción está íntimamente ligada con la variable CHOST que será del estilo: i586-pc-linux-gnu, i686-pc-linux-gnu, x86_64-pc-linux-gnu, etc.

La mayoría de las distribuciones que se usan son precompiladas, Debian/Ubuntu, RedHat, Mandriva, … y esto no es algo de lo que preocuparse pero esto cobra especialmente sentido en distros como Gentoo y LFS donde todo el código es compilado desde cero con las optimizaciones y opciones que se quieran, ajustadas al tipo de máquina que va a ejecutar el código.

Pero ya se sabe, la gente funciona del modo “a ver quien la tiene más larga”. Cuando Gentoo empezó a ganar terreno y adeptos con la versión 1.4  y la 2004 la gente se cascaba unas pedazos de CFLAGS que no tenían ni pies ni cabeza, ¡cuantas más le pase más guay!, ¡más rápido irá! ¡más todo! Estilo pajillero, el foro estaba lleno de hilos de discusión sobre las CFLAGS y que no sé quien se había puesto tales y podía viajar atrás en el tiempo con ellas. En realidad lo único que se consigue es tener como salida un código inestable, que puede funcionar mal y más lento. Por ejemplo, la opción -ffast-math además de no cumplir con el estándar hace que las raices negativas no existan en lugar de devolver números complejos. ¿y si compilamos octave/algo_tipo_matlab con -ffast-math? => fiesta del confeti.

Generalmente se recomienda usar -O2 -pipe -fomit-frame-pointer y poco más. La opción -O3 se considera un poco insegura que ya de uvas a peras puede dar problemas. La opción -pipe en realidad no cambia el código de salida, sólo provoca que el compilador use tuberías entre las distintas etapas de una compilación en lugar de usar ficheros temporales, esto aumenta la velocidad de compilación pero puede provocar que en algunos sistemas donde el código ensamblador no pueda recibir de una tubería falle, algo poco común en realidad. La opción -fomit-frame-pointer reduce el tamaño del código bastante pero provoca que la depuración de código sea infinitamente más complicada, además, para gran parte de las arquitecturas, viene activada en el set -O2 así que no necesitaríamos ni ponerla xD

Por poner algunos ejemplos en las máquinas que tengo a mano uso:

AMD Ahtlon 3200+ (2GHz)
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer -msse3"

Intel Core Duo T2500 (2GHz)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -msse3"

Intel Pentium4 (3.2GHz)
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -msse3"

Intel Pentium4 Celeron (2GHz)
CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer"


Vamos, más simple y pobre imposible jejeje. Y ahora viene el tema, resulta que en el Athlon 3200+ de 64bits tenía -O3… yo ni me acordaba.

Quien no tenga ni amigos ni cosas que hacer que acuda al man gcc y se las estudie todas.

El problema con libgcrypt

Para la prueba 12, creé en mi portátil una par de pares de claves GPG para cifrar con clave asimétrica un mensaje, el objetivo de la prueba era recuperar la clave privada y la passphrase y a continuación descifrarlo. Al principio pensé hacerla más larga y que luego no estuviese enviado por quien decía ser y hubiera que encontrar más cosas pero bueno, lo deje en el primer stage, así que la clave pública del emisor ya no era ni necesaria.

Una vez creadas las clave y cifrado el mensaje procedí a probar que funcionaba…claro. Así que exporté las claves y las importé en el sobremesa (el Athlon). Procedo a descifrar y:
...
AES-128 test encryption failed.
...

Premio, ¿qué habré hecho mal? Venga a probar a importar de nuevo, crear de nuevo las claves, … Resulta que tenía versiones distintas de GnuPG en cada máquina, ¿afectará? O_o, no debería en absoluto pero bueno, compilo la misma versión, sigue fallando, creo otra vez la claves, me empiezo a desesperar, busco por internet, no encuentro nada, me bajo el código fuente donde sale esa cadena para ser mostrada, me lo empiezo a mirar para ver cuando y por qué sale. No veo nada raro, cambio a otra versión de libgcrypt, recompilo, más de lo mismo, sólo puede ser una cosa, que el algoritmo de AES no esté haciendo lo que toca, pero ¡el mismo código funciona en otra máquina!

Ya desesperadísimo a falta de 20 minutos para que demos comienzo el reto, la prueba 12 no funciona xD, genial. Asumiendo que el código es correcto sin bugs me meto en el make.conf y veo “-O3“, uhm, no me jodas, lo cambio por “-O2” y recompilo libgcrypt, que es el paquete que contiene la función con dicho código tocapelotas, y recompilo GnuPG, pruebo a descifrar, a la primera ¬¬

De normal cuando un paquete es propenso a funcionar mal por estas razones en el proceso de compilación te avisan de que no uses alguna optimización, éste no era el caso aunque después de lo visto quizá deberían avisarlo. O cambiarlo por -O2 sin decir nada.

Así que ya sabéis, KISS (efe eeeeeeeeeeeeeeeeeeeeeeeeemeeeeeeee), Keep It Simple, Stupid!

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• The Machines
• Dejar bonito un server SSH – Parte 1
• Arduino MEGA y módulo XBee – Instalación en gentoo

Cuanta razón tiene Nate Lawson cuando recomienda encarecidamente usar librerías de alto nivel cuando estemos usando criptografía. Ejemplos de ellas son GPGME (GnuPG Made Easy) y Keyczar, de la que hace poco el mismo autor sacó un timing attack de libro, irónicamente xD (para ver de qué va el Side Channel TuXeD tiene unos cuantos posts interesantes, entre otros [1] [2])

Si nos ponemos a buscar cagadas que haya hecho la gente en los últimos años veremos que se tropieza una y otra vez en las mismas piedras. Por eso jamás se deben implementar los algoritmos por nuestra cuenta reinventando la rueda… mal, y siempre deberemos usar código contrastado y revisado por terceros.

Muy recomendable la siguiente presentación:

http://www.slideshare.net/rootlabs/when-crypto-attacks-yahoo-2009

En la conferencia en la UPV (PDF) de hace unas semanas ya lancé ideas sobre estas cosas con metidas de pata gordas, como la de Nintendo Wii, la de Mifare, la de Debian, etc.

–
Fuente original en http://vierito.es/wordpress

Similar Posts:

• Soluciones del reto de criptografía – Parte 2
• Historias de la cripta
• Descifrando un reto del FBI