In den letzten Tagen wurden zwei Zero-Day-Schwachstellen für Microsoft Exchange Server vor Ort bekannt und angegriffen. Die gute Nachricht ist, dass Exchange-Cloud-Benutzer, wie z. B. Microsoft 365-Kunden, sich keine Sorgen machen müssen, da diese Schwachstellen nur gegen lokale Versionen gerichtet sind.
Während Microsoft an der vollständigen Antwort arbeitet, bietet Microsoft einige frühe Reparaturen an, darunter nur Administratoren den Remotezugriff auf PowerShell zu erlauben und eine URL-Rewrite-Blockregel auf dem Exchange-Server zu erstellen.
LoadMaster-Load-Balancer helfen bei beiden Konten. An der URL-Rewrite-Front arbeitet LoadMaster schnell und einfach. Wie genau, werde ich später im Blog beschreiben.
Diese Exploits beruhen auch darauf, dass Hacker authentifizierten Zugriff auf Exchange-Server erhalten, was mit einer starken und einfach zu verwaltenden Zwei-Faktor- oder Multi-Faktor-Authentifizierung vereitelt werden kann. Auch dazu gleich mehr.
Es überrascht nicht, dass Microsoft dringend empfiehlt, von Exchange vor Ort in die Cloud zu wechseln, obwohl dies keine rechtzeitige Lösung für die neuen Zero-Day-Exploits ist.
Jetzt möchte ich in die Details der Exploits eintauchen.
"Microsoft ist bekannt, dass zwei gemeldete Zero-Day-Schwachstellen verwendet wurden, die Microsoft Exchange Server 2013, Exchange Server 2016 und Exchange Server 2019 betreffen. Die erste, die als CVE-2022-41040 identifiziert wurde, ist eine serverseitige SSRF-Schwachstelle (Request Forgery), während die zweite, die als CVE-2022-41082 identifiziert wurde, Remotecodeausführung (RCE) ermöglicht, wenn der Angreifer auf Exchange PowerShell zugreifen kann. Weitere Informationen finden Sie im Microsoft Security Response Center-Blog. CVE-2022-41040 kann es einem authentifizierten Angreifer ermöglichen, CVE-2022-41082 aus der Ferne auszulösen. Ein authentifizierter Zugriff auf den anfälligen Exchange Server ist jedoch erforderlich, um beide Sicherheitsanfälligkeiten erfolgreich auszunutzen, und sie können separat verwendet werden."
Microsoft hat diese Exploits seit August verfolgt und "im August 2022 Aktivitäten im Zusammenhang mit einer einzelnen Aktivitätsgruppe beobachtet, die einen ersten Zugriff erlangte und Exchange-Server kompromittierte, indem sie CVE-2022-41040 und CVE-2022-41082 in einer kleinen Anzahl gezielter Angriffe verkettete", so Microsoft. "Bei diesen Angriffen wurde die Chopper-Webshell installiert, um den Zugriff auf die Tastatur zu erleichtern, die die Angreifer für die Active Directory-Aufklärung und Datenexfiltration verwendeten."
Microsoft ist sich "halbwegs sicher", dass die einzelne Aktivitätsgruppe wahrscheinlich eine staatlich geförderte Organisation ist.
Öffentliche Bekanntgabe erhöht den Anreiz
Exploits nehmen explosionsartig zu, sobald sie öffentlich bekannt werden - und genau das geschah nach dem 28. September, als GTSC in einem Blog über die Sicherheitslücke informierte. "Es ist zu erwarten, dass ähnliche Bedrohungen und die allgemeine Ausnutzung dieser Schwachstellen zunehmen werden, da Sicherheitsforscher und Cyberkriminelle die veröffentlichten Forschungsergebnisse in ihre Toolkits übernehmen und Proof-of-Concept-Codes verfügbar werden", warnte Microsoft.
Patchen und Aktualisieren
Sobald eine Sicherheitslücke bekannt wird, handelt es sich nicht mehr um Zero-Day-Angriffe. Sobald Patches und/oder Updates veröffentlicht werden, um die Lücke zu schließen, nehmen die Angriffe im Allgemeinen zu und werden gefährlicher. Die öffentliche Bekanntgabe und die Patches oder Updates schaffen eine Blaupause für Cyberkriminelle, die die Schwachstellen sofort ausnutzen. Oft werden die Angriffe weitergegeben und sogar als Dienste verkauft, so dass selbst die amateurhaftesten Hacker Netzwerke angreifen können. Deshalb ist es so wichtig, Systeme zu patchen oder zu aktualisieren, sobald Sicherheitslücken behoben sind.
Phishing für Administratoren
Angriffe zur Erhöhung der Rechte ermöglichen es Hackern, sich Zugang zu den tiefsten Bereichen des Netzwerks zu verschaffen. Eine Abkürzung besteht darin, die Administratorkonten selbst zu übernehmen, häufig durch Phishing. So kann ein IT-Administrator beispielsweise eine E-Mail erhalten, in der er aufgefordert wird, seine Anmeldedaten preiszugeben.
In anderen Fällen sind IT-Administratorkonten nur allzu leicht zu knacken, da viel zu wenige Multi-Faktor-Authentifizierungstools (MFA) verwenden. Microsoft befragte die Teilnehmer seiner Ignite-Konferenz und stellte schockierenderweise fest, dass weniger als 2 % aller Office 365-Administratoren weltweit MFA aktiviert haben. Die Ergebnisse einer Umfrage von CoreView waren besser, aber bei weitem nicht so gut - 78 % der Office 365-Administratoren haben MFA nicht aktiviert.
Ja, das klingt ziemlich lächerlich, aber Administratoren haben oft viele, viele Konten, und dieser zusätzliche Anmeldeschritt ist in der Tat ein Ärgernis. Aber ist es so lästig wie ein Hacker, der Privilegien stiehlt und Ihr Unternehmen in Gefahr bringt? Das entscheiden Sie.
Obwohl es sich hierbei um Cloud-Beispiele handelt, kann man davon ausgehen, dass MFA und übermäßige Berechtigungen vor Ort genauso schlecht sind.
Zwei-Faktor-Authentifizierung – nicht ignorieren
Wir sehen, wie Phishing Administratorkonten kompromittieren kann. Dies ist, wenn nicht sogar eine Rechtfertigung für die Zwei-Faktor-Authentifizierung – sei es mit einem Einmalpasswort-Token oder einer SMS. Sie können die Verwendung eines zweistufigen Überprüfungsdiensts in Betracht ziehen, z. B. Microsoft Authenticator. Die Verwendung der Zwei-Faktor-Authentifizierung ist effektiv gegen Bots, da sie nicht in der Lage sind, die sekundäre Herausforderung zu erfüllen. LoadMaster bietet native Unterstützung für alle wichtigen Anbieter von Zwei-Faktor-Authentifizierung, was die Integration vereinfacht. Bei Bedarf können Sie den Zugriff auch weiter sperren, indem Sie die Verwendung von Clientzertifikaten auf Clientgeräten erzwingen.
Implementieren Sie Zero-Trust-Network-Access
Ich habe bereits erwähnt, dass diese Angriffe darauf beruhen, dass Hacker sich Admin-Rechte aneignen. Genau das wollen Zero Trust und Least Privilege Access verhindern.
Zero Trust Network Access (ZTNA) ist ein Ansatz für den Anwendungs- und Ressourcenzugang, der keiner Client-Entität vertraut und den Zugang nur dann gewährt, wenn er explizit durch Richtlinien definiert ist. Zero Trust vertraut niemals implizit und gewährt den Zugriff nur, nachdem sich der Client erfolgreich authentifiziert hat. Der Zugriff auf Ressourcen ist explizit in der Richtlinie festgelegt, wodurch verhindert wird, dass Benutzer über ihren erlaubten Zugriff hinausgehen.
Zero Trust beginnt mit der Berücksichtigung der Identität des Clients und des Kontexts der Zugriffsanforderung, z. B. von welchem Gerät oder Netzwerk ein Benutzer kommt. Es werden Fragen gestellt wie: Stammt es von einem vom Unternehmen verwalteten Gerät? Arbeiten Sie von zu Hause aus? Befinden Sie sich in einem Drittland?
Nach der Authentifizierung werden Clients basierend auf der Richtlinie mit gerade so viel Zugriff autorisiert, dass sie eine Verbindung mit den Ressourcen herstellen können. LoadMaster kann als ZTNA-Gateway mit einfacher Definition von Richtlinien über eine API fungieren, was die Integration mit anderen Sicherheits- und Richtlinien-Toolsets vereinfacht.
Warum Load Balancing eine kritische Netzwerksicherheitsebene ist
LoadMaster kann die Cloud-Sicherheit eines Unternehmens als integrierter Sicherheitsdurchsetzungspunkt erheblich verbessern. LoadMaster erweitert die Sicherheitsdienste der Cloud-Plattform, um einen mehrschichtigen Ansatz für die Anwendungssicherheit und -verfügbarkeit zu bieten. LoadMaster ist auf allen wichtigen Cloud-Plattformen und auch als virtuelle Appliance verfügbar, wenn Sie eine On-Premises-Bereitstellung durchführen möchten.
Verwenden Sie TLS 1.3. Verlassen Sie sich nicht auf SSL
Eine weitere lokale Sicherheitsmaßnahme für Exchange besteht darin, sich nicht mehr auf SSL zu verlassen, das von vielen als veraltetes kryptografisches Sicherheitsprotokoll angesehen wird – zumindest für Exchange – und auf TLS 1.3 umzusteigen. "TLS 1.3 eliminiert veraltete kryptografische Algorithmen, verbessert die Sicherheit gegenüber älteren Versionen und zielt darauf ab, so viel wie möglich vom Handshake zu verschlüsseln", erklärte Microsoft in seinem Exchange Server Roadmap-Update.
Beachten Sie, dass TLS 1.3 diese Exchange-Exploits zwar nicht stoppt, aber insgesamt ein wichtiger Sicherheitsschritt für Exchange-Server darstellt.
Vereinfachen der Problemumgehung für das Umschreiben von URLs
LoadMaster beschleunigt das Umschreiben von URLs. Microsoft bietet zwar Anweisungen in seinem Kundenleitfaden für gemeldete Zero-Day-Sicherheitslücken in Microsoft Exchange Server, aber wir glauben, dass wir einen besseren Weg haben.
Microsoft hat einige Abhilfemaßnahmen bereitgestellt. Dazu gehört das Erstellen einer Blockregel für das Umschreiben von URLs auf dem Exchange-Server über den IIS-Manager im virtuellen AutoErmittlungsverzeichnis, um die spezifische PowerShell-URL-Syntax zu blockieren, die für den Remotezugriff über die AutoErmittlung verwendet wird. Dies kann auch mit LoadMaster erreicht werden. Die Blockregel für das Umschreiben von URLs kann als Inhaltsregel auf dem LoadMaster erstellt und auf den untergeordneten virtuellen AutoErmittlungsdienst angewendet werden. Hier sind einige Schritte, um dies in LoadMaster zu erreichen:
- Navigieren Sie zu Rules & Checking > Content Rules > Create new
- Für die Syntax dieser Inhaltsregel geben Sie bitte Folgendes ein:
- Regeltyp: Content-Matching
- Match-Type: Regular Expression
- Match-Field: Leave Blank
- Match String: /.autodiscover\json “\@Powershell”/
- Überprüfen Sie Folgendes: Groß-/Kleinschreibung ignorieren; Abfrage in URL einschließen; Scheitern bei Übereinstimmung
- Perform IT Flag Set: Unset
- Perform If Flag is NOT Set: Unset
- Set Flag is Matched: None
- Erstellen Sie diese Regel wie in Schritt 2 beschrieben, navigieren Sie dann zu dem Autodiscover Sub Virtual Service innerhalb des Exchange Virtual Service auf LoadMaster und klicken Sie auf Ändern.
- Gehen Sie zu Erweiterte Eigenschaften, dann zu HTTP-Auswahlregeln und klicken Sie auf "Auswahlregeln anzeigen". Fügen Sie hier die Inhaltsregel "Zero Day Block" hinzu, die in Schritt 2 erstellt wurde. Dies wäre das Ergebnis, sobald die Regel erfolgreich hinzugefügt wurde.
