SET 39 Call For Papers

¿Eres un hacker? Si deseas pasar a formar parte de la historia del hacking hispano, colabora con la próxima edición de SET 39 enviándonos un artículo. No esperes más, esta es tu oportunidad de demostrar lo que sabes. Ayúdanos a construir una revista de hackers para hackers. SET Staff

SET 27

42804 visitas

john-16-32

      2303

Autor: madfran
-[ 0x0A ]--------------------------------------------------------------------
-[ John The Ripper 6-32 ]----------------------------------------------------
-[ by madfran ]------------------------------------------------------SET-27--

CASI UNA NUEVA VERSION DEL VIEJO JOHN


INTRODUCCION

Una de mis manias es el seguimiento de programas que causaron un enorme impacto
en su tiempo pero que hoy en dia languidecen sin que nadie les preste atencion
ni intenten ayudar para resolver pequenyos bugs o bien para actualizarlos para
hacerlos eficaces frente a nuevos desafios. No hablemos de incluirles nuevas
funcionalidades o anyadirles habilidades que faciliten la vida a sus usuarios.

Ha sido por tanto una agradable sorpresa encontrarme con un programita que
todavia da guerra y con gente a su alrededor de dar parte de su tiempo para
el bien de la comunidad, siempre ausente y desagradecida. Me estoy refiriendo
al legendario John The Ripper, famoso donde los haya, util arma de ataque
frente a tontos administradores que dejan acceso a sus ficheros de passwords
o simple herramienta de estos para llamar a la atencion de sus usuario sobre
el peligro de utilizar como password la fecha de nacimiento, del suyo o de
cualquier otro, que para los resultados es lo mismo. 


UN AGRADABLE DESCUBRIMIENTO

Efectivamente. Una agradable sorpresa me lleve, cuando pasando un poco al azar
por una web denominada http://www.false.com/security/john/ y me encuentro que
hay una nueva version. Si, es cierto que no es una version liberada ni que
esten disponibles los ejecutables, pero si que estan los fuentes a la vista y
alcance de nuestras avidas manos y que poniendos un poco de empenyo y algo de
energia mental, que no fisica, podemos hacer algunas pruebas y finalmente,
incluso, obtener algunos resultados.

Lo primero, como es de rigor, hay que bajarse los fuentes. Lo cosa esta al 
alcance de las conexiones mas miserables, ya que el todo se encuentra 
debidamente enpaquetado y compactado en formato tar.gz y no ocupa mas de
133 KB. A este precio quien se resiste a bajarselo!

Despues de soportar diversos parpadeos de vuestro modem y pasados algunos
minutos o segundos, segun el costo mensual de vuestra conexion, vuestros 
esfuerzos se ven recompensados con el apetecible archivo, un tal 
john-1.6.32.tar.gz Con semejante tesoro bajo vuestros ojos, no teneis mas que
empezar a desempaquetar el regalo. No requiere mas esfuerzo que tener 
actualizado vuestro WinZip,  la version 8.0 se desenvuelve maravillosamente, y
con un simple click de vuestro raton, se consigue que el archivo se desdoble
una serie de directorios convenientemente ordenados.

Si no le decimos nada especial al WinZip, va a crear un directorio con el
nombre de john-1.6.32 , bajo este se encuentran otros tres que rezan de la
forma siguiente, doc, run, src Si miramos en doc, en lugar de una prolija
explicacion de que va la cosa, nos encontramos con tres escualidos ficheros en
los cuales no da ninguna pista de como se compila y linka el invento. Como no
nos arredramos ante este tipo de dificultades, nos vamos al john 16 que tenemos
funcionando en otro directorio y rebuscando en la doc nos encontramos con una
escueta informacion.

Hay que,

Cambiar al directorio donde estan los fuentes ==> cd src
teclear un comando                            ==> make

Esto te dara una lista de los sistemas bajo los cuales puede funcionar el john
despues en funcion de la lista que salga hay que ordenar el compilado y linkado

                                              ==> make 'tu sistema'

El problema es que a los autores de John nunca se les paso por la cabeza que
el miserable que se encontraba frente al teclado no dispusiera de ningun
compilador en su maquina, aunque este fuera mi caso. La solucion es sencilla,
buscarse una gratuito en la red.


INSTALANDO UN COMPILADOR

El que uno no posea un compilador decente no significa que no tenga recursos
y disponga de una conexion a la red de aceptable velocidad. La tipica conexion
al buscador google y una busqueda por +compiler +free +gcc me da una tonelada
de informacion pero rapidamente una direccion me llama la atencion. Una  tal
direccion http://www.delorie.com/djgpp , me lanzo sobre alla y que descubro ?
pues un compilador de 32 bit junto a un entorno de programacion, totalmente
gratuito. Releyendo rapidamente la documentacion, veo que estuvo escrito
originariamente para UNIX pero funciona bien bajo sabores DOS. Vamos a por el!

Lo primero de todo es bajarse los archivos comprimidos, hay varios y en funcion
de vuestro equipo y necesidades. No puedo ayudaros mucho, hay que leerse la
informacion que aparece en la pagina de descarga. Leerse la documentacion es
incluso un placer sobre todo si esto te permite ahorrarte una pila de trabajo
mas tarde. Para que quede clara la situacion, sepase que la maquina que 
respondia a mis ordenes era un PC Portable perteneciente a la empresa para
la cual trabajo (de vez en cuando). Este era el motivo por el cual el 
respetable instrumento estaba bien dotado con un Windows 2000 pero carecia
por completo de compiladores. Evidentemente nadie esperaba que se hicieran
ciertas cosas en este honorable entorno de trabajo.

Bien, lo primero es crear un directorio para el DJGPP. No se os ocurra hacerlo
en sitios exoticos y no os encontrareis con problemas extras. Despues hay
que unzipear los archivos bajados. Si no disponeis de algo decente, o sea que
conserve la estructura de los subdirectorios y soporte nombres largos os podeis
bajar un unzip gratuito en ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/
Se llama unzip32.exe

Despues hay que unzipear todo, sobre el mismo directorio. No dejeis que cada
cosa vaya por su lado. Finalmente se deben configurar algunas variables de
entorno. En el W2000 esto se hace en el Control Panel, Systemn, Advanced,
Environment Variables y creais una nueva variable llamada DJGPP con el
contenido C:\DJGPP\DJGPP.ENV o donde diablos se os haya ocurrido instalar
vuestro compilador. Despues se debe anyadir al contenido de la variable Path
C:\DJGPP\BIN Mismo comentario que en el caso anterior. Siempre me ha llamado
la atencion que Windows considere 'Advanced' el anyadir o modificar una 
variable de entorno.

Bien. A partir de ahora ya tenemos instalado y funcionando el compilador. 
Podemos leernos una tonelada de documentacion, pero como lo unico que deseabamos
era probar el John 16-32, salimos corriendo hacia el directorio donde reposan 
sus fuentes y ya quedara para otro rato el culturizarnos.


VAMOS A COMPILAR Y LINKAR TODO ESTO

Como he dicho antes, basta con irse al directorio donde estan los fuentes y
teclear make. En pantalla saltaran todas las combinaciones que los chicos de 
john han previsto. Algo parecido a esto :

 linux-x86-any-elf        para Linux con x86 y para binarios ELF
 linux-x86-mmx-elf        para Linux con x86 con MMX y binarios ELF
 linux-x86-any-a.out      para Linux con x86 y binarios a.out
 linux-alpha              para Linux con procesador Alpha
 linux-sparc              para Linux con arquitectura SPARC
 linux-ppc                para Linux con PowerPC
 freebsd-x86-any-elf      para FreeBSD con x86y para binarios ELF
 freebsd-x86-mmx-elf      para FreeBSD con x86 con MMX y para binarios ELF
 freebsd-x86-any-a.out    para FreeBSD con x86 y para binarios a.out
 freebsd-alpha            para FreeBSD con Alpha
 openbsd-x86-any          para OpenBSD con x86
 openbsd-sparc            para OpenBSD con SPARC
 openbsd-vax              para OpenBSD con VAX
 netbsd-vax               para NetBSD con VAX
 solaris-sparc-gcc        para Solaris con SPARC y compilador gcc
 solaris-sparc-v8-cc      para Solaris con SPARC V8 y compilador cc
 solaris-sparc-v9-cc      para Solaris con SPARC V9 y compilador  cc
 solaris-x86-any          para Solaris con x86 y compilador gcc
 sco-x86-any-gcc          para SCO con x86, compilador gcc y para binarios ELF
 sco-x86-any-cc           para SCO con x86, compilador cc y para binarios ELF
 tru64-alpha-cc           para Tru64 (Digital UNIX, OSF/1), arquitectura Alpha
                          y compilador cc
 aix-ppc-cc               para AIX, arquitectura PowerPC y compilador cc
 macosx-ppc-cc            para MacOS X, arquitectura PowerPC y compilador cc
 hpux-pa-risc-gcc         para HP-UX, arquitectura PA-RISC y compilador gcc
 hpux-pa-risc-cc          para HP-UX, arquitectura PA-RISC, ANSI y compilador cc
 irix-mips32-cc           para IRIX, arquitectura MIPS 32-bit y compilador cc
 irix-mips64-cc           para IRIX, arquitectura MIPS 64-bit y compilador cc
 dos-djgpp-x86-any        para DOS, compilador DJGPP 2.x con x86
 dos-djgpp-x86-mmx        para DOS, compilador DJGPP 2.x con x86 y MMX
 win32-cygwin-x86-any     para Win32, Cygwin con x86
 win32-cygwin-x86-mmx     para Win32, Cygwin con x86 y MMX
 beos-x86-any             para BeOS con x86
 beos-x86-mmx             para BeOS con, x86 yMMX"
 generic                  para cualquier otra arquitectura Unix y compilador gcc"

