Die meisten Entwickler kennen und lieben Github-Seiten. Falls Sie sich nicht mit ihnen getroffen haben, können Sie mit diesem Dienst eine statische Site aus Ihrem Repository erstellen, die in der Domäne smth.imtqy.com verfügbar ist. Dies ist unglaublich praktisch für temporäre Statiken, Dokumentationen, kleine einfache Sites und so weiter. Sie müssen nicht über einen zusätzlichen Webserver nachdenken.
Es besteht auch die Möglichkeit, Ihre Domain an das Repository zu binden - dann wird alles sehr schön. Es gibt sogar SSL-Unterstützung.
Nach dieser kurzen Einführung wenden wir uns dem eigentlichen Thema des Artikels zu. Zuletzt (9. November) hatte ich eine interessante Geschichte. Ich empfehle, es nicht in einem Zug zu lesen, sondern in regelmäßigen Abständen anzuhalten und sich zu fragen, was alle im Moment erhaltenen einleitenden Anmerkungen bedeuten. Ich denke, daraus wird ein interessantes Training, obwohl die Handlung meines Detektivs nicht sehr lang und verdreht war.
Ich habe beschlossen, die Adresse meines Lebenslaufs zum nächsten Profil hinzuzufügen. Die Zusammenfassung liegt nur auf Github-Seiten, denn warum nicht? Aus Gewohnheit klickte er, um zu überprüfen, ob alles funktionierte ... Und plötzlich entdeckte ich dort etwas Seltsames:
Ich war sehr überrascht Ging zu Repository-Einstellungen. Ich habe gesehen, dass es im Moment nicht an die Domäne gebunden ist, an die es gebunden werden soll. Ich versuchte zu schnappen. Plötzlich bekam ein Fehler:
Der CNAME whois.jehy.ru ist bereits vergeben. Weitere Informationen finden Sie unter https://help.github.com/articles/troubleshooter-custom-domains/#cname-already-taken
Er spannte sich ein wenig an und war überrascht. Danach habe ich mir diese plötzliche Seite genau angesehen. Nach wie vor sah ich dort nur eine bestimmte Standardvorlage, Copyright von 2013 und plötzlich einen Link zur Sitemap. Die Sitemap enthält das Erstellungsdatum ab dem aktuellen Datum sowie ein statisches HTML-Dokument mit einem Titel und Inhalt, der stark an die Google-Validierungsmethode erinnert (Name googlef3e716e930ae1730 , Inhalt der google-site-verification: googlef3e716e930ae1730.html ). Hier war ich schon stark angespannt, rannte, änderte den NS-Datensatz auf meinen Server und begann zu überlegen, was schief gelaufen war.
Oberflächen-Googeln ergab Folgendes:
- Es scheint, dass Domain-Hijacking ein potenziell bekanntes Problem ist und bereits behoben wurde. Es reicht aus, die Adresse Ihres Repositorys in CNAME zu registrieren .
- Trotzdem werden in vielen Anweisungen zum Binden eines Githubs an eine Domain (einschließlich der Top-10-Suchanfragen) IPs direkt oder einfach in imtqy.com geschrieben.
Dann dachte ich, ich hätte wahrscheinlich einen CNAME-Eintrag. Also habe ich es in das richtige geändert, das an mein Repository gebunden ist. Jetzt sah der Eintrag so aus:
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
Und was war mein Erstaunen, als ich wieder diese wundervolle Landung „Coming Soon“ sah!
Um das zu überprüfen, habe ich sogar einen weiteren Test durchgeführt:
1) Startete einen neuen CNAME-Datensatz test.jehy.ru und gab ihr ein Profil von Ryan Dahl an
2) Startete ein Test-Repository und gab dafür eine benutzerdefinierte Domäne test.jehy.ru an. Gemäß den Anweisungen scheint alles korrekt zu sein, und die Bindung sollte nicht funktionieren. Aber leider ist das Ergebnis offensichtlich .
Als nächstes kontaktierte ich den technischen Support des Githubs über ein seltsames Formular auf der Website . Dort sagten sie mir, dass sie das Repository eines anderen von meiner Domain trennen könnten, wenn ich mir einen weiteren NS-Datensatz hinzufüge. Ich habe es getan, es zurückgeschrieben und von Freitag bis Montag keine Antwort erhalten. Vielleicht war es notwendig, in dieser Form neu zu schreiben - aber es war bereits höher als meine Stärke. Also habe ich meine statische Site einfach auf meinem Server gelassen.
Zu dieser Zeit hatte ich drei Möglichkeiten für das, was passiert ist:
1) Jemand hat 2018 versehentlich die Adresse „whois.jehy.ru“ in sein Repository geschrieben, während er eine Landingpage mit dem Titel „Coming Soon“ aus dem Jahr 2013 erstellt hat, auf der aus irgendeinem Grund ein Google-HTML-Code zur Überprüfung von Rechten liegt. Na ja, kaum.
2) Ein verrückter Fehler ist passiert. Es ist auch unwahrscheinlich. Wiederholte er auf der zweiten Teststelle.
3) Der CNAME-basierte Fokus hat entweder nie funktioniert oder ist gebrochen, und Angreifer verwenden diesen, um anzugreifen. Bisher schien mir dies die wahrscheinlichste Option zu sein.
Dann erinnerte ich mich, dass Github selbst bei der Domänenbindung eine Datei mit dem Namen CNAME in Ihrem Repository erstellt. Und er suchte, wer meine Domain hinzugefügt hat. Und - Bingo!
Bei einer Suche wurde ein Angreifer gefunden:
Hier ist meine Domain:
Und hier sind ein paar andere:
Wie Sie sehen, war dies überhaupt kein Unfall. Jemand hat eine anständige Anzahl von Domains gestohlen - einschließlich der zweiten Ebene! Und er erhielt die volle Kontrolle über deren Inhalte, einschließlich der Bestätigung der Rechte, diese Domains zu besitzen, in Google!
Übrigens können Sie auch hinzufügen, dass ein Hacker manchmal nicht nur den Inhalt der Site ersetzt, sondern das ursprüngliche Repository aufteilt, wonach er dort Verifizierungsdateien hinzufügt. Und so hat es mindestens einen Monat lang Spaß gemacht (ich habe ab dem 6. Oktober spontane Commits gefunden). Nun, Anhänger sind dort ähnlich.
Außerdem meine Annahmen darüber, wie ein solcher Angriff stattfindet und warum er benötigt wird.
1) Zunächst findet der Hacker Websites, die auf imtqy.com aufgelöst werden. Das ist ziemlich einfach.
2) Als nächstes werden sie gefiltert, wobei nur diejenigen übrig bleiben, die einen Fehler zurückgeben (es scheint, dass nur 404 vorhanden sind). Es kann viele Fälle geben, in denen die Repositorys nicht angehängt wurden - jemand hat das Repository nicht konfiguriert, jemand hat es gelöscht, jemand hat die Bindungseinstellungen erhalten (es scheint mir, dass dies passiert ist, als ich den Zweig für Github-Seiten geändert habe).
3) Dann erstellt der Hacker einfach ein neues Repository mit dem Inhalt, den er benötigt, und bindet es an die "freie" Domain. Voila!
4) Dann hängt alles nur von der Vorstellungskraft des Hackers ab. Türen, Links platzieren, Daten abfangen, über Google auf die Verwaltung von Google Apps zugreifen ... Es gibt viele Optionen.
Was ich als nächstes getan habe, mit allen Beweisen für die böswillige Verwendung von Bindungen:
- Beschrieben in Korrespondenz mit support@github.com alle Details;
- Noch einmal schrieb sie im Kontaktformular neu;
- Ticket zu hackerone.com hinzugefügt . Ich muss sagen, dass es heißt, dass githubpages.io nicht im Belohnungsprogramm enthalten ist, aber es gab keine anderen Optionen. Daher musste ich diese Warnung ignorieren und sogar den Roboter, der mir sanft riet, diesen Bericht aus den gleichen Gründen nicht zu senden.
Bis heute haben sie das Kontaktformular bis heute nicht beantwortet, aber zwei Tage später haben sie mir auf Hackerone geantwortet. Kurz gesagt, die Antwort war, dass dies ein bekanntes Merkmal des Dienstes ist, keine Sicherheitslücke darstellt und das Spam-Team mit solchen Dingen beschäftigt ist. Der Bericht wurde als „informativ“ abgeschlossen, daher schreibe ich mit gutem Gewissen über alles, was passiert ist. Sie teilten mir auch mit, dass das von mir angegebene Konto gesperrt wurde. Ich habe nachgesehen - ja, er ist nicht mehr. Seine Anhänger verschwanden einige Tage später (es ist nicht klar, warum nicht sofort).
Man könnte damit enden und sagen, dass alles in Ordnung ist ... Aber tatsächlich ist mir diese Situation äußerst peinlich:
- Warum sind diese Konten nicht in Monaten? Es gibt identischen Inhalt, es gibt überall Google-Validierungsdateien, auf einem Konto gibt es viele solcher Websites ... Häufige Anzeichen - ein Wagen und ein kleiner Wagen.
- Warum hat das Spam-Team die zugehörigen Repositorys nicht überprüft?
- Warum sehen Sie die Illusion von Sicherheit in den Anweisungen zum Binden einer Domain, die darauf hindeuten, dass Sie den Namen Ihres Repositorys in CNAME festlegen, wenn dies keine Auswirkungen hat?
- Warum gibt es keinen Warnmechanismus, der besagt, dass eine Domain, die zuvor mit Ihrem Konto verknüpft war, jetzt mit einer anderen verknüpft ist?
- Warum ist es im Github unmöglich, E-Mails vom Support zu beantworten? Oder bin ich unter einen Filter gefallen?
Die Hauptfrage, die mich stört, ist jedoch, warum der Github die NS-Datensätze der auf den Github-Seiten aufgelisteten Domänen nicht auf das Vorhandensein eines CNAME-spezifischen Repositorys überprüft. Dies ist die einfachste Operation, die beim Binden einer Domain ausgeführt werden kann und keine Zeit in Anspruch nimmt. Darüber hinaus vermitteln die Anweisungen das Gefühl, dass dies beabsichtigt war. Warum ist dieser Scheck gebrochen?
Im Allgemeinen schreibe ich diesen Beitrag mit der Hoffnung, dass er in irgendeiner Form den Github erreicht und die Jungs Maßnahmen ergreifen. Vor der Frage "Warum darüber reden, werden jetzt alle klettern, um es zu tun" - werde ich antworten, dass das Loch bereits bekannt ist und aktiv genutzt wird. Und jetzt werden die "verlassenen" Domains eindeutig ständig gescannt, sodass mehrere neue Teilnehmer das Bild nicht ändern werden.
Normalerweise mache ich das nicht, aber es ist großartig, wenn Sie die Übersetzung dieses Artikels, den ich auf das Medium gestellt habe, tätscheln. Ja, ich weiß, dass habr jetzt mehrsprachig ist, aber die ganze Zeit habe ich eineinhalb Beiträge auf Englisch gesehen, und ich glaube nicht, dass irgendjemand darauf achten kann. Und auf dem Medium gibt es oft gute technische Beiträge. Es ist also großartig, wenn Sie dabei helfen, auf dieses Loch zu achten. Wenn überhaupt - ich bekomme kein Geld dafür, es gibt keine US-Karte, die Zinsen sind rein altruistisch.
Woran können Sie am Ende noch denken? Wahrscheinlich lohnt es sich immer, sich daran zu erinnern, wenn Sie Kapazitäten von Drittanbietern einsetzen. Natürlich gibt es im Internet überhaupt nichts Persönliches und alles ist von Drittanbietern - "Ihre" Domains gehören dem Registrar, "Ihre" Server gehören Google, Amazon oder jemand anderem ... Es kann nicht gesagt werden, dass der Github weniger zuverlässig ist als jeder "eigene" Server ... Aber "Ihr" Server ist irgendwie näher am Körper und vorhersehbarer. Im Allgemeinen müssen Sie sich immer an Ihre Ressourcen erinnern, an deren Bedeutung, an mögliche Verluste beim Abfangen und daran, dass es bei Diensten von Drittanbietern zu einer sehr plötzlichen Spezifität der Arbeit kommen kann.
PS Danke Cavin für das Bild und pndpnd für die Übersetzung des Artikels ins Englische.