Un RFD (Remote File Downloading) "protegido" por ofuscación

Hace no demasiado, cuando recordaba las charlas que había dado con mi amigo Palako por todo el mundo de hacking, me vinieron las demos de RFD (Remote File Downloading) que contamos en Noruega o Washington D.C. en la que utilizando diferentes ataques de SQL Injection íbamos descargando ficheros del servidor web, junto con otras técnicas de LFI (Local File Inclusion) o RFI (Remote File Inclusion).

Figura 1: Un RFD (Remote File Downloading) "protegido" por ofuscación

En todas estas técnicas, la idea es siempre la misma, ver cómo utilizar código Server-Side para que al final se acceda a un fichero que está en el servidor web y nos lo entregue vía web browser. Ni sé cuantos proyectos de Ethical Hacking a empresas o pentesting a aplicaciones web se han terminado con una sola técnica de estas, ya que en el momento en el que te puedes descargar ficheros del servidor vas a ir a por los "juicy files" que te van a entregar las configuraciones de acceso a la base de datos, los usuarios del servidor web, los datos de la DMZ por las configuraciones de red, etcétera.

Figura 2: Hacking Web Applications: Client-Side Attacks

De hecho, cuando te enfrentas a una auditoría de un sitio web, es una de las cosas que primero buscas. SQL Injection, Blind SQL Injection, errores verbose que te dan información jugosa, Client-Side Attacks como XSS/CSRF/SSRF y descarga de ficheros. Por eso los pentesters en los Red Team, en los equipos de QA de seguridad y en los equipos de Ethical Hacking, estas disciplinas se entrenan con fuerza. En muchos CTFs de las CONs, conseguir una bandera es descargar un fichero - o muchos - del servidor web. 

Un RFD protegido por ofuscación

El caso que os voy a contar es uno de muchos, pero me hizo gracia encontrármelo de casualidad, ya que, en lugar de hacer las cosas bien, han puesto un parche de oscuridad que seguro que a los bots, y a los menos expertos evita, pero desde luego no a ningún pentester profesional. 

Figura 3: Aplicación PHP que descarga ficheros

En esta implantación, el código que te permite acceder a los ficheros es un fichero PHP que devuelve un fichero PDF o un PNG. Hasta aquí tiene toda la pinta de ganarse la atracción de cualquier auditor de seguridad profesional, pero lo que más llama la atención es que utiliza dos parámetros para conseguir la descarga. El primero de ellos un hash y el segundo un Ln.

Figura 4: Analizando el hash con Hash Analyzer

Lo primero que puedes pensar es que se trata de un esquema tipo cucharón, donde el programa tira un Select contra una base de datos, y puedes intentar hacer un UNION para que devuelva un Path al fichero que tú quieras. Es un esquema típico de RFD, pero no era así. Analizando el Hash se ve rápidamente que era un BASE64, así que se puede decodificar fácilmente.

Figura 5: Libro de Hacking Web Technologies 2ª Edición en 0xWord de
Chema Alonso, Enrique Rando, Amador Aparicio, Pablo González y Ricardo Martín

Al decodificarlo, se ve que aparece una ruta a un fichero, pero que cuenta con unos caracteres de más al inicio, y otros caracteres del más al final, como si llevara más información de la que es necesaria en esa ruta. 

Figura 6: Decodificando el hash. Aparecen caracteres antes y después de la ruta

Tras probar las cosas que hay que probar, es decir, probar el Hash original con valores aleatorios de LN se observa que no descarga nada y salen todos los ficheros vacíos, pero cuando se pone un LN+1 se descarga un fichero vacío con un nombre que tiene una letra más que el nombre del fichero correcto, y eso hizo saltar el dato final.

Figura 7: con LN+1 busca un fichero con extensión pngo que no existe

Al principio confundí los caracteres de inicio como parte del Path pero viendo este comportamiento y contando LN caracteres hacia atrás desde .png y ver que acaba en la barra de /home, es fácil asumir que el valor de LN es el límite de caracteres que se debe tomar del string de caracteres que viene en el HASH Base64 del parámetro de llamada. Pero... ¿para que sirve la cadena de  caracteres al inicio y la cadena de caracteres al final?

