sábado, 28 de marzo de 2009

Backtrack 4 con Ubuntu Intrepid

Como ya comentamos en una anterior entrada, la nueva versión de la distribución Linux más conocida, BackTrack, ha salido con algunos cambios más que interesantes. Entre ellos, el hecho de que esté basada en Ubuntu Intrepid en lugar de Slax como las anteriores, y que de hecho la gente de Remote-Exploit.org hayan dejado como públicos sus repositorios de APT, cumpliendo con algo que llevaba años queriendo hacer yo mismo, crearme un repositorio binario con las herramientas de seguridad para añadirlo a mis origenes de software y que se pudiera instalar todo este software igual que se instala cualquier otro, mantenerlos actualizados más cómodamente, etc.

Así que allá fui, arranqué la Backtrack 4 recien bajadita y le pegué un ojito a sus repositorios de software, entre los que encontré el siguiente:



Realmente, esta captura es de cuando ya lo puse en mi Ubuntu Intrepid, aprovechando que utilizo la misma versión que Backtrack 4, no debería tener ningún problema de dependencias, así que me añadí el repositorio y recargué el listado de paquetes, sin que me diera ningún problema.

Efectivamente, si ahora abro el Synaptic (aunque yo uso normalmente aptitude, pero la captura del Synaptic quedará más vistosa) me encuentro con todo lo siguiente:



La teoría es que, cuando intente instalar algo de los grupos de paquetes de Backtrack, estos localizarán sus dependencias de mis repositorios Ubuntu originales, y se instalarán sin problemas. Lo pruebo y, realmente, sin problemas, fijaros como se va descargando el software de seguridad del repositorio de Backtrack, y el resto de los repositorios "normales":



Al final el proceso de instalación acaba, y efectivamente ejecuto mi w3af ( /pentest/web/w3af/w3af_gui) o mi webscarab sin ningún problema:



Y todo esto con la ventaja de que cada vez que la gente de backtrack actualice una versión, a mi me aparecerá abajo que hay una versión nueva, por lo que estaré permanentemente actualizado (o esa es la teoría).

Un gran trabajo de los de Backtrack!! Se acabó ir con liveCDs/Máquinas virtuales de backtrack de arriba para abajo! :)

lunes, 23 de marzo de 2009

Pregunta a pentester.es

La dura vida del blogger... en ocasiones no sabemos que cosas pueden interesar a las personas que leen nuestros blogs, es posible que a alguien le gustara que explicaramos algunos conceptos básicos de seguridad, o quizá todo lo contrario, el último ataque sofisticado que no se acaba de entender muy bien.

Como vuestra corteza cerebral no tiene aún vulnerabilidades documentadas, mientras nos programamos nuestro patentado fuzzer cerebral, hemos creado una cuenta de correo en la que los lectores del blog pueden hacernos sugerencias de que os gustaría que escribieramos en el blog.

La cuenta será preguntas en ya s@beis donde, pentester.es ,supongo que ninguno de vosotros tendreis problemas para recomponer este correo, pero espero que sí que los tengan los bots que mandan Spam :P

Esperamos vuestros correos!

lunes, 16 de marzo de 2009

Busca, Busca... Busca Malware bonito...

Hace unos pocos días una muy buena amiga me hizo la pregunta que se nos hace muchas veces a los que nos dedicamos a esto de la seguridad: Mi ordenador/servidor hace cosas raras, ¿Estaré infectado por algún virus o habré sufrido alguna intrusión?

Sin duda es la pregunta del millón, pues aunque tengas un anvirus actualizado, todas las medidas de seguridad y todos los parches aplicados al siguiente instante de ser publicados, nadie puede garantizarte que un error humano al aplicarlos, o en la administración del sistema, o un exploit zero-day no haya tirado por tierra todos tus esfuerzos.

Una de las cosas que me gusta hacer a mi para contestar a esta pregunta es buscar herramientas, puesto que los intrusos generalmente no buscan "entrar y salir" (y si lo hubieran hecho probablemente no se estarían notando ya esas "cosas raras"), sino que buscan mantener el control de la máquina. Por ello, suelen dejar algún tipo de software que realice las acciones que deseen, puertas traseras o algún otro tipo de Malware. También podrían crearse cuentas de usuario, pero eso suele cantar mucho, vamos a centrarnos en el caso en que hemos revisado ya el sistema (apagado, para evitar que un rootkit nos de gato por liebre) y no vemos nada raro en cuanto a la configuración de usuarios, y temas similares.

