Der beste Weg, um die Aufzählung von Brute-Force-Benutzernamen / fehlgeschlagene Versuche mit Benutzernamen zu verfolgen AD


9

Wir haben einen Windows Server, auf dem sich eine Anwendung befindet, die beim Anmelden bei der Anwendung Domänenanmeldeinformationen verwendet. Während eines kürzlich durchgeführten Pen-Tests konnten die Tester die Anwendung verwenden, um gültige Domänenbenutzernamen basierend auf der Antwort der Anwendung aufzulisten (es gab eine andere Antwort für einen ungültigen Benutzernamen als für ein ungültiges Kennwort).

Die Anwendung wird repariert, sodass diese Informationen nicht angezeigt werden. Ich bin jedoch der Meinung, dass wir diesen Angriff hätten erkennen sollen, da in kurzer Zeit über 2000.000 ungültige Benutzernamenversuche stattgefunden haben. Wir haben es nicht gesehen, selbst wenn unsere Administratoren Active Directory genau beobachteten. Anscheinend wurden die Fehler immer nur im lokalen Ereignisprotokoll des Servers angezeigt, auf dem die Anwendung installiert wurde.

Meine Frage: 1) Gibt es eine Möglichkeit, Active Directory dazu zu bringen, diese fehlgeschlagenen Benutzernamenanforderungen an einem zentralen Ort zu protokollieren, damit wir einen Anstieg in ihnen feststellen können?

2) Wenn nicht, wie lässt sich diese Art von Angriff in Zukunft am besten überwachen und aktiv erkennen (hoffentlich ohne zu viel neue Ausrüstung kaufen zu müssen).

Danke für Ihre Hilfe.

Antworten:


11

Gute Frage.

Das Wichtigste zuerst - Ich betrachte die meisten "Penetrationstester" als Script-Kiddies. Meine Voreingenommenheit mag nicht fair oder genau sein, aber ich füge diesen Haftungsausschluss ein, damit Sie wissen, woher er kommt, wenn Sie einen Zynismus in meinem Ton feststellen. Ich sage nicht, dass es keine qualifizierten Pentester gibt, aber das ist meine umfassende Allgemeinheit.

(Blaues Team fürs Leben!)

Meine Frage: 1) Gibt es eine Möglichkeit, Active Directory dazu zu bringen, diese fehlgeschlagenen Benutzernamenanforderungen an einem zentralen Ort zu protokollieren, damit wir einen Anstieg in ihnen feststellen können?

Sie haben nicht genügend Informationen bereitgestellt, um diese Frage gründlich und sicher beantworten zu können. Sie sagten, Ihre Anwendung enthielt einen Fehler, der es den Angreifern ermöglichte, Benutzerkonten aufzulisten. Ich versuche zu verstehen, auf welche Weise AD Ihrer Meinung nach die Protokollierung für Ihre Anwendung durchführen muss.

Anscheinend wurden die Fehler immer nur im lokalen Ereignisprotokoll des Servers angezeigt, auf dem die Anwendung installiert wurde.

Anscheinend wurden die Fehler im Ereignisprotokoll auf dem Server angezeigt? Oder die Fehler haben im Ereignisprotokoll auf dem Server angezeigt? Wenn ja, was genau haben die Ereignisse gesagt? Wer hat sie angemeldet? Ihre Bewerbung? Oder Windows? Wenn Sie es herausfinden, kann ich meiner Antwort möglicherweise zusätzliche Erläuterungen hinzufügen.

Ich werde hier auf die Nerven gehen, basierend auf Ihrer Vermutung, dass diese Ereignisse von Active Directory irgendwie protokolliert werden sollten ... Was wäre, wenn Ihre Pentester einen Fehler in Ihrer Anwendung überhaupt nicht ausnutzen würden, sondern stattdessen verwenden würden? ein sehr bekannter Fehler in Kerberos selbst, um Benutzernamen aufzulisten? Kerberos selbst enthält einen Konstruktionsfehler, bei dem ein Angreifer Tausende und Abertausende von "Vorauthentifizierungs" -Versuchen (dh einen Brute-Force-Angriff) versuchen kann, und das KDC reagiert unterschiedlich, je nachdem, ob das Benutzerkonto vorhanden ist oder nicht. Dies ist kein Active Directory-spezifisches Verhalten, gilt jedoch ebenso für MIT Kerberos, Heimdal usw. Das KDC antwortet mitKDC_ERR_PREAUTH_REQUIREDwenn ein gültiger Benutzername ohne Vorauthentifizierungsdaten angezeigt wurde, auch ohne eine tatsächliche Authentifizierung zu versuchen. Auf diese Weise können Sie Benutzernamen aus einem KDC auflisten. Da der Angreifer (oder das Tool, das der Angreifer verwendet, wie z. B. KrbGuess - weil Pentester am besten sind, wenn sie die Tools anderer verwenden), keinen vollständigen Authentifizierungsversuch durchführen muss, wird nichts protokolliert, da nein Die eigentliche Authentifizierung wurde versucht!

