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.

Buscar bugs de HeartBleed en Well-Known Ports con Google Hacking: Cpanel, Oracle Web Server, Open View y demás

En el artículo de HeartBleed puede desangrarte vivo se explica cómo se puede explotar esta vulnerabilidad para robar las contraseñas de los usuarios de un servidor web, la demostración se hacía con un servidor Plesk publicado por el puerto 8443. El que ese puerto sea no demasiado común hace que muchos rastreos lo dejen fuera del radar. Pensando en cuántos tipos de servidores web, publicados a Internet en puertos no habituales, podrían estar esperando a que cualquiera le enviara un latido malicioso decidí hacer unas sencillas pruebas esta mañana de sábado que os paso a contar.

Detección automática con el navegador

Para simplificar la tarea de descubrir si un servidor es vulnerable o no, decidí automatizar este proceso mediante un plugin del navegador. Ahora existen muchos plugins como ChromeBleed para Google Chrome o FoxBleed para Mozilla Firefox que te ayudan a detectar cuando estás navegando por un servidor vulnerable a HeartBleed.

Figura 1: StopBleed y ChromeBleed instalados en Google Chrome

Esta protección es más que recomendable, y ayuda a saber cuáles son los servidores que podrían estar monitorizados en tiempo real para capturar todos los datos de la memoria del proceso OpenSSL vulnerable. Con uno de ellos activado en el navegador, ya estamos listos para poder comenzar a hacer un poco de hacking con buscadores.

Buscando los puertos comunes no habituales con OpenSSL

Como ya sabéis, el proceso OpenSSL puede usarse para muchos servicios, como VPN-SSL, FTP-s, LDAP-s, etcétera, pero también para paneles de administración web es común que los servidores HTTP-s de acceso estén en puertos distintos al que por defecto es usado para este servicio, el número 443.

Para encontrar cuántos puertos podrían tener servicios con SSL lo más sencillo es irse a cualquier base de datos de Well-Known Ports en Internet. En este caso yo utilicé la base de datos de puertos de Speed Guide que tiene un interfaz de búsqueda muy cómodo y una lista de puertos bastante ampliada. Una sencilla búsqueda por SSL para saber en cuántos puertos debería buscar para encontrar la mayoría de los servicios que pudieran tener una versión vulnerable de OpenSSL arrojó un total de 99 77 servicios.

Figura 2: Puertos con algún servicio SSL en ellos

Esto quiere decir que si escaneamos todas las direcciones IP de Internet por esos 99 77 puertos buscando versiones de OpenSSL vulnerables tendríamos un porcentaje grandísimo de todas las versiones vulnerables expuestas a Internet. Si alguien se anima y me pasa los datos, estaré agradecido.

Seleccionando los paneles de administración web

Para poder hacer Hacking con Buscadores, lo más cómo es buscar aquellos puertos que son utilizados por servicios como Plesk (8443), para lo que una revisión manual es suficiente. Como podéis ver, salen cosas interesantes en la lista.

Figura 3: Servicios HTTPs por puertos no habituales

Entre ellos, servidores web de Oracle, OpenView o el popular CPanel, utilizando puertos no demasiado habituales en los escaneos de HTTPs. Ahora se trataría de localizar esos servidores web indexados en los buscadores. Vamos a ello.

El truco de barra para localizar los servidores web en Google

Si te has leído el libro de Pentesting con FOCA, sabrás que una de las cosas que hace la herramienta para buscar los servidores más interesantes a la hora de hacer un pentesting es utilizar El Truco de la Barra en Google Hacking.

Este truco es algo que no acabo de entender muy bien por qué funciona así, pero lo cierto es que si pones una barra antes del dominio en el modificador site, te permite buscar por puertos. Así, si queremos localizar servidores web en un determinado puerto pertenecientes a un dominio solo habría que hacer algo como site:/dominio:puerto/. En los siguientes ejemplos se puede ver cómo serían las búsquedas en Google para localizar servidores Cpanel en Alemania o Argentina.

Figura 4: Servidores indexados en Google por el puerto 2096 de Cpanel

Esto es válido para cualquier puerto en cualquier dominio. Por ejemplo, para localizar servidores de Oracle Web Application Server en un país, solo habría que cambiar el dominio y el puerto para obtener una lista de servidores indexados por ese puerto.

Detectando la vulnerabilidad de HeartBleed

Para detectar la vulnerabilidad, bastaría con obtener los resultados y abrir la página web en nuevas pestañas y el plugin de detección automáticamente irá cantando si el servidor es vulnerable o no al fallo. Yo he probado en varios países y sorprende ver lo fácil que es encontrar servidores de administración de hosting, webmails o herramientas de gestión publicadas sobre versiones vulnerables de OpenSSL.

Figura 5: Uno de los muchos Cpanels vulnerables a HeartBleed descubiertos

Esto deja claro que la vulnerabilidad va a dar mucho juego durante años, como el famoso bug de IIS que permitía ejecutar comandos remotamente en los servidores y que costó erradicar de Internet años.

La explotación de HeartBleed

Explotar el bug de HeartBleed para conseguir las credenciales de los usuarios es ya conocido, solo hay que monitorizar la memoria del proceso OpenSSL constantemente hasta que en un volcado aparezcan - en texto claro - las credenciales buscadas. Todos los pentesters tienen ya sus scripts y herramientas, y si usas FOCA ya sabes que tiene un plugin de monitorización continua para que se vuelque la memoria.

Figura  6: Monitorización continua de un bug de HeartBleed con el plugin de FOCA

Vamos a ver si desde Eleven Paths podemos sacar algún plugin de Latch para Plesk o CPanel para poder implantarlo. Ya teníais disponibles los de RoundCube, y SquirrelMail para servidores de WebMail y ahora está listo también el de Open-Xchange que podéis conseguir ya si nos lo pedís. Aquí tenéis una lista de guías y plugins de Latch para integrar ya. Si alguien se anima a querer integrarlo con Cpanel o Plesk, o cualquier otro servicio, nosotros le ayudamos.

Lo dicho ya con anterioridad. Si descubres que alguno de los servidores que utilizas habituales es vulnerable a HeartBleed, notifícalo y no envíes ningún dato hasta que no esté solucionado. Después cambia las passwords de esos sistemas. Si estás a cargo de una red, escanea los 99 77 puertos del principio en todas tus direcciones IP, a ver si aparece alguna versión vulnerable del software en algún punto.

Saludos Malignos!

No le vemos problema alguno a los reportes que nos envías

Hace unos dias, revisando unos scripts que realicé en Perl decidí adaptarlos con algunos modulos a una pagina shtml. Tenía montado un servidor Apache corriendo en mi maquina, aceptando scripts en CGI para poder probar las salidas que realizaban desde el servidor hasta el cliente. Decidí buscarme un alojamiento que me brindara la posibilidad de programar Perl en el servidor contratado.

Para mi sorpresa, al ejecutar uno de los scripts que subo descubro que tengo mas privilegios en el servidor desde mi cuenta gratuita de los que me esperaba. Tas reiterados correos electrónicos a la compañía durante dias advirtiéndoles de algunos errores en sus configuraciones, y la única respuesta que recibo es:

//No le vemos problema alguno a los reportes que nos envías//

Como no sé si esto es una cosa solo en mi cabeza, os paso algunos de los los reportes que he enviado que no son considerados como problema:

Reporte 1:

Esta empresa como muchas otras tiene un Panel de Control donde el cliente mantiene un usuario y una contraseña para acceder desde la pagina web del proveedor a sus servicios - facturaciones, dominios contratados, espacio contratado, etc. - y paralelamente acceso a su Cpanel para la configuración de sus servicios dado por otro usuario y otra contraseña.

Figura 1: Información en datos de cuenta

En el primer reporte podemos comprobar como en el Panel de Control del Site podemos ver en texto plano el usuario y la contraseña que da acceso al Cpanel de la configuración de todo nuestro sitio. ¿Realmente es un problema?¿Un error?¿Es normal? Si lo es no se porque tener dos usuarios y dos contraseñas distintas de acceso.

Reporte 2:

Programe un script que listase en una tabla los archivos de un directorio dado con su enlace, pero al hacerlo se me olvidó indicar el directorio a listar. Como aún no tenia claro qué directorios iba a emplear configuré un simple my $dir = '../'; con lo que me dí cuenta de la mala gestión del administrador del sitio.

Figura 2: Ejecución de un listado de ficheros desde Perl

Fue entonces cuando me picó en la nuca ese gusanillo que te hace la tipica pregunta de “¿Y si…?” Pues si. ¿Y si pruebo todo lo que puedo obtener de aquí para tener los suficientes argumentos y que la empresa a la que no le debo nada proteja a sus clientes? Por lo menos los clientes que tengan cuentas que estan pagando un dinero por tener sus ficheros protegidos.

Tras eso cree distintos scripts en Perl que ejecutaban comandos en el sistema. Y estos son los resultados.

Figura 3: Salida de un comando df -h

Figura 4: Salida de un cat /etc/passwd

Sin extenderme más, he de decir que abandono mi cuenta en este hosting, porque no me gustaría que cualquier pudiera acceder al código de mis programas, así que mejor no usar este servidor.

Terminando con este llanto a gritos

Llevo mas de dos semanas intentando de buena fe contactar por todos los medios con esta empresa que suministra espacio protegido a la gente. Me he tomado las molestias de recopilar todo tipo de información para que se guíen a la hora de ver qué ocurre, moletandome para nada, porque la única respuesta ha sido:

//No le vemos problema alguno a los reportes que nos envías//

Pues vale, sin problemas, aquí queda escrito, saludos a http://www.host-ed.net/ por la colaboración aen este articulo.

Saludos
Miguel Francisco Morata