Auch uns bei Univention beschäftigt natürlich der Angriff auf die IT-Infrastruktur des Bundestages, der sogenannte „Bundestags-Hack“. Zur Erinnerung: Es gab dort offenbar gefälschte E-Mails mit Links zu Schadsoftware. Mehrere der Windows-Rechner im Bundestags-Netzwerk „Parlakom“ waren oder sind von der Schadsoftware befallen, die nach bestimmten Word-Dokumenten gesucht und diese kopiert haben soll. Laut einem Bericht des Tagesspiegels haben die Angreifer dadurch “Administrationsrechte für die Infrastruktur” gewinnen können. Der Angriff lief als sogenannter “Advanced Persistent Threat”, kurz „APT-Attacke“ ab – also ein komplexer und mehrstufiger Angriff auf das IT-Netzwerk „Parlakom“ des Deutschen Bundestages.

Wie IT-Systeme übernommen werden können

Um IT-Systeme zu übernehmen, gibt es eine Reihe von “klassischen” Methoden, wie das Ausnutzen von Sicherheitslücken in der Software, das Abfangen oder Erraten von Kennwörtern (brute-force) oder das Knacken von Kennwort-Hashes. Diese Methoden sind gut bekannt und das Risiko, dass solche Attacken Erfolg haben, lässt sich vergleichsweise einfach reduzieren. Die dazu notwendigen Maßnahmen sind: regelmäßiges, flächendeckendes und zügiges Einspielen von Updates, Verschlüsseln von sensiblen Daten und der Netzwerk-Kommunikation mit modernen Verschlüsselungsstandards, Verwenden von ausreichend langen Kennwörtern, Protokollieren von fehlgeschlagenen Anmeldeversuchen und Sperren der Benutzerkonten bei zu vielen Fehlversuchen, Verwenden von “salted” Passwort-Hashes (zwei identische Passwörter werden durch den Salt zu unterschiedlichen Hashes), Iterieren der Hash-Funktion (rounds) und regelmäßiges Ändern der Kennwörter.

Es gibt allerdings auch fortgeschrittene Angriffsmethoden, die nicht „mit der Tür ins Haus fallen“ (wie eine Brute-Force-Attacke) und auch keine massive Rechenleistung zum Knacken von Passwort-Hashes benötigen. Vom SANS-Institut gibt es zu diesem Thema ein White Paper mit dem treffenden Namen “Why crack when you can pass the hash?”.

Gleiches Angriffsszenario des Bundestags-Hacks auch mit Univention Corporate Server möglich?

Nun wissen wir, wie man z. B. hier nachlesen kann, dass der Bundestag als zentrale Verzeichnisdienste OpenLDAP und Active Directory einsetzt. OpenLDAP ist auch der zentrale Verzeichnisdienst in UCS und Active Directory Dienste werden in UCS durch die Open Source Software Samba bereitgestellt. Wir haben uns deswegen gefragt, ob ein solcher Angriff auch bei Einsatz von UCS hätte erfolgreich sein können und welcher Schutz davor erforderlich gewesen wäre. Es stellt sich also die Frage, ob es bekannte Angriffsszenarien gegen Active Directory gibt, ob diese auch auf UCS und Samba zutreffen und welche Schutzmaßnahmen gegebenenfalls ergriffen werden können.

Pass-the-Hash

Pass-the-Hash ist ein Beispiel für eine Angriffsmethode, die sich nicht eine bestimmte Sicherheitslücke im Code zunutze macht, sondern eine Designschwäche in einem Authentifizierungsprotokoll. Dabei wird ein Passwort-Hash (und nicht das eigentliche Passwort) verwendet, um sich an einem entfernten Windows-System anzumelden.

Ein Angriff kann beispielsweise so aussehen:

1. Der Angreifer verschafft sich zunächst lokale Administrator-Rechte auf einem Domänen-System (i. d. R. Windows-Clients), zum Beispiel durch eine Sicherheitslücke oder über eine Phishing-Mail, wie unter Umständen im Falle des Bundestags-Hacks.

2. Anschließend werden Passwort-Hashes ausgelesen, i. d. R. aus dem Arbeitsspeicher, ggf. aber auch aus lokalen Dateien. Die bislang bekannten, erfolgreichen Angriffe beschränken sich auf LM- und NTLM-Hashes.

3. Diese Passwort-Hashes können dann verwendet werden, um sich an Serverdiensten anzumelden, die eine NTLM-Authentifizierung erlauben. Es gibt auch Tools, die aus einem NTLM-Hash ein gefälschtes Kerberos-Ticket schmieden können.

4. Eine Domäne lässt sich vollständig kompromittieren, wenn auf einem AD/Samba DC der Passwort-Hash des KRBTGT-Benutzers ausgelesen werden kann, denn damit lassen sich beliebige Kerberos-Tickets erstellen (Stichwort: “Golden Ticket”).

Alles in allem ist das äußerst unangenehm und ein Angreifer kann sich so dauerhaft in einem Active Directory festsetzen. Man spricht hier von Advanced Persistent Threats (APT).

Derzeit sind für Samba AD DC Server keine Möglichkeiten bekannt, mit denen ein unprivilegierter Benutzer Zugriff auf den Passwort-Hash des KRBTGT-Benutzers bekommen könnte.

Ein privilegierter Benutzer hingegen kann sehr wohl Zugriff auf den Passwort-Hash des KRBTGT-Benutzers bekommen, da dies konzeptionell so vorgesehen ist. Unter Univention Corporate Server ist dafür root-Zugriff nötig, während bei einem Windows AD DC ein Domänen-Administrator ausreichend ist. Angriffe wie Pass-the-Hash machen sich dies zunutze, indem sie andere Sicherheitslücken ausnutzen und sich so die Rechte der privilegierten Accounts beschaffen.

Hinzu kommen ggf. Sicherheitslücken wie MS14-068, die beschreibt, wie die Microsoft Kerberos-KDC-Implementierung Signaturen nicht ordnungsgemäß auf Gültigkeit überprüft und sich so in Kerberos-Service-Tickets enthaltene Authorisierungsdaten fälschen lassen. Nach unserem Kenntnisstand war Samba von dieser Lücke nicht betroffen.

Das allgemeine Risiko lässt sich nur durch entsprechende, organisationsweite Sicherheitsmaßnahmen verringern – das Stichwort hier lautet „defense in depth“.

Wie kann nun eine wirksame Verteidigung aussehen?

Grundvoraussetzung für Pass-the-Hash-Attacken ist ein lokaler, administrativer Zugang zu einem Domänen-Rechner. Daher muss es dem Angreifer so schwer wie möglich gemacht werden, Zugriff auf die Domänen-Systeme zu erlangen. Sollte das bereits passiert sein, darf er keine Möglichkeit haben, wirklich relevante Passwort-Hashes auslesen zu können.

Da sich die Angriffsmuster zwischen Microsoft AD und Samba AD in diesem Punkt nicht unterscheiden, sollten auch die auf Microsoft AD abzielenden Analysen und White Paper bzgl. Pass-the-Hash-Attacken zu Rate gezogen werden.

Gibt es Unterschiede zwischen der Active Directory-Implementierung von Samba in UCS und von Microsoft Windows?

Samba 4 LogoWie bereits erwähnt, unterscheidet sich hier die grundlegende Angriffsmöglichkeit nicht. Um kompatibel zu Microsoft Active Directory zu sein, musste die dort vorhandene Design-Schwäche auch in Samba implementiert werden. Lediglich die Art und Weise, wie sich Zugriff auf einen Domänen-Rechner verschafft werden kann und welche Benutzerkonten und Hashes ausgelesen werden können, variiert.

Unter Microsoft Windows ist ein lokaler Admin-Zugriff Grundvoraussetzung für diese Art von Angriff, um initial einen NTLM-Hash von einem Benutzer abgreifen zu können. Ein Äquivalent unter UCS/Linux wäre der root-Zugriff.

Das unter Microsoft Windows standardmäßige Zwischenspeichern von Passwörtern – auch nachdem sich Benutzer wieder abgemeldet haben – findet so auf UCS Systemen nicht statt, weder für den root- noch für Domänen-Benutzer.

Da für Pass-the-Hash-Attacken auf dem angegriffenen System unsalted Passwort-Hashes (i. d. R. LM oder NTLM) vorhanden sein müssen, ist es wichtig zu wissen, wo diese Hashes ggf. gespeichert sind:

  • Auf UCS DCs liegen alle (NTLM-)Passwort-Hashes in OpenLDAP und auf Samba DCs zusätzlich in der SAM.ldb vor. Daher sind diese Systeme besonders zu schützen.
  • Auf UCS-Systemen, auf denen eine interaktive Benutzeranmeldung erlaubt ist, liegen möglicherweise Kerberos-Credential-Caches unter /tmp.
  • Auf allen UCS-Systemen liegen für root lesbare Host-Credentials (/etc/machine.secret, /etc/krb5.keytab).
  • Auf Windows DCs werden die Passwort-Hashes der Domänen-Benutzer im Active Directory gespeichert – konkret in der Datei %SystemRoot%\NTDS\Ntds.dit
  • Lokale Benutzer werden auf Windows Systemen in der SAM-Datenbank gespeichert (%SystemRoot%/system32/config/SAM) – diese ist auch über die Registry zugänglich.
  • Darüber hinaus gibt es Tools, die unter Windows auf Passwort-Hashes im Arbeitsspeicher zugreifen und diese auslesen können. Dadurch lässt sich an einem kompromittierten Client auch der Passwort-Hash eines (zuvor) angemeldeten Domänen-Administrators gewinnen, obwohl dessen Passwort-Hash nicht lokal gespeichert ist.

