Wie ich einen Hosting-Provider gehackt habe



    Vor kurzem erhielt ich einen Vorschlag, die Funktionsweise verschiedener Dienste auf Fehler und Schwachstellen zu überprüfen. Und in solchen Sätzen versuche ich, für das Ergebnis zu arbeiten und den Prozess maximal zu genießen. Aber das Ergebnis des letzten "Projekts" hat mich schockiert, es milde auszudrücken.

    Ich wurde gebeten, den Hostinganbieter zu testen.

    Ich werde den Namen nicht preisgeben. Und in meiner Geschichte werde ich den Namen Hoster verwenden. Mit dem Site-Hosting-Service war alles Standard. Angebote zum Kauf von VDS, Domains, SSL-Zertifikaten.

    Zunächst war ich überrascht, wie der persönliche Account des Benutzers implementiert wurde. Ein Eigentumsnachweis der E-Mail-Adresse während der Registrierung war nicht erforderlich. Dh es war möglich, sich mit der E-Mail-Adresse steve.jobs@apple.com zu registrieren. Oder noch besser - support@hoster.com.

    Glücklicherweise fand jedoch, analog zu dieser Geschichte , keine Offenlegung von Unterstützungsdiensten für vertrauliche Informationsdienste statt.

    Dies geschah jedoch, als ich eine Testanforderung für den Support erstellt und sofort die Verfügbarkeit der benachbarten IDs anderer Supportanfragen geprüft hat. Überraschenderweise waren sie verfügbar. Und man konnte beobachten, wer und was sich beim Hoster registriert. Und vor welchen Problemen stehen Benutzer? Im Allgemeinen die Standard-IDOR-Schwachstelle, die jetzt niemanden überrascht. Sie wurde sicherlich sofort behoben.

    Bei Stored XSS gab es auch mehrere Orte. Es gab auch ein Blind XSS, das mir das Service Administrator Cookie zurückgab. Dank dieser XSS konnte ich herausfinden, wo sich die Administratorschnittstelle befindet. Nun, im Allgemeinen habe ich viele interessante Informationen gefunden.

    • Wie viele aktive Benutzer
    • Wie viele Domains haben die Kontrolle?
    • Wie viele VDS wurden bereitgestellt?

    Und vieles mehr ...



    Es gab verschiedene Fehler bei CSRF-Token, die es Ihnen ermöglichten, im Namen des Benutzers viele gefährliche Dinge auf Ihrem Konto auszuführen. Und wenn es Orte gab, an denen CSRF-Token übertragen wurden, wurden sie einfach übertragen. Niemand hatte vor, sie im Backend zu überprüfen. Aufgrund meiner Ergebnisse wurde ein Teil der Funktionalität vollständig deaktiviert. So wurde beispielsweise beschlossen, die 2FA-Authentifizierung vorübergehend zu entfernen, da sie nicht implementiert wurde.

    Bei meiner Arbeit habe ich nicht nur auf Sicherheitsprobleme geachtet, sondern auch auf Implementierungsfehler oder Probleme beim Betrieb einiger Funktionen. Ich als QA konnte nicht gerne vorbei. Infolgedessen erreichte mein Issue-Tracker die Zahl - 22. So viele Probleme in der Gesamtheit habe ich gefunden und behoben (nur bemerkenswert).

    Die Ergebnisse waren mehr als überzeugend. Und ich hatte bereits vor, dieses Projekt abzuschließen. Aus irgendeinem Grund erinnerte ich mich noch einmal an das Problem der fehlenden Bestätigung des Inhabers der E-Mail-Adresse während der Registrierung. Und er begann mit Situationen zu kommen, in denen dies für das Hosting und seine Besitzer maximale Probleme verursachen könnte. Irgendwann fing ich an, über die Verbindungen der Besitzer dieses Hosting-Service mit anderen Projekten des gleichen Unternehmens nachzudenken, die mir bekannt waren. Nach ein paar Minuten habe ich ein Konto mit der E-Mail-Adresse eines anderen Projekts desselben Unternehmens registriert (lass es support@example.com sein). Dann gelang es mir, die Domain example.com mit meinem erstellten Konto suppot@example.com zu verknüpfen. Trotzdem konnte ich den Inhalt der verlinkten Domain immer noch nicht kontrollieren.

    Aber er konnte ihn perfekt für den example.com-Service per E-Mail kontaktieren.



    Bis zum Ende ist nicht klar, woher die Antwortschreiben kamen. Weil ich mir einen solchen Testbrief beantwortet habe. Ich habe aber selbst keine Antwort bekommen. Wahrscheinlich ging es zurück an den eigentlichen Besitzer der E-Mail-Box support@example.com.

    Und hier geschah etwas, für das ich mich entschieden habe, diesen Artikel zu schreiben.

    Es gelang mir, die vergessene Subdomain aufzulösen. Klassische Schwachstelle bei der Übernahme von Subdomains. Sie können hier ausführlich nachlesen .

    Ich weiß nicht warum, aber ich habe versucht, einer nicht vorhandenen Domäne eine Bindung hinzuzufügen. Und ich habe es geschafft.



    Die Subdomain wurde erfolgreich hinzugefügt und ich konnte den Inhalt dieser Subdomain steuern. Und der Inhalt wurde angezeigt.



    Aber das gleiche kann nicht sein! Wie so Die klassische Schwachstelle bei der Übernahme von Subdomains funktioniert nur mit vorhandenen Subdomains.

    Diese Situation passte absolut nicht in meinen Kopf. Das heißt, okay, ich konnte die Validierungsstufen meiner Beziehung zu example.com umgehen, was nie meine ist (wahrscheinlich aufgrund von Beispiel .com in meinem Kontonamen). Wie ist es jedoch möglich, Subdomains hinzuzufügen und zu steuern, ohne die Komponenten in den Datensätzen A, TXT, CNAME ... zu prüfen?

    Normalerweise treffe ich mich so - wir fügen Ihnen eine Subdomain hinzu, nur Sie beweisen, dass Sie es können. Geh und füge den gegebenen Hash ololopyshpyshpyshbdysh123 zu TXT hinzu .

    Aber so etwas gab es nicht. Möchten Sie die Subdomain admin.example.com? Kein Problem!



    Als ob die Schwachstelle Subdomain Takeover V2.

    Dank der Möglichkeit, schnell mit den Inhabern des getesteten Hosting-Services zu kommunizieren, habe ich die Box dieser Pandora geöffnet.

    Es stellte sich folgendes heraus. Hosting funktionierte über CloudFlare. Und er hat sehr knifflig gearbeitet.
    Ich werde versuchen, es mit einfachen Worten zu erklären.

    Grob gesagt sage ich dir, geh zu mir, ich werde dich hosten. Delegiere deine Domains an mich.
    Alle eingehenden Anrufe werden dann wahllos an CloudFlare gesendet und als korrekt betrachtet.
    Und wenn mir die Domäne vasya.ru anvertraut wurde und ein Nachbar kam und bei test.vasya.ru eine Website ablegte, die er mir auch als Hosting gab, dann fügte mein Server, der Zugriff auf CloudFlare hatte und bereits Rechte an vasya.ru hatte, eine dritte Ebene ohne Probleme hinzu Domain für einen Nachbarn und alle Regeln, schnell und ohne Frage. Für alle DNS sind korrekte Informationen aus CloudFlare gekommen. Und CloudFlare vertraut mir.

    Natürlich konfigurieren Hosting-Provider natürlich ihre DNS-Dienste. Hier stellt sich jedoch heraus, dass es clever ist, einfach alles von einem Benutzer auf CloudFlare zu übertragen.

    Wir haben also eine Subdomain-Übernahme god_mode. Es funktionierte zwar nur mit den Adressen, die bereits vom Hosting gesteuert werden. Aber in Verbindung mit dem zuvor entdeckten Admin-Service - dies könnte sowohl beim Hoster als auch beim Hosting-Service-Client einen grausamen Scherz darstellen.

    Im Moment wurden fast alle kritischen Schwachstellen und Fehler behoben. Und ich hoffe, dass sich niemand sonst nach dem Lesen dieser Geschichte für solche architektonischen Freuden entscheiden wird.

    PS: Kommentare und Vorschläge zum Artikel sind willkommen. Besonderer Dank geht an Patriot2k für die technische Beratung! Ich bin auch offen für Vorschläge, um etwas Interessantes zu testen.

    Jetzt auch beliebt: