In diesem Beitrag sammele ich alle meine bisher erlebten und festgestellten Sicherheitsschwachstellen, die einfach nicht sein müssen.
Gefühlt wird dieser Beitrag nie vollständig sein, deshalb wird der Beitrag im laufe derzeit immer wieder um weitere Punkte ergänzt 🙂
Helft gerne mit die Deutsche KMU IT etwas sicherer zu machen, teilt eurer erlebtes in den Kommentaren mit und lasst den Beitrag um weitere Themen wachsen.
Edits/Updates:
KW44 – Punkt 1-4 ergänzt.
KW45 – Punkt 5-8 ergänzt.
1.Tägliches arbeiten mit einem Konto, das Mitglied der Domänen-Admins ist.
Oft bekomme ich es mit, dass die IT-Mitarbeiter ihre täglichen administrative Tätigkeiten, mit einem Konto ausführen, welches Mitglied der Active Directory Gruppen “Domänen-Admins” ist.
Meistens wird dies so gehandhabt, da sobald man Mitglied dieser Gruppe ist, alles innerhalb der Windows Domäne möglich ist. Und genau dies ist auch so gefährlich.
Domänen-Admins können standardmäßig folgene Dinge ausführen:
– Anmeldungen an allen Domänen Mitglied Servern und Clients ist möglich.
– Remotedesktop-Verbindungen zu allen Domänen Mitgliedern ist möglich.
– Volle Rechte im Active Directory, DNS, DHCP, Gruppenrichtlinien,…
-Komplette administrative Rechte auf den Servern und Clients.
– (Meistens) Lese und Schreibrechte auf so ziemlich alle Ordner und Dateien die es gibt (auch versteckte Freigaben).
und und…
Es funktioniert wirklich alles. Und genau das macht das arbeiten mit dieser Gruppe so gefährlich. Gerät ein solches Benutzerkonto in die falschen Hände, oder fängt sich dieses Benutzerkonto einen Ransomeware Trojaner ein, kann man sich ausmalen, was alles passieren kann. Ich bin der Meinung das diese Gruppe nur in Sonderfällen benötigt wird und alle anderen täglichen Admin-Tätigkeiten, wie z.B. Benutzerkonten-, Client- und Postfach- Verwaltungsaufgaben mit gezielten Delegierungen auf ein seperates Konto berechtigt werden kann. Und spätestens der IT-Dienstleister, der Azubi, der Helpdeskmitarbeiter oder die halbtags IT-Unterstützungskraft muss nicht mit solchen Rechten arbeiten. Das Least-Privilege-Prinzip ist nicht von heute auf morgen umgesetzt, aber einmal korrekt geplant und implementiert stellt es eine deutliche steigerung der IT-Sicherheit da.
2. Authentifizierte Benutzer sind berechtigt einen Computer der Domäne hinzuzufügen.
Ja richtig gelesen. Per default ist es jedem Domänen Benutzer möglich, Computer einer Domäne hinzuzufügen. Bei der Installation des Active Directory werden Standard Gruppenrichtlinien erstellt. In dieser wird die Berechtigung dafür gesetzt. Und wurde die Anpassung mal vergessen empfhielt es sich diese umgehend anzupassen. Der Auszug aus dem Technet dazu erklärt es schön.
3. Netzwerk Zugriff – DHCP für alle!
Im normalen IT Tagesbetrieb mangelt es oft an Zeit und Manpower. Daher passiert es öfters, das dass Netzwerk etwas vernachlässigt wird. Auch hat nicht jeder Admin noch Zeit sich in die tiefen einer Cisco oder HP CLI einzuarbeiten.
So kommt es vor, dass alle Geräte die in die nähe eines Netzwerkdose kommen automatisch eine IP Adresse erhalten.
Dies bringt zahlreiche gefahren mit sich mit:
- Unbekannte Geräte im produktiven Netzwerk
Ein Mitarbeiter bringt sein privates Notebook mit an den Arbeitsplatz, schließt dieses an eine freie Netzwerkdose an bekommt über DHCP eine IP Adresse zugewiesen und befindet sich im produktiven LAN. Im Idealfall kann er ohne Proxy keine Verbindung ins Internet aufbauen und merkt schnell, das das arbeiten mit dem privaten Gerät durch Firewall und co. eingeschränkt ist. Bis es er aber zu der Erkenntnis kommt hat sich das Gerät nun eben schon im dem Firmen Netz eingewählt…
- Ausnutzung durch Kriminelle
Auch von Kriminellen können unzureichende Netzwerkabsicherung ausgenutzt werden. Kleines Beispiel: ein Besucher iversteckt einen kleinen Access Point an einer Netzwerkdose – das Gerät bekommt im schlimmsten Fall über DHCP eine IP Adresse zugewiesen und der Kriminelle kann von der Straße aus, außerhalb der Geschäftszeiten in ruhe seine Infiltration durchführen.
Um die Gefahr zu verringern empfiehlt es sich das Netzwerk so zu konfigurieren, dass bevor ein Netzwerkzugriff möglich ist, die MAC Adresse des Gerätes freigeschaltet werden muss.
An einem Switch kann dies über eine sogenannte Port Security erfolgen. Dabei wird an einem Switch Port die MAC Adresse von dem Gerät hinterlegt, welches an dem Port betrieben werden darf. Versucht ein Gerät mit einer anderen MAC Adresse eine Verbindung aufzubauen, wird der Port gesperrt.
Ist die Switch Variante zu aufwendig, sollte wenigstens – wenn z.B. ein Windows DHCP Server genutzt wird – an diesem die Funktion des MAC Filter genutzt werden. Darüber können MAC Adressen freigeschaltet werden, die eine DHCP Adresse erhalten dürfen. Somit wird es wenigstens etwas erschwert eine IP Adresse zu erhalten und man müsste erst einmal herausfinden, welches Subnetz auf dem jeweiligen VLAN Port genutzt wird – das hält den richtigen Hacker nicht lange auf, aber wenigstens den normalen Benutzer, welcher vielleicht sein eigenes Team W-LAN etablieren möchte :-).
4. Interne DNS Zonen – Dynamische Updates Einstellung unsicher
Was ich auch schon oft gesehen habe, sind internen DNS Server die falsch konfiguriert sind. Die Dynamischen DNS Updates sind nicht nur von vertrauenswürdigen Geräten möglich, sondern auch von nicht vertrauenswürdigen Geräten. Ist dies der Fall könnte man zum Beispiel einen Client mit dem DNS-Namen eines anderen Servers im DNS registrieren und so das Störungen im Netzwerk, oder Sicherheitsrelevanten Daten abfangen.
Beispiel:
In diesem Bild sieht man einen Windows Client der nicht Mitglied des Active Directory ist.
Der Hostname ist “jrex02”. Mit der Einstellung Dynamische Updates: “nicht sichere und sichere” kann das Gerät sich im DNS unter der jeweiligen Zone registrieren.
Im zweiten Foto habe ich den Client im Namen so angepasst, das er identisch mit einem Server Hostname ist, der Mitglied im Active Directory ist. Die IP Adresse wird überschrieben (jr-legacy-adc01).
5. Anmeldung an Clients mit hohem Administrativen Konto.
Meldet man sich mit einem Benutzerkonto an einem Client an, wird u.a. der Kennwort Hash des Benuzerkontos auf dem Client von Security Account Manager verwaltet und von dem Windows Local Security Authority Subsystem (LSASS) verwendet. Gespeichert wird das alles in der der SAM Datei unter C:\Windows\system32\config\sam.
Beispiel: Meldet man sich an einem Client mit einem Benutzerkonto – welches z.B. Mitglieder der Domänen-Admins ist – an, ist der Kennwort Hash dieses Benutzerkontos auf dem Client “zwischengespeichert”. Auch nach dem abmelden.
Hat der normale Benutzer auf dem Client nun zufälligerweise noch administrative Rechte, kann mithilfe von diversen Tools (z.B. Mimikatz) der Kennwort Hash des oben genannten Benutzer ausgelesen und für weitere zwecke missbraucht werden (Pass the Hash Attacke).
Ausführliche Szenarien findet man u.a. auch Live und in Farbe auf Youtube :-).
https://www.youtube.com/results?search_query=pass+the+hash
Abhilfe:
https://docs.microsoft.com/de-de/windows-server/security/credentials-protection-and-management/credentials-protection-and-management
https://www.microsoft.com/en-us/download/details.aspx?id=46899
Screenshot von Mimikatz:
7. Passwörter unsicher abgespeichert.
Passwörter gehören nicht in eine Excel, Word, oder andere Dateiformate abgespeichert. Ebenso wenig sollten diese nicht nur auf einem Netzlaufwerk oder lokalen Client abgelegt sein.
Eine abhilfe schafft hier das Tool Keeper:
8. Windows Updates vernachlässigt.
Im Tagesgeschäft oft vernachlässigt ist das regelmäßige Updaten der Server und Clients mit den aktuellsten Windows Sicherheitsupdates.
Die Sicherheitsupdates erscheinen jeden zweiten Dienstag im Monat und sollten zeitnah eingespielt werden.
Eine aktuelle Übersicht findet man auf der Seite des Microsoft Security Response Center
https://msrc.microsoft.com/update-guide
9… Coming Soon
10… Coming Soon
…