EtiquetaSeguridad

Inseguridad de redes inalámbricas en cafeterias, pubs, hoteles, etc

hackwifiMe gustaría escribir un poco sobre el tema de la seguridad en las redes inalámbricas que uno se encuentra cuando va a alguna cafetería, hotel, pub, restorante, etc. Es muy común que sólo las personas que consuman algún producto en el local tengan acceso a wifi, para esto la súper medida de protección que se toma es entregar en un papelito la clave de la WiFi y que, aunque no lo crean, generalmente es una clave WEP y más todavía, muchas veces es una clave por defecto entregada por el proveedor. Este tipo de accesos muy pocas veces (por no decir nunca) cuentan con un portal cautivo o captive portal, algún tipo de protección o filtro en un firewall, proxy, etc y para rematar, este tipo de señales son emitidas con los típicos router de marca dlink (sí, esos baratos) o bien uno de marca X que cueste poco dinero.
La mayoría de la gente que acude a éste tipo de lugares, no son expertos informáticos o en seguridad ni tienen mucho conocimiento en temas de protección de información, redes inalámbricas, etc. Generalmente son personas “normales” que se compran un portatil (pc, mac o lo que sea) y se conectan a una red donde sea que la pillen. Realizan sus transferencias (desde su banco online), revisan su correo, inician sesión en los servicios que tengan cuenta, chatean, etc sin ni si quiera preocuparse (yo diría que ni si quiera se imaginan) de que alguien puede estar leyendo y/o observando todo lo que está haciendo, filtrando y guardando información.

¿Y cómo termina todo esto?
Por ejemplo, con ésto.

Seguir leyendo

Atacando desde el corazón

Hay dos técnicas para atacar un objetivo desde “el corazón”, una es ingresando remotamente a alguno de los servidores mediante algún servicio o alguna vulnerabilidad en el sitio web y la segunda, es ingresando directamente a la red de área local o LAN. Existen muchas vulnerabilidades conocidas y comunes que nos permiten ingresar a lugares confidenciales de nuestro objetivo, donde podemos rescatar informacion sensible de lo que buscamos como usuarios, accesos a sistemas o servidores, etc.
Para llevar acabo el segundo plan, es necesario conocimientos en seguridad de redes WiFi, ésta técnica es más divertida y práctica que la anterior.

La idea de este post es explicarles, en base a mi experiencia, ambas técnicas. En especial la segunda. Existen muchas empresas que exhiben su red en una señal wifi pública con cifrado WEP y es por esto que quiero dar mayor énfasis a éste tipo de penetración.

Seguir leyendo

[Proof-of-Concept] DoS gracias al script wp-trackbacks de wordpress

Un par de horas atrás, publiqué un artículo luego de haber leído una publicación de jcarlosn. Me di el tiempo de realizar una prueba de concepto (PoC) usando el exploit que él mismo propone. Si bien el código que él publicó tiene algunos problemas, luego de hacerle un par de modificaciones logré ejecutarlo y analizar su comportamiento y ver cómo sufre el servidor objetivo.

Duración de la prueba de concepto: 2 minutos
Sitio o servidor objetivo: blog.zerial.org
Tipo de exploit: remoto
Vulnerabilidad: Resource Exhaustion (DoS)
Descripción: El servidor comienza a consumir recursos hasta agotarlos, provocando la denegación del servicio.

wpress-test

Ejecuté el exploit en tres consolas distintas de forma simultanea, y al pasar 10 o 15 segundos ya se comenzó a notar el consumo de recursos en el servidor.

Seguir leyendo

Más Full Path Disclosure en WordPress y sin solución

Hace unos días publiqué un artículo sobre varios plugins que nos permitian ver el directorio completo de la instalación de wordpress (full path disclosure). Luego de esta publicación de una discusión en un hilo de la lista en full disclosure, me llegó un correo donde me comentaban que no sólo eran esos ficheros los que tenian esta vulnerabilidad, sino muchos más dentro de todo el sistema de wordpress.pwnpress
En la lista full disclosure y por otros medios, la gente me decia que eso se desactivaba facilmente deshabilitando la opcion “display errors” de php (ya sea en el php.ini, htaccess o en el mismo fichero php) pero mi opinión fue siempre la misma: Esta forma de ‘solucionarlo’ ocultaría el error pero en ningún caso lo solucionaría, es decir, el problema continuaría estando, pero oculto. Otras personas dieron otro tipo de solución como la de editar los ficheros e incluir una validación de la existencia de algunas constantes o variables que WordPress setea y, de esta forma, saber si el fichero se está ejecutando directamente o mediante wordpress.

Este problema lo reporté a security en wordpress.com el mismo día que hice la publicación pero no obtuve respuesta.

Ahora les mostraré los otros ficheros por los cuales es posible descubrir la ruta completa del sistema y las posibles soluciones que me han palnteado.

Seguir leyendo

Cómo validar correctamente la descarga de un archivo en php

Este post es debido a un correo que recibí preguntando como evitar el full path disclosure y el directory transversal desde un fichero php que realiza descargas. El error que plantearé a continuación es muy común en muchos sistemas web y ya he publicado varias webs vulnerables con este mismo problema. Corresponde a la forma de descarga tipo download.php?dir=ficheros/&file=test.pdf.

secure

Con una URL de este tipo, es posible forzar un FPD modificando las variables “dir” y “test”, cambiadolas por cualquier cosa que sepamos que no existe y de esta forma obtendremos un fichero php con un error, el cual nos revelará el path de la aplicación. Si cambiamos el valor de la variable “dir” a “../../../../../../etc/” y “file” a “passwd”, es muy probable que nos deje descargar el fichero /etc/passwd, lo mismo con cualquier otro fichero. De esta misma forma, podemos ir descargando uno a uno los códigos fuentes del sistema php y poder acceder a los usuarios y claves de conexion a la base de datos y otro tipo de información confidencial.

Seguir leyendo

Vulnerabilidad en la mayoría de los plugins para WordPress

pwnpressHace un par de días, mientras hacia unas pruebas y revisaba unos sistemas descubrí una vulnerabilidad que afectaba a unos cuantos plugins de WordPress instalados.
Continuando mi investigación llegúe a la conclusión de que se trata de una vulnerabilidad Full Path Disclosure (FPD) que afecta a la mayoría de los plugins de WordPress, incluyendo al “Hello Dolly” y Akismet (plugins por defecto). Para explotar esta vulnerabilidad, no es necesario que el plugin esté activo, simplemente que esté instalado. Esta vulnerabilidad es debido a un problema o error a la hora de programar los plugins, al no validar la existencia de funciones antes de ejecutarlas el sistema devuelve un error fatal, mostrandonos la ruta completa de la instalación del CMS. Por ejemplo, en Akismet:

Fatal error: Call to undefined function add_action() in /home/XXYYZZ/public_html/wp-content/plugins/akismet/akismet.php on line 26

Hablando un poco sobre la vulnerabildiad FPD y recordando lo que dije en el post pasado, explotar esta vulnerabilidad no significa que podamos hacer grandes cosas, simplemente nos entregará información que podría ser utilizada para lo que uno estime conveniente.

Seguir leyendo