security - online - password cracking beini

Mi sitio web fue pirateado... ¿Qué debería hacer? (8)

Mi padre me llamó hoy y me dijo que las personas que iban a su sitio web recibían 168 virus que intentaban descargar a sus computadoras. Él no es técnico en absoluto, y construyó todo con un editor WYSIWYG.

Abrí su sitio y vi la fuente, y había una línea de Javascript en la parte inferior de la fuente justo antes de la etiqueta HTML de cierre. Incluyeron este archivo (entre muchos otros): http://www.98hs.ru/js.js <- APAGAR JAVASCRIPT ANTES DE IR A ESA URL.

Así que lo comenté por ahora. Resulta que su contraseña ftp era una palabra simple del diccionario de seis letras, así que pensamos que así fue como fue pirateada. Cambiamos su contraseña a una cadena de más de 8 dígitos sin palabra (no buscaría una frase de contraseña ya que es un tipeador de caza y pepe).

Hice un whois en 98hs.ru y encontré que está alojado en un servidor en Chile. En realidad, también hay una dirección de correo electrónico asociada, pero tengo serias dudas de que esta persona sea la culpable. Probablemente solo otro sitio que fue pirateado ...

No tengo idea de qué hacer en este momento, ya que nunca antes había tratado con este tipo de cosas. ¿Alguien tiene alguna sugerencia?

Estaba usando el ftp simple no protegido de jane a través de webhost4life.com. Ni siquiera veo una manera de hacer sftp en su sitio. ¿Estoy pensando que su nombre de usuario y contraseña fueron interceptados?

Entonces, para que esto sea más relevante para la comunidad, ¿cuáles son los pasos que debe seguir / mejores prácticas que debe seguir para proteger su sitio web de ser pirateado?

Para el registro, aquí está la línea de código que "mágicamente" se agregó a su archivo (y no está en su archivo en su computadora; lo dejé comentado solo para asegurarme de que no hará nada) en esta página, aunque estoy seguro de que Jeff se preocupó por esto):

¿Es el sitio simplemente HTML estático? es decir, ¿no ha logrado codificarse a sí mismo una página de carga que permita a cualquier persona que conduzca cargar guiones / páginas comprometidas?

¿Por qué no preguntar a webhost4life si tienen registros de FTP disponibles y reportar el problema a ellos? Nunca se sabe, pueden ser muy receptivos y descubrir exactamente lo que sucedió.

Trabajo para un proveedor de servicios compartidos y siempre recibimos informes como estos y, por lo general, podemos identificar el vector exacto de ataque y asesorar sobre dónde se equivocó el cliente.

Con una contraseña de seis caracteres, puede haber sido forzado por fuerza bruta. Eso es más probable que su ftp sea interceptado, pero podría ser eso también.

Comience con una contraseña más segura. (8 caracteres todavía es bastante débil)

Vea si este enlace a un blog de seguridad en Internet es útil.

Intenta reunir tanta información como puedas. Vea si el host puede darle un registro que muestre todas las conexiones FTP que se hicieron a su cuenta. Puede usarlos para ver si fue incluso una conexión FTP que se utilizó para realizar el cambio y, posiblemente, obtener una dirección IP.

Si está utilizando un software preempaquetado como Wordpress, Drupal o cualquier otra cosa que no haya codificado, puede haber vulnerabilidades en el código de carga que permitan este tipo de modificación. Si está hecho a medida, compruebe dos veces los lugares donde permite a los usuarios cargar archivos o modificar archivos existentes.

La segunda cosa sería tomar un vertedero del sitio tal como está y verificar todo para ver otras modificaciones. Puede ser solo una modificación que hicieron, pero si ingresaron vía FTP, quién sabe qué más hay allá arriba.

Vuelva su sitio a un buen estado conocido y, si es necesario, actualice a la última versión.

Hay un nivel de rentabilidad que también debes tener en cuenta. ¿Vale la pena tratar de rastrear a la persona o es algo en lo que solo vives y aprendes y usas contraseñas más fuertes?

Mencionas que tu papá estaba usando una herramienta de publicación de sitios web.

Si la herramienta de publicación publica desde su computadora al servidor, puede ser que sus archivos locales estén limpios y que solo necesite volver a publicar en el servidor.

Debería ver si hay un método de inicio de sesión diferente para su servidor que un simple FTP, aunque ... eso no es muy seguro porque envía su contraseña como texto claro a través de Internet.

¡Nos habían pirateado los mismos tipos aparentemente! O bots, en nuestro caso. Usaron la inyección SQL en URL en algunos viejos sitios ASP clásicos que nadie más mantiene. Encontramos atacar direcciones IP y las bloqueamos en IIS. Ahora debemos refactorizar todos los ASP anteriores. Por lo tanto, mi consejo es echar un vistazo a los registros de IIS primero, para encontrar si hay algún problema en el código de su sitio o en la configuración del servidor.

Desconecte el servidor web sin cerrarlo para evitar secuencias de comandos de apagado. Analice el disco duro a través de otra computadora como una unidad de datos y vea si puede determinar el culpable a través de archivos de registro y cosas de esa naturaleza. Verifique que el código sea seguro y luego restaurelo desde una copia de seguridad.

Esto le sucedió a un cliente mío recientemente alojado en ipower. No estoy seguro de si su entorno de hosting estaba basado en Apache, pero si era seguro, verifique si hay archivos .htaccess que no haya creado, particularmente encima de la raíz web y dentro de los directorios de imágenes, ya que tienden a inyectar un poco de maldad. también (estaban redireccionando a las personas dependiendo de dónde venían en el referido). También verifique cualquier cosa que haya creado para un código que no haya escrito.

Sé que esto es un poco tarde en el juego, pero la URL mencionada para el JavaScript se menciona en una lista de sitios conocidos por haber sido parte del resurgimiento del bot ASPRox que se inició en junio (al menos eso fue cuando nos marcaron con eso). Algunos detalles al respecto se mencionan a continuación:

http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx

Lo desagradable de esto es que efectivamente cada campo de tipo varchar en la base de datos está "infectado" para escupir una referencia a esta URL, en la que el navegador obtiene un pequeño iframe que lo convierte en un bot. Aquí puede encontrar una solución SQL básica para esto:

http://aspadvice.com/blogs/programming_shorts/archive/2008/06/27/Asprox-Recovery.aspx

Sin embargo, lo más tenebroso es que el virus busca que los valores de los archivos del sistema se infecten y muchos planes de alojamiento compartido también comparten el espacio de la base de datos para sus clientes. Así que lo más probable es que ni siquiera el sitio de su padre estuviera infectado, sino el sitio de otra persona dentro de su clúster de alojamiento que escribió un código deficiente y abrió la puerta al ataque de inyección SQL.

Si todavía no lo ha hecho, enviaría un correo electrónico URGENTE a su anfitrión y les daría un enlace a ese código SQL para arreglar todo el sistema. Puede arreglar sus propias tablas de base de datos afectadas, pero lo más probable es que los bots que están infectando pasen por ese agujero otra vez e infecten todo el lote.

Espero que esto te brinde más información para trabajar.

EDITAR: Una idea más rápida, si usa una de las herramientas de diseño en línea de los hosts para construir su sitio web, todo ese contenido probablemente esté en una columna y se haya infectado de esa manera.