Vor kurzem erhielt ich einen Vorschlag, den Betrieb verschiedener Dienste auf Fehler und Schwachstellen zu überprüfen. Und in solchen Vorschlägen versuche ich, für das Ergebnis zu arbeiten und die maximale Freude am Prozess zu haben. Aber das Ergebnis des letzten „Projekts“ hat mich gelinde gesagt schockiert.
Ich wurde gebeten, den Hosting-Anbieter zu testen.
Ich werde den Namen nicht preisgeben. Und in meiner Geschichte werde ich den Namen Hoster verwenden. Bei der Site selbst war der Hosting-Service Standard. Angebote zum Kauf von VDS, Domains, SSL-Zertifikaten.
Zunächst war ich überrascht, wie das persönliche Konto des Benutzers implementiert wurde. Ein Eigentumsnachweis der E-Mail-Adresse bei der Registrierung war nicht erforderlich. Das heißt, Sie können sich unter der E-Mail-Adresse steve.jobs@apple.com registrieren. Oder noch besser, support@hoster.com.
Glücklicherweise fand in Analogie zu
dieser Geschichte die Offenlegung sensibler Informationen des Service-Support-Desks nicht statt.
Dies geschah jedoch, als ich eine Test-Support-Anfrage erstellte und sofort die Verfügbarkeit benachbarter ID-Anfragen für andere Support-Anfragen überprüfte. Überraschenderweise waren sie verfügbar. Und es war möglich zu beobachten, wer und was sich beim Hoster anmeldet. Und mit welchen Problemen sind Benutzer konfrontiert? Im Allgemeinen die Standard-IDOR-Sicherheitslücke, die jetzt niemanden überraschen wird. Natürlich wurde sie sofort korrigiert.
Es gab auch mehrere Orte mit Stored XSS. Es gab auch Blind XSS, das mir das Service Administrator Cookie zurückgab. Dank dieses XSS konnte ich herausfinden, wo sich die Administratoroberfläche befindet, und im Allgemeinen enthüllte es viele interessante Informationen.
- Wie viele aktive Benutzer.
- Wie viele Domains haben die Kontrolle?
- Wie viele VDS werden bereitgestellt?
Und vieles mehr ...
Es gab verschiedene Fehler mit CSRF-Token, die es dem Benutzer ermöglichten, viele gefährliche Dinge in Ihrem Konto zu tun. 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 Erkenntnisse war ein Teil der Funktionalität vollständig deaktiviert. Beispielsweise wurde beschlossen, die 2FA-Authentifizierung vorübergehend zu entfernen, da sie in der Implementierung nicht stattfand.
Bei meiner Arbeit habe ich nicht nur auf Sicherheitsprobleme geachtet, sondern auch auf Implementierungsfehler oder Probleme beim Betrieb einiger Funktionen. Ich mag QA konnte so nicht vorbeigehen. Infolgedessen erreichte mein Issue-Tracker die Zahl 22. So viele Probleme insgesamt habe ich gefunden und behoben (äußerst bemerkenswert).
Die Ergebnisse waren mehr als überzeugend. Und ich hatte bereits vor, dieses Projekt abzuschließen. Aber aus irgendeinem Grund erinnerte ich mich wieder an das Problem der fehlenden Bestätigung des Inhabers der E-Mail-Adresse bei der Registrierung. Und er begann Situationen zu entwickeln, in denen dies dem Hosting und seinen Eigentümern maximale Probleme bereiten kann. Irgendwann begann ich über die Beziehungen der Eigentümer dieses Hosting-Dienstes zu anderen Projekten des gleichen Unternehmens nachzudenken, von denen ich wusste. Nach ein paar Minuten registrierte ich ein Konto mit der E-Mail-Adresse eines anderen Projekts desselben Unternehmens (sei es support@example.com). Dann habe ich es geschafft, die Domain example.com an mein erstelltes Konto suppot@example.com zu binden. Aber ich konnte den Inhalt der gebundenen Domain immer noch nicht kontrollieren.
Aber er konnte im Auftrag des example.com-Dienstes perfekt mit E-Mails fischen.
Es ist nicht klar, wohin die Antwortschreiben kamen. Weil ich mir einen solchen Testbrief beantwortet habe. Aber ich habe die Antwort selbst nicht erhalten. Es ist wahrscheinlich als Antwort auf den tatsächlichen Eigentümer des E-Mail-Kontos support@example.com verschwunden.
Und dann passierte etwas, für das ich mich entschied, diesen Artikel zu schreiben.
Ich habe es geschafft, die vergessene Subdomain aufzulösen. Klassische Sicherheitslücke bei der Übernahme von Subdomains. Mehr dazu lesen Sie
hier .
Ich weiß nicht warum, aber ich habe versucht, einer nicht vorhandenen Domain 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.
Das kann aber nicht dasselbe sein! Wie so ?! Schließlich funktioniert die klassische Sicherheitsanfälligkeit bezüglich der Übernahme von Subdomains nur mit vorhandenen Subdomains.
Diese Situation passte absolut nicht in meinen Kopf. Das heißt, okay, ich konnte die Validierungsstufen meiner Einstellung zu example.com umgehen, die niemals meine ist (wahrscheinlich dank
example .com im Namen meines Kontos). Aber wie ist es überhaupt möglich, Subdomains hinzuzufügen und zu steuern, ohne Komponenten in den A-, TXT-, CNAME-Datensätzen zu überprüfen ...?
Normalerweise sehe ich das - wir werden Ihnen eine Subdomain hinzufügen, nur Sie beweisen, dass Sie es können. Gehen Sie und fügen Sie TXT diesen Hash
ololopyshpyshpyshbdysh123 hinzu .
Aber so etwas gab es nicht. Möchten Sie die Subdomain admin.example.com? Kein Problem!
Als ob eine Subdomain Takeover V2-Sicherheitslücke.
Aufgrund der Möglichkeit, schnell mit den Eigentümern des getesteten Hosting-Dienstes zu kommunizieren, wurde mir diese Box von Pandora geöffnet.
Es stellte sich Folgendes heraus. Das Hosting funktionierte über CloudFlare. Und er arbeitete sehr schlau.
Ich werde versuchen, es in einfachen Worten zu erklären.
Grob gesagt, ich sage dir, komm zu mir, ich werde dich aufnehmen. Delegieren Sie Ihre Domains an mich.
Und dann sende ich alle eingehenden Anrufe wahllos an CloudFlare, wenn ich sie für richtig halte.
Und wenn mir die Domain vasya.ru anvertraut wurde und ein Nachbar kam und die Site mit test.vasya.ru geknebelt und mir auch zum Hosting gegeben hat, hat mein Server, der Zugriff auf CloudFlare hat und bereits Rechte an vasya.ru hat, die dritte Ebene ohne Probleme hinzugefügt Domain für einen Nachbarn und alle Regeln, schnell und ohne Frage. Für alle DNS sind die richtigen Informationen von CloudFlare eingetroffen. Und CloudFlare vertraut mir.
Normalerweise konfigurieren Hosting-Anbieter ihre DNS-Dienste natürlich. Aber hier stellt sich heraus, dass sie betrogen haben und einfach alles von einem Benutzer auf CloudFlare übertragen.
Wir haben also eine Subdomain-Übernahme god_mode. Dies funktionierte zwar nur mit den Adressen, die das Hosting bereits steuert. In Verbindung mit dem zuvor entdeckten Service-Admin-Panel könnte dies sowohl für den Hoster als auch für die Hosting-Service-Clients einen Streich spielen.
Im Moment wurden fast alle kritischen Schwachstellen und Fehler behoben. Und ich hoffe, dass sich niemand 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 zum Testen von etwas Interessantem.