El ataque del CUCO: Cómo un enemigo se puede hacer con tu WordPress, Joomla!, Drupal, Magento y cPanel

Hola gente de este blog maravilloso, si bien he aportado varias veces en artículos, nunca se me ocurrió hacer uno de mi autoría, así que le doy las gracias y es un honor que Chema Alonso me deje redactar uno completamente. Aquí va y espero no defraudarlos. Como sabéis mi especialidad es el "Hacking con buscadores" y les mostrare lo fácil que puede ser para un atacante hacerse con un hosting completamente gratis. Cómo conseguir el mejor CMS o eCommerce o cualquier otra plataforma solo con usar Shodan y Google.

Figura 1: El ataque del CUCO. Cómo un enemigo se puede
hacer con tu... WordPress, Joomla!, Drupal, Magento y cPanel

La idea es tan sencilla como estar atentos a cuándo quedan indexados sistemas CMS a medio instalar, por descuido o por desconocimiento. Un atacante los puede usar para distribuir exploits, hacer campañas de phishing, alojar malware o simplemente meterlos en campañas de BlackSEO. Un hosting gratis es un hosting gratis, y siempre se le puede sacar valor. Como si fuera un Cuco poniendo los huevos en el nido ajeno.

Figura 2: Descubriendo scripts de instalación de WordPress en Shodan

Para seguir los pasos de este artículo, como primera medida hay que registrarse en Shodan.io con una cuenta gratuita ya que haremos uso del operador "title" y eso no es posible si no estás con una sesión iniciada. Una vez registrados, veremos lo fácil que es localizar los paneles de instalación de WordPress, Joomla!, Magento y Drupal indexados a Shodan.io. Como se puede ver en la imagen superior, podemos localizar scripts por título, como en el caso de WordPress, pero en la Figura 4 lo vamos a hacer con el modificador title.

Figura 3: Script de instalación de un WordPress

Comenzaremos por el CMS de WordPress, que lo que vamos a explotar en Shodan es el gestor de instalación de esta plataforma. El script de instalación de WordPress se puede localizar accediendo a wp-admin/install.php y veremos cuántos de estos están indexados en Shodan.io por descuido de sus administradores, que no han hecho los deberes.

Figura 4: Buscando en Shodan los scripts de configuración de WordPress

Deberían leer el libro de Máxima Seguridad en WordPress para no tener estos problemas, que luego pasa lo que pasa.  ;). Estos scripts de WordPress, aunque no tengan un motor de bases de datos al que conectarse, pueden ser utilizados para hacer ataques Time-Based Blind XSPA (Cross-Site Port Attack) en WordPress, como ya se explicó en otro artículo anteriormente.

Figura 5: Script inicial de Setup en WordPress

El segundo de los panel CMS que podemos localizar es Joomla! que también tiene su script de instalación para configurar las bases de datos, los usuarios privilegiados, etcétera.  Lo que haremos nosotros en Shodan es encontrar gestor de instalación que esta generalmente en la ruta installation/index.php.

Figura 6: Buscando scrips de instalación de Joomla! en Shodan

En los scripts encontramos los parámetros de configuración de acceso a la base de datos, que en el caso de que no estuviera presente el motor de bases de datos MySQL siempre podríamos usar para escanear la DMZ con un ataque XPBA como el de WordPress de antes.

Figura 7: Script de instalación de Joomla!

Y si está la base de datos, pues te la configuras y ya tienes tu sitio web completo para hacer lo que quieras. Y si quieres, le pones hasta el Latch para Joomla!, que también se puede hacer una vez termines de ejecutar el script.

Figura 8: Búsqueda de scripts de instalación de Drupal

El siguiente en la lista de objetivos populares sería Drupal. Su script de instalación se encuentra indexado como ya podéis suponer en Shodan.io, y es un fichero install.php.

Figura 9: Script de instalación de un Drupal

Como es demasiado común el nombre de install.php, lo podemos filtrar como se ha hecho en la búsqueda de la Figura 8 por el campo title, usando el que tiene el paso 1 del script.

Figura 10: Búsqueda de scripts de Magento en Shodan

Magento es una plataforma de código abierto para eCommerce escrita en PHP. Es una de las más comunes y tiene versión community (para la que se hizo una versión de Latch para Magento). Su fichero de instalación se encuentra en: index.php/install/

Figura 11: Versión de Magento Community disponible para instalar

Como se puede ver, no solo aparecen versiones Community en las búsquedas, e incluso las versiones Enterprise están a disposición de cualquier atacante.

Figura 12: Versión de Magento Enterprise disponible para instalar

Esta es una fuga importante de información en la plataforma de Magento. También hay otras como la de Magento Repair Tool que tiene un XSPA o la de Magento Check. Con ellas se puede sacar información de la base de datos, del servidor en que está instalado y de la DMZ.

Figura 13: Magento Enterprise. Configuración de la base de datos

Quise, para completar este artículo, si ya directamente era posible localizar paneles de hosting completos, como cPanel. Con este dork es posible localizarlos en Google, pero de momento solo versiones "demo". Eso sí, si alguno alguna vez se lo deja indexado... tendrá problemas.

Figura 14: Cpanel google dork: inurl:login -intext:login inurl:user= 
inurl:pass= - intext:user -intext:pass inurl:2082 OR inurl:2083

Al final, son leyes muy sencillas. No poner en los servidores nada que no esté en uso. No poner servidores a medio configurar en Internet, y revisar periódicamente la configuración de la seguridad de tus sistemas. Espero que les haya gustado.

Saludos,

Autor: Rootkit, Pentester independiente.

BlackBox: Ataques para Joomla, WordPress, Magento o PrestaShop

Esta herramienta llamada BlackBox y escrita en Python permite a un pentester disponer de una suite interesante en su día a día en la oficina. BlackBox, que se encuentra en su versión 2.0 para desarrolladores, proporcionan distintas funcionalidades para los procesos de pentesting. Desde funcionalidades para hacer ataques de fuerza bruta, hasta recopilación de información, exploits, comandos para hacer algo dorking en tareas de hacking con buscadores e incluso cracking. Mucho potencial en la caja negra.

Figura 1: BlackBox. Ataques para CMSs Joomla, WordPress, Magento o PrestaShop

Para instalar BlackBox sobre nuestra máquina podemos descargarlo desde su Github. Después, simplemente, hay que ejecutar el script install. Como se puede ver en la imagen tenemos elementos orientados a auditorias web, en su mayor parte.

Figura 2: BlackBox en GitHub

Disponemos también de una serie de funcionalidades orientadas a realizar ataques de fuerza bruta en entornos web, además de para localizar la página de login en cada sitio, con las opciones de:

• Wordpress Bruteforce
• FTP Bruteforce
• SSH Bruteforce
• Admin Page Finder

Figura 3: Funciones disponibles en BlackBox

La categoría de exploits orientados a entornos web tenemos algunos para diferentes frameworks, como Joomla!, Magento o PrestaShop:

• Joomla RCE (Remote Code Execution)
• Magento RCE (Remote Code Execution)
• PrestaShop Exploit

Aunque no tengamos gran cantidad de exploits, pueden ser útiles en algunos escenarios. Además, para complementar entornos como exploit-db, tenemos la categoría de dorking dónde podemos encontrar:

• Google Dorker
• Bing Dorker
• Scan list

Por último, tenemos la posibilidad de utilizar una herramienta para crackear hashes en formato MD5, SHA1, etcétera, generalmente algoritmos utilizados en muchos de estos frameworks para aplicaciones web. Vamos a probarlo un poco.

PoC: Carga y configuración del módulo de fuerza bruta SSH

En esta prueba de concepto vamos a configurar el módulo de fuerza bruta de SSH con BlackBox, para replicar cómo podría funcionar el proceso de capturar dispositivos para una botnet mediante un proceso tan sencillo como crackear por diccionario un servicio SSH mal fortificado. Si ejecutamos la opción blackbox ssh_brute -h podemos ver las diferentes opciones del módulo. Esto sirve para todos los módulos que tenemos disponible en BlackBox.

Para configurar el módulo hay que indicar la dirección IP dónde se lanzará la fuerza bruta a SSH, el usuario de SSH que se quiere atacar y la ruta del fichero de contraseñas. Existen muchas herramientas que permiten realizar este tipo de acciones, pero BlackBox permite tener estas funcionalidades centralizadas por módulos. Esto es interesante, ya que es fácilmente escalable en número de módulos, es decir, en otras funcionalidades.

Figura 4: Prueba de diccionario contra servidor SSH

Si ejecutamos la opción blackbox google_dorker -h podemos ver las opciones para la búsqueda en Google. El ejemplo que el propio BlackBox propone es blackbox google_dorker –dork=”php?id” –level 10. Es interesante ir probando esto, también probando sobre Bing. Esto permite automatizar el descubrimiento de determinados objetivos y generar scripts automatizados para probar exploits, por ejemplo, de los que acompañan a la herramienta.

El módulo hash_killer permite generar hashes en el algoritmo que se quiere y realizar la comparación los hashes que se encuentran en dicho algoritmo. Por ejemplo, tenemos la opción -w dónde situamos las palabras de diccionario que queremos hashear y comparar con los hashes que se encuentran en el fichero asociado al parámetro –md5, por ejemplo.

Figura 5: Opciones para Hash_Killer

Como se puede ver, la herramienta tiene opciones especiales para crackear los hashes de los motores de bases de datos más populares en los CMS para los que incorpora exploits.

Reflexión final

Este proyecto es una caja de herramientas sencilla, que debemos llevar encima por si acaso nos es útil. Si miras el proyecto en su estructura, tal vez su creador no lo tiene tan enfocado al mundo del pentesting como al mundo de exploiting masivo en Internet automatizado - a la vista de las opciones de dorking y los objetivos tan populares en la red -, pero para nosotros lo más interesante es que el proyecto se encuentra bastante activo y se van añadiendo diferentes módulos con cada nueva versión, por lo que os proponemos que estéis atentos a las diferentes opciones y posibilidades que BlackBox ofrece con cada release.

Figura 6: Actualizaciones en cada versión

Por el otro lado, vistas la existencia de muchas herramientas automatizadas como estas, no me queda más que recomendar la actualización constante del software de las plataformas CMS, además de que hagas un esfuerzo por proteger WordPress contra ataques de fuerza bruta - y si lo ponéis en Paranoid Mode mejor -, y que pongáis un Latch en vuestros servicios SSH, en vuestros servidores e-commerce con Magento o en vuestra tienda con Prestashop... por si las moscas, que ahí suele haber datos de clientes y no te gustaría que aparecieran en la Dark Web.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”

Protege tu #Magento: Explotación del bug CVE-2016-4010 que permite Ejecución Remota de Código

Magento es una de las principales plataformas de comercio electrónico en Internet y con una amplia comunidad - incluso han desarrollado un plugin de Latch para Magento -. Es posible encontrar multitud de tiendas online que hacen uso de este software de código abierto y en el equipo de Faast lo tenemos muy presente para la evaluación de sus vulnerabilidades en los procesos de pentesting persistente que ejecutamos sobre nuestros clientes. En mayo de este año, Netanel Rubin descubrió una vulnerabilidad de alta criticidad (CVE 2016-4010), que permite a un atacante no autenticado inyectar y ejecutar código en el servidor.

Figura 1: Protege tu Magento: Explotación del bug CVE-2016-4010 que permite RCE

Esta vulnerabilidad está presente en las versiones de Magento comprendidas entre la 2.0.0 y la 2.0.5 y, por supuesto, tenemos un plugin en nuestro sistema para detectar versiones afectadas por ella. Aprovechando que tenemos el entorno de test del plugin que montamos, hemos hecho este artículo para explicar el fallo y su explotación, que es un caso típico de PHP Object Injection tal y como se explica en el libro de Hacking Web Technologies.

En que consiste el CVE-2016-4010

Para entender la vulnerabilidad es necesario conocer cómo se comunican cliente y servidor. Cuando el cliente envía un objeto al servidor (nuestros productos, nuestros datos bancarios, etcétera), antes de insertarlo en la base de datos, serializa aquellos campos que estén especificados en el diccionario _serializableFields y que además sean arrays u objetos.

Una vez el servidor recibe los datos, se aplica la lógica inversa para deserializarlos. Como se ve en la línea 27 de la figura 1 el servidor no va a deserializar arrays ni objetos, lo que a priori pone las cosas difíciles si queremos inyectar un objeto en el servidor.

Figura 2: Métodos serializeFields y unserializeFields de Magento

Sin embargo, si introducimos un string adecuado en uno de los campos catalogados como _serializableFields, esa cadena sí será deserializada posteriormente, por lo que el servidor es vulnerable.

Basta con determinar qué campo es el adecuado. En este caso, la vulnerabilidad está en la información de pago, concretamente en el campo additional_information del diccionario additional_data, que permite al usuario añadir información adicional sobre el método de pago seleccionado. Esa información no se controla en servidor, sino que es deserializada directamente. Ahí es donde inyectaremos nuestro payload.

Para que la inyección funcione es necesario utilizar como payload un objeto de PHP serializado que tenga ‘métodos mágicos’ (como _wakeup(), _sleep(), etcétera más info en el artículo de PHP Object Injection). Estos métodos tienen la particularidad de que se ejecutan automáticamente cuando el objeto es serializado o deserializado, y por tanto son muy útiles ya que en este escenario no es posible llamar explícitamente a ningún método del objeto.

Figura 4: Exploit para CVE-2016-4010 publicado en Exploit-DB

Así pues, usando un objeto de estas características, es posible modificar el comportamiento de los métodos mágicos ya que tenemos control total de las propiedades del objeto. Podríamos, por ejemplo, modificar las propiedades que usa el método _destruct() para así llamar indirectamente a otro método del propio Magento. Las posibilidades son infinitas, tan solo es necesario utilizar objetos que cumplan esta condición. Un buen ejemplo (el utilizado por el descubridor de la vulnerabilidad) es una instancia de la clase Credis_Client, un cliente de Redis para PHP.

¿Cómo se explota?

Magento incluye una API REST que permite la integración de terceros. A través de esta API es posible realizar todo tipo de transacciones. El endpoint set-payment-information es el punto vulnerable en este caso.

Cuando un cliente anónimo (esto es, no autenticado contra el servidor de la tienda) va a realizar el checkout de una compra, automáticamente se le asigna un ID alfanumérico de 32 caracteres, el guest cart ID. Es posible obtener este ID a partir de la petición POST que se realiza internamente contra la API cuando se pulsa el botón checkout, ya que va en plano en la propia URL.

Figura 4: Petición POST a la API REST de Magento, con el Guest Cart ID en plano

A partir de ese momento, todas las transacciones entre cliente y servidor relacionadas con esa compra están asociadas a ese ID. Así, modificando adecuadamente la petición a set-payment-information es posible conseguir la inyección de código.

Figura 5: Body de la petición a set-payment-information, con el payload en"additional_information".
En rojo, el nombre del fichero a crear en el servidor y su contenido.

Para comprobar que el ataque ha funcionado, basta con crear el fichero en un directorio del servidor que sea accesible públicamente, y navegar hasta él. Por supuesto, todo el proceso puede ser automatizado, haciendo uso de otras funciones de la API para emular el proceso de compra:

• /rest/V1/guest-carts permitiría obtener un guest cart ID
• /rest/V1/{guest-cart-id}/items permite añadir objetos al carro, pero es necesario conocer su SKU o número de referencia
• /rest/V1/{guest-cart-id}/shipping-information permite añadir la información de envío

Tras esos tres pasos previos, la vulnerabilidad ya estaría en condiciones de ser explotada. En el siguiente vídeo tienes el proceso completo para ver cómo se puede explotar esta vulnerabilidad en un servidor con Magento afectado por este CVE-2016-4010.

Figura 6: Explotación del CVE-2016-4010

Más artículos sobre Seguridad en Magento

- Configurar y utilizar Latch en Magento Community
- Magento Repair Tool: Un XSPA a quitar de tu e-commerce
- Magento Check: Un info leak a eliminar de tu servidor

Autor: Cristobal Bordiú
Faast Engineer en ElevenPaths

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!

Configurar y utilizar Latch en Magento Community