Figura 8:Codificando la ruta de /etc/passwd con los caracteres sobrantes

Para probar si esta suposición es correcta y si tenemos que hacer algo más con los caracteres al inicio y al final, basta con hacer una sencilla prueba. Vamos a dejar los caracteres al principio y los caracteres al final tal y como están, y vamos a meter la ruta al /etc/passwd en el medio. Después vamos a codificar en BASE64 esta cadena. Y ahora hacemos la llamada al programa PHP poniendo este Hash como parámetro uno y como parámetro LN al valor de lenght(/etc/passwd), y vemos si el fichero descarga y que hay dentro.

Figura 9: Fichero /etc/passwd descargado

Como se puede ver, tenemos el fichero /etc/passwd descargado, y haciendo lo mismo todos los ficheros del servidor a los que tenga acceso el usuario del servidor web - que no es root -. Tras unas cuantas pruebas, y ver que con ese sencillo algoritmo era posible descargar todos los ficheros, la respuesta de para qué sirven esos caracteres al inicio y al final es sencillo. Son "Tokens de ofuscación" que el programador ha metido para que no le sea tan fácil a un script kiddie o a un bot automático descargar los ficheros.

Figura 10: Probando con /etc/hosts y los mismos caracteres sobrantes

Realmente es una solución inútil, porque cualquier pentester profesional va a encontrarlo fácilmente, y si tienes que hacer una aplicación web, más vale que conozcas las técnicas de hacking de aplicaciones web, y que sepas cómo desarrollar de forma segura, porque lo que te puede parecer una buena idea, puede ser un desastre de seguridad.

¡Saludos Malignos!

Chema Alonso (Contactar con Chema Alonso) (Consigue Tempos gratis con ESET)

Chema Alonso en MyPublicInbox

Nuestro nuevo libro de "Hacking Web Technologies" @0xWord #pentesting #hacking

Hoy estoy contento, pues después de varios meses de trabajo ya esta disponible desde hoy un nuevo libro de 0xWord en el que he podido trabajar con grandes amigos. Haciendo equipo con Enrique Rando, Pablo González, Ricardo Martín y Amador Aparicio hemos escrito un libro orientado al pentesting y hacking de tecnologías web, y desde hoy lo puedes comprar: Hacking Web Technologies

Figura 1: Nuestro nuevo libro de "Hacking Web Technologies" @0xWord

El libro está centrado en explotar diferentes vulnerabilidades de los sistemas basados en tecnologías web, sin tocar para nada las técnicas de SQL Injection, de las que ya sabéis que escribimos otro libro Enrique Rando y yo. En éste libro nos centramos en otros tipos de ataques como son, por ejemplo, los ataques a las tecnologías LDAP, ataques a Connection String, los ataques de Info Leaks, las técnicas de Local File Inclusion o XPath Injection. 

Figura 2: Libro de Hacking Web Technologies

Además, en el libro se tocan temas como el uso de herramientas de auditoría web como ZAP Proxy de manera profesional, las técnicas de ataque de PHP Object Injection o la explotación de ataques de MongoDB Injection. El índice del libro lo he subido a SlideShare para que lo podáis ver en detalle.

Figura 3: Índice del libro "Hacking Web Technologies"

Este es el libro número 40 de la colección de libros de 0xWord, y por ahora está dentro ya del pack de Colección Completa, aunque probablemente lo incluyamos pronto en algún pack. Puedes comprarlo online y solicitarlo a nuestros distribuidores en latinoamérica para que te llegue lo antes posible.

Saludos Malignos!

Dorking & Pentesting con Tacyt: Inyección de comandos

En cualquier auditoría de una aplicación web es importante buscar los puntos en los que se introducen los comandos. Decía Michael Howard que "All input is EVIL until it proves otherwise" para referirse a la necesidad de controlar absolutamente todos los datos de entrada de un sistema sin importar de donde vengan. En el mundo del pentesting, localizar las entradas de parámetros pronto y testear las inyecciones de comandos de las distintas tecnologías es algo básico que se hace siempre.

Figura 1: Dorking & Pentesting con Tacyt. SQL Injection,
LDAP Injection y Command Injection

