Magento Repair Tool: Un XSPA a quitar de tu e-Commerce

El framework Magento es uno de los entornos Open Source más populares dentro del mundo del e-Commerce. Está detrás de una gran cantidad de tiendas en Internet y es fácil toparse con él en una auditoría de seguridad web. En el pasado os había hablado de él cuando me topé con Magento Chek, una pequeña utilidad de comprobación del estado de configuración del framework que podría ser muy útil para hacer una pentesting a la tecnología web, y hoy os vengo a hablar de otro.

Figura 1: Magento Database Repair Tool. Un XSPA a quitar de tu e-Comerce

En esta ocasión se trata de una herramienta especial para corregir un error en la instalación del servidor. En concreto se llama Magento Database Repair Tool, y es una utilidad para troubleshooting en caso de que la base de datos se quede corrupta por alguna de las situaciones explicadas en la documentación de dicha herramienta.

Figura 2: Cuándo usar Magento Database Repair Tootl

Localizarla en Internet, como me apuntó mi amigo rootkit, no es nada complicado. Basta con usar un dork como éste que se ve en la imagen para que, con un poco de Hacking con Buscadores lleguemos a muchos servidores con ella instalada.

Figura 3: Dork para localizar Magento Database Repair Tool en Google.

Una vez que tenemos esta herramienta, es fácil darse cuenta que puede ser utilizada para hacer ataques de XSPA (Cross-Site Port Attack), ya que con poner en la dirección del servidor con la base de datos corrupta la dirección IP y el puerto a escanear, tenemos los mensajes de error que necesitamos para diferenciar un puerto abierto o un puerto cerrado.

XSPA: Escaneado de puertos con Magento Database Repair Tool 

Si el puerto está cerrado, el mensaje de error que obtenemos (después de esperar unos segundos) nos dirá se ha perdido la conexión con el servidor y que no se ha podido hacer nada.

Figura 4: Puerto cerrado. El mensaje informa de "Lost Connection" 

Por el contrario, si el puerto está abierto, el mensaje nos dirá que no se ha podido conectar a la base de datos MySQL que supuestamente debería estar allí. 

Figura 5: Puerto abierto. El mensaje informa de "Can´t connect to MySQL"

Por supuesto, si en ese puerto nos encontráramos con una base de datos MySQL, el mensaje de error volvería a cambiar a un Login Failed que nos indicaría que no tenemos credenciales adecuadas para conectarse con el servidor de bases de datos (y si las tenemos, aún mejor).

Escaneo de DMZ y fortificación de Magento

Con estos mensajes de error, es fácil automatizar un ataque de XSPA para escanear cualquier servidor de Internet o de la DMZ, tal y como se ve en este equipo en el que descubrimos una dirección IP interna con un puerto de Telnet abierto.

Figura 6: Servidor en la DMZ con puerto 23 abierto

Al final, esta herramienta que se instala aparte, no debería estar dentro del path de publicación del sitio web en Internet, así que si la tienes, restringe el acceso a Magento Database Recovery Tool con una lista de control de acceso.

Figura 7: Configuración y uso de Latch en Magento Community

Para terminar, solo como recordatorio, acuérdate de quitar (o restringir su acceso) a Magento Check y añade para fortificar aún más tu entorno Latch a Magento que desde el año pasado está disponible una integración de Latch con Magento Community que tienes disponible.

Saludos Malignos!

Time-Based XSPA (Cross-Site Port Attack) en DBKISS

No hace demasiados días os hablé de un bug de Time-Based XSPA en los scripts de instalación de WordPress, y hoy os quiero hablar de otro caso similar con un WebGUI para administrar motores de bases de datos MySQL y PostgreSQL que se llama DBKiss. Es un bug curioso que en este caso se explota bien con el driver de PostgreSQL. Os lo explico en este post.

Figura 1: Time-Based XSPA (Cross-Site Port Attack) en DBKiss

Los bugs de XPSA (Cross-Site Port Attack) se basan en la explotación de un SSRF (Server-Side Request Forgery) mediante la que un atacante fuerza a la aplicación a realizar una determinada conexión a un servicio que se encuentra en un servidor corriendo por un puerto para poder así escanear los puertos de un servidor objetivo. En este caso, aprovechándonos de que la aplicación vulnerable es un WebGUI que muchos usuarios implanta en sus sitios web para gestionar la base de datos MySQL de WordPress o de cualquier otro CMS, basta con manipular los datos de la cadena de conexión.