Vamos al lio, esto es lo que haría yo en un caso como este, para un sistema Windows, después de haber observado la máquina y no ver cuentas raras ni ningún tipo de punto de entrada que pueda no implicar el uso de malware:
  1. Apagado de la máquina: Con la máquina encendida corremos el riesgo de que la información que nos devuelva la máquina esté siendo alterada por algún tipo de rootkit. Existen varias vertientes de como hacer el apagado de la máquina, yo suelo optar por tirón del cable, no sin antes tener backup de todo, especialmente si tenemos servicios que manejan una gran cantidad de datos en memoria, como las bases de datos.
  2. Escaneo antivirus: Lo primero de nada es ver si existen virus conocidos, igual la cosa es tan fácil como que un virus ha inutilizado el antivirus local, y simplemente con arrancar desde CD y pasar un antivirus es suficiente.
  3. Busqueda de ejecutables: Al final, no importa si el código del virus está realmente cifrado, o si se lo baja de Internet, o lo que sea, pero lo que es seguro es que tiene que haber algo en la máquina que lo llame y que no sea original de un fabricante de software, esto nos dará algunos candidatos. Para ello, vamos a partir de la suposición que la mayoría de ejecutables de un sistema Microsoft son de Microsoft (o al menos si conseguimos descartar todos los originales de Microsoft esto nos va a quitar un montón de trabajo). ¿Como sabemos que binarios del sistema son realmente de Microsoft? Pues por ejemplo con una herramienta de Mark Russinovich Sigcheck, que nos permite detectar ficheros ejecutables (independientemente de su extensión) y comprobar si están firmados por Microsoft o no, esto nos dará una buena lista de candidatos con tan solo lanzar el siguiente comando: sigcheck -e -s "c:\\"
  4. Criba de candidatos: De esta lista, donde más es posible que haya ejecutables legítimos no firmados es en Archivos de programa, así que en una primera aproximación podriamos obviar ese directorio por el momento y quedarnos con el resto, que deberían ser ya pocos.
  5. Análisis de Malware: A partir de ahí, realizariamos un pequeño análisis de malware sobre los ficheros encontrados, en los que iremos cribando sucesivamente hasta encontrar el bichito en cuestión o hasta determinar que no ha existido infección.
A partir de ahí... se pueden hacer muchas más cosas, tanto si hemos encontrado el malware como sino, quizá se encuentre en algún datastream... una cosa que no he probado todavía es si sigcheck detectaría un ejecutable en un stream alternativo, quizá un intruso podría ocultar un ejecutable en uno de estos streams alternativos de un binario legítimo del sistema.

Si alguien lo prueba que lo diga :)

martes, 3 de marzo de 2009

12 trucos de seguridad web

Ayer mismo fue publicado por el SANS Institute un documento que nos ofrece 12 trucos para mejorar la seguridad de nuestras aplicaciones web. El autor, el conocido Ed Skoudis, Instructor de SANS y responsable del temario de los cursos de Incident Handling, Técnicas de Hacking y Test de Intrusión/Hacking Ético.