En el mundo del dorking masivo se ha utilizado mucho en el pasado a través de los buscadores. Hemos visto ataques SQL Injection realizados masivamente que se han llevado millones de aplicaciones web inseguras indexadas en Google, hemos visto campañas de explotación masiva que se han llevado a Apple.com por delante, y hemos visto como a través de buscadores como Shodan o los mismos buscadores de repositorio de código OpenSource se crean dorks para localizar sitios vulnerables. Esto también lo podemos hacer buscando en el código de las apps.

(Blind) SQL Injection

No voy a centrarme mucho en explicar los ataques de SQL Injection o Blind SQL Injection, ya que de ellos he escrito largo y tendido en el pasado e incluso tenéis un libro en 0xWord para profundizar más [Hacking Web: SQL Injection]. En esta parte, cuando comencé a mirar si con las apps se podría llegar fácilmente a localizar sitios de backend vulnerables a SQL Injection comencé por buscar enlaces con parámetros como SQLQuery o Query y luego nombres de aplicaciones en el backend que fueran como MySQL.php, SQL.php, QuerySQL.aspx, etcétera y salió de todo.

Figura 2: Un enlace en una app para conectarse a una base de datos

Como era de suponer, muchas de estas aplicaciones en backend no están indexadas en otros buscadores y por supuesto no están sometidas a los dorks de búsqueda masivos que hay ya creados para todos esos motores, así que aún no han sentido la importancia de revisar mucho el código de ejecución de una consulta SQL para detectar los ataques de SQL Injection.

Figura 3: Código decompilado de una app con ShowMyCode
para ver los parámetros de SQLQuery.php

Algunos de estas aplicaciones envían, como es normal, el envío de parámetros por POST usando un URLEncodedFormEntity, por lo que es cierto que cuando se descubre el enlace, en muchas ocasiones hay que decompilar el código (descomprimir el APK, decompilar el classes.dex, y con los ficheros en Bytecodes .class hacer un ShowMyCode para el ver el fichero Java y sacar los parámetros). El resto, inyectar con cualquier herramienta tipo Burp Proxy o similares.

Figura 4: En el parámetro Query basta con poner la consulta. FAIL!

Buscando por cosas como DBlink, QueryBBDD, BDD.php, SQLServer, etcétera, el resultado es que aparecen miles de resultados que llevan a backends con poca o ninguna protección contra ataques de inyección de comandos SQL.

Figura 5: Otro enlace en una app sin ningún tipo de protección en el parámetros query

(Blind) LDAP Injection

Desde hace años llevo yo jugando personalmente con las inyecciones de comando LDAP - tenéis el whitepaper que hicimos para BlackHat 2009 [(Blind) LDAP Injection] - y uno de los problemas ha sido siempre el encontrar entornos LDAP expuestos en Internet, ya que la mayoría de los árboles están siempre en la red interna. Por eso yo buscada en Shodan, con trucos en Robtex y hasta en las listas CRL de los certificados digitales para poder inspeccionar los árboles LDAP. 

Figura 6: Una app con un backend LDAP

Buscando por LdapSearch, también aparece alguna app que, lógicamente, lleva un enlace que permite inyectar parámetros en LDAP Search filters. Por supuesto, como es un enlace creado para una app, está fuera de los circuitos habituales para los dorks, así que tampoco está muy machacado.

Figura 7: Un LdapSearch en una app con escritura de LDAP Searh Filters

El número de apps utilizando LDAP es alto, así que los dorks para localizar estos entornos facilitan la misión. Teniendo en cuenta que las técnicas LDAP Injection no son "mainstream" y no todo el mundo está puesto con ellas, el resultado es que estas apps casi no tienen ninguna protección contra ellas.

Command Injection

Una vez metidos en harina, buscar cualquier tipo de aplicación web que pudiera tener un bug de estas características no es demasiado complicado. Basta con pensar qué no se debería hacer nunca para ver si a alguien le ha parecido una buena idea. Buscando por apps con Command Injection, busqué enlaces con el parámetro "command" o con la cadena Command.php, o Execute.cgi, o ... lo que se te ocurra.

Figura 8: Un enlace a un command.cgi en una app (con enlace local)

