Der Feind im Haus: Wenn Mitarbeiter Daten stehlen

Windows-Versionen ab XP lehnen grundsätzlich die Übertragung des Klartextpassworts über das Netz ab, sofern dies nicht in der Sicherheitsrichtlinie explizit erlaubt wurde, siehe Bild 4. Das bietet jedoch keinen echten Schutz. Wenn Windows-Clients ein Passwort verschlüsselt senden, bedeutet das, dass es noch auf dem Client in einen Hashwert umgerechnet wird, aus dem sich das Klartextpasswort nicht mehr berechnen lässt.

Dieser Hashwert wird mittels Challenge-Response-Verfahren verschlüsselt an den Server geschickt, der ihn wieder entschlüsselt und mit der lokalen SAM- oder der Active-Directory-Datenbank vergleicht. Neuere Samba-Hacks speichern den erhaltenen Hashwert anstelle des Klartextpassworts zusammen mit dem Benutzernamen ab.

Mit Standard-Windows-Programmen, etwa dem Windows-Explorer, lässt sich der Hashwert nicht nutzen. Trotzdem gilt, dass der Hashwert eines Passworts genauso gut ist, wie das Passwort selbst. Mit einem eigenen Programm, das das SMB-Protokoll nachbildet, kann der Hashwert zur Authentifizierung verwendet werden. Diese Form des Angriffs wird Pass-the-Hash-Attacke genannt. Auch dafür bietet das Metasploit-Framework einen Exploit, der sich mit dem Meterpreter-Payload kombinieren lässt.

Den besten Schutz gegen diese Form des Angriffs erreicht man dadurch, dass man Rechnern, die nicht zum Firmennetz gehören, den Zugang zum Intranet bereits auf der MAC-Ebene verweigert, etwa durch 802.1X-Authentifizierung und die Network Access Protection von Windows Server 2008. So können Mitarbeiter keine Rechner mit modifizierten SMB-Servern ins Netz nehmen. Sollten Mitarbeiter jedoch auf andere Art und Weise an Passwort-Hashwerte gekommen sein, können sie diese von ihren Arbeitsplatzrechnern aus für Angriffe verwenden.

Derzeit existiert kein Metasploit-Modul, das Pass-The-Hash-Angriffe mit der NTLMv2-Authentifzierungsmethode erlaubt. Wer seine Server so konfiguriert, dass sie nur NTLMv2-Verbindungen akzeptieren, hat dennoch nur einen geringen Schutz, da Angreifer einen NTLMv2-kompatiblen Exploit entwickeln können. Zudem verhindert diese Methode nicht, dass Mitarbeiter Passwort-Hashwerte sammeln.

Themenseiten: Big Data, Datendiebstahl, Datenschutz, Hacker, Privacy, Security-Praxis

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

1 Kommentar zu Der Feind im Haus: Wenn Mitarbeiter Daten stehlen

Kommentar hinzufügen
  • Am 5. Mai 2010 um 19:34 von Tom

    Erst mal gründlich schlau machen!
    „Das Beispiel Conficker zeigt, dass viele Unternehmen ihre Intranet-Server nicht regelmäßig updaten.“

    Dieser Satz zeigt leider die Unwissenheit des Autors. Auch in einem System bei dem alle Windows-Updates eingespielt sind, kann sich der Conficker Wurm über Administrative Netzwerkfreigaben weiterverbreiten. Das -auch von Microsoft- vielbeschworene Windows-Update hilft nur gegen das Eindringen von außen (übers Internet).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *