TOP
AutoresTOTAL
LecturasSET 27
77623 visitas
- Contenidos - SET Staff
- Editorial - Editor
- Guia para newbies - blackngel
- Bazar de SET - Varios Autores
- No_banners (bazar) - FCA00000
- Windoxs versus linux (bazar) - KSTOR
- PGP 8.0 (bazar) - KSTOR
- CisoPIXfirewall - bafomet
- Desbloquear consola NES - chinaski
- El SO de mi vida - KSTOR
- Proyectos, peticiones, avisos - SET Staff
- freenet - lindir
- Strhanix - Strhanix
- john-16-32 - madfran
- VIR-MOV - FCA00000
- Articulo publicado por SET en @RROBA - SET Staff
- Fuentes Extract - SET Staff
- Llaves PGP - SET Staff
john-16-32
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*