De hecho, después de eso comencé a buscar directamente comandos como mkdir en los enlaces y llegué a este mkdir que cuando se invocaba en el lado del servidor daba un error muy significativo.

Figura 9: Llamada aun programa para hacer directorios en el servidor.
Muchos lo han debido de usar ya.

Al final, la imaginación para hacer los dorks es tuya, y la gracia es que al tener en Tacyt un potente motor de filtros, cada vez que se descubre un nuevo app se le pasa por todos esos filtros. Si por cada dork que se te ocurra generas un filtro, por la mañana solo tienes que leer el feed RSS de tus dorks y ver qué ha caído nuevo.

Mañana la última parte

Si has seguido esta historia hasta aquí, supongo que ya te habrás hecho una idea de que en las apps que subas debes ser muy escrupuloso a la hora de dejar información, pues igual que dejar un leak en una aplicación web puede atraer a muchos atacantes que te localicen por medio de dorks, esto es exactamente los mismo con las apps móviles - peor aún, que también les dejas el código -. Por si queréis aprender más sobre esto, os dejo la referencia del libro "Desarrollo Android Seguro".

Saludos Malignos!

***********************************************************************************

- Dorking & Pentesting con Tacyt: Dominios, IPs y Puertos

- Dorking & Pentesting con Tacyt: Las P@ssw0rds

- Dorking & Pentesting con Tacyt: Las APIs de terceros
- Dorking & Pentesting con Tacyt: Inyección de comandos

- Dorking & Pentesting con Tacyt: Diapos de RootedCon Valencia 2015

***********************************************************************************

Usar Google para descubrir sitos webs con bugs de LFI

Años después, cuando sigo mostrando los sitios defaceados en tiempo real en Zone-h, la gente sigue preguntándome cómo es posible que alguien sea capaz de hacer esos ataques en tanto sitios. No hay ninguna trampa, solo experiencia y técnicas. Lo cierto es que en muchos de esos ataques hay un proceso de automatización basado en el descubrimiento de sitios vulnerables a un determinado fallo o exploit. Es decir, se tiene un exploit para un determinado CMS o Framework de Internet y se automatiza el descubrimiento de servidores con ese software afectado y la explotación del fallo. Por eso hay que tomar medidas de fortificación en los frameworks más populares como Joomla!, WordPress, y similares, ya que cuando se publica un nuevo bug para ellos, se explota de forma automatizada masivamente.

Figura 1: Los sitios defaceados y reportados esta mañana

En otras ocasiones se utilizan herramientas de escaneo automático en busca de vulnerabilidades explotables de SQL Injection, Command Injection, Remote File Inclusion, Métodos Put inseguros o Local File Inclusion, que serán las que más juego den a la hora de subir una Web Shell o meter un fichero para hacer un defacement.

Para localizar las posibles víctimas, desde hace ya muchos años se utilizan los buscadores, que permiten localizar mediante lo que se llamaron "dorks", a los que tienen una determinada característica que denota su vulnerabilidad. Esto se ha utilizado ya en ataques masivos para distribuir malware, buscando fallos de SQL Injection de forma masiva en Google y automatizando la inyección de scripts mediante sentencias Update, como se explica en el libro de Fraude Online. En alguna de ellas llegando a afectar a sitios como la propia Apple.

Saber jugar bien con Bing Hacking, Google Hacking, Shodan, Archive o Robtex es parte fundamental para los defacers, los pentesters, los analistas de seguridad y los investigadores. En el libro de Hacking con Buscadores Enrique Rando cuenta algunos trucos muy interesantes de Google, y explica en detalle cómo utilizar los comodines para localizar objetivos concretos, algo que todos los perfiles citados anteriormente utilizan en algún momento.

Yo uso los buscadores en infinidad de ocasiones para todo tipo de cosas, como para localizar centralitas de VoIP a través de Shodan, localizar sitios vulnerables a HeartBleed por puertos no habituales o para encontrar ficheros ICA usando el operador contains de Bing. Por poner algunos ejemplos de los muchos artículos en los que me han venido.

Por poner un ejemplo de cómo teniendo control de los buscadores se puede sacar petróleo, alguien podría utilizar los comodines para poder localizar sitios vulnerables a LFI (Local File Inclusion). En estas vulnerabilidades lo que se trata de poder acceder a ficheros locales del servidor manipulando los parámetros de algún programa que accede al sistema de archivos donde corre la aplicación web y normalmente se encuentran de dos tipos.

Generalmente las vulnerabilidades más comunes de LFI, llamémoslas de Tipo 1, son ficheros que acceden directamente al sistema de ficheros construyendo la ruta de acceso con algún parámetro que se les pasa desde la URL. Se localizan porque alguno de los parámetros es el nombre de un fichero "loquesea.pdf", lo que atrae la atención del pentester para hacer algunas pruebas, como las que puedes ver en este post de "descubrir un LFI al estilo FOCA" que nosotros automatizamos en nuestro servicio de pentesting persistente Faast.

Figura 2: Descargando el fichero que descarga

Si se descubre el bug, que generalmente se hace intentando descargar el propio fichero que realiza la descarga de los ficheros, basta con introducir la ruta absoluta o relativa,  según sea cada programa de descargas - en el de la Figura 2 se puede ver que es una ruta absoluta cuando el parámetro que se usa es "fichero" y relativa cuando el parámetro que se usa es "serie" -, para pedir el fichero que se desea obtener del servidor.

Figura 3: Un LFI en una web para acceder a /etc/passwd con ruta absoluta

En otras ocasiones, las que llamaremos de Tipo 2,  no viene ningún nombre de fichero como parámetro, pero el nombre de la aplicación es algo como "descargarfichero.php" o el nombre del parámetro es "fichero=identificador", lo que indica que probablemente con ese parámetro se esté accediendo a una tabla en una base de datos - o un fichero XML que sería otra historia de XPath Injection - de la que se está recuperando o el nombre o la ruta completa del fichero. En esos casos hay que hacer un ataque de SQL Injection buscando inyectar la ruta del fichero buscado.

Es decir, en una aplicación en la que apareciera algo como fichero=23, y en la que el programador generase una consulta para acceder a la ubicación donde se almacena el fichero de forma similar a esto:

$SQLCommand="Select ruta from ficheros where id="+$_GET["fichero"]+";"; 

Lo que se debería hacer el algo como:

fichero=-1 union Select '/etc/passwd'

En cada motor de base de datos y en cada aplicación programada habría que ver cómo ajustar la cadena de inyección, pero en regla general sería algo así, pero eso es otra historia para otro libro.

Para las vulnerabilidades del Tipo 1 - que es lo que os venía a contar en esta historia - como en Google se pueden usar los comodines y el truco de la barra para jugar con las búsquedas, se pueden hacer dorks para localizar aquellas URLs que cumplan una serie de condiciones, por ejemplo que tengan la palabra php file y pdf con un patrón, o que sea lo mismo pero en Español.

Figura 4: Muchos resultados para jugar y probar

Figura 5: Miles de ellos en Español

Al final, estos dorks - dale al enlace de "Mostrar más resultados" - muestran una cantidad de sitios que cumplen esa estructura en su URL y que para cualquier herramienta automatizada para la búsqueda de bugs de LFI siguiendo unos patrones será fácil explotar.

Saludos Malignos!

Hacking con buscadores en los repositorios Open Source

En la última conferencia Asegúr@IT que impartimos en Málaga participó el gran Enrique Rando con una charla sobre Hacking con Buscadores. En esa charla enseñaba trucos avanzados de cómo sacar provecho a todo lo que había escrito en su libro de Hacking con Buscadores e hizo algunas demos muy impactantes. Entre otras cosas utilizaba unos dorks para buscar las vulnerabilidades directamente en los repositorios de código para localizar proyectos Open Source con bugs de SQL Injection que después pudieran ser explotados en sus instalaciones en real. Aquí hay algunas de las demos que realizó, con un ejemplo de búsqueda de Command Injection localizando herramientas que hacían Ping.

Figura 1: Demos de la presentación de Enrique Rando en el Asegur@IT 9 de 2011

El analizar los proyectos Open Source no es nuevo, y las empresas de búsqueda de bugs que se dedican profesionalmente a esto, tienen sus analizadores de código conectados a todos los repositorios para revisarlos constantemente, ya que ahí puede salir de todo. Nosotros lo hicimos también tras publicar las técnicas de Blind LDAP Injection para localizar proyectos vulnerables.