Nun zu Ihrer nächsten Frage:

2) Wenn nicht, wie lässt sich diese Art von Angriff in Zukunft am besten überwachen und aktiv erkennen (hoffentlich ohne zu viel neue Ausrüstung kaufen zu müssen).

Ein paar Dinge.

Erstens gibt es kostenpflichtige Produkte für Unternehmen, die diese Art von Angriffen erkennen (unter anderem). Viele Anbieter bieten solche Produkte an, und Produktempfehlungen sind für Serverfault nicht thematisch, reichen jedoch aus, um zu sagen, dass sie nicht verfügbar sind Dort. Bei vielen dieser Produkte müssen Sie die Portspiegelung zwischen Ihren Domänencontrollern und diesen "Datenkollektoren" konfigurieren, damit sie jedes einzelne Paket, das in Ihre Domänencontroller eintritt oder aus diesen austritt, buchstäblich sehen und analysieren.

(Entschuldigung, das fällt irgendwie in Ihre Klausel "ohne zu viel neues Zeug zu kaufen".)

Eine andere Sache, die Ihnen helfen könnte, ist der Registrierungseintrag:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

LogLevel = 1

Dokumentierte hier .

Wenn Sie diesen Registrierungseintrag aktivieren, sollten Sie mit Ereignissen in Ihrem Sicherheitsereignisprotokoll über Kerberos-Fehler überflutet werden, die darauf hinweisen, dass eine Kerberos-Vorauthentifizierung erforderlich ist. Ein Beispiel für ein solches Ereignis:

A Kerberos Error Message was received:
 on logon session DOMAIN\serviceaccount
 Client Time: 
 Server Time: 12:44:21.0000 10/9/2012 Z
 Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
 Extended Error: 
 Client Realm: 
 Client Name: 
 Server Realm: DOMAIN
 Server Name: krbtgt/DOMAIN
 Target Name: krbtgt/DOMAIN@DOMAIN
 Error Text: 
 File: e
 Line: 9fe
 Error Data is in record data.

Dies kann Ihnen jedoch helfen oder auch nicht, wenn nicht angegeben ist, woher genau der Tsunami von Kerberos-Anforderungen stammt. Dies führt uns zurück zu den zuvor erwähnten Enterprise Intrusion Detection-Produkten.

Vergessen Sie nicht die Windows-Ereignisweiterleitung, mit der Ihre Server Ereignisse an einen zentralen Ort weiterleiten können, um sie mit einem beliebigen Tool zu analysieren.

Diese gesamte Antwort basiert bisher auf dem Kerberos-Protokoll, das ich nicht einmal für selbstverständlich halte, weil Sie in Ihrem Beitrag so wenig Details angegeben haben. Trotzdem hoffe ich, dass dies zumindest ein wenig hilft.


Vielen Dank für Ihre Antwort. Ich werde es am Montag noch einmal überprüfen, aber ich glaube, dass die Ereignisprotokolle die Standard-Windows-Ereignisse für die fehlgeschlagene Anmeldung am lokalen Server sind (z. B. entsprechen sie einer fehlgeschlagenen Anmeldung über RDP mit einem ungültigen Benutzernamen). Es ist definitiv nichts Anwendungsspezifisches. Für die Kerberos-Authentifizierungsaufzählung müssen sich die Pen-Tester meines Erachtens in unserem lokalen Intranet befinden. Sie waren nicht. Die Anwendung ist im Internet mit standardmäßiger formularbasierter Authentifizierung öffentlich verfügbar, die das Betriebssystem unter dem Deckmantel aufruft.
Doug

0

Dies ist eine interessante Frage, auf die ich gerne eine richtige Antwort hören würde. Ich bin auf einige Informationen gestoßen, die Doug möglicherweise hilfreich findet, die ich jedoch für etwas unzureichend halte. Jemand anderes kann wahrscheinlich eine erweiterte Antwort geben:

Melden Sie sich bei dem Server an, auf dem die Überwachungsinformationen gespeichert werden sollen. Ausführen -> RSOP.MSC -> Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Überwachungsrichtlinie -> "Anmeldeereignisse für Konto überwachen" & " Anmeldeereignisse überwachen "

Die Erklärung für "Kontoanmeldeereignisse" lautet:

Anmeldeereignisse für Überwachungskonten

Diese Sicherheitseinstellung bestimmt, ob das Betriebssystem jedes Mal überprüft, wenn dieser Computer die Anmeldeinformationen eines Kontos überprüft.

Kontoanmeldeereignisse werden immer dann generiert, wenn ein Computer die Anmeldeinformationen eines Kontos überprüft, für das er autorisiert ist. Domänenmitglieder und nicht mit Domänen verbundene Computer sind für ihre lokalen Konten maßgeblich. Domänencontroller sind alle für Konten in der Domäne autorisierend. Die Überprüfung der Anmeldeinformationen kann eine lokale Anmeldung unterstützen oder im Fall eines Active Directory-Domänenkontos auf einem Domänencontroller eine Anmeldung an einem anderen Computer unterstützen. Die Überprüfung der Anmeldeinformationen ist zustandslos, daher gibt es kein entsprechendes Abmeldeereignis für Kontoanmeldeereignisse.

Wenn diese Richtlinieneinstellung definiert ist, kann der Administrator angeben, ob nur Erfolge, nur Fehler, sowohl Erfolge als auch Fehler, überwacht werden sollen oder ob diese Ereignisse überhaupt nicht überwacht werden sollen (dh weder Erfolge noch Fehler).

Die Erklärung für "Anmeldeereignisse" lautet:

Anmeldeereignisse überwachen

Diese Sicherheitseinstellung bestimmt, ob das Betriebssystem jede Instanz eines Benutzers überwacht, der versucht, sich an diesem Computer anzumelden oder sich abzumelden.

Abmeldeereignisse werden immer dann generiert, wenn die Anmeldesitzung eines angemeldeten Benutzerkontos beendet wird. Wenn diese Richtlinieneinstellung definiert ist, kann der Administrator angeben, ob nur Erfolge, nur Fehler, sowohl Erfolge als auch Fehler, überwacht werden sollen oder ob diese Ereignisse überhaupt nicht überwacht werden sollen (dh weder Erfolge noch Fehler).

Sie müssten diese Richtlinien im Wesentlichen aktivieren, die Richtlinieneinstellungen definieren und "Fehler" auswählen, wenn Sie nur fehlgeschlagene Versuche überwachen möchten. Wenn Sie möchten, können Sie auch Erfolge überwachen, aber es könnte etwas schwieriger sein, diese zu analysieren, wenn Sie sich nur Sorgen machen, nach dieser Art von Angriff zu suchen.

Wenn Sie sich Sorgen über ähnliche Konfigurationen machen, für die Ihre Systeme möglicherweise anfällig sind, würde ich empfehlen, die STIG-Einstellungen ( Link ) zu überprüfen. In Verbindung mit einem SCAP-Scanner kann dies wirklich dazu beitragen, einige der Risiken hervorzuheben, die Ihr Unternehmen möglicherweise birgt gegenüber. Der STIG-Viewer neigt dazu, einige Fehlalarme auszulösen. Wenn Sie jedoch die Einzelheiten der einzelnen Probleme lesen, ist dies möglicherweise kein Anfänger.


1
Ich würde die MSFT- oder nist-Baselines vorschlagen. DISA macht Annahmen über die Umgebung, anstatt den Host als Einheit zu sichern. Ja, eine ordnungsgemäße Prüfung ist erforderlich. Ich habe auch die Best Practices zum Sichern des Active Directory-Whitepapers gelesen.
Jim B

Toller Punkt, Jim B! Ich hatte diesen Aspekt nicht berücksichtigt.
Sawta
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.