Angriffsvektor: Laterales Server-Hopping mit dem lokalen Administrator.

Bei Windows-Systemen kann mit dem Passwort-Hash des lokalen Administrators i. d. R. auch auf weitere Windows-Systeme zugegriffen werden, wenn dort dasselbe Kennwort verwendet wird. Das UCS- bzw. Linux-Äquivalent zum lokalen Administrator ist „root“ und dieser ist kein Samba/Kerberos-Benutzer. Dadurch kann mit einem einfachen Hash keine Anmeldung an einem entfernten UCS-System stattfinden. Der lokal gespeicherte passwd-Hash des root-Kennwortes ist mit einem Salt versehen, was das Cracken des Kennwortes über Rainbow Tables stark erschwert. Nichtsdestotrotz ist es empfehlenswert, nicht auf allen Systemen dieselben root-Passwörter zu verwenden. In der Regel ist es auch sinnvoll, root-Passwörter zu deaktivieren und stattdessen ausschließlich sudo zu verwenden.

Alternativ/Zusätzlich können SSH-Keys mit starker, hostspezifischer Passphrase verwendet werden.

Angriffsvektor: Laterales Server-Hopping mit Hash eines Domänen-Benutzers.

Im Gegensatz zu Windows Systemen kann mit einem NTLM-Hash allein keine Anmeldung an einem entfernten UCS-System durchgeführt werden.
Ähnlich wie bei Windows wäre es jedoch auch unter UCS möglich, sich mit dem Kerberos-Credential-Cache eines Benutzers oder UCS-Hosts an kerberisierten Diensten anderer UCS-Systeme zu authentisieren. Hier ist dann die Beschränkung der Authorisierung entscheidend (z. B. über die UCR-Variablen auth/.*/restricted und auth/.*/ ).

Angriffsvektor: Auslesen von Hashes per LDAP aus dem Samba Verzeichnisdienst.

Das ist prinzipiell nur über einen lokalen Socket möglich, nicht über den LDAP-Port. Es erfordert also lokalen root-Zugriff. Eine Ausnahme bildet das Joinen eines zusätzlichen Samba/AD- oder Microsoft AD-DCs als Angriffsmittel, da AD-DCs alle Passwort-Hashes per DRS-Replikation geliefert bekommen. Dies erfordert Domänen-Administrator Credentials,
z. B. Kerberos-Hashes.

Angriffsvektor: Auslesen von Hashes per LDAP aus OpenLDAP.

Dies ist durch LDAP-ACLs geschützt. Standardmäßig können neben Domain-Admins auch alle UCS DCs die Hashes zwecks LDAP-Replikation auslesen. Der Zugriff auf OpenLDAP erfordert seit UCS 3.0 grundsätzlich eine Authentifikation. Es muss allerdings geprüft werden, ob die Authentifikation nicht aus Gründen der Abwärtskompatibilität manuell deaktiviert wurde (ldap/acl/read/anonymous und ldap/acl/read/ips). Die Replikation findet über TLS-verschlüsselte Verbindungen statt.

Weitere Bausteine einer Defense-in-Depth-Strategie

