viernes, 17 de abril de 2009
¿No te parecería un poco sospechoso encontrar páginas con texto como "Canada Mail Order Pharmacy Viagra Levitra" o "Buying Viagra In UK" en los sitios oficiales de los gobiernos latinoamericanos, de las fuerzas militares o de las instituciones universitarias? ¿Por qué razón el sitio oficial de una capital enlazaría, desde la mayoría de sus páginas, a una tienda farmacéutica de dudosa calidad? La explicación más probable es que el webmaster no haya publicado estos contenidos y que un tercero sea el responsable de haber insertado estos enlaces de manera maliciosa; es decir, lo más probable es que el sitio haya sido hackeado. Una tendencia que nuestro equipo de Calidad de búsqueda ha observado durante los últimos meses es que cada vez hay más casos de sitios importantes .gov, .mil y .edu en Latinoamérica, pero también casos de pequeñas compañías y blogs, que han sido hackeados.
El objetivo de esta entrada es ayudar a la comunidad de webmasters a prevenir que sus sitios sean atacados, ayudar a determinar cuándo el sitio se ha visto comprometido y dar consejos de cómo corregir el problema y solicitar una reconsideración si esto fuera necesario.
Hacking: ¿Qué, por qué y cómo?
Es probable que hayas escuchado anteriormente el término hacking en distintas áreas de la informática, a veces con connotaciones positivas (por ejemplo expertos en arreglar problemas de sistemas a través de soluciones ingeniosas) y en otras ocasiones con un significado negativo (por ejemplo, piratas informáticos que esquivan los sistemas de protección de un sistema informático y lo atacan para su propio beneficio). Cuando hablamos de un sitio web hackeado, nos estamos refiriendo precisamente a este último caso: personas sin escrúpulos que deciden aprovechar las vulnerabilidades de los sitios web para modificar su contenido, insertando código que en ningún caso sería aprobado por su webmaster.
Ahora, la siguiente pregunta es cómo lo hacen, ¿van los hackers manualmente examinando cada dominio para ver si encuentran alguna nueva vulnerabilidad? No precisamente. Una estrategia más efectiva es utilizar programas que identifiquen automáticamente sitios web con sistemas de gestión de contenidos (CMS) desactualizados (versiones antiguas con fallos conocidos) e insertar el contenido deseado a través de técnicas de hacking conocidas como una inyección SQL o el cross-site scripting (XSS).
El primer caso consiste en insertar trozos de código SQL en los formularios de las páginas que se utilizan para enviar información a la aplicación web (registro, inicio de sesión, comentarios, etc.), con el objetivo de modificar la sentencia SQL y esquivar el sistema de autenticación o introducir información no deseada en la base de datos. El segundo consiste en insertar en los campos del formulario un script que en el momento de ser interpretado por el navegador, redirige al usuario a otra pagina o intenta robar la información almacenada en las cookies para enviarla a un servidor externo. En nuestra entrada Prácticas recomendadas contra el hacking este tema se discute más a fondo y enlazamos hacia algunos artículos interesantes del Web Application Security Consortium donde se discuten los temas de inyección SQL [inglés] y cross-site scripting (XSS) [inglés] .
¿Como prevenir y dectectar el ataque?
Una de las ventajas del movimiento de código abierto es que ha traído consigo un número considerable de aplicaciones para la publicación y administración de blogs como WordPress, sistemas de gestión de contenidos como Joomla y PHP Nuke, o sistemas de gestión de cursos como Moodle, que se pueden descargar e instalar fácilmente. Sin embargo, es muy importante que los webmasters mantengan al día las versiones de sus aplicaciones. Dado que existe una amplia comunidad de usuarios y desarrolladores de estos paquetes, es común que se descubran fallos y que se corrijan en las nuevas versiones. Si tienes instalada una versión antigua de un sistema de gestión que tiene un fallo conocido, es posible que un hacker consiga acceder al sitio y modificar el contenido, por lo tanto es conveniente estar al corriente de las últimas versiones y informarse acerca de las vulnerabilidades conocidas. El sitio BlogSecurity mantiene una lista con los fallos conocidos en las diferentes versiones de WordPress [inglés] o Linux Security ofrece un informe sobre las vulnerabilidades encontradas en Moodle [inglés] y recomienda actualizar el paquete a la última versión.
El uso de un paquete desactualizado es una de las causas más comunes del hacking, pero a su vez es una de las más fáciles de prevenir. Por ejemplo recientemente encontramos un caso de hacking en el sitio oficial de una capital sudamericana y la causa de este problema fue una versión antigua de Moodle en un sistema de enseñanza. Ahora si no utilizas un paquete de código abierto y codificas tu mismo las páginas dinámicas de tu sitio web en lenguajes como PHP o Python, es muy importante que tus scripts eviten la inyección de SQL o el cross-site scripting descritos previamente: Toda la información enviada en los formularios que ofrezca tu sitio debe ser tratada como texto, debes asegurarte de escapar los caracteres especiales como las comillas y debes evitar que ciertas etiquetas HTML puedan ser embebidas dentro de la información enviada (por ejemplo SCRIPT, META, IFRAME, DIV o SPAN). Finalmente es importante que nunca confíes ciegamente en la información enviada en los formularios y prepares tus scripts para el peor de los escenarios posibles en caso de un ataque. El manual oficial de PHP ofrece una buena descripción en castellano sobre en qué consiste y cómo puedes prevenir el ataque.
Ahora, ¿cómo puedes saber si tu sitio ha sido atacado? A veces es evidente dado que el hacker cambia el contenido de la página principal e inserta mensajes como "este sitio ha sido hackeado por tal grupo" o en el peor de los casos puede borrar todos los archivos del sitio a través de sentencias SQL, drop tables . Sin embargo, en los casos que hemos observado en los sitios latinoamericanos el ataque es más discreto dado que los hackers combinan dos técnicas distintas: hacking y encubrimiento (cloaking) . Esta última técnica hace referencia a la práctica de presentar a los usuarios y motores de búsquedas contenido distinto. En estos casos los hackers modifican el código de tal forma que se muestra el contenido normal a los usuarios, pero cuando el Googlebot o algún otro robot visitan tu sitio, muestran una versión ligeramente distinta que contiene un sin número de enlaces escondidos.
Lo que hace difícil detectar esta técnica es que, al revisar tu sitio en un navegador como FireFox o Chrome, no encuentras ninguna anomalía. Sin embargo, el Googlebot rastrea e indexa el contenido hackeado. Una manera muy sencilla de detectar este problema es comparar el código de la última versión de tu página que Google almacenó en cache con el código de la versión que aparece en el navegador. Para hacerlo, agrega en el campo de búsqueda de Google el operador "cache:" y la página que deseas revisar (por ejemplo cache:www.google.com ) y como resultado obtendrás la versión cache de la página. Si en la versión cache aparecen muchos enlaces hacia sitios no deseados acompañados de palabras comerciales, es muy probable que tu sitio haya sido hackeado.
Otro operador muy útil para detectar si tu sitio se ha visto comprometido es el operador "site:" el cual restringe los resultados de acuerdo al dominio especificado. Puedes combinar este operador con una consulta no relacionada con tu sitio, por ejemplo site:https://example.com viagra or site:example.com cialis . Si tu sitio no tiene ningún contenido relacionado con fármacos y esta consulta te devuelve resultados, de nuevo es probable que tu sitio haya sido hackeado. Ahora, si tienes una cuenta de Herramientas para webmasters , puedes mirar cuáles son las palabras principales por las que tu sitio aparece en los resultados de búsqueda y recibir potenciales notificaciones en el Centro de mensajes.
Mi sitio ha sido hackeado ¿y ahora qué hago?
Una vez has identificado que tu sitio web ha sido atacado, lo más importante es implementar las medidas necesarias tanto para corregir el problema como para evitar que ocurra nuevamente. En enero pasado publicamos en este blog una entrada sobre cómo puedes corregir el problema . En resumidas cuentas, consiste en desactivar el sitio mientras se implementan los correctivos (devolviendo una respuesta 503), buscar qué archivos se han visto comprometidos y revertirlos a su estado original, eliminar los directorios o páginas creadas por el hacker, actualizar las últimas versiones del sistema de gestión de contenidos, cambiar las contraseñas y, si fuera necesario, utilizar la herramienta de solicitud de eliminación de URL .
Finalmente, si el hacker modificó tu sitio incluyendo código que viola nuestras Directrices para webmasters , una vez se haya solucionado el problema, puedes solicitar la reconsideración de tu sitio desde las Herramientas para webmasters.
Esperamos que esta entrada sea útil para los webmasters latinoamericanos que administran sitios que pueden ser o que han sido víctimas del hacking. Si tienes cualquier comentario no dudes en dejarlo aquí o enviar la pregunta a nuestro Foro de ayuda para los webmasters .
Hacking: ¿Qué, por qué y cómo?
Es probable que hayas escuchado anteriormente el término hacking en distintas áreas de la informática, a veces con connotaciones positivas (por ejemplo expertos en arreglar problemas de sistemas a través de soluciones ingeniosas) y en otras ocasiones con un significado negativo (por ejemplo, piratas informáticos que esquivan los sistemas de protección de un sistema informático y lo atacan para su propio beneficio). Cuando hablamos de un sitio web hackeado, nos estamos refiriendo precisamente a este último caso: personas sin escrúpulos que deciden aprovechar las vulnerabilidades de los sitios web para modificar su contenido, insertando código que en ningún caso sería aprobado por su webmaster.
Ahora, la siguiente pregunta es cómo lo hacen, ¿van los hackers manualmente examinando cada dominio para ver si encuentran alguna nueva vulnerabilidad? No precisamente. Una estrategia más efectiva es utilizar programas que identifiquen automáticamente sitios web con sistemas de gestión de contenidos (CMS) desactualizados (versiones antiguas con fallos conocidos) e insertar el contenido deseado a través de técnicas de hacking conocidas como una inyección SQL o el cross-site scripting (XSS).
El primer caso consiste en insertar trozos de código SQL en los formularios de las páginas que se utilizan para enviar información a la aplicación web (registro, inicio de sesión, comentarios, etc.), con el objetivo de modificar la sentencia SQL y esquivar el sistema de autenticación o introducir información no deseada en la base de datos. El segundo consiste en insertar en los campos del formulario un script que en el momento de ser interpretado por el navegador, redirige al usuario a otra pagina o intenta robar la información almacenada en las cookies para enviarla a un servidor externo. En nuestra entrada Prácticas recomendadas contra el hacking este tema se discute más a fondo y enlazamos hacia algunos artículos interesantes del Web Application Security Consortium donde se discuten los temas de inyección SQL [inglés] y cross-site scripting (XSS) [inglés] .
¿Como prevenir y dectectar el ataque?
Una de las ventajas del movimiento de código abierto es que ha traído consigo un número considerable de aplicaciones para la publicación y administración de blogs como WordPress, sistemas de gestión de contenidos como Joomla y PHP Nuke, o sistemas de gestión de cursos como Moodle, que se pueden descargar e instalar fácilmente. Sin embargo, es muy importante que los webmasters mantengan al día las versiones de sus aplicaciones. Dado que existe una amplia comunidad de usuarios y desarrolladores de estos paquetes, es común que se descubran fallos y que se corrijan en las nuevas versiones. Si tienes instalada una versión antigua de un sistema de gestión que tiene un fallo conocido, es posible que un hacker consiga acceder al sitio y modificar el contenido, por lo tanto es conveniente estar al corriente de las últimas versiones y informarse acerca de las vulnerabilidades conocidas. El sitio BlogSecurity mantiene una lista con los fallos conocidos en las diferentes versiones de WordPress [inglés] o Linux Security ofrece un informe sobre las vulnerabilidades encontradas en Moodle [inglés] y recomienda actualizar el paquete a la última versión.
El uso de un paquete desactualizado es una de las causas más comunes del hacking, pero a su vez es una de las más fáciles de prevenir. Por ejemplo recientemente encontramos un caso de hacking en el sitio oficial de una capital sudamericana y la causa de este problema fue una versión antigua de Moodle en un sistema de enseñanza. Ahora si no utilizas un paquete de código abierto y codificas tu mismo las páginas dinámicas de tu sitio web en lenguajes como PHP o Python, es muy importante que tus scripts eviten la inyección de SQL o el cross-site scripting descritos previamente: Toda la información enviada en los formularios que ofrezca tu sitio debe ser tratada como texto, debes asegurarte de escapar los caracteres especiales como las comillas y debes evitar que ciertas etiquetas HTML puedan ser embebidas dentro de la información enviada (por ejemplo SCRIPT, META, IFRAME, DIV o SPAN). Finalmente es importante que nunca confíes ciegamente en la información enviada en los formularios y prepares tus scripts para el peor de los escenarios posibles en caso de un ataque. El manual oficial de PHP ofrece una buena descripción en castellano sobre en qué consiste y cómo puedes prevenir el ataque.
Ahora, ¿cómo puedes saber si tu sitio ha sido atacado? A veces es evidente dado que el hacker cambia el contenido de la página principal e inserta mensajes como "este sitio ha sido hackeado por tal grupo" o en el peor de los casos puede borrar todos los archivos del sitio a través de sentencias SQL, drop tables . Sin embargo, en los casos que hemos observado en los sitios latinoamericanos el ataque es más discreto dado que los hackers combinan dos técnicas distintas: hacking y encubrimiento (cloaking) . Esta última técnica hace referencia a la práctica de presentar a los usuarios y motores de búsquedas contenido distinto. En estos casos los hackers modifican el código de tal forma que se muestra el contenido normal a los usuarios, pero cuando el Googlebot o algún otro robot visitan tu sitio, muestran una versión ligeramente distinta que contiene un sin número de enlaces escondidos.
Lo que hace difícil detectar esta técnica es que, al revisar tu sitio en un navegador como FireFox o Chrome, no encuentras ninguna anomalía. Sin embargo, el Googlebot rastrea e indexa el contenido hackeado. Una manera muy sencilla de detectar este problema es comparar el código de la última versión de tu página que Google almacenó en cache con el código de la versión que aparece en el navegador. Para hacerlo, agrega en el campo de búsqueda de Google el operador "cache:" y la página que deseas revisar (por ejemplo cache:www.google.com ) y como resultado obtendrás la versión cache de la página. Si en la versión cache aparecen muchos enlaces hacia sitios no deseados acompañados de palabras comerciales, es muy probable que tu sitio haya sido hackeado.
Otro operador muy útil para detectar si tu sitio se ha visto comprometido es el operador "site:" el cual restringe los resultados de acuerdo al dominio especificado. Puedes combinar este operador con una consulta no relacionada con tu sitio, por ejemplo site:https://example.com viagra or site:example.com cialis . Si tu sitio no tiene ningún contenido relacionado con fármacos y esta consulta te devuelve resultados, de nuevo es probable que tu sitio haya sido hackeado. Ahora, si tienes una cuenta de Herramientas para webmasters , puedes mirar cuáles son las palabras principales por las que tu sitio aparece en los resultados de búsqueda y recibir potenciales notificaciones en el Centro de mensajes.
Mi sitio ha sido hackeado ¿y ahora qué hago?
Una vez has identificado que tu sitio web ha sido atacado, lo más importante es implementar las medidas necesarias tanto para corregir el problema como para evitar que ocurra nuevamente. En enero pasado publicamos en este blog una entrada sobre cómo puedes corregir el problema . En resumidas cuentas, consiste en desactivar el sitio mientras se implementan los correctivos (devolviendo una respuesta 503), buscar qué archivos se han visto comprometidos y revertirlos a su estado original, eliminar los directorios o páginas creadas por el hacker, actualizar las últimas versiones del sistema de gestión de contenidos, cambiar las contraseñas y, si fuera necesario, utilizar la herramienta de solicitud de eliminación de URL .
Finalmente, si el hacker modificó tu sitio incluyendo código que viola nuestras Directrices para webmasters , una vez se haya solucionado el problema, puedes solicitar la reconsideración de tu sitio desde las Herramientas para webmasters.
Esperamos que esta entrada sea útil para los webmasters latinoamericanos que administran sitios que pueden ser o que han sido víctimas del hacking. Si tienes cualquier comentario no dudes en dejarlo aquí o enviar la pregunta a nuestro Foro de ayuda para los webmasters .