Pentester Notes: Jagdfälle

- Ihr seid cool! Also hat uns noch niemand im Stich gelassen!
- Wir haben es versucht.

Ja, das Leben von Schwachstellenjägern ist voller spezifischer Komplimente von Kunden und nicht weniger spezifischer Situationen. Im vergangenen Jahr haben wir mehr als fünfzig Penetrationstests in verschiedenen Unternehmen durchgeführt und, wie gesagt, alles gesehen. Ein Passwort für alle Konten und Systeme, die offene Speicherung von Passwörtern in einer Datenbank, die Überreste der Debugging-Funktionalität in einer Kampfumgebung ... Als unsere Kollegen von JSOC CERT mehrere Geschichten über Untersuchungen zu Cyber-Vorfällen erzählten , beschlossen wir in der Pentest-Abteilung, die andere Seite der „Barrikade“ zu verfolgen und zu zeigen. »: Kundeninfrastruktur mit den Augen eines Hackers. Heute erzählen wir Ihnen von den interessantesten externen Pentests der letzten Zeit, als wir in den internen Bereich des Kunden eindringen mussten und nur eine Liste seiner externen IP-Adressen und Domainnamen hatten.

Odyn

Montag:
- Leute, fängt schneller mit einem Pentest an - du hast nur 3 Wochen Zeit, uns zu hacken. Aber denken Sie daran, dass Ihre Chancen minimal sind: Sie überprüfen uns jedes Jahr und finden keine Hinweise.

Nach 4 Stunden:
"Wir sind schon drinnen."
- Nun ja? So kann es nicht sein! Jetzt überprüfen wir die Protokolle ...

Freitag:
- Verdammt, wirklich. Wie so ?! Aber da die Zeit nicht geklappt hat, suchen Sie vielleicht nach etwas anderem?
- Ja, keine Frage.

Und wir begannen zu suchen. Beim Durchsuchen des Unternehmensumfangs stießen wir auf einen Host, auf dem sich 4 Webanwendungen drehten, einen FTP-Server und das phpMyAdmin-Admin-Panel. Die Analyse von Webanwendungen ergab keine kritischen Schwachstellen (z. B. SQL-Injections, XXE, RCE usw.), die uns den Zugriff auf den Server ermöglichen würden. Irgendwann wechselten sie zu FTP - und hier war es schon interessanter: Anonymer Zugriff wurde auf dem Server geöffnet, aber nur zum Lesen.



Wir haben mehrere Tage lang den Inhalt des Servers untersucht und einige seltsame Zeilen in den Protokollen gefunden - einige falsch eingegebene Passwörter für einen der Administratoren der Webanwendung.



Aufgrund der falschen Optionen haben wir angenommen, wie das Passwort aussehen soll, und es wurde angezeigt. Wir haben beschlossen, es für phpMyAdmin zu versuchen, und - oh, ein Wunder - es ist auch aufgetaucht. Als nächstes war es eine kleine Sache - die Shell hochladen, Zugriff auf das interne Netzwerk erhalten, dort Fuß fassen und sich bereits im Inneren entwickeln.



Auf diese Weise ebnet gewöhnliche Faulheit (und wie kann man sonst die Zurückhaltung bei der Eingabe unterschiedlicher Kennwörter für jedes Admin-Panel erklären?) Den Weg für Hacker in das interne Netzwerk des Unternehmens.

Warum in einer Kampfumgebung debuggen?

Die meisten unserer Durchbrüche erfolgen über Webanwendungen, und oft stoßen wir auf merkwürdige „Überreste“ von Entwicklungs- und Testzeiten. Oft finden wir Protokolle, einige Debug-Modi, aber nicht immer mit ihrer Hilfe haben wir es geschafft, RCE (Remote Code Execution) durchzuführen.

Bei einem unserer Kunden haben wir ein CRM-System entdeckt, für das wir uns entschieden haben, etwas mehr Zeit zu investieren (und das hat sich später ausgezahlt). Bei der Analyse der Anwendung fanden wir die Überreste der Tests, die anscheinend in der Entwicklungsphase verwendet wurden. Die Authentifizierung erfolgte auf sehr wundersame Weise: Nur der Benutzername und die Tatsache, dass ein Parameter mit einem Kennwort übergeben wurde, wurden überprüft. Fünf Minuten Suchen und Lesen der Standarddokumentation - und wir haben den Namen des integrierten Superuser-Kontos in der Hand. Das Befüllen der Schale war bereits eine Frage der Technologie.



