Krypto-Trojaner Locky, Cryptowall und Co.

Seit einigen Wochen bis wenigen Monaten kursieren sehr unangenehme Krypto-Trojaner wie Locky, TeslaCrypt, Cryptowall und seit kurzem auch ein Erster für MacOS. Im folgenden Text finden Sie Informationen und Handlungsempfehlungen, die helfen, sich möglichst gut gegenüber den neuen Schädlingen abzusichern. Dabei spielen das Bewusstsein und eine gute Sicherheitsinformationspolitik im Unternehmen eine wichtige Rolle neben den technischen Schutzmaßnahmen.

„Krypto-Trojaner Locky, Cryptowall und Co.“ weiterlesen

Kerberos Verkehr im Netzwerk-Trace

Im letzten Blogpost habe ich schon etwas über die theoretischen Kerberos Grundlagen geschrieben. Jetzt möchte ich noch einmal technisch zeigen, was genau bei einer Kerberos Anmeldung passiert. Dafür nutze ich einen einfachen Netzwerk Trace von einer NetScaler Appliance in unserem Demo Center und öffne diesen mit Wireshark.

Zuerst möchte ich die nötigen DNS Abfragen kontrollieren.

  • Dafür filtere ich den Trace, um nur „DNS“ Verkehr auszuwerten.
  • Zuerst suchen wir DNS Abfragen für „SRV_kerberos.tcp.Domainname“

 

  • Im weiteren Verlauf dann die entsprechenden Responses bis zur Auflösung der IP-Adresse des Domänen Controllers

 

 

Nachdem wir die DNS Auflösung kontrollieren konnten, können wir direkt den Kerberos Verkehr prüfen.

  • Dafür Filtere ich den Trace, um nur „kerberos“ Verkehr auszuwerten.

  • Jetzt bekommen wir die gesamte Kerberos Kommunikation auf dem Silbertablett präsentiert…

 

 

 

 

Kerberos Basics

Ich habe zwei Posts in Bearbeitung in denen ich etwas über Citrix NetScaler und Kerberos erklären möchte. Aber zuerst möchte ich etwas zu den Kerberos Basics schreiben.

Wer hat’s erfunden?

  • Nicht die Schweizer, sondern Steve Miller und Clifford Neumann am MIT.

Wann wurde es erfunden?

  • Die erste Version wurde ab 1978 vorerst nur intern am MIT eingesetzt.

Wozu dient es?

  • Kerberos als verteilter Authentifizierungsdienst arbeitet ohne die Übertragung des Benutzerpasswortes. Unter anderem dadurch gilt es als sehr sicherer Authentifizierungsdienst.

Woher kommt der Name?

Doch genug geschwafelt, lasst uns anfangen 🙂

Der erste Schritt in der Kerberos Welt ist immer die Erstauthentifizierung und damit das Ticket Granting Ticket. Um dieses zu erlangen, muss unser Test-Client per DNS das KDC (Key Distribution Center) finden.

  • Der Client fordert  für unseren Testbenutzer M.Müller ein TGT (Ticket Granting Ticket) an.
  • Dafür schickt der Client zuerst einen AS-Req (verschlüsselt mit dem User-Secret von M.Müller) an das KDC.
  • Das KDC (zum Beispiel unser Active Directory Domänencontroller) validiert den AS-Req und antwortet mit einem AS-Rep. Dieser ist wieder mit dem Secret von M.Müller verschlüsselt und enthält das TGT.
  • Der Client entschlüsselt den AS-REP mit dem Secret von M.Müller und speichert das TGT im lokalen, sicheren Ticket-Speicher ab.

Als nächstes möchte M.Müller gerne eine Datei vom zentralen File-Server öffnen.

  • Der Client erzeugt ein TGS-Req und übermittelt den Request an das KDC. Der TGS-Req enthält das vorher gespeicherte TGT und dient so zur Authentifizierung von M.Müller.
  • Das KDC wertet den TGS-Req aus und kann so ein Service Ticket für den angefragten Service erzeugen. Das Service Ticket wird mit dem Secret des Services (hier des Computer-Kontos unsers File-Servers) verschlüsselt.
  • Das KDC übermittelt dieses Service Ticket als TGS-Rep an den Client.
  • Der Client speichert das Service Ticket wieder im lokalen Ticket Speicher und sendet es ab jetzt mit jeder Anfrage an den File-Server.
  • Der File-Server kann das Service Ticket mit dem eigenen Secret entschlüsseln und damit verifizieren.

Soweit die Basics. In den folgenden Artikeln möchte ich darauf eingehen wie wir diese Grundlagen nutzen können, um im Zusammenspiel mit NetScaler eine Kerberos Authentifizierung auszuführen.