En la última Hack.Lu 2013 los investigadores Dennis Pellikaan y Thijs Houtenbos de la Universidad de Amsterdam han impartido una charla analizando los proyectos de de GitHub y SourceForge para localizar vulnerabilidades SQL Injection, Remote File Injection y de Command Injection, utilizando para ello dorks para localizar instrucciones como estas.

Figura 2: instrucciones vulnerables a buscar en los proyectos de GitHub y SourceForge

Por supuesto, de los resultados iniciales han tenido que ir filtrando todo para quitar los que tengan protecciones extras que invaliden la vulnerabilidad, para lo que se implementan una especie de analizador de código estático utilizando expresiones regulares que filtren los que tienen alguna protección de los que no tienen ninguna.

Figura 3: Expresiones regulares para localizar los bugs en el código

Una vez tienen esto, el resto es automatizar la búsqueda de estos proyectos por medio de dorks en Google o BING para hacer un poco más de hacking con buscadores, saltándose para ello los captcha del motor de búsquedas haciendo uso de Round Robin sobre 13 distintas direcciones IP y realizando una petición cada 8 segundos, lo que les permitió localizar unas 122.000 URLs vulnerables y explotables indexadas por los buscadores.

Figura 4: Por tipo, los bugs más localizados siguen siendo SQL Injection

Estas URLs encontradas se convierten en maná para los distribuidores de malware, los amigos del Fraude Online, los especialistas en Black SEO, ya que con un kit de exploits actualizado podría permitir llegar a millones de usuarios para crear unas buenas botnets de gran tamaño.

Figura 5: Proyectos vulnerables y distribución de ellos en repositorios de código

En la presentación hay también resultados de porcentajes de proyectos vulnerables o no con estas tres vulnerabilidades analizadas, y los resultados son bastante malos, tal y como se puede ver en estas gráficas, así que si vas a poner un proyecto Open Source, procura que sea uno mantenido y cuidado - que los hay - y no uno subido y abandonado en su repositorio de código - que los hay -.

Saludos Malignos!

¿Dónde meto mi webshell? Métodos inseguros con Shodan

Esta tarde a las 16:00 comienza el Curso Online de Auditoría y Seguridad Web, y ayer estuvimos discutiendo un poco sobre él. Preparando una de las clases que van sobre Hacking con Buscadores, estuvimos mirando algunas demos que hacer con Shodan, este simpático buscador que te permite encontrar casi de todo y que nosotros siempre utilizamos en nuestras auditorias de aplicaciones web.

En este caso, la gracia era buscar aquellas respuestas en servidores HTTP que ya directamente, sin necesidad de hacer un escaneo de OPTIONS, informan de que soportan el método PUT, para poder subir una webshell.

Figura 1: Método PUT permitido en Allow

Que el servidor web devuelva que soporta el método PUT no quiere decir que luego esté implementado y que los permisos que tenga en el sistema de ficheros sean los necesarios para poder escribir los ficheros, pero viendo la gran cantidad de sitos donde se aparecen con un programa que pruebe en todos ellos las probabilidades de desplegar webshells por Internet de forma masiva son altas. Pero si lo que se busca es una vulnerabilidad, puede que con un DELETE sea más que suficiente para tirar abajo una aplicación web.

Figura 2: Servicio con método DELETE permitido

Otra de las cosas que también es posible encontrar, es no solo los métodos en Allow, sino también los permitidos en Access-Control-Allow-Methods, que aunque son políticas para peticiones AJAX Cross-Domain, es más que probable que, si tiene el método PUT permitido para ellas, es más que probable que también lo tenga como método HTTP.

Figura 3: PUT y DELETE en Access-Control-Allow-Methods

Puestos a buscar por métodos en inseguros en Shodan, es posible encontrar todos ellos, pasando por DELETE, COPY, y los utilizados en servidores documentales como SharePoint para solicitar bloqueo de ficheros o acceso a propiedades. 

Figura 4: Servidor documental con Access-Control-Allow-Methods para casi todo

