Microsoft Exchange- und Verkada-Hacks: Isolieren Sie Ihre Apps und APIs vom Schmutz des öffentlichen Internets
Der März begann mit mehreren Zero-Day-Exploits, die für den Angriff auf On-Premises-Versionen von Microsoft Exchange Server verwendet wurden. Und als ob das nicht genug wäre, folgte auf diesen Angriff schnell die Nachricht, dass ein Hacktivisten-Kollektiv, das sich selbst APT-69420 nennt, die internen Systeme des Silicon Valley-Sicherheitsunternehmens Verkada geknackt hatte – ein Vorfall, der weitreichende Aufmerksamkeit erregte, da das Kollektiv behauptete, Zugriff auf Live-Videofeeds von mehr als 150.000 Überwachungskameras erhalten zu haben.
Ich glaube, diese beiden Vorfälle – und die Reaktionen der betroffenen Unternehmen – haben uns vor Augen geführt, worüber wir als Branche schon eine Weile sprechen: Die klassische Netzwerkverteidigung mit abgeschirmten Systemen und der Unterscheidung zwischen innen und außen ist einfach nicht mehr zeitgemäß. Diese jüngsten Sicherheitsverstöße belegen, dass der Wechsel zu einem Zero-Trust-Sicherheitsmodell mit einem Cloud-First-Ansatz für die Mehrheit von uns die Zukunft der Sicherheit ist.
Warum? Es ist ganz einfach. Sehen wir uns zunächst die RCE-Schwachstelle (Remote Code Execution) in Exchange an.
Der Exchange-Vorfall
Microsoft empfahl Kunden dringend, On-Premises-Systeme sofort zu patchen. Doch wie wir alle wissen, ist das Patching von Systemen nicht immer so einfach oder schnell, wie es klingt, insbesondere für IT-Teams, die im Allgemeinen überlastet und unterbesetzt sind. Wie man erwarten würde, nutzen weiterhin mehrere Akteure ungepatchte Systeme, um Unternehmen mit anfälligen On-Premises-Exchange-Servern anzugreifen.
Bei Akamai führte unser Threat Research Team Signaturen für unsere Web Application Firewall (WAF) ein, die potenziell schädliche Payloads verhindern können, die auf anfällige Microsoft Exchange-Server abzielen. Mit anderen Worten: Die WAF von Akamai kann die schädliche Payload blockieren, die für ein potenziell ungepatchtes System bestimmt ist. Dies ersetzt zwar nicht langfristig das Patching, kann jedoch IT-Teams wertvolle Zeit verschaffen.
Wenn Sie mehr über die WAF-bezogenen Zero-Day-Abwehrmaßnahmen für Microsoft Exchange-Server erfahren möchten, lesen Sie So kann Akamai Sie im Kampf gegen die neuesten Exploits für Microsoft Exchange unterstützen.
Diese Vorfälle werfen auch die Frage auf: Was darf mit dem öffentlichen Internet in Kontakt kommen und was nicht? Diese Frage bringt mich zurück zu einem Gartner-Bericht aus dem Jahr 2016 mit dem passenden Titel „It’s Time to Isolate Your Services From the Internet Cesspool“, der einen Leitfaden zu diesem Thema bietet. Die Antwort ist klar: Verbinden Sie nur das mit dem Internet, was Sie unbedingt verbinden müssen, und stellen Sie für diese Services sicher, dass die entsprechenden Sicherheitskontrollen vorhanden sind.
Das bringt mich zu der zweiten wichtigen Nachricht: dem Verkada-Hack.
Der Verkada-Hack
Wie bei den meisten Angriffen gibt es immer noch viele offene Fragen und Mutmaßungen. Doch was sich herauskristallisiert, deutet darauf hin, dass die Offenlegung eines Jenkins-Servers im öffentlichen Internet ziemlich riskant ist. In Kombination mit den wohlverstandenen Taktiken, Techniken und Verfahren, die die meisten Bedrohungsakteure einsetzen – um Systemzugriff zu erhalten und um diesen Zugriff für Angriffe auf andere Ressourcen im Netzwerk zu nutzen –, ergibt sich eine Mischung, die sogar noch mehr Risiken bedeutet.
In beiden Fällen kann die Einschränkung des Zugriffs auf einen anfälligen Exchange- oder Jenkins-Server über eine intelligente Zugriffskontrolle dazu führen, dass Bedrohungsakteure Ressourcen nicht direkt erreichen können. Ich mag ZTNA-Ansätze (Zero Trust Network Access), die einschränken, wer schädliche Payloads an die anfälligen Systeme senden kann. Sie beseitigen natürlich nicht die Schwachstelle, doch die Einschränkung des Zugriffs auf einen potenziell anfälligen Server über ZTNA kann verhindern, dass böswillige Akteure direkt darauf zugreifen.
Wenn externe Akteure ein anfälliges System nicht direkt erreichen können, müssen sie ihre Bemühungen umlenken, indem sie einen tatsächlichen Endnutzer imitieren – eine zunehmend schwierige Aufgabe durch die Verwendung kontextbezogener, adaptiver und identitätsbezogener Zugriffskontrollen, wie z. B. ZTNA, verstärkt mit FIDO2-konformer Multi-Faktor-Authentifizierung (MFA). Kombinieren Sie diese Zugriffskontrollen mit einer Inline-WAF und es ergibt sich ein positives Bild. Kontrollieren Sie, wer Zugriff hat, und untersuchen Sie den Trafficfluss auf schädliche Inhalte – selbst für Nutzer, die Kontrolle haben.
Die Lösung
Fazit: Beide Vorfälle heben die Notwendigkeit eines Wechsels zu einem Zero-Trust-Sicherheitsmodellhervor. Es ist an der Zeit, Apps und APIs effektiv vom Internet zu isolieren.
Wenn Sie mehr erfahren möchten, sehen Sie sich die Lösungen Akamai Secure Access Service Edge und Enterprise Defender an, die ZTNA, Secure Web Gateway, Web Application Firewall und Anwendungsbeschleunigung in einem einfach zu nutzenden Sicherheitsservice an der Akamai-Edge kombinieren.