Figura 2: Un DBKiss gestionando el MySQL de un WordPress

Hay que tener cuidado con publicar estos scripts a la ligera, pues muchas veces son herramientas en proceso de desarrollo o con vulnerabilidades conocidas. Basta con ver el código fuente de DBKiss para darse cuenta de que aún le quedan muchas cosas que corregir a esta herramienta antes de poder instalarse y publicarse a Internet, ya que se estarían asumiendo muchos riesgos.

Figura 3: Cosas aún por solucionar en los comentarios de DKiss (XSS y CSRF)

El peligro de poner estos scripts vulnerables a estas técnicas de XSPA es que el servidor objetivo al que se quiere escanear puede estar dentro de la DMZ, es decir, con direccionamiento en la red local, ya que basta con que el servidor web tenga conectividad con ellos. Con un aplicación web vulnerable a XSPA en un servidor de la DMZ, un atacante podría hacer un mapa detallado de todos los servidores y todos los puertos que estos tienen abiertos.

Time-Based XSPA en DBKiss

En el caso de los ataques de Time-Based XSPA, el atacante mide el tiempo de respuesta de cada conexión para saber si es un resultado que indica que el puerto está abierto, o un un resultado que indica que el puerto está cerrado. Para esto, en las cadenas de conexión a bases de datos el bug se aprovecha de que la configuración de la conexión no tenga un Time-Out bien configurado que evite que el atacante pueda medir las diferencias temporales en las respuestas sin error.

Figura 4: Con la conexión al puerto 80 usando el driver de PostgreSQL el tiempo de respuesta es corto

Como se puede ver, si forzamos una conexión con DBKiss contra un servidor con un puerto abierto, en este caso contra el puerto 80 de la web de Eleven Paths utilizando el driver de PostgreSQL, podemos ver que se obtiene un tiempo de respuesta muy corto.

Figura 5: Con el puerto cerrado el tiempo de respuesta es muy alto y salta el Time-Out por defecto

Si hacemos lo mismo contra un puerto que esté cerrado, lo que pasamos a obtener es un tiempo de respuesta muy largo que llega a generar un Time-Out en la web, es decir, que el tiempo configurado por defecto de Time-Out en la conexión de la base de datos es mayor que el Time-Out configurado en el servidor web.

Figura 6: Hay que configurar el Time-Out en la conexión a PostgreSQL para evitar este leak

Al final, estas vulnerabilidades abren la captura de información de la infraestructura de una organización a un atacante que en un APT será de gran utilidad para poder planificar el siguiente paso del ataque. Cuidado con lo que publicas en tu servidor web.

Saludos Malignos!

Cómo explotar un SSRF (Server Side Request Forgery) y hacer un XSPA (Cross Site Port Attacks) a una DMZ

Las vulnerabilidades SSRF (Server Side Request Forgery) y los ataques de XSPA (Cross Site Port Attacks) son dos fallos de seguridad que van casi siempre de la mano. Los bugs de SSRF se producen en aplicaciones web inseguras que permiten a un atacante forzar al servidor web a realizar peticiones desde dentro del sistema hacia el exterior. Usando esas conexiones, los ataques de XSPA tratan de conocer, en base a las respuestas obtenidas, la lista de puertos que se encuentran abiertos o por el contrario cerrados en el servidor al que se fuerza la conexión.

Figura 1: Cómo explotar un SSRF y hacer un XSPA a una DMZ

Es importante tener claro que estas vulnerabilidades afectan al Back-End y que vienen conducidas por una mala validación en el Front-End o API al poder ser manipuladas las direcciones a las que se le van a realizar peticiones desde el Back-End. La principal ventaja para un atacante de que las peticiones sean realizadas desde dentro de la red en la que se encuentra el sistema vulnerable es que le van a permitir acceder a sitios que de otra manera no podría (pivoting), tal como sucede cuando estamos conectados a nuestro router y podemos acceder a las maquinas conectadas a nuestra red local.

SSRF & XSPA en buscadores y paneles de administración con CSPP 

Estos fallos son muy típicos, y ya los hemos visto en un buen número de sitios. En el artículo de Buscadores como arma de destrucción masiva se hablaba de posibles ataques de SSRF utilizando la indexación maliciosa o los agregadores de noticias, que permitían por ejemplo que un servidor lanzara un ataque de SQL Injection sin interacción alguna del atacante.

Figura 2: Ejemplo de utilización de un agregador de noticias para realizar ataques SSRF

Un caso curioso de SSRF son los paneles de administración expuestos en Internet, como sitios de configuración de impresoras HP que permiten escanear la DMZ completa, o los casos de bugs de Connection String Parameter Polution, tanto de bases de datos MySQL como de tecnologías .NET. Con ellos hemos visto lo fácil que es realizar ataques de XSPA (Cross Site Port Attacks) aprovechando estas vulnerabilidades de SSRF o CSPP, como en el caso de las herramietnas MyLittleAdmin.

Figura  3: XSPA en MyLittleAdmin for SQL Server

Como se ve, aprovechando la ventaja de que sea el Back-End el encargado de realizar peticiones internamente y que estas a su vez puedan ser manipuladas, permitiría a un atacante apuntar a direcciones IP internas y ya sea visualizando la respuesta o en base a tiempos dibujar un mapa de los activos de la red interna o conocer los puertos abiertos. A continuación les dejo una serie de enlaces donde se documenta cómo explotaron este fallo en sitios de Yahoo!, Facebook o Coinbase, por poner solo algunos ejemplos:

• Yahoo! SSRF/XSPA Vulnerability
• XSPA / SSRF bug with Facebook's Developer Web Application
• SSRF/XSPA Bug in Coinbase

SSRF/XSSA usando ScreenShots

El siguiente caso que les traigo me pareció interesante, vendría a ser algo así como SSRF/XSSA aprovechando un sistema implementado para hacer ScreenShots en aplicaciones web. Esto es algo similar a lo que se publicó por aquí en el artículo de "Jugando con los ojos", donde aprovechando un sistema de captura de pantallas en distintos navegadores se hacían ataques a terceros servidores.

En este caso se trata de una aplicación web hecha en ruby on rails que a través de un sencilla interfaz web, recibe una URL o dominio que luego es enviada a un servicio externo que consulta en su base de datos quién es el propietario del dominio - lo que viene a ser un Whois -. Una vez el servicio Whois devuelve una respuesta a la aplicación web, ésta - además de imprimir dichos datos a través del navegador- seguidamente realizará una captura de pantalla levantando un navegador que visitará la misma dirección.

Figura 4: Funcionamiento normal de la web con el screenshot de Google

Como se puede ver en el navegador aparece en la parte inferior derecha una imagen de la página principal de google.com, al inspeccionar el elemento se puede comprobar que el nombre de la imagen parece ser un Hash MD5 por los 32 caracteres de longitud, que efectivamente corresponde a la concatenación del dominio más un slash tal que así google.com/.

Figura 5: Nombre de la imagen vinculada al screenshot

Escaneando la DMZ interna

Entonces, recordando la ventaja que supone que sea el servidor web el encargado de realizar la petición, por su conectividad con el resto de máquinas de su red interna, se podría realizar un escaneo completo de la DMZ. Para ello sería cuestión de ir probando a enviar por el parámetro uri, diferentes direcciones IP locales con la esperanza de obtener capturas de pantalla de máquinas de la red interna que tengan corriendo en el puerto 80 aplicaciones con interfaz web. Para ello bata con lanzar varias peticiones enviado varias direcciones IP locales, desde la 192.168.0.1 a la 192.168.0.24, y una vez el servicio externo hubiese procesado la dirección IP y devuelto la respuesta, se realizaría la captura de pantalla contra el servidor web en dicha dirección IP.

Figura 6: Resultados del escaneo completo de la DMZ

Ya por último teniendo un listado de las rutas a las imágenes que contiene las capturas realizadas, bastaría con acceder a cada una de ellas para comprobar si contenían algo interesante o simplemente estaban en blanco.

Figura 7: Resultados obtenidos con Burp

Después de realizar peticiones e intentar acceder a cada uno los enlaces con las imágenes, pude ver que algunas tenían un peso mayor que otras, dando a entender que algunas capturas realizadas contra algunas direcciones IP locales SÍ contenían información,  y por lo consiguiente alguna aplicación web corriendo sobre la máquina con dicha dirección IP. Ordene el listado de las imágenes por peso y fui visualizando cada una de ellas, algunas contenían información muy sensible y otras simplemente el típico banner de un servidor Apache.

Nota de reflexión final

