Verificaciones Maliciosas en Google Search Console

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone

El verano pasado, observamos una mayor tendencia a los ataques de SEO blackhat que tratan de verificar cuentas adicionales, como propietarios de sitios web comprometidos en Google Search Console (anteriormente conocido como Herramientas para Webmasters)

Google Search Console proporciona información y herramientas realmente útiles para los webmasters que quieren:

Saber el desempenõ de sus sitios web en los resultados de búsqueda.
Recibir notificaciones acerca de los problemas de rendimiento, configuración y seguridad.
Resolver problemas de Optimización de Motor de Búsqueda (Search Engine Optimization – SEO).

Realmente no hay razón para que alguien no registre su sitio web allí. Google Search Console contiene informaciones muy buenas para cualquier persona que quiere que su sitio web sea indexado por Google. Los hackers se dan cuenta de esto y tratan de obtener acceso a Search Console para los sitios web que hackean, especialmente cuando añaden su propio contenido de spam y se convierten, técnicamente, en webmasters (maliciosos).

Por ejemplo, se encontró eso en un modelo de un pharma doorway generator:

Esa línea de código permite a los hackers verificar la propiedad de sitios web comprometidos.

El uso meta tags de verificación de Google es sólo uno de los muchos enfoques que los hackers utilizan. En este post, vamos a mostrar otros trucos (más sofisticados) y hablar de los resultados de estos hacks.

¿Por qué Verificar la Propiedad de Sitios Web Hackeados?

En primer lugar, usted debe darse cuenta de que verificar la propiedad de un sitio web en Search Console no hace que usted sea el propietario real de un sitio web. Es sólo una manera de demostrar a Google que usted controla este sitio web. Hay varias maneras de hacer esto – usted puede probar que tiene acceso al servidor de archivos, a los registros DNS del dominio, o a servicios relacionados, tales como Google Analytics. Una vez que haya verificado su acceso al sitio web como administrador en otros lugares, Google le mostrará información exclusiva para propietarios de sitios web. También puede hacer algunas cosas que pueden afectar a la forma cómo Google indexa su sitio web y muestra los resultados de búsqueda.

Usted también debe darse cuenta de que Google permite que un sitio web tenga varios propietarios (por ejemplo, un verdadero propietario y otro webmaster se pueden verificar como propietarios, así como terceros expertos de SEO que pueden necesitar permisos completos de “propietario”, mientras trabajan en el sitio web). Cada propietario debe verificar la propiedad de forma individual y agregar sitios web a su Search Console. Si los hackers logran pasar por propietarios de su sitio web, no significa que Search Console (o su cuenta de Google) fue hackeado.

Entonces, ¿por qué lo hacen?

Bueno, sólo puedo adivinar, pero los hackers pueden utilizar Search Console para hacer varias cosas:

  1. Reunir estadísticas que pueden mostrarles cómo su campaña de SEO de blackhat funciona: clics, impresiones, CTR, posiciones en la sección de resultados de búsqueda y otras ventajas del “Search Analytics” de Google.
  2. Enviar sitemaps de sus páginas web con spam para que Google las encontre rápidamente, lo que significa que no hay que esperar hasta que Google encuentre esas páginas web por medio de links en otros sitios web. Hackers pueden creer que Google tratará sus páginas de spam como legítimas cuando las submeten en un sitemap directamente a partir del propietário de sitio web verificado.
  3. Obter notificaciones sobre detección de hacks. Eso puede ajudarlo a estimar la eficiéncia con la cual Google detecta sus entradas y la cantidade de daños que hace para sus campañas.
  4. Hacer con que cuentas de propietarios de sitios web verificados como ilegítimos , no reciban notificaciones (e.g. sobre seguridad) de Google Search Console.

Vamos nos centrar en el último punto y ver qué pasa cuando alguien añade un nuevo propietario a un sitio web en Search Console y cuando alguien elimina otros propietarios de sitios web (comprueban que sus contas no son legítimas).