Active Directory: Zirkulär verschachtelte Gruppen finden

Ein PowerShell-Skript, das wir jetzt in der TechNet Gallery veröffentlicht haben, kann Active-Directory-Gruppen ausfindig machen , die Mitglied von sich selbst sind.

Die Beschreibung mag erstmal anmuten, als wäre das selten und unmöglich, aber auch Großunternehmen haben mit diesem Phänomen hin und wieder ihre Problemchen. Häufig können Anwendungen nicht damit umgehen, bleiben stehen, werfen Fehler oder stürzen sogar ab – abgesehen davon, dass es halt auch einfach Quatsch ist.

Die Benutzung ist denkbar einfach: Ausführen, Lesen, Prüfen und manuell korrigieren.

Die Korrektur wäre natürlich auch automatisiert denkbar, würde aber schwerlich sicher das richtige Ergebnis liefern. Benötigt wird das AD-Modul und es kann losgehen, an Zugriffsrechten sind ausschließlich Leserechte vorausgesetzt, da das Script wie gesagt nicht schreibt.

Das Skript findet sich hier:
[TechNet Get Circular Nested AD Groups]
https://gallery.technet.microsoft.com/Get-Circular-Nested-AD-491145d1

SSL für alle: Let’s Encrypt geht den nächsten Schritt

Verschlüsselung ist die wichtigste Methode, in der Internetkommunikation für Vertraulichkeit und für Sicherheit zu sorgen. Es lassen sich damit nicht nur Inhalte gegen unerwünschtes Mitlesen schützen, sondern man kann mit kryptographischen Funktionen auch digitale Identitäten nachweisen. So ist es einem Anwender möglich zu überprüfen, dass er wirklich mit dem richtigen Server verbunden ist, bevor er sensible Daten dorthin sendet.

Die Technik, die dazu im Web eingesetzt wird, ist bekannt als SSL (Secure Sockets Layer). Richtiger wäre der Ausdruck TLS (Transport Layer Security), weil das ältere SSL-Protokoll schon vor vielen Jahren durch den Nachfolger TLS abgelöst wurde. Trotzdem hält sich der Begriff SSL im allgemeinen Sprachgebrauch, gemeint ist aber eigentlich immer TLS. Das Protokoll beruht auf kryptographischen Zertifikaten, die einen sicheren Austausch von digitalen Schlüsseln für die eigentliche Datenverschlüsselung erlauben. Wenn es richtig eingerichtet ist, gilt TLS als hochsichere und effektive Methode.

Um nicht nur Spionage, sondern auch kriminelle Machenschaften im Internet sehr weitgehend einzuschränken, wäre es also wünschenswert, wenn alle wichtigen Webseiten TLS nutzen würden. Tatsächlich gehen viele Security-Experten so weit zu sagen, dass am besten gleich sämtlicher Web-Traffic verschlüsselt werden sollte. Zwei große Hürden haben allerdings bislang verhindert, dass TLS umfassend zum Einsatz kommt:

  • Die Technik dahinter ist recht komplex. TLS auf einem Webserver einzurichten, erfordert eine Reihe manueller Schritte und vor allem einigen organisatorischen Aufwand.
  • Zuverlässige TLS-Zertifikate (von Anbietern oft immer noch als “SSL-Zertifikate” bezeichnet) kosten Geld. Zwar sind die Preise nicht richtig hoch, doch für viele Zwecke fallen sie schon ins Gewicht.

Eine Initiative aus der Open-Source-Community hat sich auf die Fahnen geschrieben, diese beiden Kernprobleme anzugehen. Unter dem Namen “Let’s Encrypt” plant die Gruppe nicht weniger, als zuverlässige SSL-Zertifikate kostenlos für jedermann anzubieten – und zwar verbunden mit Werkzeugen, die den Aufwand drastisch reduzieren, bis hin zur völligen Automatisierung. Mittlerweile hat die Initiative Unterstützung von Branchengrößen wie Cisco, Akamai oder Automattic erhalten. Seit den ersten Ankündigungen vor einem Jahr ist die Initiative ISRG (Internet Security Research Group) große Schritte vorangekommen: Sie hat die Kernsoftware entwickelt, eine zuverlässige Infrastruktur aufgebaut und dafür gesorgt, dass ihre Zertifikate von allen wichtigen Browsern und Systemen akzeptiert werden.

