Wir schreiben bald November 2020. Das Biervirus hält uns alle gefangen. Alle? Nein, ein kleines gallisches Dorf…
Moment – falsche Geschichte. Vor Kurzem ist in Patient verreckt, weil ein Spital in Düsseldorf seine IT nicht im Griff hatte (Suchbegriffe für die präferierte Suchmaschine: düsseldorf citrix patient tot).
In unserer volkseigenen Waffen- und Rüstungsschmiede wurden 2017 unfreiwillig elektronische Steintafeln abgewandert. Die meisten kleinen, mittleren und grossen Unternehmen sehen sich tagtäglich mit Gefahren aus den Untiefen des Rechtsnachfolgers des des Arpanets konfrontiert. Beispielweise mit Lösegeldware, neudeutsch Ransomware.
Unsere Geschichte beginnt vor einigen Tagen. Bei meinem “Noch-” Kunden sollen einige Anpassungen durch eine Drittfirma gemacht werden. Unter Anderem wird auch ein Tool für das automatische Generieren von E-Mail-Signaturen implementiert.
Das Ding, funktioniert eigentlich ganz clever. Das Tool liegt auf einer zentralen Freigabe, auf der der E-Mail-Signaturenbeauftragte die Signatur(en) erstellt/verwaltet/bearbeitet.
Mittels einer geplanten Aufgabe wird das, was der E-Mail-Signaturenbeauftragte kreiert, als Nutzlast in eine Gruppenrichtlinie geschrieben. Hätte ich so nicht gemacht – denn es kann ja sein, dass der E-Mail-Signaturenbeauftragte mal Mist baut. Aber egal, Sicherheitstechnisch ist nichts dagegen einzuwenden.
Mit der Implementation habe ich nichts am Hut, aber ich hab mir das Tool trotzdem mal auf eine Testmaschine gezogen und etwas damit herumgespielt. Da ist mir doch folgendes aufgefallen:
Natürlich fragte ich mich, wo das Tool denn diese Informationen ablegt und wie es gedenkt, diese Informationen zu “schützen” (Anmerkung 1).
Vielen Dank und gute Nacht. Im Handbuch des Tools steht Sinngemäss: Falls Sie nicht den Standard-Administrator verwenden möchten machen Sie dies und das.
Da prinzipiell der Weg des geringsten Widerstands eingeschlagen wird, führt das meiner Meinung nach sehr oft dazu, dass da ein Benutzerkonto mit Domänenadministrator-Rechten eingetragen wird.
Dann liegt ein XML-File mit Domänen-Administrator-Zugangsdaten in der Gruppenrichtlinien-Partition im SYSVOL-Verzeichnis herum. In welchem standardmässig jeder AD-Account über Leserechte verfügt.
Und jetzt?
Bei einem gezielten Angriff ist das Gold wert, dem Angreifer werden die höchst-privilegierten Zugangsdaten auf dem Silbertablett serviert.
Bei einem gezielten Angriff habe ich Zeit, um nicht Aufzufallen, um Informationen zu sammeln und wenn Notwendig das verschleierte Kennwort zurückzurechnen…
Wenn ich in den nächsten zwei Monaten mal etwas wirklich überflüssige Zeit finde, werde ich versuchen, den Algorithmus für das zurückrechnen des Kennworts zu finden.
PS: Mir ist bewusst, dass ich die Geschichten aus der Gruft in der Regel Humoristisch oder Satirisch geschrieben sind – und dass das hier überhaupt nicht diesem Stil entspricht. Mir ist das Humorium ausgegangen.
Anmerkung 1: Es ist schlicht und einfach nicht möglich, die Daten in diesem Szenario zu schützen. Das Tool, welches diese Anmeldedaten benutzt liegt im selben Verzeichnis wie die Information. Das Tool muss über die Fähigkeit verfügen, das verschleierte Datum in die Klartextinformationen zurückzurechnen. Damit ist der Schlüssel bekannt und muss nur noch aus dem Tool extrahiert werden. Daher schreibe ich auch “verschleiert” (obfuscated), nicht verschlüsselt.