Visto asi es impresionante el trabajo realiza por estos muchachos. No se si 
disponen de todas estas combinaciones o simplemente confian en la literatura 
existente y en su buena suerte, pero el trabajo previo realizado es de 
'chapeau'.

En nuestro caso, dado que dispongo de un portatil con Intel x86 family 6 Model
8 Stepping 10 de 1000 Mhz con una memoria RAM de 264 Kb, y utilizo el djgpp, 
tengo que decir a la maquina 

make dos-djgpp-x86-mmx

La maquina suelta una serie de mensajes incomprensibles en la pantalla y 
finalmente debe terminar sin ningun mensaje de error. Si es asi, en el 
directorio run, te vas a encontrar un archivo extra llamado john.bin


PRUEBAS Y RESULTADOS

Uno es impaciente y no tiene ganas de buscarse un fichero con hash de password
asi que utilizo directamente las utilidades que se encuentran en el john. Segun
su documentacion, para hacer un test nada como teclear,

johnn -test

y el sistema me responde con,

Benchmarking: Traditional DES [24/32 4K]... DONE
Many salts:	94677 c/s
Only one salt:	88345 c/s

Benchmarking: BSDI DES (x725) [24/32 4K]... DONE
Many salts:	3242 c/s
Only one salt:	2833 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:	2032 c/s

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:	144 c/s

Benchmarking: Kerberos AFS DES [24/32 4K]... DONE
Short:	86296 c/s
Long:	218020 c/s

Benchmarking: NT LM DES [32/32 BS]... 

Exiting due to signal SIGSEGV
General Protection Fault at eip=00026ec9
eax=00000008 ebx=000086a0 ecx=03020100 edx=0006fcb0 esi=07060504 edi=00045c80
ebp=0003c9b0 esp=000f70a8 program=C:\******\WIN-NT\JOHN\JOHN-1~2\JOHN-1~1.32\RU
N\JOHN.BIN
cs: sel=034f  base=02a80000  limit=0011ffff
ds: sel=0357  base=02a80000  limit=0011ffff
es: sel=0357  base=02a80000  limit=0011ffff
fs: sel=033f  base=00008000  limit=0000ffff
gs: sel=0367  base=00000000  limit=0010ffff
ss: sel=0357  base=02a80000  limit=0011ffff
App stack: [000f72f0..000772f0]  Exceptn stack: [00077248..00075308]

Call frame traceback EIPs:
  0x00026ec9

Asi de memoria no me parecia que fuera mucho mas rapido que la vieja version
y encima peta con el NT asi que lanzo el john 16 y veo sorprendido que,

Benchmarking: Standard DES [24/32 4K]... DONE
Many salts:	95163 c/s
Only one salt:	89173 c/s

Benchmarking: BSDI DES (x725) [24/32 4K]... DONE
Many salts:	3277 c/s
Only one salt:	2858 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:	2086 c/s

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:	123 c/s

Benchmarking: Kerberos AFS DES [24/32 4K]... DONE
Short:	87513 c/s
Long:	223216 c/s

Benchmarking: NT LM DES [24/32 4K]... DONE
Raw:	621368 c/s

Es mas rapido que la nueva version y no peta cuando hace el test de NT !


MAS COMPILACIONS

Veamos, no nos rindamos tan pronto. Releyendo un poco mas en la web de john, 
vemos que hay una aportacion de un tercero que brinda un patch para NTLM. Me
bajo el todo y lo descomprimo en directorio separado. Veo que hay un FAQ y
me dispongo a leerlo. Descubro que basta copiarlo todo en el directorio src
y despues teclear 

patch < john_ntlm.diff

pero esto es solo para el caso de trabajar bajo linux,.... no estamos en estas
condiciones ! Tengo que hacer todo el trabajo a mano, que consiste basicamente
en editar a mano el archivo makefile de la forma siguiente,

Si en el archivo john-ntlm.diff encontramos algo asi,

+++ src/john.c	Mon Jun 10 15:34:36 2002
@@ -36,7 +36,7 @@
 #endif
 
 extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;
-extern struct fmt_main fmt_AFS, fmt_LM;
+extern struct fmt_main fmt_AFS, fmt_LM, fmt_NT;

Tengo que buscar en el archivo john.c la linea,

 extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;

eliminarla y cambiarla por,

 extern struct fmt_main fmt_AFS, fmt_LM, fmt_NT;

Toda una delicia en la cual he perdido mas de media hora, para despues poder
compilar, linkar y obtener,.... el mismo resultado. 


