Zum massenhaften Hack der Exchange Server gibt es derzeit mehr Fragen als Antworten und welche Konsequenzen daraus in der Zukunft entstehen sind zum jetzigen Zeitpunkt nicht wirklich seriös zu beantworten. Trotzdem ist es gerade jetzt wichtig sich so gut wie möglich auf das was kommen könnte vorzubereiten, denn das war mit Sicherheit noch nicht alles. Daher ist nun keinesfalls die Zeit des Abwartens, sondern die Zeit die Initiative zu ergreifen und zu handeln.
Der Angriffsvektor über die öffentlich erreichbaren Exchange Dienste ist mit mehr als nur einem PoC oder theoretischen Szenario. Diese Form der Angriffe sind seit Monaten allen bekannt und es finden massenhaft Angriffe statt bzw. haben erfolgreich stattgefunden und es ist nur eine Frage der Zeit, bis weitere Cyber Angriffe auf diesem Wissen aufbauen und weitere Varianten folgen werden. Ein gutes Beispiel dafür ist Spectre und Meltdown, nach dem das Prinzip einmal bekannt war, gab es immer weitere Versionen dieses Angriffs und dessen Auswirkungen wir alle bis heute zu spüren bekommen. Erst kürzlich gab es wieder einen Patch, um sich vor einer neuen Variante zu schützen. Das Desaster, welches wir alle mit den CPU’s immer noch erleben, kommt nun Form einer von sehr vielen Unternehmen benutzer Software daher, die den Standard in der Unternehmenskommunikation darstellt. Es ist müßig darüber zu diskutieren, ob es nicht besser OpenSource oder eine andere Alternative statt Exchange von Microsoft sei. Ist eine Software verbreitet genug, hat es genau diesen Effekt. Beispiele gibt es hier genug, aus der OpenSource Welt oder auch von kommerzieller Software. Vielleicht ist der Umgang mit Sicherheitslücken und Patches bei OpenSource der Bessere, was aber auch nichts nützt, wenn die zur Verfügung stehenden Patches nicht installiert werden. Aber auch der Hersteller hat Fehler gemacht und das nicht zu knapp.
Microsoft hat die Lage und die Dynamik des Angriffs falsch eingeschätzt, dazu kommt noch das etwas merkwürdige Szenario der Updates, die immer nur auf dem neusten CU fußen. In dieser Kombination ist es eine sehr unglückliche Verkettung von Fehlern, die gemacht wurden, um es mal vorsichtig auszudrücken. Aber nun ist die Situation mal so wie ist und daran ist rückwirkend nichts zu ändern. Daher muss man sich jetzt auf das konzentrieren, was man noch beeinflussen kann und dazu gehört mit Sicherheit nicht die Vergangenheit. Was also ist der (aktuelle) Stand der Dinge?!
Der Geist des Angriffsvektors ist da und den bekommt man nicht mehr zurück in die Flasche. Analog gilt das auch für die Exchange Server in den Unternehmen, diese löst man auch nicht mal eben so ab und schafft eine andere Lösung. Wobei ja auch hier keiner weiß, ob diese wirklich besser bzw. sicherer sind. Dass grundsätzlich die Kommunikation per E-Mail kaputt ist, steht außer Frage nur das ist aber nicht das Thema. Das Thema ist vielmehr, was ist zu tun, um die IT-Infrastruktur besser auf das was noch kommen wird vorzubereiten.
Es braucht einen besseren Schutz der so exponierten Dienste wie dem OWA. Hier ist nicht nur Microsoft gefordert, sondern auch jeder, der einen Exchange Dienst betreibt. Der Zugriff nur per VPN auf den Dienst ist keine Lösung. Zum einen ist VPN eine Legacy Technologie, die nicht mehr wirklich zu den Anforderungen hybrider Clouds und moderner Services passt und wer sagt denn, dass der VPN Service sicher ist?! Im Falle eines SSLVPN steht dieser ja auch exponiert auf Basis von https im Internet. Beispiele für anfällige (SSL) VPN Dienste gibt es auch in mehr als ausreichende Anzahl. Es verbessert ja die Gesamtsituation nicht, wenn man einen öffentlich zu erreichenden Dienst gegen einen anderen tauscht. Das Szenario ist immer noch das gleiche. Die grundsätzliche Frage ist doch die des Schutzes für den extern zu erreichenden Service, die sich hier stellt.
Viele Hersteller im Bereich der Security haben ihre Produkte bzw. ihre IPS- und WAF-Muster angepasst, um diese Angriffe auf den Exchange Dienst zu erkennen. Das bedeutet aber auch, dass der Datenstrom zwischen Client und OWA aufgebrochen werden muss. Hierbei ist es wichtig, dies auf jeden Fall so umzusetzen, dass man nicht eine weitere Schwachstelle öffnet. In letzter Konsequenz ist dies ja ein „man in the middle“ Szenario, was aufgebaut werden muss. Es gibt verschiedene Beispiele, wie man dies entsprechend sicher umsetzen kann und welche Produkte sinnvoll eingesetzt werden können. Auch muss das Patch-Management auf den Prüfstand, unabhängig davon, dass Microsoft an der ganzen Situation um den Exchangen Hack einen großen Anteil trägt. Das Patch-Management muss ganz weit nach oben auf der Maßnahmenliste und bei großen Umgebungen muss dieses auch entsprechend automatisiert werden, bzw. müssen die Administratoren mit entsprechenden Tools passend unterstützen werden. Zu einem Patch-Management gehört aber auch eine regelmäßige Verwundbarkeitsanalyse, es braucht eine Kontrolle, ob auch alle zur Verfügung stehenden Updates installiert sind. Ziel muss es sein, dass man es jedem Angreifer so schwer wie möglich macht in die Systeme einzudringen und wenn er es an einer Stelle geschafft hat, ihm es dann nicht leichter macht, weil weitere Patches fehlen, deren Lücken er dann ausnutzen kann. Eine weitere Überlegung, die es anzustellen gilt, ist es darüber nachzudenken, wie die eigenen Server noch besser abzuschotten sind. Dieser Fall hat wiederholt gezeigt, dass die Angreifer Code aus dem Internet, in diesem Fall von Github, nachgeladen haben. Es ist auch eine RemoteShell zum Einsatz gekommen, welche ebenfalls Ziele im Internet kontaktiert hat und über die dann auf die internen Server remote zugegriffen wurde. Die Server jetzt grundsätzlich vom Internet abzuschotten ist auch keine Lösung, es braucht aber eine Lösung wie man dies zukünftige besser, im Sinne von besser kontrollierbar umsetzen kann. Es sollten Überlegungen angestellt werden, wie die Zugriffe der Server auf das Internet entkoppelt und somit strenger kontrolliert werden können. Bei der Vielzahl der Verbindungen ist dies nicht so trivial, wie es sich vielleicht anhört. Aber nur, weil etwas nicht einfach ist, es dann nicht anzugehen hilft ja auch nicht.
Der Vorfall hat ein weiteres Thema zu Tage gefördert, was die Aufklärung und auch die Analyse was genau passiert ist und ob es zu Datenabflüssen kam sehr schwierig gemacht hat. Es gab in vielen Fällen keine ausreichenden forensischen Daten bzw. Logfiles, um diese Auswertungen durchzuführen. Daher gehört das Thema zentrales protokollieren von Ereignissen mit auf den Prüfstand. Hier gehört aber nicht nur die vorhandenen Datenquellen mit einzubeziehen dazu, sondern auch zu überlegen welche weiteren Datenquellen zu schaffen sind, um zukünftig verlässliche Aussagen darüber treffen zu können. Themen wie Aufbewahrungsfristen, Auswertbarkeit, Authentizität oder Archivierung sind ebenfalls von zentraler Bedeutung. Auch hier ist es wichtig, diese Daten so zu speichern, dass ein Angreifer diese nicht manipulieren oder gar löschen kann.
So banal wie es klingt spielt das Thema Backup zur Vorbereitung auf das was noch kommt eine sehr wichtige Rolle. Es ist davon auszugehen, dass in letzter Konsequenz ein Angriff nicht zu verhindern ist. In diesem Fall bleibt nur das Backup! Daher sollte auch das eigene Backup-Konzept auf den Prüfstand und dahingehend überprüft werden, ob es so konzipiert ist, dass es nicht durch die Angreifer manipuliert werden kann. Dazu gehören Dinge wie die Abschottung des Backups und vor allem dessen Repositories. In die Überlegungen sollte ein offline oder ein externes Backup miteinfließen, an das die Angreifer nicht rankommen.
In diesem Beitrag geht es um den notwendigen Handlungsbedarf und nicht darum Panik zu verbreiten. Es geht darum die richtigen Fragen zu stellen, den Blick für möglich Gefahren zu schärfen und darum die Dinge anzugehen, um sich auf Basis der aktuellen Erkenntnisse besser vor aktuellen und vielleicht auch zukünftigen Cyber Angriffen zu schützen. Aber keine Konsequenzen aus dem Vorfall zu ziehen ist mit Sicherheit falsch.