Por supuesto, este tipo de vulnerabilidades son muy peligrosas, ya que desde el servidor no solo se puede hacer el escaneo de puertos, sino que se pueden hacer ataques de SQL Injection a servidores internos, Heartbleed o ShellShock, por poner algunos casos, así que hay que tener mucho cuidado con ellas.

Autor: Ricardo Martín (@ricardo090489)
Security QA Engineer en Eleven Paths

Tu impresora "Brother" puede ser el "Hermano" de tu peor enemigo

Hace unos días me pasaron por correo electrónico - ¡gracias rootkit! - un dork para localizar un panel de búsqueda de impresoras que llevan las impresoras del fabricante Brother. Dicho panel es simple de localizar con el dork, pero tras mirar un poco la información que puedes obtener de él y lo que se puede hacer con la interfaz de administración web de las impresoras, parece la tormenta perfecta para que alguien ataque una empresa con la información que recolecte de ellos o que directamente se monte una botnet con las impresoras de este fabricante.

Figura 1: Tu impresora "Brother" puede ser el "Hermano" de tu peor enemigo

El trick para hacer el Hacking con Buscadores en cuestión busca una sencilla URL del panel de administración web de las impresoras multifunción Brother que no está protegido bajo ninguna sesión de usuario. Es decir, que es público y está abierto a todos los usuarios que lo busquen. Para localizar los paneles basta con buscar esta URL /pbio/find.html. Tras jugar con ello un rato, creo que es mejor dork buscar la página de información del dispositivo principal, ya que salen del orden de diez veces más dispositivos. Para ello, se puede usar este dork.

Figura 2: Dork para localizar impresoras Brother en Google

Una vez en el panel de administración, se accede a la lista de impresoras que se encuentran en la misma organización con la opción de Find Device y que se hayan dado de alta, ya sean de la marca Brother o de cualquier otro fabricante - como HP, Dell o Panasonic - con lo que se obtiene información táctica útil para cualquier atacante, como nombres de equipos, direcciones IP, segmentos de red, etcétera. Además, conociendo las direcciones de esas otras impresoras se podría buscar el panel de control de las mismas, que a veces tienen problemas de seguridad conocidos, como ya se ha visto en el pasado con impresoras HP o Ricoh - por poner un par de ejemplos -.

Figura 3: El panel de Find Devices no está protegido por sesión de usuario

Si desde ese panel se intenta acceder a la administración de cualquier impresora, ya sí que aparece un proceso de autenticación en la propia impresora en el que se solicita un nombre de usuario y contraseña para gestionar el dispositivo concreto. No obstante, en el caso de las impresoras Brother no hay que volverse loco, ya que con cancelar el proceso de login se llega a una pagina de error muy curiosa donde se nos informa de cuáles son los usuarios por defecto y cuándo debemos usar cada uno de ellos.

Figura 4: Usuarios y contraseñas por defecto en la página de error

Por supuesto, como podéis imaginar los usuarios y contraseñas de miles de esas impresoras no están cambiados, así que se llega a los paneles de administración de todas y cada una de ellas, sin necesidad de hacer nada complicado. Entre las fugas de información más curiosas que he visto está en el panel de control una dirección URL que permite ver todas las redes WiFi que se encuentran al alcance de esa impresora y cuáles son las que están configuradas, con lo que si se está haciendo un test de intrusión a una empresa el wardriving previo ya te lo ahorras.

Figura 5: Listado de todas las redes WiFi accesibles desde la impresora

Entre la información que se puede sacar de la configuración de los segmentos de red lógicamente se encuentran servidores DNS, DHCP, Gateways, etcétera, direcciones IP de clientes que envían trabajos de impresión, direcciones MAC, etcétera, y si se quisiera plantear un ataque de red en IPv6 con Evil FOCA, las impresoras lo tienen activado por defecto.

Figura 6: IPv6 configurado en Wired y Wireless por defecto

Una vez allí, se podría acceder a información incluso de los clientes de la red, ya que hay una función de administración que permite autenticar a los clientes por el nombre de su PC, con lo que en algunos sitios se puede localizar una lista de los PC-Names. 

Figura 7: Función que permite restringir por nombre de los PC el uso de las impresoras

Hay que remarcar que el panel de administración va con HTTP en casi todos los casos con lo que la información de gestión y por tanto las cookies de sesión van expuestas a ataques de session hijacking, además de que  los ficheros de exportación de datos en formato CSV no se borran automáticamente y no están protegidos por ninguna sesión, así que sabiendo la URL es fácil acceder a los datos de configuración de la impresora.

