Esta publicación detalla el análisis forense realizado por el profesional de seguridad de la información durante la operación de limpieza. El experto también nota recomendaciones de seguridad específicas de WordPress basadas en el análisis.
Fondo
El cliente había registrado recientemente un nuevo nombre de dominio, configuró un espacio web en su VPS y luego comenzó a instalar manualmente la versión más reciente de WordPress. Antes de completar la instalación ejecutando el script de instalación de WordPress, se fueron de vacaciones por una semana, suponiendo que pudieran completar la instalación a su regreso. Normalmente, la instalación de WordPress se completará ingresando las credenciales de la base de datos.
Después de que el cliente regresó de sus vacaciones, intentaron acceder a su sitio para completar la instalación, pero recibieron una advertencia del navegador.
Ignorando la advertencia e ingresando al sitio, se mostró una página negra con el logo “Rooted Syntax”.
Análisis forense
Un rápido Google para “Rooted Syntax” condujo al experto en seguridad de la información a la página de Facebook de un grupo de hackers, que contenía publicaciones con detalles sobre los sitios que habían desfigurado y hackeado.
También quedó claro a partir de una búsqueda en Google que otros sitios se habían borrado de la misma manera.
La primera tarea fue hacer SSH en el servidor donde se alojó el sitio hackeado para ver la raíz de WordPress. El profesional notó algunas rarezas que normalmente no serían parte de una instalación base de WordPress.
Los siguientes archivos y directorios llamaron la atención:
- Doc_file
- zip
- webmail
- php
Además de los archivos no estándar, también anotó las marcas de tiempo de los archivos, la instalación original se había realizado el 20 de marzo y estaba claro que los archivos se habían agregado después de esa fecha.
Para iniciar la limpieza, el experto movió la raíz del documento a otra ubicación para su posterior análisis e instaló una nueva página de espera HTML estática para el sitio.
Uno de los archivos que se modificó desde la instalación original fue wp-config.php.
Al verlo, quedó inmediatamente claro que el hacker había completado la instalación de WordPress ingresando sus propias credenciales de MySQL, alojadas en un servidor utilizado por el hacker.
Usando esas credenciales de MySQL, pude ejecutar consultas SQL desde el host de mi cliente para ayudar en mi investigación. Ejecuté SHOW TABLES y me mostró 2.310 tablas, considerando que cada instancia de WordPress usa 12 tablas por defecto, lo que hace que aproximadamente 192 instalen WordPress hackeado en este único servidor MySQL. La opción $ table_prefix en MySQL wp-config.php se usó para dar a cada instalación un prefijo único.
Estaba interesado en ver qué archivos, si hay alguno, habían sido editados recientemente a través del sistema de administración de WordPress. Ejecuté SQL select option_value de jhmxeoptions donde option_name = ‘recently_edited’ \ G para ver qué archivos habían sido editados recientemente por un usuario administrador.
Los hackers obtuvieron el control del sitio al ingresar los detalles de su propia base de datos y, posteriormente, alteraron la página de inicio del tema Veinte diecisiete predeterminado al colocar en este nuevo archivo index.php a través del sistema de administración.
Dentro del index.php había una gran cantidad de código ofuscado. Los hackers dejaron en un comentario la herramienta utilizada para generar el código ofuscado: FOPO. Desafortunadamente, la herramienta no desactivará el código sin una clave de cifrado.
El ofuscador funciona ejecutando el código PHP inicial a través de una serie de etapas que involucran las funciones str_rot13, gzinflate y base64_decode de PHP. Eventualmente, esto condujo al experto al archivo PHP fuente original.
Al examinar el código fuente más de cerca se reveló que muchas de las acciones del script consisten en descargar e instalar scripts maliciosos desde ubicaciones remotas, incluido el wso.php previamente encontrado. Los scripts adicionales se descargan al pasar en el parámetro raíz GET, por ejemplo, index.php? Root = domains.
También hay una opción genérica de carga de archivos disponible en root = home.
Después de recopilar esta información, el profesional de seguridad de la información tiene claro que los hackers podrían haber accedido a otras partes del servidor web. El analista continuó la investigación buscando otros archivos maliciosos en todo el sistema de archivos, pero no encontró nada.
El investigador de seguridad de la información llegó a la dirección abuse @ para la red que posee la dirección IP utilizada por el servidor MySQL para que puedan tomar medidas adicionales.
La suposición para este caso particular fue que los hackers están buscando sitios web en dominios recientemente registrados, y luego tratan de ver si se completó la configuración de WordPress. Si encuentran un escenario así, entonces se están haciendo cargo del sitio al poner sus propios detalles de MySQL. El escaneo de dichos sitios es trivial, por ejemplo, Shodan le permite buscar sitios web que expongan el script de instalación de wp-admin / setup-config.php.
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