Ohne Anspruch auf Vollständigkeit:

  • Wenn Microsoft Windows-Clients und -Fileserver in einer UCS-Domäne gejoint sind, dann gelten für diese Systeme alle Microsoft-Empfehlungen, insbesondere http://blogs.microsoft.com/cybertrust/2012/12/11/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash/ bzw. https://technet.microsoft.com/en-us/dn785092.aspx . Windows 8.1 und Windows Server 2012 R2 verbessern zusätzlich die Sicherheit der lokalen Anmeldedienste, siehe http://blogs.microsoft.com/cybertrust/2014/07/08/new-strategies-and-features-to-help-organizations-better-protect-against-pass-the-hash-attacks/.
  • Auf DCs den Zugriff für reguläre Benutzer verbieten. Für viele UCS-Dienste ist das bereits die Standard-Konfiguration (UCR-Variablen auth//restrict)
  • Zudem sollte eine gezielte Separierung der unterschiedlichen Account-Typen in Erwägung gezogen werden:
      Deaktivierung des Domain-Admins „Administrator“ und Verwendung von personalisierten Admin-Accounts
      Einführung von DC-Domain-Admins – diese dürfen sich nur an Domaincontrollern anmelden
      Einführung von Client-Domain-Admins – diese dürfen sich nur an Memberservern und Clients anmelden
      Die Administratoren verwenden die Admin-Accounts nur zum Administrieren, sprich, die tägliche Arbeit erfolgt sowohl für Benutzer als auch für Admins mit nicht-privilegierten Accounts.
  • regelmäßiges, rasches und flächendeckendes Installieren von Sicherheits-Updates
  • Full-Disk-Encryption
  • Passwortgeschütztes BIOS/UEFI
  • Virenscanner mit entsprechendem Reporting
  • Firewalls mit entsprechendem Reporting
  • Intrusion-Detection-Systeme mit entsprechendem Reporting
  • Firewall-Regeln: keine Client-to-Client Kommunikation, Clients dürfen nur mit den notwendigen Servern kommunizieren.
  • Regelmäßiges Rotieren aller Kennwörter
  • Sicherstellen, dass, soweit möglich, nur starke Verschlüsselungsmethoden/Hashes verwendet bzw. akzeptiert werden.
  • Sicherstellen, dass sich lokale Benutzer (z. B. Administrator/root) nicht remote an einem anderen System anmelden können – insbesondere nicht mit demselben Passwort.
  • Sicherstellen, dass Windows die Kennwort-Hashes nicht länger zwischenspeichert als nötig, bspw. nicht mehr nach dem Abmelden des Benutzers.

Fazit zum Bundestags-Hack

Auch bei der IT-Sicherheit gilt: 100% Sicherheit gibt es nicht – auch bei UCS nicht. Aber es gibt viele Dinge, die getan werden können und bei einer kritischen Infrastruktur wie der des Deutschen Bundestages sicher auch getan werden müssen. Ob sie wirklich getan wurden, müssen die aktuell laufenden Untersuchungen zeigen.

Und klar ist auch: Nur quelloffene Software, die sowohl vom Hersteller, vom Anwender, aber auch von unbeteiligten Dritten auf mögliche Fehler und Hintertüren untersucht werden kann, bietet maximale Transparenz. Sie ist deswegen zwingender Bestandteil einer wirkungsvollen, nachhaltigen IT-Sicherheitsstrategie.

Fotoquelle „Deutscher Bundestag“: Groman123 / CC BY-SA 2.0

UCS Core Edition jetzt kostenfrei einsetzen!

Zum Downloadbereich
Michael Grandjean

Michael begann 2007 eine Ausbildung zum Fachinformatiker Systemintegration bei der G&M IT-Systeme GmbH, wo er anschließend in der Abteilung Support, Administration und IT-Sicherheit kleine und mittelständische Unternehmen betreute und eine Weiterbildung zum IT-Sicherheitsmanager abschloss. 2013 wechselte er als Open Source Software Consultant in das Professional Services Team von Univention.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Kommentare

  1. Toller Artikel!
    Herzlichen Dank!

    Gruß

    Antworten
  2. Das ist aber schon ein reichlich schräger Artikel. Zum einen beruf er sich auf Aussagen des Tagesspiegel, die bestenfalls als „Höhrensagen“ zu werten sind. Zum anderen werden hier sicher einige richtige Aspekte genannt, zum anderen aber auch einiges weggelassen bzw. schlicht falsch dargestellt.
    NTLM ist nicht das Standardprotokoll für die Authentifizierung unter Windows, sondern eben Kerberos. Nun kann Samba da nur mit großem Klimmzug überzeugt werden, Kerberos Authentifizierung zu machen und deshalb nutzt auch UCS eben die veraltete Authentifizierung. Windows nutzt natürlich auch noch NTLM, wenn die Gegenseite eben nicht Kerberos unterstützt. Aber das liegt an den anderen Systemen, per Default macht Windows schon längere Zeit nicht mehr.
    Das Problem des Hash ist sicher bekannt und auch die aktuelle Version hilft ja nicht wirklich. Einen lokalen Administrator unter Windows mit Unix root zu vergleichen, ist aber schon ein wenig komisch, denn das System funktioniert vollkommen anders (auch ein lokaler Windows Admin kann eben nicht alles). Im Übrigen speichert Windows den Hash eines NTLM Passwortes nie im AD, denn das liegt nicht auf der lokalen Maschine. Was sie meinen, ist wohl eher die Registry. 🙂

    Antworten
    • Hallo Herr Tolkmitt,

      vielen Dank für ihr Feedback.

      Zum Tagesspiegel: Das genannte Zitat „Administrationsrechte für die Infrastruktur“ findet sich so im IuK-Protokoll und wurde laut Protokoll von Herrn Hange vom BSI getätigt. Weitere Quellen:

      * golem.de

      * bild.de

      Zu root vs. Administrator: Dass Windows und Linux unterschiedlich funktionieren, steht ja außer Frage. In dem Abschnitt ging es aber doch um Unterschiede und Gemeinsamkeiten von Windows AD und UCS/Samba AD im Bezug auf Angriffsszenarien. Und da passt die Einschätzung meiner Meinung nach schon: sowohl der lokale Administrator unter Windows als auch ‚root‘ unter Linux sind a) privilegierte Benutzerkonten zur Administration des lokalen Systems und b) keine Domänen-Benutzer.

      Zu NTLM vs. Kerberos: Sicherlich ist Kerberos das bevorzugte Protokoll, aber NTLM funktioniert standardmäßig immernoch als Fallback, wenn man es nicht explizit abschaltet. Und selbst wenn man das umsetzen möchte kann man schnell vor der ein oder anderen Herausforderung stehen, wenn sich ein Client authentifizieren soll, der kein Kerberos spricht (erfahrungsgemäß ist das schon bei dem
      nächstbesten Multifunktionsdrucker der Fall, der seine Scans auf eine Freigabe ablegen soll).

      Außerdem wird Kerberos direkt übersprungen und NTLM standardmäßig benutzt, wenn DNS nicht funktioniert, wenn der Client oder der Server nicht in der selben Domäne sind oder wenn Firewallregeln auf Server oder Client die Kerberos-Kommunikation verhindern. Als Angreifer mit lokalen Adminrechten habe ich da natürlich genügend Möglichkeiten das zu erzwingen. Fazit ist also: Ja, Kerberos ist das bevorzugte Protokoll und sowohl Windows als auch UCS und Samba nutzen das per default – ein Downgrade auf NTLM ist aber in der Regel möglich.

      Noch ein Wort zu UCS, Samba und AD: Wir reden hier von Samba als Active Directory kompatiblen Domänencontroller – der spricht natürlich genau wie ein Microsoft AD DC bevorzugt Kerberos und das auch ohne „Klimmzüge“.

      Zu den NTLM-Hashes im AD: Ich befürchte, ich kann ihrer Ausführung nicht ganz folgen. Meiner Auffassung nach, ist es genau umgekehrt: Das Active Directory selbst ist auf Windows DCs verfügbar und verwendet dort eine Datenbank, den sog. Directory Data Store. Dieser Directory Data Store wird auf jeden regulären Windows DC repliziert und dort in der Datei Ntds.dit gespeichert. Und natürlich stehen dort auch die Passwort-Hashes drin. Die sind nicht ohne weitere einsehbar (z.B. zeigt ADSIEdit sie nicht an), aber sie sind vorhanden und können mit entsprechenden Tools auch extrahiert werden (mal davon ab, dass sie auch zusätzlich im Arbeitsspeicher bzw. im LSASS-Cache vorhanden sein können).

      Die Kennwörter von lokalen (!) Benutzern hingegen werden auf Windows-Clients in der SAM-Datenbank gespeichert. Und auch das ist schlussendlich „nur“ eine Datei – und die kann auch als Registry-Hive geladen werden.

      Schönen Gruß,

      Michael Grandjean

      Antworten
  3. […] Bremen ansässiges Unternehmen, welches Server und Rechnernetze auf Basis von Linux anbietet, hat ausführlich über unterschiedliche Schwachstellen und mögliche Schutzmaßnahmen nachgedacht und di…. Wenig überraschend ist die Schlussfolgerung, dass der Einsatz von offener Software viele […]

    Antworten
  4. Vielen Dank für diese Gedanken! Freundliche Erlaubnis voraussetzend, habe ich diesen Beitrag in meinem Blog gemeldet und verlinkt: http://www.pc-fluesterer.info/wordpress/2015/06/30/hack-des-bundestagsnetzes-gedanken-zum-schutz/

    Herzliche Grüße,
    Christoph Schmees

    Antworten
  5. Da haben wir’s: mimikatz und „Insgesamt sei es den Angreifern gelungen, 5 der 6 Accounts der Domänenadministratoren der Bundestagsverwaltung zu kompromittieren und zu nutzen.“
    -> https://netzpolitik.org/2016/wir-veroeffentlichen-dokumente-zum-bundestagshack-wie-man-die-abgeordneten-im-unklaren-liess/

    Antworten

Schreibe einen Kommentar zu Michael Grandjean Antworten abbrechen

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