La mayoría de los desarrolladores conocen y aman las páginas de Github. En caso de que no se haya reunido con ellos, este servicio permite crear un sitio estático desde su repositorio, que estará disponible en el dominio smth.imtqy.com. Esto es increíblemente conveniente para cualquier estadística temporal, documentación, pequeños sitios simples, etc. No es necesario pensar en algún tipo de servidor web adicional.
También existe la oportunidad de vincular su dominio al repositorio, entonces todo será muy hermoso. Incluso hay soporte SSL.
Después de esta breve introducción, pasamos al tema real del artículo. Más recientemente (9 de noviembre) tuve una historia interesante. Recomiendo no leerlo de un trago, sino detenerse periódicamente y preguntarme qué significan todas las notas introductorias recibidas en este momento. Creo que surgirá un entrenamiento interesante, aunque la trama de mi detective no fue muy larga y retorcida.
Decidí agregar la dirección de mi currículum al siguiente perfil. El resumen solo se encuentra en las páginas de Github, porque ¿por qué no? Por costumbre, hizo clic para verificar si todo funcionaba ... Y de repente descubrí algo extraño allí:
Estaba muy sorprendido Fue a la configuración del repositorio. Vi que en este momento no está vinculado al dominio al que debería estar vinculado. Traté de romper. De repente recibí un error:
El CNAME whois.jehy.ru ya está en uso. Consulte https://help.github.com/articles/troubleshooting-custom-domains/#cname-already-taken para obtener más información
Se tensó un poco y se sorprendió. Después de eso fui a mirar de cerca esta página repentina. Como antes, solo vi una cierta plantilla estándar, derechos de autor de 2013 y de repente un enlace al mapa del sitio. El mapa del sitio contiene la fecha de su generación a partir de la fecha actual, así como un documento html estático con un título y contenido que recuerda mucho al método de validación de google (nombre googlef3e716e930ae1730 , contenido de google-site-verification: googlef3e716e930ae1730.html ). Aquí ya estaba muy tenso, corrí, cambié el registro NS a mi servidor y comencé a pensar qué había salido mal.
La búsqueda en superficie reveló lo siguiente:
- Parece que el secuestro de dominio es un problema potencialmente conocido, y ya se ha resuelto: es suficiente para registrar la dirección de su repositorio en CNAME .
- A pesar de esto, en muchas instrucciones sobre cómo vincular un github a un dominio (incluidas las 10 búsquedas principales), las IP se escriben directamente o simplemente imtqy.com.
Entonces pensé que probablemente tenía un registro CNAME. Así que lo cambié por el correcto, atado a mi repositorio. Ahora la entrada se veía así:
dig whois.jehy.ru +nostats +nocomments +nocmd ; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> whois.jehy.ru +nostats +nocomments +nocmd ;; global options: +cmd ;whois.jehy.ru. IN A whois.jehy.ru. 6984 IN CNAME jehy.github.io. jehy.github.io. 3384 IN A 185.199.108.153 jehy.github.io. 3384 IN A 185.199.110.153 jehy.github.io. 3384 IN A 185.199.109.153 jehy.github.io. 3384 IN A 185.199.111.153
¡Y cuál fue mi asombro cuando volví a ver este maravilloso aterrizaje "Próximamente"!
Para verificar, incluso hice otra prueba:
1) Comenzó un nuevo registro CNAME test.jehy.ru e indicó para ella un perfil de Ryan Dahl
2) Comenzó un repositorio de prueba , especificando para él un dominio personalizado test.jehy.ru. Todo parece ser correcto, de acuerdo con las instrucciones, y el enlace no debería funcionar. Pero, por desgracia, el resultado es obvio .
Luego, contacté al soporte técnico de Github a través de un formulario extraño en el sitio . Allí me dijeron que podían desvincular el repositorio de otra persona de mi dominio si me añadía otro registro NS. Lo hice, lo escribí de vuelta y desde el viernes hasta el lunes no recibí una respuesta. Tal vez fue necesario volver a escribir de esta forma, pero ya era superior a mi fuerza. Así que acabo de dejar mi sitio estático en mi servidor.
En ese momento, tenía tres opciones para lo que sucedió:
1) Alguien escribió accidentalmente la dirección "whois.jehy.ru" en su repositorio en 2018, mientras presentaba una página de inicio con "próximamente" desde 2013, donde por alguna razón se encuentra un html de Google para verificar los derechos. Bueno, apenas
2) Algún error loco sucedió. También es poco probable. Repitió en el segundo sitio de prueba.
3) El enfoque basado en CNAME nunca funcionó o se rompió, y los atacantes lo usan para atacar. Hasta ahora, esta me pareció la opción más probable.
Entonces recordé que, en el caso del enlace de dominio, github crea un archivo llamado CNAME en su repositorio. Y fue a buscar quién agregó mi dominio. Y - bingo!
Se encontró un atacante en una búsqueda:
Aquí está mi dominio:
Y aquí hay un montón de otros:
Como puede ver, esto no fue un accidente en absoluto. Alguien robó una cantidad decente de dominios, ¡incluido el segundo nivel! ¡Y obtuvo el control total sobre sus contenidos, incluida la confirmación en Google de los derechos de propiedad de estos dominios!
Por cierto, también puede agregar que a veces un hacker no solo reemplaza el contenido del sitio, sino que bifurca el repositorio original, después de lo cual agrega archivos de verificación allí. Y, por lo tanto, ha sido divertido durante al menos un mes (encontré confirmaciones imprevistas del 6 de octubre). Bueno, los seguidores son similares allí.
Además, mis suposiciones sobre cómo se produce dicho ataque y por qué es necesario.
1) Primero, el hacker encuentra sitios que resuelven en imtqy.com. Esto es bastante fácil de hacer.
2) Luego, los filtra, dejando solo aquellos que devuelven un error (parece que solo hay 404 allí). Puede haber muchos casos en los que los repositorios no estaban vinculados: alguien no configuró el repositorio, alguien lo eliminó, alguien obtuvo la configuración de enlace (me parece que eso sucedió cuando cambié la rama de las páginas de Github).
3) Luego, el hacker simplemente crea un nuevo repositorio con el contenido que necesita y lo vincula al dominio "gratuito". Voila!
4) Entonces todo depende solo de la imaginación del hacker. Puertas, colocar enlaces, interceptar datos, acceder a la administración de Google Apps a través de Google ... Hay muchas opciones.
Lo que hice a continuación, con toda la evidencia del uso malicioso de enlaces a mano:
- Descrito en correspondencia con support@github.com todos los detalles;
- Una vez más los reescribió en el formulario de contacto;
- Se agregó un boleto a hackerone.com . Debo decir que dice que githubpages.io no está incluido en el programa de recompensas, pero no había otras opciones. Por lo tanto, tuve que ignorar esta advertencia, e incluso el robot, que gentilmente me aconsejó que no enviara este informe por las mismas razones.
Hasta el día de hoy, no han respondido el formulario de contacto hasta el día de hoy, pero dos días después me respondieron con hackerone. En resumen, la respuesta fue que esta es una característica conocida del servicio, no es una vulnerabilidad y el equipo de spam está involucrado en tales cosas. El informe se cerró como "informativo", por lo que escribo sobre todo lo que sucedió con la conciencia tranquila. También me informaron que la cuenta que indiqué estaba prohibida. Lo comprobé, sí, ya no está. Sus seguidores desaparecieron unos días después (no está claro por qué no de inmediato).
Uno podría terminar con esto y decir que todo está en orden ... Pero, de hecho, estoy extremadamente avergonzado por esta situación:
- ¿Por qué estas cuentas no están en meses? Hay contenido idéntico, hay archivos de validación de Google en todas partes, en una cuenta hay muchos de esos sitios ... Señales comunes: un carro y un carrito pequeño.
- ¿Por qué el equipo de spam no revisó los repositorios relacionados?
- ¿Por qué ves la ilusión de seguridad en las instrucciones para enlazar un dominio, sugiriendo que establezcas el nombre de tu repositorio en CNAME si esto no afecta nada?
- ¿Por qué no hay un mecanismo de advertencia que diga que un dominio que anteriormente estaba vinculado a su cuenta ahora está vinculado a otro?
- ¿Por qué en Github es imposible responder correos electrónicos del soporte? ¿O tal vez me caí bajo algún tipo de filtro?
Pero la pregunta principal que me molesta es por qué github no comprueba los registros NS de los dominios que se enumeran en las páginas de github por la presencia de un repositorio específico de CNAME en ellos. Esta es la operación más simple que se puede realizar al vincular un dominio, y no lleva tiempo ... Además, las instrucciones dan la sensación de que estaba destinado a ser así ... Entonces, ¿por qué está roto este cheque?
En general, escribo esta publicación con la esperanza de que de alguna forma llegue al github, y los chicos tomarán medidas. Antes de la pregunta "¿por qué hablar de eso, todos subirán para hacerlo ahora?", Responderé que el agujero ya es bien conocido y está siendo explotado activamente. Y ahora, claramente, los dominios "abandonados" se escanean constantemente, por lo que varios participantes nuevos no cambiarán la imagen.
Por lo general, no lo hago, pero sería genial si tocas la traducción de este artículo, que puse en el medio. Sí, sé que habr ahora es multilingüe, pero durante todo el tiempo he visto una publicación y media en inglés, y no creo que nadie pueda prestarles atención. Y en el medio, a menudo hay buenas publicaciones técnicas. Por lo tanto, será genial si ayudas a prestar atención a este agujero. En todo caso, no obtendré dinero por esto, no hay tarjeta de EE. UU., El interés es puramente altruista.
¿En qué más puedes pensar al final? Probablemente siempre valga la pena recordar cuándo coloca algo en capacidades de terceros. Por supuesto, en Internet no hay nada personal, y todo es de terceros: "sus" dominios pertenecen al registrador, "sus" servidores pertenecen a Google, Amazon u otra persona ... No se puede decir que el github sea menos confiable que cualquier servidor "propio". ... Pero "su" servidor está de alguna manera más cerca del cuerpo y es más predecible. En general, siempre debe recordar sus recursos, su importancia, las posibles pérdidas al interceptarlos y que en los servicios de terceros puede haber una especificidad de trabajo muy repentina.
PD: Gracias Cavin por la imagen y pndpnd por traducir el artículo al inglés.