Notificación de Nuevo Propietario

Cuando alguien verifica la propiedad de una nueva cuenta de Google, todos los propietarios de sitios web existentes reciben inmediatamente una notificación por correo electrónico diciéndoles, “Google identificó que ejemplo@gmail.com se añadió como propietario de una cuenta de Search Console para http://www.ejemplo.com“. Este correo electrónico también advierte que sólo las personas competentes deben tener dicho acceso y proporciona links útiles para gestionar los usuarios existentes y sus niveles de permisos.

Notificación de Nuevo Propietário en Search Console
Notificación de Nuevo Propietário en Search Console

Hasta aquí todo va bien. Si los hackers se incluyen como propietarios de su sitio web usted lo sabrá de inmediato y podrá investigar y resolver el problema de seguridad (verifique su cuenta como no legítima, evalue los daños, limpie su sitio web, acabe con los agujeros de seguridad, etc.). Esto es realmente genial y servicial. ¡Gracias, Google!

No Verificar la Propiedad es Fácil

¿Y si usted no ha visto el correo electrónico?

Y si usted estaba de vacaciones y cuando regresó este correo electrónico se perdió entre muchos otros que quedaron sin leer, y si eso pasó por meses… Este escenario da a los hackers tiempo que pueden utilizar, por ejemplo, para no verificar su propiedad, así nunca más recibirá ninguna otra notificación de su sitio web (por ejemplo, cuando Google detecta problemas de seguridad causados por el hack). ¿Puede adivinar qué más? No recibirá ninguna notificación por parte de Google diciéndole que ya no es el propietario de su sitio web en Search Console.

Si usted se conecta pocas veces al Search Console, entonces nunca sabrá que ya no tiene acceso a los datos de su sitio web allí.

Ahora imagine el siguiente escenario: Google detecta y notifica a los propietarios de sitios web sobre el hack. Sólo los hackers recibirán esta notificación. El propietario real del sitio web ni siquiera sabrá sobre el hack y ni hará nada para limpiar el sitio web. Esta vez, los hackers pueden mitigar el problema para ellos. Por ejemplo, se pueden eliminar temporalmente sus doorways y pedir una revisión a Google. Cuando el equipo del Google Web Spam no encuentra doorways, desbloquea el sitio web y les notifica a los propietarios del sitio web (en nuestro caso, los hackers) sobre el tema en Search Console. Tras esta notificación, los hackers simplemente restauran sus páginas con spam (tal vez usando un patrón de URL ligeramente diferente) y siguen explotando los recursos del sitio web hackeado.

WNC-582900

Llega de especulación en el mundo real. ¿Hackers, en realidad, se pasan por propietarios de sitios web en Google Search Console? La respuesta es sí. Los correos electrónicos de notificación del “nuevo propietario” de Google nos ayudan a demostrarlo. Esa última frase del mensaje dice lo siguiente:

Haga preguntas en nuestro foro para obtener ayuda – mencione el mensaje del tipo [WNC-582900].

Se hacen preguntas en el Foro de Google Webmaster mencionando este tipo de mensaje, la mayoría de estos mensajes están relacionados con hacks de sitios web.

Nuevos Usuarios Múltiplos

Por lo general, los hackers añaden más de un “propietario” por cuenta. Esta discusiónmenciona dos nuevos propietarios comprobados. Otros webmasters han informado que recibieron informes sobre los nuevos 30 propietarios “verificados” en un solo día. Otro webmaster ha compartido una captura de pantalla del “Propietario verificado” en su Search Console con más de cien entradas (extrapolación basada en el tamaño y en la posición de la barra de desplazamiento en la captura de pantalla).

Todo empezó ayer por la tarde, cuando recibi muchos mensajes [WNC-582900] de notificación de nuevo propietario y, después, cuando leí mis propietarios de sitio web, ¡habían MUCHOS propietarios listados!