Figura 8: Descargando un CSV de la impresora sin autenticación de credenciales

También, desde los paneles de administración web de estas impresoras se puede cargar el firmware directamente desde el panel de gestión web, así que podría estudiarse la posibilidad de meter un firmware modificado para controlarlas remotamente como una botnet.

Figura 9: Configuración de un nuevo firmware para la impresora

Además, por si se quiere automatizar el control total de estas impresoras, el panel de administración cuenta con una consola de comandos vía web que puede simplificar un poco más aún el trabajo.

Figura 10: Web Console de las impresoras Brother

En cualquier caso, si tienes una impresora Brother en tu empresa, revisa la seguridad de la misma urgentemente - si no lo has hecho ya -. Si tienes una impresora de otro fabricante tampoco te olvides de realizar las mismas tareas de fortificación. Viendo todo esto, creo que estaría bien ver qué posibilidades hay de hacer algún plugin de Latch para estos paneles de administración de impresoras. Si alguien hace algo que lo cuente.

Saludos Malignos!

Connection String Parameter Pollution en aplicaciones Windows publicadas en Citrix o Terminal Services

Este puente ha tenido lugar el Cybercamp, y entre los ponentes se encontraba Stefano Di Paola, padre de las técnicas de ataque HPP (HTTP Parameter Pollution). En un rato en la sala de ponentes del evento estuvimos hablando y además de aprovechar para tirarnos una foto juntos le conté que cuando descubrimos las técnicas de ataque de Connection String Parameter Pollution fue porque desde que vimos su charla queríamos polucinar todo lo polucionable, y al final fueron las cadenas de conexión a bases de datos las que nos dieron el premio.

Figura 1: Ataques CSPP en aplicaciones Windows publicadas en Citrix

En aquel momento, cuando estábamos escribiendo el paper de Connection String Parameter Pollution, hubo un software vulnerable al que no le hicimos mucho caso, pues no tenía mucho sentido en aquel entonces el entorno de ataque. Me refiero a la Consola de Administración de SQL Server 2000, que permite la inyección de un punto y coma en cualquier campo y como consecuencia la polución de los parámetros de la cadena de conexión.

Figura 2: Connection String Parameter Pollution Attacks

No tuvo mucho sentido para nosotros publicar que era vulnerable a CSPP, pues no encontramos un entorno de ataque donde tener la Consola de Administración de SQL Server 2000, que ya de por sí permite configurar todos los parámetros para hacer una conexión a una base de datos, diera alguna ventaja al atacante pero lo cierto es que lo era y se podrían inyectar comandos.

Figura 3: Presentación de Connection String Parameter Pollution en DEFCON 18

Sin embargo, quiso el destino que ayer mismo me topara con un servidor Citrix que estaba publicando una aplicación Windows que realizaba la autenticación contra una base de datos Microsoft SQL Server. Como se puede apreciar, es un panel de login en el que no se puede elegir ni el motor de la base de datos, ni tampoco se podía tocar el nombre del servidor y la base de datos, que venían prefijado y sin posibilidad de manipular. Solo se pueden introducir valores en el campo de usuario y contraseña. 

Figura 4: Un aplicación Windows publicada en un servidor Citrix con una conexión a SQL Server

Para probar si estaba ante una cadena de conexión a bases de datos inyectable y polucionable, en el campo de Usuario introduje una cadena con el carácter ";" en medio, para ver si conseguía generar un nuevo elemento en la configuración de la conexión. Como se puede ver en el siguiente mensaje de error obtenido, mi carácter ";" aparece en la cadena como uno de los caracteres de control introducidos por el programador, así que podría probar otras cosas.

Figura 5: Mensaje de error ODBC que muestra la cadena inyectada

Teniendo en cuenta que esta aplicación está en un entorno Citrix la cosa podría ser más que interesante. Al final, al haberse publicado esta aplicación, se está publicando un usuario del sistema operativo Windows sobre el que está corriendo, lo que podría permitir hacer un ataque de Jailbreak, pero al mismo tiempo podríamos utilizar un parámetro Integrated Security en la cadena de conexión para utilizar ese usuario Windows en el motor de la base de datos.

El resultado, como puede verse en este ejemplo concreto es que ese usuario de Windows concreto sobre el que está corriendo esta aplicación Windows publicada en este entorno Citrix no tiene los privilegios de acceso a este motor SQL Server en particular, pero el ataque podría haberse realizado si hubiera estado configurado con otro usuario podría haber tenido éxito.

Figura 6: Error. El usuario no está dentro de una conexión de confianza

Al final, con esta aplicación en concreto se daba otra singularidad negativa, y es que el nombre de la base de datos había sido agregado al final de la cadena de conexión. Esto, conociendo que en la polución de los parámetros hace que el "último gane", significa que desde el campo de usuario pudieramos manipular todos los parámetros anteriores menos el nombre de la base de datos.

En este último ejemplo se puede ver como se ha polucionado el valor Server de esta cadena de conexión para obtener un resultado de que en Localhost no hay instalado ningún servidor SQL Server. Esta polución nos permitiría buscar todos los servidores SQL Server dentro de la DMZ de la organización - uno de los entornos de ataque descritos en nuestra presentación de DEFCON - e intentar realizar realizar una conexión a algún entorno de backup no publicado en Internet.

Figura 7: Conexión a server Localhost con polución de parámetro SERVER

Al final como se puede ver, aunque las técnicas de Connection String Parameter Pollution las pensamos más en aplicaciones web, con aplicaciones Windows publicadas en entornos de Citrix y/o Terminal Services en los que ya hay un usuario con una sesión abierta, también tienen su cabida. 

Saludos Malignos!

La NSA prefiere hackear routers y switches para espiar(te)

No sé ni cuantas veces he visto conferencias de hacking de routers, switches, cámaras de vídeo-vigilancia o impresoras.... y yo he llegado a jugar hasta con sensores de temperatura. Todas ellas tienen al final algunas conclusiones similares peros las más importantes quizá desde el punto de vista de seguridad son: 

1) Son sistemas operativos completos con muchas funcionalidades
2) Están dentro de tu red

Es cierto que el sistema operativo que funciona en una cámara de video-vigilancia o un switch de red no es un Controlador de Dominio de la red, pero en él se pueden ejecutar sniffers de red, servidores web, bases de datos, programas de hacking para hacer ataques de red en IPv4 & IPv6, etcétera, etcétera, etcétera.

En segundo lugar están dentro de la red de la organización, con lo que ofrecen el punto de apoyo que pedía Arquímedes para mover el mundo pero para capturar e interceptar todas las comunicaciones de red que se producen desde todos los sistemas informáticos que se encuentran allí.

Teniendo esto presente, según revela un artículo en el Washington Post, los espías de la NSA decidieron que la mejor forma de espiar el mundo era mediante el hackeo de los dispositivos de red de las empresas, para que desde allí tomar control del resto del sistema.

Figura 1: Artículo en Washington Post explicando el proyecto de Black Budget

Según un memorandum interno filtrado por Edward Snowden, el hacking de los dispositivos de red tiene muchas más ventajas que pueden ser aprovechadas para colarse dentro de una red:

- Desactualizados: Por desgracia es cierto que dentro de las empresas el plan de actualización de software no se toma tan en serio con los dispositivos de red como con los equipos informáticos, por lo que suelen encontrarse con vulnerabilidades conocidas. 

- Contraseñas por defecto: El número de dispositivos que se encuentran con contraseñas por defecto es altísimo. Esto se basa muchas veces en la creencia de que no hay conexión desde fuera, lo que permite tomar el control de ellos fácilmente. En el artículo de Explorando una DMZ desde un servidor Citrix se puede ver claramente. 

- Backdoors de fábrica: Aunque parezca raro, muchos de los fabricantes crean usuarios secretos dentro de los dispositivos con capacidades de administración. Ejemplos de ellos hay cientos, pero os dejo como ejemplo el backdoor de super usuario descubierto en el Proyecto Fin de Master de la UEM sobre la seguridad de cámaras de vídeo vigilancia.

Figura 2: Ejemplo de Backdoor en Vídeo Cámara TelnetVid

- Faltos de auditoría de seguridad real de fábrica: Mientras que a los productos de software se les suelen hacer auditorías de seguridad robusta, a los sistemas que se implantan en los dispositivos de red de gama baja no suelen hacerse tan exhaustivas. Caso de ejemplo, la aparición de 0days como el que se publicó en el libro Hacker Épico en las cámaras de vídeo vigilancia que permite sacar las passwords remotamente. 

- Falta de fortificación del dispositivo: Así como en el software de escritorio existen políticas corporativas que marcan cómo debe instalarse un equipo en la red, en el caso de los dispositivos no se hace de forma tan estricta por lo que es fácil que aparezcan con IPv6 instalado y sin configurar, con portales web desprotegidos o con servicios SNMPv1 o SNMPv2 sin ninguna seguridad. 

- Sin software de seguridad: Mientras que los equipos de escritorio cuentan con soluciones antimalware para la protección de ataques o exploits - al menos algo hacen - en el resto de dispositivos de red nunca se ha pensado en poner ese tipo de medidas de forma extendida. Esto hace que sea más fácil usar cualquier herramienta e instalar cualquier software. 

- Sin monitorización: Muy pocas son las empresas que tienen una monitorización completa de todo lo que está pasando en todos los dispositivos conectados a la red de la organización. Es cierto que routers o switches de gama alta en empresas medianas y grandes son monitorizados, pero no suele monitorizarse la totalidad de los dispositivos que se conectan, entre otras cosas porque muchos de los equipos carecen de esas funcionalidades.

Todo esto fue tenido en cuenta por la NSA, y desde el año 2011 han estado hackeando y controlando todos los dispositivos que han podido, manejando equipos en redes de todo el mundo, especialmente en China, Rusia ... y países amigos.

Si estás gestionando una red, o llevando la política de seguridad de una organización, revisa todas estas cosas, ya que además muchos de estos dispositivos salen haciendo un poco de hacking con buscadores en sitios como Shodan, lo que te hace estar más expuesto aún.

Saludos Malignos!

Atacando a la DMZ desde una impresora de Internet

Un lector del blog me pasó un hilo en 4chan en el que hablaban de un fallo de protección de las impresoras HP publicadas en Internet que permiten imprimir archivos desde una URL de Internet. Para encontrar estas impresoras expuestas en Internet es fácil hacer algo de Hacking con Buscadores para localizarlas. 

Figura 1: El hilo en el foro de 4Chan sobre este tema

Esta opción permite no sólo que alguien desde fuera haga uso del papel de tu impresora, te lance un ataque de D.O.S. o sea una incomodidad, sino que además, la impresora realiza la petición a una URL de Internet, con lo que se pueden plantear ataques a la Intranet o la DMZ - por ejemplo con una URL de ataque con un SQL Injection, o hacer un hacking similar al de los buscadores con arma de destrucción masiva.

Figura 2: Atacando una URL interna con SQL Injection usando la impresión desde URL

Por supuesto, además de que es un fallo de configuración claro en la implantación de las impresoras, por defecto esto debería estar capado con contraseña de administración, además de que deberían venir todos los modelos de impresoras con panel de administración web con un fichero robots.txt que evitase la indexación en los buscadores que respetan estos ficheros.

Saludos Malignos!

Explorando la DMZ de una red (3 de 3)

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

- Explorando la DMZ de una red (1 de 3)

- Explorando la DMZ de una red (2 de 3)

- Explorando la DMZ de una red (3 de 3)

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

La herramienta de administración de Sonicwall CDP

Tras arrancar la aplicación instalada, la herramienta ya está configurada para conectarse al appliance de copias de seguridad, con lo que sólo se solicita una contraseña. Usando la password por defecto de estos dispositivos, como era de esperar se permite el acceso.

Figura 12: Herramienta de administración de SonicWall CDP

No sabía lo que allí me iba a encontrar, pero parece que está absolutamente todo el corazón de la empresa, ya que en este servidor se hace backup de Active Directory, las bases de datos MS SQL Server y las bases de datos de servidores de correo MS Exchange Server. Vamos, creo que los datos más valiosos de la infraestructura de la compañía.

Figura 13: Backups de Active Directory, MS SQL Server y MS Exchange Server

Tenerlos protegidos sólo con la contraseña por defecto es una autentica temeridad y si hubiera tenido delante al administrador le hubiera mordido una oreja por luser. La herramienta permite hacer restore de datos a cualquier sitio, y por lo tanto se podría acceder a todo. Sin embargo, esto no acaba aquí, ya que también se realizan copias de seguridad de carpetas compartidas, y desde la aplicación se pueden consultar todos los ficheros, y restaurarlos.

Figura 14: Buscando ficheros en el backup de datos

Todos los datos de una empresa sólo controlados por una contraseña por defecto es una autentica temeridad. Espero que todos vosotros hayáis cambiado las passwords por defecto de todos vuestros equipos de la red.

192.168.X.150: Otra impresora

Y también con la contraseña por defecto. Lo curioso es que con esta se puede acceder a ver qué usuarios han mandado a imprimir qué documentos, con lo cual se puede extraer un poco más de información. Lo cierto es que tras poder acceder al backup del Active Directory deja de tener importancia este resquicio de datos.

Figura 15: Otra impresora, con su password por defecto

Como curiosidad, quise comprobar a ver si tenía una shell que permitiera sacar algo de allí, pero lo cierto es que la consola msh que trae estaba bastante limitada.

Figura 16: La consola msh con password por defecto

Locahost: El servidor web público

Encontré alguna impresora más - sí, también con la password por defecto - pero ya era suficiente, así que revisé mi equipo para terminar, y como era de esperar, allí estaba el servidor web publicado en Internet con el acceso a los servicios Citrix.

Figura 17: El servidor web local con Citrix

Como estaba en ese equipo, miré a ver si podría haber metido una webshell en el servidor para poder acceder siempre al equipo. Allí estaba InetPub, y no estaba protegido, por lo que se podría meter un fichero con la webshell para perpetuar el acceso y control a la red.

Figura 18: El directorio InetPub y una rara aplicación llamada keygen

Conclusión

Tener un firewall no es una garantía de protección. Si estás publicando servicios en Internet audítalos. Si estos servicios están en una DMZ, audítala como si los servidores hubieran sido comprometidos. Si tienes dispositivos en tu red.... ¡cambia ahora mismo las passwords por defecto de todos ellos!

Saludos!

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

- Explorando la DMZ de una red (1 de 3)

- Explorando la DMZ de una red (2 de 3)

- Explorando la DMZ de una red (3 de 3)

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

Explorando la DMZ de una red (2 de 3)

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

- Explorando la DMZ de una red (1 de 3)

- Explorando la DMZ de una red (2 de 3)

- Explorando la DMZ de una red (3 de 3)

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

Continuando con el paseo curioso por la DMZ era previsible que acabase apareciendo todo lo necesario para que funcione normalmente una compañía, así que lo siguiente que encontré fue:

192.168.X.7: Impresora multifunción RICOH Aficio AP4510

No conozco ninguna empresa sin impresoras, pero el que esté configurada en la DMZ deja claro que en ésta en concreto, no hay segmentación entre los servidores de la DMZ y el resto de los equipos de la red, algo que es muy peligroso, ya que también estarán los equipos por aquí.

Figura 6: Panel de Administración de Impresora

Tocó buscar la contraseña por defecto de este modelo, y resultó que funcionó. Así que ahora habrá que repasar la charla de nighterman de la RootedCON para ver cómo se podría sacar más provecho a este cacharro...

Figura 7: Administración de la impresora

192.168.X.20: SonicWall CDP

Continuando con el paseo topé con este producto de SonicWall, que he de decir que no conocía al principio. Buscando información por Internet descubrí que es una solución en appliance destinada a realizar copias de seguridad, es decir, en él se encuentran los datos de la empresa.

Figura 8: Panel de Administración de SonicWall CDP

Como os podéis imaginar, lo único que hice fue buscar la contraseña por defecto de estos productos para comprobar que... funcionaba.

Figura 9: Administración de SonicWall CDP

Una vez dentro, me decepcionó un poco, ya que no fui capaz de acceder con esta herramienta a ningún dato, aunque se podía realizar una ataque de Purga de Datos, que como se explica en la pantalla que se ve en la figura siguiente, no son recuperables.

Figura 10: Purga de datos en el Appliance SonicWall CDP

No era mi intención romper nada, pero me había quedado un mal sabor de boca al no haber podido acceder a los datos del appliance. ¿Cómo se podría acceder a ellos? Mirando la consola por arriba y por abajo, volví a caer en la pantalla de Login donde me fije en el hipervínculo a unas herramientas clientes... ¿Estarán instaladas en algún sitio?

Me puse a revisar el equipo local en que estaba conectado, por si hubiera suerte y estuvieran instaladas, ya que con una cuenta de usuario no creía que pudiera instalarlas yo... y resultó que allí estaban.

Figura 11: Herramientas de administración de SonicWall CDP

Ya tenía las herramientas y la contraseña por defecto funciona, ¿qué habrá allí?

Saludos Malignos!

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

- Explorando la DMZ de una red (1 de 3)

- Explorando la DMZ de una red (2 de 3)

- Explorando la DMZ de una red (3 de 3)

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