Ein weiteres Beispiel. Zu Beginn des Projekts haben wir eine rekursive Bruteforce von Subdomains gestartet und verlassen. Nach einiger Zeit erschien zu unserer Überraschung eine Subdomain der fünften Ebene namens test.debug.application.client.ru, auf der wir eine Webanwendung mit dort installiertem Adminer fanden. Dies ist eine einfache Datenbankverwaltungsanwendung, in deren älteren Versionen Sie bei falscher Konfiguration ohne Kennwort mit einer SQLite-Datenbank interagieren können.

Die Tatsache, dass diese Datenbank keine Daten enthielt, war nicht wichtig. Schließlich können Sie in SQLite eine Datenbank auf einem beliebigen Pfad mit einer einfachen Web-Shell erstellen und so den Server bequem verwalten und Befehle von einer Webseite aus ausführen.

Es blieb nur die vollständige Adresse der Webanwendung auf dem Server herauszufinden. Hier half uns das „geliebte“ CMS 1C-Bitrix, das uns in einer Fehlermeldung gerne mitteilte, wo es sich befindet. Dann blieb nur noch die Hülle zu füllen und das Projekt zu beenden.



Die Arbeit mit SQLite DB kann hier eingesehen werden .

Protokolle gefunden? Passwörter als Geschenk!

Ein Kunde hat uns gebeten, einen Pentest einer Webanwendung durchzuführen. In den letzten drei Jahren hielt er Pentests mit einem anderen Team ab und schaffte es wahrscheinlich, einige der Löcher im Perimeter zu flicken, sodass wir keinen schnellen Erfolg erwarteten.

Während des Fuzzing der Webanwendung haben wir eine Seite gefunden, auf der die Benutzerautorisierung protokolliert wurde. Die Zeit und die Anmeldung des Benutzers, der sich bei der Anwendung angemeldet hat, wurden im Protokoll angezeigt. Wir haben ein Skript geschrieben, das diese Seite einige Minuten lang abgefragt, die Antwort analysiert und die in einer Datei gefundenen Anmeldungen notiert hat. Nach ein paar Tagen konnten wir ungefähr hundert Logins sammeln. Wir haben beschlossen, mit der Auswahl der Passwörter zu beginnen. Für 5 Anmeldungen wurden sie in der Liste der schlechtesten TOP-500-Passwörter gefunden .

Nachdem wir Zugriff auf die Anwendung erhalten hatten, analysierten wir sie weiter und fanden eine weitere interessante Datei - alle Echtzeit-Datenbankabfragen wurden darin angezeigt. Mit einem so praktischen Debugging-Tool ist das Suchen nach Schwachstellen und das Ausnutzen der gefundenen booleschen zeitbasierten SQL-Injection zu einer trivialen Aufgabe geworden.

Trotz der Tatsache, dass es bereits 2019 ist, glauben die Leute immer noch, dass das Speichern von Passwörtern in einer Datenbank in offener Form eine gute Idee ist. Wir verwenden dies und haben SQL Injection gefunden und erhalten ein Administratorkonto, mit dem wir die Web-Shell ausfüllen können. Der offene Zugriff auf das interne Netzwerk der Organisation war keine große Sache.

Schnittmarken

Führen Sie zunächst regelmäßige Penetrationstests durch. Sie helfen Ihnen dabei, dünne Stellen zu finden, die Sie in der Entwicklungsphase oder beim Wechsel von Testumgebungen zu Kampfumgebungen möglicherweise übersehen haben.

Zweitens sollten Sie immer den menschlichen Faktor berücksichtigen: Menschen sind einfach zu faul, um Passwörter zu ändern, und sie können sogar ein Passwort auf mehreren Websites verwenden. Ja, Admins sündigen dies auch.

Drittens entfernen Sie Debugging-Modi in Kampfumgebungen.

PS

Im Allgemeinen ist der Alltag der Pentest-Abteilung voller „Unterhaltungen“, und natürlich sind nicht nur externe Tests erforderlich. Der Kunde möchte möglicherweise nach Schwachstellen des internen Perimeters (interner Pentest) suchen, die Sicherheit von Web- und Mobilanwendungen sowie WiFi-Netzwerken analysieren oder die Mitarbeiter mithilfe von Social-Engineering-Methoden überprüfen lassen.

In unserer Freizeit aus Projekten verstehen wir Zen, suchen nach neuen Schwachstellen, verbessern unsere Werkzeuge und Techniken. Und wir sind mit einem Bugbounty beschäftigt (wo ohne es).

In den folgenden Beiträgen erfahren Sie mehr über die Vielfalt unserer „Abenteuer“.