Actualmente, los métodos inseguros en FOCA los buscamos con un escaneo de OPTIONS, que es un poco más inteso en cómputo, pero más exhaustivo, pero si está bloqueado el método Options en el firewall, mirar las cabeceras Allow y Access-Control-Allow-Methods puede dar aún información útil.

Saludos Malignos!

Curso Online de Auditoria y Seguridad Web

A partir del próximo día 16 de Octubre dará comienzo un Curso Online de Auditoría y Seguridad Web compuesto de 20 seminarios online de dos horas de duración cada uno, que se harán en horario de 16:00 a 18:00 - hora local en Madrid (España) -, y tendrá lugar todos los martes, miércoles y jueves hasta el día 29 de noviembre de 2012.  El curso lo vamos a impartir desde Informática 64 y este es el calendario y temáticas que abarca esta formación:

Octubre de 2012

16/10: Introducción a la auditoría Informática
17/10: Google Hacking y Shodan Hacking
18/10: Metadata Security
23/10: Fuzzing y Crawling
24/10: Análisis de capa de seguridad SSL
25/10: Auditoría a un CMS
30/10: Exploiting con Metasploit
31/10: Post-Explotación con Metasploit 

Noviembre de 2012

06/11: Herramientas de Metasploit
07/11: Cross-Site Scripting (XSS)
08/11: Cookie Spoofing e Hijacking
13/11: SQL Injection: Manual
14/11: SQL Injection: Automático
15/11: LFI/RFI/RFD
20/11: Clickjacking, Full Path Disclosure y contramedidas
21/11: (Blind) LDAP Injection/XPATH Injection y CSPP
22/11: Fortificación de IIS
27/11: Fortificación de servidor Apache, PHP y Análisis de código I
28/11: Fortificación de servidor Apache, PHP y Análisis de código II
29/11: Fortificación de servidor Apache: Mod_Security

A esta formación te puedes apuntar en solitario, en un grupo hasta de 5 personas y a un único seminario, es decir, no pagar el curso entero sino sólo el seminario que quieras hacer. En el siguiente enlace podrás ver con más detalle toda la información relacionada con esta formación: Curso Online de Auditoría y Seguridad Web

A parte de esta formación, esa semana también está el Curso Avanzado de Desarrollo de Aplicaciones iOS para iPhone & iPad en Madrid, y a finales de mes tenemos el Asegúr@IT Camp 4, donde nos lo vamos a pasar genial }:))

Saludos Malignos!

Ejecutar código remoto en Apache con PHP en modo CGI

El pasado 3 de Mayo ha salido a luz un serio bug, identificado con el CVE-2012-1823, que afecta a todas las instalaciones de PHP en modo CGI, que permite llamar directamente desde el la URL a los parámetros del motor PHP, lo que provoca que se pueda ejecutar código remoto en cualquier servidor con una instalación vulnerable.

Figura 1: Parámetros de llamada del motor PHP

Con estos parámetros se pueden hacer cosas bastante curiosas, como se puede ver en la ayuda del motor PHP, entre los que tenemos -s, que deja ver el código fuente del código a ejecutarse. Esto permite que con un sencillo -s en la URL el servidor web muestre el todo el código del sitio PHP que estamos visitando, y poder acceder a toda la información de configuración que allí se encuentre.

Figura 2: Código PHP mostrado desde la llamada de la URL

Por supuesto, con el modificador -d es posible incidir en los parámetros de ejecución del motor PHP, pudiendo escribir nuestro propio código en el servidor, por ejemplo, para obtener un phpinfo que nos de todas las variables del servidor.

Figura 3: info.php obtenido por medio de una llamada al motor PHP con -d

Y si se desea ejecutar una webshell, se puede modificar la configuración directamente desde la URL para insertar la webshell remotamente, en este ejemplo una C99.

Figura 4: Introduciendo una C99 por medio de una llamada al motor PHP

PHP ha publicado un parche de urgencia, pero tiene una vulnerabilidad que hace fácil saltárselo, y se ha abierto un nuevo expediente CVE-2012-2311 para seguirlo. Pero la historia del bug es aún más curiosa. El estándar CGI permite que se envíen desde el query string argumentos al ejecutable que se encargue de la ejecución, y Apache lo implementa. En el año 2004 se supo de los problemas que esto podría acarrear en entornos PHP y la documentación dice que PHP, cuando se ejecute en modo CGI ignorará esos argumentos... pero en algún momento de aquel 2004 alguien quitó el código de protección.