Los 12 trucos son los siguientes, con mi propia interpretación y comentarios:
  1. Usa librerías de validación de datos de entrada: En lugar de programarte unas ad-hoc, utiliza librerías conocidas, sus desarrolladores han invertido muchas más horas que tú y han sido mucho más testeadas. El proyecto OWASP es un buen sitio donde conseguir buenas librerías de este tipo.
  2. Especifica los tipos de las variables: Es una buena manera de evitar problemas en la validación de datos de entrada de aquellos campos de los que se esperen valores muy concretos, por ejemplo valores enteros. Los campos en los que se introducen enteros son un gran punto de entrada para los ataques web, ya que ni tan siquiera son necesarias comillas. No obstante, si dichos campos fueran verificados comprobando si el valor obtenido es un entero o no, resultaría imposible para un atacante poder inyectar nada que no fuera un entero. Por lo tanto, si el resultado tiene que ser un entero, comprueba que sea un entero, y si tiene que ser un NIF, comprueba que son los números requeridos seguido de una letra del alfabeto estandar e ignora otro tipo de caracteres, esto nos ahorrará muchos disgustos.
  3. No definas los caracteres incorrectos en lugar de definir los correctos: No podemos garantizar que conocemos todos los ataques existentes, y por lo tanto no podemos garantizar que no permitir determinados caracteres va a detener todos los tipos de ataque. Sin embargo, sí que podemos saber que juego de caracteres va a usar la aplicación y prohibir todos los demás, de esta manera evitamos sufrir ataques tanto conocidos como hasta ahora desconocidos por nosotros.
  4. Limita el tamaño de la entrada: En un campo "edad", con 3 dígios es suficiente (nadie va a tener más de 999 años), por lo tanto manejar valores de entrada más largos para ese campo sólo puede propiciar un espacio en el que un intruso puede intentar realizar algún tipo de ataque o inyección. Una implementación posible es, por ejemplo, la clase "Validator" de Java.
  5. Canonizar antes del filtrado: Se llama "canonizar" a convertir los caracteres encodeados en cualquier juego de caracteres a un juego de caracteres dado. Utilizar diferentes encodings es una práctica habitual para evitar los filtrados de las aplicaciones web por parte de los atacantes. Utilizar funciones como la ESAPI.encoder().canonicalize() permite evitar este tipo de ataques, puesto que tras convertir cualquier entrada a un juego de caracteres conocido ya podemos filtrar sin temor a este tipo de técnicas.
  6. Filtra todas las entradas: Cualquier dato de entrada a la aplicación web puede ser alterado y por tanto debe ser verificado. Muchas veces los desarrolladores tienden a pensar que hay campos que no pueden ser modificados, como las cookies, los valores de un desplegable o los campos hidden. Sin embargo, todos ellos pueden ser igualmente alterados por medio de proxys y otras técnicas de hacking, y por tanto deben ser verificados.
  7. Filtrar en el lado servidor: No podemos tener ningún tipo de control sobre lo que se ejecuta en el lado del cliente, por lo que no se debe delegar en esta parte ningún tipo de filtrado. El uso de proxies y otras técnicas permitirían modificaciones de los datos tras ser enviadas por el navegador, por lo que el atacante podría modificar los parámetros sin ningún tipo de restricción, haciendo inútil la validación realizada en el lado cliente. Por ello, la validación debe ser realizada siempre en el lado servidor.
  8. No pasa nada por utilizar varias capas de validación: Esta práctica fortalece aún más la seguridad del sistema, siguiendo un diseño de defensa en profundidad.
  9. Utiliza encoding de salida: Algunos ataques como los de Cross Site Scripting (XSS) consisten en introducir código de script que es ejecutado en los clientes al ser devuelto por la aplicación. Una manera de evitarlo es encodear también la salida de los datos, de tal manera que caracteres peligrosos como el "menor que" son traducidos a sus correspondientes caracteres en HTML, con lo que ya no serán interpretados por el navegador.
  10. Elije el encoding adecuado para la salida: Dependiendo de como vaya a ser interpretado, utiliza HTML, XML, comandos del sistema operativo, etc.
  11. Realiza revisiones de código: Si puedes permitirtelo, es muy positivo que personal especializado en seguridad externo al proyecto de desarrollo realice un análisis del código para detectar vulnerabilidades.
  12. Realiza un test de intrusión: Otro medio para verificar el estado final de tu aplicación web.

  13. Y a esta lista de Ed Skoudis, yo le añado las recomendaciones número 13, 14 y 15 de mi propia cosecha:

  14. Mantén el código lo más sencillo y bien documentado/comentado que puedas: La vida de un software está llena de actualizaciones, de persoans diferentes metiendole mano y de "esto tiene que estar para ayer", pero añadir correcciones descontroladamente puede ofuscar el código y hacerlo cada vez menos mantenible, y por lo tanto será más fácil que nos dejemos ese parámetro nuevo que añadimos con prisas y del que no realizamos validación, y al final es por ahí por donde todo se complica. Intentar siempre que todo el equipo conozca como deben codificarse las entradas de datos según las anteriores reglas, y si es posible que alguien lo verifique (como dicen las reglas 11 y 12).
  15. Implementa detección de intrusiones: Existen librerías de detección de intrusiones como PHP-IDS que pueden ser utilizadas para detectar intentos de intrusión. No sólo basta con que los intrusos no consigan sus objetivos, si conseguimos detectarlos y filtrarlos antes de que jueguen demasiado rato con nuestra aplicación como para encontrar algo, mucho mejor.
  16. Implementa un buen registro de log: En muchas ocasiones los que nos enfrentamos a la gestión de incidentes nos encontramos con que vamos a ver "que ha pasado" y los sistemas no guardan ningún tipo de registro, lo que ha pasado ya pasó, pero la información guardada en el registro es muy escasa, tan escasa que es imposible saber que pasó. Recordad que los logs típicos de aplicaciones web no guardan demasiada información, practicamente sólo registran la URL visitada, y se dejan información tan importante como la información o ficheros subidos por medio del método POST, las cabeceras de la llamada HTTP, la cookie empleada, etc. Por ello es importante que registremos en un log cualquier anomalía que detectemos, por ejemplo el uso de identificadores de sesión inválidos, porque si tenemos un incidente, cuando el Incident Handler revise los logs, verá que alguien ha estado intentando buscar identificadores de sesión válidos para realizar un robo de sesión (por ejemplo). De lo contrario, probablemente poco os podrá decir, y por lo tanto poco podreis aprender de vuestro incidente, factor fundamental para que no vuelva a suceder.

Como dice el autor, seguir estas medidas de seguridad no asegura que nuestras aplicaciones web sean "a prueba de balas", pero desde luego vamos a obligar a los intrusos a emplear una buena cantidad de horas si quieren sacar algo de provecho de nuestros sistemas, probablemente tantas horas que no merecerá la pena en ninguno de los casos, que es al final lo que persigue la seguridad, ofrecer tantas dificultades a los intrusos que el premio obtenido por romper la seguridad no sea compensado por la recompensa que se obtiene.

Librerías:
Yo soy un total fan del proyecto OWASP, pero si alguien tiene sus librerías favoritas que deje en enlace como comentario y las voy añadiendo a la lista.

domingo, 1 de marzo de 2009

Attacking Intel Trusted Execution Technology

Aquí teneis un video publicado en securitytube (ya sabeis, el youtube de la seguridad informática) de la presentación en la última BlackHat DC de los ataques descubiertos contra la Trusted Execution Technology (TXT) de Intel.

El video empieza explicando como funciona el TXT antes de pasar a como se ataca, realmente muy interesante: