Un patrón común que vemos en sitios web comprometidos es la presencia de backdoors y otros códigos maliciosos. Durante el tercer trimestre de 2016, vimos que el 72 % de todas las infecciones que hemos encontrado tenían una backdoor basada en PHP oculta dentro del sitio web. Los atacantes experimentan con varias técnicas y tipos de malware para abusar de los recursos del servidor y distribuir spam mientras mantienen el acceso al sitio web durante el mayor tiempo posible.
En el caso de los ataques automatizados, a veces tenemos la suerte de ver a los hackers acceder al mismo sitio web. Cuando varios hackers tratan de comprometer el mismo sitio web a través de ataques similares, vemos resultados interesantes.
Backdoor Shell en la Base de Datos del vBulletin
Al investigar un caso, hemos descubierto exactamente el mismo caso de un backdoor. Uno de los backdoors más usados es el C99 shell web. Para aquellos que no están familiarizados con él, el C99 es una variación de la shell WSO con funcionalidades adicionales y permite al atacante administrar el sitio web de una víctima remotamente, incluso ejecutar comandos remotos arbitrarios directamente en el sistema, navegar a través de una interfaz de administrador de archivos, leer archivos arbitrarios y mucho más.
Aunque este tipo de shell normalmente se encuentre dentro de los archivos, recientemente lo encontramos en una base de datos de vBulletin. VBulletin es un excelente candidato para recibir backdoors dentro de una base de datos, debido a la capacidad de la plataforma de ejecutar PHP directamente desde la base de datos.
La tabla datastore de vBulletin, más específicamente el record pluginlist, se utiliza ampliamente para almacenar contenido malicioso. A través de esta tabla, los hackers pueden agregar código PHP arbitrario que se convierte en parte de cualquier plugin instalado en el sitio web. En algunos casos, los atacantes también agregan el código malicioso como su propio plugin, agregándolo a la tabla plugin.
En este caso, vimos un shell normal apareciendo cuando accedimos a /forum.php/subscriptions.php
El path donde está accesible puede parecer extraño, pero las solicitudes en vBulletin son manejadas por forum.php en lugar del index.php.
Al rastrearlo, encontramos al culpable en la base de datos dentro de la tabla plugin:
De la imagen de arriba, vemos 2 registros que se presentan como plugins init_startup. Esto inmediatamente llamó nuestra atención ya que no más de un plugin no puede tener el mismo nombre dentro de vBulletin.
Hemos identificado los plugins responsables de mostrar el shell, sin embargo, la investigación no se ha detenido allí. Esos plugins aún deben tener una incidencia dentro de la línea pluginlist dentro de la tabla datastore para poder activarse y actuar en el sitio web.
Un Cuento de Dos Hackers
Analizando muy rápidamente esos registros, hemos encontrado varias piezas de código malicioso:
Al comprobar la entrada de la base de datos, vemos dos conjuntos de código que tienen el mismo propósito. Esto indica la probabilidad de que al menos dos atacantes diferentes han explotado la misma vulnerabilidad a través de un sistema automatizado y agregado el mismo malware.
Lo curioso es que después de la primera instrucción “exit”, el segundo conjunto de código se vuelve no funcional ya que ya no será leído o ejecutado por el servidor.
En otras palabras, el primer atacante comprometió el sitio web y luego el segundo intentó exactamente lo mismo. Desafortunadamente para ellos, el init_startup ya existía y su ataque simplemente infectó el plugin ya existente. Puesto que la primera infección era el shell regular y no el c99, esto significa que el c99 no funcionó.
Backdoor Global en vBulletin
También había otra pieza pequeña, pero potente de malware inyectada en la base de datos:
Este código hace que todo el foro sea un backdoor, independientemente del área en la que se encuentre. El único requisito es enviar una instrucción a través de una solicitud $_GET o $_POST como:
forum.php?x=shell_exec&y=rm -rf ./
Puede parecer un conjunto de instrucciones extremadamente simple, pero es más que suficiente para eliminar todos los archivos del sitio web.
Muchos otros conjuntos de instrucciones se pueden enviar de esta manera para infectar el sitio web con otros tipos de malware.
Conclusión
Esto plantea algunas preocupaciones serias.
¿Y si las infecciones tuvieran algún tipo de incompatibilidad entre ellas?
¿Qué pasa si el resultado fue destructivo para su sitio web?
Una multitud de problemas pueden surgir tan pronto como su sitio web se vuelva vulnerable, por lo que es extremadamente importante para mantenerlo seguro y asegúrese de tener la protección de un firewall para solucionar problemas de seguridad y evitar que los hackers entren en su sitio web.