En el CTF de la NullCON se utilizaron los servidores de DreamHost para el llevar la puntuación, y al final se encontró el bug para conseguir ejecución de código y ownear el servidor. Ahora Internet está revuelto. Tienes toda la historia de este ya famoso bug en el post de publicación del fallo.

Ya está implementado el ataque en Metasploit, y por supuesto, nosotros estamos metiendo esta comprobación a la FOCA, por lo que los que tengáis la versión PRO en breve tendréis ya en la nueva actualización esta búsqueda, junto con alguna sorpresa más.

Saludos Malignos!

¿Es seguro mi Joomla o mi WordPress?

En muchas ocasiones, tras acabar alguna de las demos que solía hacer hace mucho tiempo - tanto que hasta si alguna de ellas infringía alguna ley a día de hoy ha prescrito - alguien se acercaba y me decía:

"Yo tengo en mi web un {Wordpress o un Joomla o un loquesea}, ¿es seguro?"

Lo cierto es que nuestro trabajo cuando hay que hacer la auditoría de seguridad es buscar todas las configuraciones inseguras, pero decirlo a la primera es siempre difícil. De cualquier modo, lo que nosotros hacemos es inventariar lo que hay en un sitio, separando lo que ha sido hecho a mano, es decir, programado sólo para esa web, y lo que es utilizado de un software común.

Una vez inventariado, en los códigos artesanos intentamos encontrar las vulnerabilidades nosotros, haciendo auditoría de caja negra, pero en los códigos comunes, antes de hacerlo, buscamos a ver si hay exploits ya publicados por otros. Uno de los trucos que aparece en el libro de Hacking con Buscadores: Google, Bing y Shodan, es utilizar directamente Shodan para buscar los exploits de los componentes utilizados en los sitios web.

Así, si llegamos a un sitio donde hay un Tomcat, basta con irse a Shodan Exploits y buscar por allí a ver que vulnerabilidades/exploits están disponibles. Shodan está indexando las bases de expedientes de seguridad de muchos sitos para centralizar el proceso de búsqueda.


Figura 1: Búsqueda de exploits para Tomcat
En el caso de aplicaciones Web con CMS, lo más fácil es revisar la lista de plugins y buscar si hay bugs conocidos para ellos. Así, si nos enfrentamos a una web con Joomla, se hace inventario de componentes y luego se busca esta lista.


Figura 2: Exploits para componentes Joomla (aunque no creo que esté el nuestro)
Y pasa exactamente lo mismo con la lista de plugins en Wordpress, para ver si alguno de los que está en la web a analizar está sin parchear y se puede hacer uso de algún XSS, un SQL Injection o un lindo y simpático RFI/LFI.


Figura 3: Búsqueda de exploits para plugins de Wordpress
¿Por que hacemos esto? Pues porque suelen ser los puntos menos controlados de estos CMS. Normalmente, por necesidad, se busca algún componente que haga algo que se quiere poner en el sito, pero luego se suele quedar fuera de los procesos de actualización.

Si tienes un CMS, sea del color que sea, te recomiendo que hagas un inventario de los plugins/componentes que has puesto en él, y busques a ver si hay bugs/exploits conocidos. Te aseguro que los "malos" van a hacer esto mismo.

En el caso de Wordpress y Joomla! aquí tienes algunos recuersos que te pueden ayudar a mejorar su seguridad:

- Listar los plugins de WordPress
- Fortificar WordPress frente a ataques de fuerza bruta
- Instalar Latch en WordPress
- Regístrate en WordPress y evalúa su seguridad
- Cómo robarle las contraseñas a los Administradores de WordPress con XSS haciendo Phishing con Unfiltered HTML
- Guías detalladas de instalación de Latch en Wordpress, Joomla, Drupal, PrestaShop y RoundCube
- Activa o desactiva el acceso al frontend o backend de Joomla 2.5.x y 3.x con Latch
- Hardening GNU/Linux

Saludos Malignos!