MAS PRUEBAS Y MAS RESULTADOS

La historia peca de aberrante y no me puedo creer los resultados, asi que 
espero un par de dias hasta disponer de otra maquina sobre la cual hay un
linux Redhat 7.3 instalado conviviendo en armonia con un Windows 2000 
(aunque no por los meritos de Windows, que ha hecho lo imposible para 
entorpecer la instalacion del linux) y reanudo las pruebas.

La maquina es un PC fijo con AMD x86 family 6 Model 4 Stepping 2 de 1000 Mhz 
con una memoria RAM de 264 Kb, o sea aparentemente bastante parecida en
cuanto a hardware respecto a la anterior si hacemos la salvedad de que esta
es un PC de sobremesa con un AMD en lugar de un Intel.

Lo primero es hacer una prueba con la maquina bajo windows y utilizando el
john 16. Los resultados a continuacion.

Benchmarking: Standard DES [48/64 4K]... DONE
Many salts:	74243 c/s
Only one salt:	71990 c/s

Benchmarking: BSDI DES (x725) [48/64 4K]... DONE
Many salts:	2591 c/s
Only one salt:	2567 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:	2830 c/s

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:	168 c/s

Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short:	71190 c/s
Long:	238500 c/s

Benchmarking: NT LM DES [48/64 4K]... DONE
Raw:	819507 c/s



Como podeis comprobar, como minimo no peta. Despues probar con el john-16-32
despues de pasar por toda la agonia de la compilacion bajo windows.



Benchmarking: Traditional DES [24/32 4K]... DONE
Many salts:	94677 c/s
Only one salt:	88345 c/s

Benchmarking: BSDI DES (x725) [24/32 4K]... DONE
Many salts:	3242 c/s
Only one salt:	2833 c/s

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:	2032 c/s

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:	144 c/s

Benchmarking: Kerberos AFS DES [24/32 4K]... DONE
Short:	86296 c/s
Long:	218020 c/s

Benchmarking: NT LM DES [32/32 BS]... 

Exiting due to signal SIGSEGV
General Protection Fault at eip=00026ec9
eax=00000008 ebx=000086a0 ecx=03020100 edx=0006fcb0 esi=07060504 edi=00045c80
ebp=0003c9b0 esp=000f70a8 program=C:\MDF\HAC\WIN-NT\JOHN\JOHN-1~2\JOHN-1~1.32\RU
N\JOHN.BIN
cs: sel=034f  base=02a80000  limit=0011ffff
ds: sel=0357  base=02a80000  limit=0011ffff
es: sel=0357  base=02a80000  limit=0011ffff
fs: sel=033f  base=00008000  limit=0000ffff
gs: sel=0367  base=00000000  limit=0010ffff
ss: sel=0357  base=02a80000  limit=0011ffff
App stack: [000f72f0..000772f0]  Exceptn stack: [00077248..00075308]

Call frame traceback EIPs:
  0x00026ec9

Aqui se nota algo de mejora en la velocidad, pero desde luego sigue sentandolo
fatal el probar cosas como hash NT LM

Veamos que pasa bajo linux. Para empezar no hay que buscar compiladores 
esotericos por esos mundos. Toda distribucion linux posee el gcc perfectamente 
activo, vivo y coleando. Por tanto, la compilacion, con patch incluido es 
sumamente rapida. Y los resultados ? Pues ahi los teneis.

Benchmarking: Traditional DES [64/64 BS MMX]... DONE
Many salts:	375232 c/s real, 375232 c/s virtual
Only one salt:	307148 c/s real, 307148 c/s virtual

Benchmarking: BSDI DES (x725) [64/64 BS MMX]... DONE
Many salts:	12531 c/s real, 12531 c/s virtual
Only one salt:	12300 c/s real, 12300 c/s virtual

Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:	2956 c/s real, 2956 c/s virtual

Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:	174 c/s real, 174 c/s virtual

Benchmarking: Kerberos AFS DES [48/64 4K MMX]... DONE
Short:	74342 c/s real, 74342 c/s virtual
Long:	256819 c/s real, 256819 c/s virtual

Benchmarking: NT LM DES [64/64 BS MMX]... DONE
Raw:	1977139 c/s real, 1977139 c/s virtual


Esto si que es velocidad ! En algunos casos casi se dobla ! Y solo por cambiar
de sistema operativo.

Esta es una historia que empezo con la sana intencion de comparar dos versiones
de un software y ha terminado comparando el sofoco que puede provocar un
sistema operativo en un software, aunque sobre el se ha hecho un gran esfuerzo 
de mejorar, limpiar y dar esplendor. Yo me he distraido bastante con todo este
barullo pero no le acabo de encontrar las razones o motivos. Si alguno la 
encuentra le agradeceria que me enviara un mensaje, al que sin duda le dare la
publicidad que se merece.


*EOF*