Nach einer geschlossenen Betaphase im Sommer 2015 folgt nun der nächste große Meilenstein: Am 3. Dezember 2015 wird Let’s Encrypt eine öffentliche Betaphase beginnen, in der alle Interessierten kostenlose und funktionierende TLS-Zertifikate erhalten können. Im Prinzip gehen die Betreiber davon aus, dass das System bereits produktionsreif ist. Den Status als “Beta” behält man deswegen bei, weil die ehrgeizigen Ziele der Automatisierung noch nicht so vollständig erreicht sind, wie sie definiert sind.

Let’s Encrypt wartet bereits jetzt mit folgenden Merkmalen auf:

  • Die ausgestellten TLS-Zertifikate werden von allen wichtigen Browsern akzeptiert. Möglich wird dies durch ein so genanntes “Cross-Signing” mit einem bestehenden Zertifikatsanbieter.
  • Administratoren von Apache-Webservern können den Vorgang, ein Zertifikat anzufordern, es einzubinden und danach regelmäßig zu aktualisieren, bereits jetzt mit einem Software-Tool vollständig automatisieren.
  • Die Zertifikate sind für 90 Tage gültig. Der Webserver kann die Aktualisierung selbstständig und ohne manuellen Eingriff abwickeln.
  • Es handelt sich um TLS-Zertifikate vom Typ “Domain Validation” (DV). Dieser Zertifikatstyp belegt, dass der betreffende Webserver tatsächlich zu der angegebenen Web-Adresse gehört und dies nicht nur vortäuscht.
    (Er belegt jedoch nicht, dass die Webadresse ihrerseits zu einer bestimmten Organisation gehört. Hierzu wäre ein “Extended Validation”-Zertifikat (EV) nötig, das Let’s Encrypt bis auf Weiteres nicht ausstellen wird.)

Wenn die technische Entwicklung so schnell voranschreitet wie bisher, wird Let’s Encrypt schon in wenigen Monaten in der Lage sein, eine wirklich einfach handhabbare und kostenlose Zertifikatslösung “für jedermann” anzubieten. Die Software für Windows-Webserver etwa ist derzeit noch nicht in offizieller Entwicklung, doch es gibt bereits fortgeschrittene Projekte in der Community.

Macht Let’s Encrypt damit bestehende Anbieter oder interne PKI-Strukturen überflüssig? Nein, für diese gibt es weiterhin zahlreiche Einsatzfelder:

  • Da Let’s Encrypt nur Zertifikate für öffentlich erreichbare Webserver ausstellt, bleiben für alle anderen Zwecke die kommerziellen Anbieter im Spiel. Dazu gehören z.B. Mailverschlüsselung oder Code-Signing.
  • Auch Organisationen, die auf ihrer Webseite “erweitertes Vertrauen” benötigen (z.B. Banken, große Web-Shops usw.), werden weiter mit kommerziellen Anbietern arbeiten. Hier sind “Extended Validation”-Zertifikate (EV) das Mittel der Wahl, die einen aufwändigeren Prozess umfassen, in dem das Unternehmen nachweist, dass es die jeweilige Web-Adresse tatsächlich besitzt.
  • Zertifikate mit erweiterten Eigenschaften wird Let’s Encrypt bis auf Weiteres ebenfalls nicht anbieten. Dazu zählen Wildcard-Zertifikate oder  andere spezielle Zertifikate. SAN-Zertifikate (Subject Alternative Name bzw. Unified Communications) hingegen soll das Protokoll ebenfalls unterstützen, dazu finden sich allerdings bislang keine offiziellen Angaben.
  • Und schließlich bleibt es für Unternehmen interessant, eine eigene, interne Zertifikats-Infrastruktur zu unterhalten. Damit lässt sich z.B. interne Kommunikation per TLS absichern (was etwa für Microsoft Exchange notwendig ist). Ebenso sind damit Vorgänge wie Code-Signing (Signieren von Programmcode und Applikationen) abbildbar.

Für den “Standard-Zweck”, die Kommunikation mit einem Webserver über das Internet abzusichern, scheint Let’s Encrypt eine sehr interessante Initiative zu sein. Es ist durchaus zu erwarten, dass sie einen “Ruck” in der IT erzeugt und der Verschlüsselung im Web endlich zum Durchbruch verhilft.

Palo Alto Networks: Endpoint Protection „Traps“

Das Thema Endpoint Protection ist nicht neu. Jeder gestandene IT-Sicherheits-Anbieter hat mittlerweile eine Schutzlösung für Einzelsysteme im Portfolio. Das Problem am klassischen, signaturbasierten Ansatz ist die Dauer, die notwenig ist, um Signaturen an die Endpunkte zu liefern. Oftmals dauert es Tage, Wochen oder sogar Monate, bis die notwendigen Signaturen für Malware beim Softwareanbieter definiert und erfolgreich an die Server- und Client-Betriebssysteme verbreitet wurden.