Éstos son sólo algunos de los correos electrónicos de los hackers que utilizaron el Search Console:

  • elsuperwhite @gmail.com
  • haolinliner @gmail.com
  • definitevvdp @gmail.com
  • josephig6aef @gmail.com
  • lindalinyang93 @gmail.com
  • canarykqiw @gmail.com
  • basininn @gmail.com
  • simeqjhz @gmail.com
  • sunbakedukok @gmail.com
  • Ollienickel22586 @gmail.com
  • Wit.61280 @gmail.com

Verificación de HTML Archivo

El método de verificación de sitio web más popular es el uso de archivos HTMLespeciales con nombres como google[code].html y el siguiente contenido:

google-site-verification: google<code>.html

En el ejemplo, el código es un número hexadecimal de 15 dígitos únicos asociado con su cuenta de usuario de Google. Este archivo se puede utilizar para verificar varios sitios web.

Cuando los hackers acceden a un sitio web, es fácil para ellos crear este archivo y verificar la propiedad de un sitio web.

Sigue otra evidencia tomada del foro:

Normalmente, estos archivos se envían a través de vulnerabilidades en aplicaciones web o a través de puertas traseras que los hackers instalan en un sitio web invadido. Es por eso que la supresión de archivos y el cambio de las contraseñas de FTP no es suficiente:

Esto sucedió durante la noche más de 2x. He revisado todos los logs y una audiencia reveló que no era mi cuenta la comprometida – las únicas acciones del servidor FTP que puedo ver son las que yo hice.

Para no verificar estos “propietarios” maliciosos, se debe eliminar los archivos (meta tags, registros DNS) que utilizaron para su verificación. Sin embargo, eliminarlos no siempre es tan fácil cómo eliminar un archivo HTML.

Hay muy pocos casos en los que los webmasters recibieron notificaciones sobre nuevos propietarios de sitios web y de la sección “Propietarios Verificados” de Search Console los mostró claramente cuáles fueron los archivos HTML utilizados para verificarlos, pero no se puede encontrar y eliminar archivos en el servidor. A pesar de la ausencia de archivos de verificación, Google se negó a comprobar los propietarios maliciosos como no legítimos porque los archivos fueron visibles de alguna manera al intentar abrirlos en un navegador.

En este último caso, el webmaster incluso no creía que la notificación era real (a pesar del hecho de que vio a estos nuevos “propietarios” en su Search Console). Ya que su incredulidad fue publicada en el sitio web de acceso público, creo que a esa persona no le importaría si explicamos públicamente por qué los correos electrónicos eran auténticos, el sitio fue hackeado, y por qué no se puede encontrar los archivos de verificación.

En primer lugar, Google usa la dirección de correo electrónico “sc-noreply @ google.com” para los correos electrónicos de notificación del Search Console. Ellos comenzaron a usarlo después de la marca de la renovación de su marca, cuando se cambió Herramientas para Webmasters, que se produjo en mayo. Esto explica por qué no hay muchas referencias a ese correo electrónico en la web.

Spam de SEO Japonés

En nuestra experiencia, la verificación de la propiedad del sitio web se utiliza, principalmente, en los ataques que generan toneladas de páginas doorways de spam en japonés (hay decenas de miles de sitios afectados, con más de mil millones de doorways creadas). Trabajan en un nicho “de bienes de marcas baratas/falsas”, por lo que normalmente puede detectarlos, busca en su sitio web por palabras clave como“louboutin“, “gucci“, “louis vuitton“, “moncler“, “ray ban“, etc. Así que lo primero que hice cuando me encontré con aquel post fue buscar en el sitio web por el Spam de SEO Japonés. Seguramente, lo encontré.

Spam japonês nos resultados de busca.
Spam japonês nos resultados de busca.

Después de haber encontrado el Spam Japonés, sabía exactamente por qué el webmaster no pudo encontrar los archivos de verificación. Este ataque utiliza un enfoque bastante inteligente para se comprobar en Google y merece una revisión detallada:

Reglas de Reescritura de .htaccess

Los atacantes han subido un script PHP que genera doorways para algun subdirectorio, y luego han añadido reglas de reescritura en archivos .htaccess para producir URLs de spam que se parescan un poco más con URLs legítimas – como están en un sitio web de nivel superior, en algunos casos, como páginas html estáticas, etc. Entre estas reglas de reescritura de doorways, ellos también han añadido una regla de reescritura específica para los archivos de verificación de Google:


RewriteRule ^([0-9]+)/(.*)-(.*)-([0-9]+)\.html$ wp-content/file.php?uu=$2-$3-$4 [L]
RewriteRule ^([0-9]+)/google(.*)\.html$ wp-content/file.php?google=$2 [L]
RewriteRule ^(.*)-(.*)-([0-9]+)\.html$ wp-content/file.php?uu=$1-$2-$3 [L]

Como puede ver, la segunda regla coincide con el formato de nombres de archivos de verificación de Google y reescribe las peticiones a un script malicioso file.phpcon un parámetro de “google“, cuyo valor es igual a una Identificación de Search Console única de un archivo de verificación solicitado. Esta regla funciona para cualquier archivo de verificación de Google, independientemente de su nombre. Así que si alguien intenta abrir http:// www. example. com/dir/google77aa6bc3a2973942.html, entre bastidores, el servidor abrirá http:// www. example. com/wp-content/file.php?google=77aa6bc3a2973942.

Múltiples Representaciones del Mismo Sitio Web en Google Search Console

Tenga en cuenta que este archivo .htaccess espera que Google le pedirá el archivo de verificación en un subdirectorio, no el nivel del root. Esto no es un error. Google realmente lo permite comprobar la titularidad de varias secciones y versiones de un mismo sitio web. Por ejemplo, se puede añadir por separado lo siguiente en su cuenta del Search Console:

  • http:// example.com
  • http:// www. example.com
  • https:// example.com
  • https:// www. example.com
  • http:// example.com/blog/
  • etc.

Aunque sea, técnicamente, el mismo sitio web, cada sitio web requiere verificación independiente. En nuestro caso, los hackers estaban específicamente interesados en la propiedad de los subdirectorios que crearon para una campaña de spam.

Verificación Dinámica de Generación de Archivo

Ahora, veamos cómo el script file.php funciona.

Script de doorway com el archivo de verificación de Google
Script de doorway com el archivo de verificación de Google

Es un script de doorway típico que devuelve páginas web con spam para el Googlebot y redirige el resto a los visitantes. Una parte interesante son las últimas cuatro líneas del código. Este script genera dinámicamente el contenido típico (y 100% válido) de un archivo de verificación de Google.

Volvemos a nuestro ejemplo, en lo cual la regla de reescritura de .htaccess ha pedido la página web file.php?google=77aa6bc3a2973942. En este caso, la respuesta del servidor será:

google-site-verification: google77aa6bc3a2973942.html

Eso es exactamente lo que Google espera ver al confirmar la propiedad.

Este truco hace que sea difícil encontrar y eliminar los archivos de verificación si un propietario de un sitio web real quiere comprobar las cuentas de los hackers como no legítimas. Al mismo tiempo, este es un enfoque muy flexible para el atacante, ya que no es necesario que se adhiera a cualquier cuenta específica de Google. Pueden utilizar cualquier cuenta de Google, o muchas cuentas para verificar la propiedad. Si una cuenta está desactivada, no hay que cambiar nada en el servidor para comprobar una cuenta diferente.

