Patchen ist wichtig !

Ich möchte einen aktuellen Support Call vor Weihnachten 2014 zum Anlass nehmen, auf Server aufzupassen, Virenscanner auch auf Servern zu installieren und Server regelmäßig zu patchen.

Die Geschichte

Angefangen hat es damit, dass Mitarbeiter nicht mehr per "Direct Access" arbeiten konnten, d.h. Windows 8.1 Client konnten sich nicht mehr per HTTPS mit dem Windows 2012R2 Direct Access Server in der Firma verbinden. Als "Fallback" haben die Anwender dann wieder das klassische "Dialup-VPN" genutzt. Über Fernwartung haben wir dann den Server kontrolliert und diverse Tests durchgeführt. Der Server war per DNS auflösbar, per HTTPS erreichbar, das Zertifikat war gültig und auch sonst sprach nichts dagegen, dass es auf dem Server ein Problem gab. Sogar die Ansicht in der Remote Access Console hat keine Probleme gezeigt. Alle Komponenten wurden von Windows als "Grün" angezeigt. Auch alle anderen

Allerdings war der Server schon länger nicht mehr gepatched worden, so dass vielleicht durch Updates auf dem Clients (Poodle etc.) oder strengere Richtlinien bezüglich SSL3/TLS hier mit reinspielen könnten. Es ist zudem nie schlecht mit "aktuellen Versionen" zu arbeiten. Der Server wurde als gepatched und in dem Zuge auch durchgestartet aber gelöst hat das erst mal nicht.

So einfach war das Problem also wohl nicht zu finden, hatte ich zuerst gedacht. Aber bei der zweiten Session ist mir dann aufgefallen, dass die Windows Firewall auf dem Public-Interface deaktiviert war. Generell sollte heute die Windows Firewall nicht mehr deaktiviert werden. Gute Programme oder Administratoren tragen entsprechende "Allow"-Regeln ein, um bestimmte Kommunikationen zu erlauben. In Verbindung mit Direct Access wird aber der Windows Firewall nicht nur eine filternde sondern auch eine tragende Rolle zuteil. Sie übernimmt nämlich aktiv Aufgaben, die für Direct Access erforderlich sind. Kurz: Ohne aktive Windows Firewall funktioniert Direct Access nicht mehr. Also haben wir die Windows Firewall auf den Schnittstellen wieder aktiviert und schon konnten die Anwender wieder arbeiten.

Hier hätte ich den SupportCase schließen können, denn die Ursache für den Ausfall war gefunden und behoben wurden. Aber man sollte zumindest immer noch ein paar Minuten investieren, um den Auslöser für die Ursache zu finden, damit zukünftig sich so etwas nicht wiederholen kann. Damit stand eine Frage im Raum: "Wer, Wann und Warum wurde die Firewall abgeschaltet".

Weitergehende Analyse

Das ist bei Windows 2012R2 gar nicht so schwer, wenn der Vorgang nicht allzu lange in der Vergangenheit liegt, denn viele Aktionen werden im Eventlog protokolliert. Man darf nur nicht einfach im System oder Application-Eventlog schauen, sondern muss schon etwas das richtige Log suchen. für die Firewall ist das unter "Microsoft-Windows-Windows Firewall With Advanced Security/Firewall". Hoffentlich wurden hier nicht zu viele andere Logs protokolliert. Ein "Angreifer" hätte das Log ja auch löschen können. Wir wurden aber fündig:

Log Name: Microsoft-Windows-Windows Firewall With Advanced Security/Firewall
Source: Microsoft-Windows-Windows Firewall With Advanced Security
Date: 03.12.2014 04:57:45
Event ID: 2003
Task Category: None
Level: Information
Keywords:
User: LOCAL SERVICE
Computer: <computername>
Description:
A Windows Firewall setting in the Public profile has changed.
New Setting:
Type: Enable Windows Firewall
Value: No
Modifying User: SYSTEM
Modifying Application: C:\Windows\SysWOW64\netsh.exe

Da stellt sich natürlich die Frage, welcher Administrator oder Prozess bei einem klassischen mittelständischen Betrieb morgens um kurz vor fünf die Firewall auf einem Direct Access-Server beenden sollte. Der Kunde konnte das nicht beantworten aber war ziemlich sicher, dass es keine Gruppenrichtlinien, geplante Tasks oder schlaflose Administratoren gibt. Wir haben also etwas weiter gestöbert und in zeitlicher Nähe sind wir im System-Eventlog auf einen anderen Eintrag gestoßen. Diesmal von Forefront, dem Virenscanner auf dem Server:

Log Name: System
Source: FCSAM
Date: 03.12.2014 04:57:56
Event ID: 3004
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: <computername>
Description:
Microsoft Forefront Client Security Real-Time Protection agent has detected changes. Microsoft recommends you analyze the software that made these changes für potential risks. You can use information about how these programs operate to choose whether to allow them to run or remove them from your computer. Allow changes only if you trust the program or the software publisher. Microsoft Forefront Client Security can't undo changes that you allow. für more information please see the following:
http://go.microsoft.com/fwlink/?linkid=37020&name=TrojanDownloader:BAT/Ftper.gen&threatid=2147576425
Scan ID: {10AAFEE4-6DFB-4BE7-8867-C190A2223662}
  Agent: On Access
  User: NT AuTHORITY\SYSTEM
  Name: TrojanDownloader:BAT/Ftper.gen
  ID: 2147576425
  Severity: Severe
  Category: Trojan Downloader
  Path Found: file:C:\Windows\SysWOW64\zax.txt
  Alert Type:
  Process Name: C:\Windows\SysWOW64\cmd.exe
  Detection Type: Generic
  Status: Suspend

Damit haben nun natürlich alle Weihnachtsglocken auf einmal gebimnmelt. Die zeitliche Nähe ist sicher kein Zufall und auch ohne ein ausgewiesener Sicherheitsexperte zu sein, ist meine Vermutung:

  1. Etwas hat es geschafft auf dem Server Prozesse als "SYSTEM" zu starten
  2. Dieses etwas hat zuerst die Windows Firewall abgeschaltet
  3. Und dann erfolgreich eine Datei irgendwo herunter geladen
  4. Der Virenscanner hat diese Datei erfolgreich blockiert

Man könnte zwar nun sagen: "Glock gehabt" aber darauf würde ich mich nicht verlassen, denn der Remote Zugriff wurde nicht blockiert und wer sagt, dass nicht noch ein anderes böses Tool "nachgeladen" wurde, was noch nicht von Forefront erkannt wurde? Ein Restrisiko bleibt immer und auch ein "Full Scan" mit einem aktuellen Patternfile ist noch immer kein Garant, dass der Schadcode entdeckt wird. Die Diskussion (FinFisher, Regin (http://de.wikipedia.org/wiki/Regin_(Spionagesoftware)) zeigt sehr wohl, dass Virenscanner nur finden, was sie früher schon mal gefunden haben. Und wenn Schadprodukte nur zielgerichtet eingesetzt werden, dann bleiben Sie lange unentdeckt. Auf dem Grund muss man schon davon ausgehen, dass dieses System nicht weiter "Trusted" ist und idealerweise frisch aufgebaut werden sollten.

Ebenso habe ich nicht erwartet, dass Forefront diesen Event nicht deutlicher gemeldet hat. Selbst auf dem Server selbst wurde das Icon in der Fußleiste nicht verändert und in der "Log-Ansicht" was die Warnung nicht vorhanden. Hier gibt es also schon Optimierungspotential.

Wo kam es her ?

Bleibt natürlich die Frage, woher diese kritische unautorisierte Veränderung gekommen ist. Leider ist es nun so, dass Firmen erst ab einer bestimmten Größe auch über ein "Log-Management" verfügen". In diesem Fall war das Windows Eventlog die einzige nutzbare Quelle und die war hierbei nicht weiter hilfreich. Die davor platzierte Firewall protokolliert zwar Verbindungen, aber schaut nicht "in" den SSL-Datenstrom und protokolliert auch nicht, was "drin" ist. Eine komplette Verkehrsaufzeichnung findet vermutlich nur an unseren Internet Austauschknoten durch Geheimdienste statt.

Wenn wir davon ausgehen, dass der Server aus dem Internet angesprochen wurde und es daher keinen Zugriff von intern gab, dann reicht ein Blick auf die Regel von extern. Als Direct Access Server sind nur ganz wenige Ports von extern erreichbar. Genaugenommen ist es 443/TLS für den Zugang per SSTP und IPHTTPS, die aus dem Internet erreichbar sind. Alle anderen Ports, insbesondere RPC etc. sind natürlich gesperrt. Mir fallen natürlich einige kritische Lücken ein, über die ein Server "gekapert" werden kann.

Leider waren auf diesem Server Patches schon einiger Zeit nicht mehr installiert worden, so dass es durchaus möglich gewesen sein könnte, dass jemand sich einen Virus eingefangen hat und dann quasi von innen den Server übernommen hat.

Man ist ja versucht solche Risiken mit einem "Meine Server sind ja nicht interessant" zu verdrängen. Aber kaum ein Schadprogrammhersteller wird im Code sich die Mühe machen, zwischen "weniger interessanten" und "interessanten" Firmen zu unterscheiden. Die einen Suchen einfach nach Opfern, um sie als Relay zu missbrauchen. Dazu ist ein VPN-Server ein geniales Ziel, da er oft unbeschränkt aus dem Internet erreicht werden als auch nach intern zu allen Servern kommunizieren kann.

Leider habe ich Beweise gefunden, ob diese Lücke wirklich dazu missbraucht werden konnte, von extern Befehle an Windows zu übermitteln, die dann als "SYSTEM" ausgeführt werden. Es könnte ja auch ein Client gewesen sein. Also haben wir geschaut, wer in der Zeit z.B. eine Verbindung aufgebaut hatte, denn in der Firma war eigentlich nur der Wachschutz da. Und tatsächlich war zu der Zeit auch ein Anwender aktiv, der in diesem Zeitrahmen sogar ein USB-Device angeschlossen hat. Eine entsprechende Device-Lock-Software hat diesen Schluss nahe gelegt. Aber für eine zuverlässige Quellenbestimmung ist auch das zu wenig.

Wir wollten den Aufwand hier nun nicht ins Endlose treiben und haben mit einem "Full Scan" auf allen Servern mit einem aktuellen Patternfile erst mal die bekannten Schädlinge ausschießen können. Der eigentliche Support Call "Direct Access funktioniert nicht" war ja schon früher abgeschlossen und eine forensische Analyse ist ein komplett andere Sache.

Lehre

Damit haben wir diesen Fall in Übereinstimmung mit dem Kunden geschlossen, aber nicht ohne ihm entsprechende Ratschläge mitzugeben, die ich kurz hier wiedergebe und eigentlich allgemeingültig sind:

  • Patchen !!!
    Wenn der Angriff wirklich von außen gekommen sein sollte, dann ist es fahrlässig, einen Server längere Zeit nicht zu patchen. Insbesondere wenn Microsoft Updates veröffentlicht, die als "Critical" gelistet werden, "Remote Code Execution" erlauben und üblicherweise erreichbare Dienste (SCHANNEL ist auch HTTPS, also 443) betreffen.

Hier also noch mal der dringende Aufruf: Patchen Sie ihre Direct Access, Reverse Proxy, TMG, Exchange-OWA, ActiveSync, Lync Edge, ADFS und anderen Server, die per HTTPS erreichbar sind oder über andere Protokolle z.B. SCHANNEL nutzen oder andere Dienste, die ohne ein Update eine Lücke offenbaren.

  • Virenscanner
    Virenscanner auf Servern sind ratsam. Auch wenn auf einem Server eigentlich kein Anwender etwas "Starten" sollte zeigt doch dieses Beispiel, dass auch auf Servern Code landen kann, der durch einen Schadscanner erkannt und blockiert werden kann und damit schlimmeres verhütet wird.
  • GPO für Firewall
    Die Windows Firewall ist und bleibt eine wichtige Komponente einer Schutzstrategie und mit entsprechend konfigurierten Regeln können Dienste auf dem Server nur mit entsprechenden Regeln arbeiten. Diese Regeln sind immer "sichtbar". Eine deaktivierte Firewall auf einem Netzwerkinterface ist in sehr guter Indikator, dass hier jemand Regeln umgehen will. Und es ist ein leichtes per Gruppenrichtlinie das vorzuschreiben.
  • Eventlog Monitoring
    Nicht alle Events, hier der Virenscanner", werden in der GuI des Programms prominent angezeigt. Eine Überwachung des Eventlog ist eine wichtige Komponenten im aktiven Management von Servern. Idealerweise werden Events möglichst umgehend an eine zentrale Stelle gemeldet, dies diese dann auswertet und weiter verarbeitet. So werden auch Vorgänge auf mehreren Servern einfacher als zusammenhängende Problematik erkannt. Natürlich kostet so ein System Geld in der Anschaffung und Aufwand beim Betrieb und Optimierung.
  • HTTP nach extern bzw. "Traffic Analyse"
    Der Direct Access-Server ist natürlich ein System mit einem Bein im Internet und auch das "Default Gateway" verweist in die große weite Welt. Damit ist es für Prozesse auf diesem Server aber auch für Direct Access-Clients viel einfacher das Internet von diesem System aus zu erreichen, als den Weg zu gehen, den alle anderen internen Clients gehen. Wenn der Direct Acess Server nicht selbst ins Internet gehen darf, dann könnte man ausgehende Pakete in diese Richtung auf einer Firewall blocken. Aber auch mit so einem Schutz kann es durchaus interessant sein, z.B. mit NetFlow und anderen Techniken die Datenströme eines Servers zu überwachen und stark wachsende oder ungewöhnliche Verbindungen zu erkennen. Ein HTTP-Download eines Trojaners könnte so an einer Proxy Authentifizierung scheitern oder könnte dort auffallen. Viel interessanter wäre es aber über so eine Überwachung ungewöhnliche oder untypische Verbindungen zu erkennen, z.B.: wenn das System wirklich "missbraucht" würde.

Diese Liste ist sicher unvollständig aber ein erster Ansatzpunkt die Sensoren zu schärfen und immer besser zu werden.

Weitere Links