AutorZerial

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

Clonación de máquinas virtuales en serie

En el lugar donde trabajo, he estado montando y monitoreando muchas máquinas virtuales (gnu/linux sobre gnu/linux). En un principio, las máquinas estaban virtualizadas con VMWare, eran sólo 3 máquinas. Luego estas máquinas fueron aumentando a 5, 10 y actualmente ya son 20 máqiunas. La empresa donde trabajo ofrece el servicio de email marketing en base  a newsletter y “fidelización de clientes“, y soy yo quien debe administrar los servidores de envios de correos. Se envían más de 500 mil emails semanales por lo que el uptime y la disponibilidad del servicio debe ser la más alta.

fide

Para ésto, decidí migrar todas las máquinas a Xen y comenzar a para-virtualizar todos los servidores de envios (nosotros les llamamos “smtp“). Si pensamos que su única función es enviar correos (ya que, de la lógica del servicio se encarga otro servidor), las caracteristicas de cada smtp son muy básicas:

  • 128MB ram
  • 2Gb disco
  • Servicios: postfix, ssh

Para lograr el objetivo, me dediqué a crear un script que me automatiza la creación y configuración de máquinas virtuales.

Seguir leyendo

Acceder a una base de datos, que sólo permite conexiones desde localhost, remotamente

Hace unos días recibí un correo preguntandome cómo acceder -remotamente- a un servidor de base de datos que sólo acepta conexiones desde localhost, sin tener phpMy/PgAdmin ni acceso “directo” (ssh) al servidor. Responderé publicamente la pregunta.

s_key

La respuesta a primera vista sería “Es imposible, ya que sólo tiene permitido ingresar desde localhost y, generalmente, el puerto no está a la escucha de 0.0.0.0” pero si vamos más allá y tenemos un poco de imaginación, podemos llegar a pensar de que si es posible; jugando un poco con los conceptos y aplicando distintas técnicas de penetración y de búsqueda de vulnerabilidades que nos lo permitan.

La idea de ingresar “remotamente” queda descartada si pensamos en conectarnos directamente a la base de datos desde un client externo, pero podemos pensarlo cómo el hecho de lograr acceder (remotamente) de una u otra forma para lograr la conexion con el host. Por ejemplo, subiendo un fichero php que tenga las líneas necesarias para conectarse a la base de datos y hacer lo que necesitemos.

No vamos a usar fuerza bruta ni técnicas de robo de información, simplemente nos aprovecharemos de algunas vulnerabilidades comunes.

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

Denial-of-Service (DoS) rápido y de una forma muy sencilla en WordPress

pwnpressjcarlosn ha descubierto una vulnerabilidad en el fichero wp-trackbacks.php de wordpress, la cual nos permitiría hacer un tipo de denegación de servicio (DoS) con unas cuantas peticiones y sin necesidad de botnets o maquinas zombies.
Como él mismo nos cuenta:

Este error, es explotable desde cualquier conexión a internet, y no requiere de ordenadores zombies, ni de nada, son sólo 20 peticiones a lo sumo, desde una línea ADSL convencional, para dejar K.O. a cualquier servidor que hospede un blog basado en wordpress.

El problema fue reportado a la seguridad en wordpress.com y no se obtuvo respuesta, luego se intentó comunicar con el creador de wordpress y al pasar un par de días, obtuvo una respuesta de que lo solucionarán en algún momento pero no de la forma que él proponia, sino que ellos mismos buscarán cómo hacerlo.
La misma persona que hizo público este bug, publicó un exploit y una posible solución.

Seguir leyendo