Un truco .htaccess similar se encontró en uno de los temas del foro mencionado anteriormente:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^([a-zA-Z0-9_-]+).html$ wp-includes/themes/good/$1.php [L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

En este caso, los archivos de verificación de URL de Google están siendo reescritos en archivos PHP con los mismos nombres en la carpeta wp-includes/themes/good/. En el caso de nuestro ejemplo anterior, wp-includes/themes/good/google77aa6bc3a2973942.php.

Este enfoque también oculta los archivos de verificación de usuarios, pero es una solución menos flexible, ya que requiere la existencia de un archivo degoogle[code].php en el servidor. En este caso, los hackers sólo pueden verificar algunas cuentas predefinidas para las cuales ya se han enviado archivos de verificación. Lo más probable es que sea una versión anterior del mismo ataque.

Para Webmasters

Los usuarios malintencionados que comprueban como si fueran los propietarios de sitios web en Google Search Console es un fenómeno relativamente nuevo y no está claro si esto es algo que los hackers adoptarán como una herramienta útil en su arsenal, o abandonarán como algo de valor cuestionable. En ambos casos, los propietarios de sitios web deben estar preparados para este tipo de ataques que incluso se aprovecha del sistema de notificación de Google.

  1. Regístrese y verifique la propiedad de todos sus sitios web (incluyendo sub-dominios) en Google Search Console. Si alguien intenta verificar la propiedad de sus sitios web (o secciones de sus sitios web), usted recibirá de inmediato una notificación de Google y será capaz de mitigar el problema rápidamente. Si no agrega sus sitios a Google Search Console, usted nunca recibirá estas notificaciones valiosas. Y este no es el único problema de seguridad que Google le notificará.
  2. Si recibe la notificación de “nuevo propietario” de Google, tómelos en serio. Usted debe revisar todas las cuentas desconocidas como ilegítimas e investigar la forma en la cual lograron verificarlas como legítimas. En la mayoría de los casos, esto significa que tenían acceso completo a su sitio web, entonces usted debe cerrar todos los agujeros de seguridad y eliminar cualquier contenido malicioso que los hackers podrían ya haber creado en su sitio web.
  3. Como he mostrado anteriormente, es muy fácil para los hackers eliminarlo como el dueño de su sitio web cuando alguien tiene acceso a su servidor. Y usted ni siquiera se notificará de ello. Si quiere que los hackers no logren verificar su cuenta como ilegítima, considere estos tres métodos de verificación alternativos:

    A diferencia de un archivo HTML y de los métodos de verificación de Meta tags, estos tres métodos requieren que los hackers obtengan acceso a su cuenta de Google, a su nombre de dominio de registro para comprobarlo como no legítimo.

Para Google

Aunque Google haga gran trabajo al notificar rápidamente a los propietarios de sitios web sobre nuevas verificaciones potencialmente maliciosas y proporcionarles toda la información y herramientas necesarias para abordar estas cuestiones, parece que no están preparados para algunos escenarios.

  • ¿Por qué no enviar una notificación de “adiós” a un propietario de sitio web que fue comprobado recientemente? Incluso si se tratara de un propietario ilegítimo completamente benigno, por ejemplo alguien que ya no trabaja en el sitio web, estas personas merecen ser notificadas al respecto. Dado que ya no son “los dueños del sitio web” no se deben preocupar porque Google está enviando muchas notificaciones. Por otro lado, si es algo malicioso, el verdadero propietario del sitio web, sin duda, ¡querrá saber acerca de ello!
  • Vemos que los hackers a veces comprueban algunas cuentas en un tiempo muy corto. Es mejor enviar notificaciones para cada una de ellas. ¿Tal vez también se debe considerar esta actividad como un hack de un sitio web? Esa es una buena razón para echar un vistazo a un sitio web (me refiero a su escáner de malware y spam) y notificar a las cuentas agregadas y enviarlas para una investigación adicional, especialmente cuando aparecen en muchos sitios web no relacionados (hackers a menudo reutilizan cuentas cuando invaden miles de sitios web y exploran docenas de cuentas para cada una de ellas).

Para concluir, me gustaría invitar a los lectores a compartir sus ideas sobre el fenómeno de la “verificación de la propiedad”. ¿Ha notado alguna actividad maliciosa en Google Search Console (ex-Herramientas para Webmasters)?

Fuente:https://blog.sucuri.net

Conocimiento pertenece al mundo
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on StumbleUponShare on TumblrShare on RedditPin on PinterestEmail this to someone