Magento es un popular framework Open Source de e-commerce utilizado en Internet para el que en Eleven Paths no habíamos construido ningún plugin oficial. Y desde hace algún tiempo ya hay uno disponible realizado por José "Joc", un desarrollador certificado de Magento, así que desde ya puedes utilizarlo en cualquiera de tus instalaciones.

Figura 1: Configurar y utilizar Latch en Magento Community

El plugin de Latch para Magento está disponible en el siguiente repositorio de GitHub, del que puedes hacer un fork o colaborar. La URL es la siguiente: https://github.com/jochhop/magento-latch. 

Figura 2: Plugin de Latch para Magento Community Edition

Para que puedas configurarlo y utilizarlo, se ha hecho este pequeño manual que explica paso a paso el proceso de instalación de Latch en Magento, el proceso de configuración en el framework y cómo utilizarlo por los diferentes usuarios.

Figura 3: Guía para configurar y utilizar Latch en Magento 

Para que veas como funciona, el siguiente vídeo muestra en detalle cómo utilizar Latch integrado en una instalación de Magento, y como responde el sistema.

Figura 4: Vídeo demostrativo de uso de Latch en Magento

Si tienes alguna idea de cómo utilizar Latch, recuerda que tenemos un Concurso de Plugins con el que puedes ganar hasta 5.000 USD por tu idea - que puede ser tu Proyecto de Fin de Carrera, tu Proyecto de Fin de Máster, tu carta de presentación en el el mundo laboral, tus prácticas, etcétera. Si necesitas ayuda, también puedes contactar con nosotros y el resto de los desarrolladores que han hecho algo con Latch en nuestra Comunidad Eleven Paths, para que te sea mucho más fácil hacerlo.

Saludos Malignos!

Magento: Otra pequeña fuga de información en el "Check"

A veces las cosas se encadenan una tras de otra en un no parar. Esto es lo que hace divertido este mundo de la seguridad informática y la auditoría de sistemas. Siempre hay un nuevo truco que aprender o que descubrir y por eso nunca me aburriré de este mundo. Éste es uno de esos casos. Empezó la historia buscando ficheros PHP para probar los Huevos de Pascua para localizar la versión del framework. Con ellos llegué a uno que se llamaba check.php que resultó ser un leak de información de instalaciones inseguras de Symfony y buscando estos ficheros, llegué a otra pequeña fuga de información en otro check, esta vez del framework para tiendas e-commerce Magento.

Figura 1: Otra pequeña fuga de información en la comprobación de requisitos

El asunto es, que para localizar ejemplos del check.php de Symfony utilicé el truco de buscar en los archivos robots.txt. Éste es un buen lugar para localizar lo que la gente no quiere que se localice, y por supuesto un fichero de test como check.php no debería estar localizable en los buscadores. Quiso el destino que el framework Magento utilice un fichero similar, pero llamado mangento-check.php y gracias a esta coincidencia en el final del nombre apareció en mis búsquedas. 

Por supuesto, una vez sabido de su existencia ya fue fácil hacer un dork en Google para localizar algunos ejemplos usando el truco de nuevo de buscar en los ficheros robots.txt, pero en este caso con el nombre magento-check.php.

Figura 2: Dork para buscar en ficheros robots.txt el fichero magento-check.php

Los ficheros de test miran un conjunto no demasiado grande de propiedades, pero como puede verse hay tres cosas muy útiles, que son: Si la versión del framework PHP es mayor o igual que una dada, si la versión de MySQL es mayor o igual que una dada y si el Safe Mode de PHP está ON u OFF.

Figura 3: Un fichero magento-check.php con todo ok

Si todo está bien, no parece excesivamente peligroso, pero si no lo está, entonces se puede inferir que estamos ante una versión antigua del software de base de datos MySQL o del framework PHP, lo que puede significar la existencia de vulnerabilidades.

Figura 4: Un fichero mangento-check.php con un warning en la versión de MySQL

Al final el problema es que esos ficheros estén accesibles en el path de publicación del sitio web, lo que no debería ser así, pero por si acaso, nosotros en nuestra lista de ficheros de leaks que buscamos y parseamos en nuestro sistema de Pentesting Persistente Faast, ya hemos metido también el de Magento - por si se le olvida en algún sitio inadecuado a alguien -.

Saludos Malignos!