Palo Alto Networks verfolgt mit der neuen Anti-Malware-Lösung „Traps“ einen neuen Ansatz. Die AV-Lösung klinkt sich in laufende Prozesse und neu gestartete Prozesse auf den Systemen ein und prüft diese fortwährend auf Anomalien und spezielle Eingriffe. Während bekannte Malware von klassischen AV-Anbietern kurzfristig zu einem sehr hohen Prozentsatz erkannt und geblockt wird, wird unbekannte, neue Malware selten kurzfristig erkannt. Damit auch Zero-Day-Malware inklusive neuer Exploits erkannt und geblockt werden kann, muss der Traps-Client auf dem System laufen.

Bei Erkennung von Exploit und Malware wird der Exploit/die Malware geblockt, der Prozess gekillt und Logdaten auf dem Client gesammelt.

Diese Informationen werden dann gemeinsam an den Endpoint Security Manager geschickt. Der Endpoint Security Manager konsolidiert die Daten und tauscht sich hashbasiert mit Wildfire aus.

Welche Systeme werden aktuell von Traps unterstützt?

  • Windows XP with SP3
  • Windows Vista
  • Windows 7
  • Windows 8.1
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012

 

XenMobile 10.1 – RBAC with custom profiles and AD

To configure role based access for a customer´s XenMobile enviroment, we created own RBAC-Profiles based on Microsoft Active Directory with administrative privileges. After assigning the RBAC-Profiles to the delivery group our admin-users are in, XenMobile locked out these users from management and redirected to the self-help portal as they were assigned as normal XM users. Using the default administrative RBAC-Profile login for administrative access on https://[XMS-IP/Hostname]:4443/zdm via UPN (username@domain.tld) was permitted and no further redirection to the self-help portal was initiated from XMS 10.1 anymore.

PAN OS 7.0 angekündigt

Palo Alto Networks hat vor Kurzem die neueste Version seines Firewall-Betriebssystems PAN OS angekündigt und die Kernfeatures und Neuerungen hervorgehoben. In einem Punkt hat Palo Alto noch deutlich zugelegt: Das schon vergleichsweise sehr gute Reporting wurde um einige weitere Möglichkeiten und Filter ergänzt, um noch besser den Kundenanforderungen gerecht zu werden.

Die Automated Correlation Engine steht fortan ab der PA-3000er-Reihe zur Verfügung und sucht das Netzwerk nach Bedrohungen ab. Die Analyse der Daten kann auch auf einer Panorama Appliance (Hardware und Virtual Appliance) stattfinden. Ziel der Automated Correlation Engine ist das Aufspüren von Bedrohungsquellen im Netz, wie beispielsweise infizierte Hosts. Reports können nun nach virtuellem System bzw. Systemnamen generiert werden. Die Adressgruppenbeschränkung wurde von 500 Objekten je Adressgruppe auf 2500 Objekte angehoben.

Zudem ist eine sogenannte „Global Find“-Funktion, also eine Suche über alle Elemente hinweg, implementiert worden. Das erleichtert, Zusammenhänge beispielsweise von Objekten und Policies zu analysieren und zu verstehen. Thematisch angrenzend ist der neue Tag-Browser, mit dem sich Objekte finden lassen, die zuvor mit einem digitalen Anhängeschild versehen wurden.

Beim Sichern der Candidate Config werden nun zusätzliche Validierungs-Checks vorgenommen, die die Syntax und Semantik prüfen.

Natives LLDP und LLDP via SNMP wird nun auch unterstützt, um benachbarte Geräte abzufragen. Auch bei der Content Inspection hat sich einiges getan. So können beispielsweise Dateien, die mindestens fünf mal verschlüsselt wurden, von den PA Firewalls geblockt werden. Von nun an wird auch Kerberos SSO (v5) zur Authentifizierung am Admin Web Interface und dem Captive Portal unterstützt. TACACS+ und eine Backend Authentication Connectivity-Prüfung sind ebenfalls ab PAN OS 7 mit an Bord.

Die Wildfire Appliance WF-500 unterstützt nun Java AV-Signaturen und eine Prüfung von E-Mail Links.

Weitere Features, die hinzugekommen sind, sind u.a.

  • IKEv2 Support für VPN-Tunnel
  • IPv6 IPsec Support
  • Licensing:
    • Lizenz-Neuzuweisung kann nun über das Self Service Portal vorgenommen werden
    • Amazon AWS wird nun möglich, nach Nutzung zu lizensieren
  • Per Virtual System Service Routes
  • TCP Split Handshake Drop
  • Session-based DSCP Classification
  • QoS on Aggregate Ethernet (AE) Interfaces
  • ECMP (Equal Cost Multi Path)