Best Practices: Wie Sie sich gegen Man-in-the-Middle-Angriffe (MitM) verteidigen

Nehmen wir an, eine Firma hat eine eigene Zertifizierungsstelle (CA – Certification Authority) und nur Anwender-Zertifikate. Sie gibt außerdem einmalige Passwörter (OPT – One-Time Password) mit einer kurzen Lebensdauer aus. Ist in dann die Gefahr eines Man-in-the-Middle-Angriffs gering? Ist in diesem Fall generell ein Risiko zu befürchten?

Um für mehr Klarheit zu sorgen, gehe ich auf Ihr Szenario etwas detaillierter ein. Danach beantworte ich die Frage, ob dies die Gefahr eines Man-in-the-Middle-Angriffs (MitM) minimiert. Die beschriebene Firma verwendet eine eigene Zertifizierungsstelle, möglicherweise Microsoft Certificate Services. Sie gibt Zertifikate an ihre Mitarbeiter aus, die diese als Teil des Authentifizierungs-Prozesses benötigen, um auf Ressourcen im Netzwerk zugreifen zu können. Um den Prozess noch etwas sicherer und persönlicher zu machen, müssen die Anwender ein einmaliges Passwort (OTP) eingeben. Das wird möglicherweise von einem Dongle generiert und ist nach kurzer Zeit ungültig.

Leider können MitM-Angriffe diesen Security-Kontrollmechanismus leicht umgehen. Bei einem Man-in-the-Middle-Angriff setzt sich der Cyberkriminelle zwischen Client und Server und gibt sich während der Kommunikation mit dem Server als Client und umgekehrt aus. Somit kann der Angreifer sämtliche Login-Daten an den Server in Echtzeit weitergeben. Das gilt auch für das OTP-Passwort. Nun ist der Schutzmechanismus ausgehebelt, den das sich ständig ändernde Passwort bietet. Benutzen Sie aber für dieses spezielle Szenario eine Technologie mit öffentlichem und privatem Schlüssel, sind Sie gegen MitM-Angriffe geschützt.

Verwenden Sie wechselseitige Client-Server-Authentifizierung, schicken sich die beiden Parteien Zertifikate. In diesem Fall können sich sowohl Client als auch Server sicher sein, mit wem sie kommunizieren. Der Cyberkriminelle könnte nun nur einen vollwertigen MitM-Angriff durchführen, wenn er sich für beide Seiten ausgibt. Er müsste ein gefälschtes Zertifikat sowohl auf dem Client als auch auf dem Server einschleusen. Dann würden beide Seiten einem Zertifikat vertrauen, das sich unter der Kontrolle des Cyberkriminellen befindet. Ein Client-Zertifikat würde einen Anwender nicht gegen einen einseitigen Identitätswechsel schützen. Sie verbinden sich möglicherweise zu einem gefälschten Server und der Angreifer ignoriert das Zertifikat des Clients einfach.

MitM-Angriffe gegen SSL-Kommunikation sind realistisch gesehen nur in diesen Fällen möglich:

• Der Schlüssel des Servers wurde gestohlen.
• Ein gefälschter Server-Schlüssel wurde von einer kompromittierten Zertifizierungsstelle erstellt.
• Der Client überprüft das Zertifikat nicht ausreichend und vergleicht es nicht mit seiner Liste der vertrauenswürdigen CAs.
• Der Client wurde angegriffen und der Angreifer hat ein falsches Zertifikat in die vertrauenswürdige Stammzertifizierungsstelle eingeschleust.

In den letzten Jahren kam es immer wieder zu erfolgreichen Angriffen auf Zertifizierungsstellen. Somit konnten sich Cyberkriminelle als Hochkaräter des Webs oder prominente Websites ausgeben. Wollen Unternehmen diese ausgefeilten, aber nicht unmöglichen und sehr gefährlichen Arten von Angriffen vermeiden, müssen Sie die Zertifizierungsstellen so sicher wie möglich halten. Auch ein physischer Zugriff sollte so limitiert wie möglich sein.

Anwender müssen den Zugriff auf Ihre Zertifikate mit einem Passwort oder einer PIN schützen. Weiterhin sollte man sie schulen, wie Sie die Echtheit eines Server-Zertifikats prüfen. Jegliche Warnung des Systems oder eines Browsers sollte sofort die Alarm-Glocken der Anwender läuten lassen und diese zum Stoppen bewegen. Die größte Bedrohung für Client-seitige Zertifikate ist Phishing. Cyberkriminelle wollen an das Zertifikat und den privaten Schlüssel des Clients kommen. Sollte ein Angreifer erfolgreich sein, kann er sich als der Client ausgeben. Hat ein Unternehmen eine OTP-Technologie im Einsatz, müsste der Cyberkriminelle auch das physische Gerät stehlen, das das einmalige Passwort erzeugt. Da sich der Angreifer somit in der physischen Nähe des Opfers aufhalten müsste, macht das die Sachlage wesentlich komplexer.

Leider gibt es wie immer in der IT keine garantierte Sicherheit. Allerdings bedeutet das eine ziemlich harte Arbeit für den Angreifer, wenn er die Verteidigungsschichten im oben genannten Szenario knacken will. Halten Sie diese Verteidigungslinie aufrecht und schulen die Anwender entsprechend, sind die Chancen eines MitM-Angriffs eher gering. Lassen Sie das einmalige Passwort dann noch mithilfe eines Gerätes generieren, das nicht mit dem Server verbunden ist, haben Sie Ihrer Security-Strategie eine weitere Schutzmaßnahme hinzugefügt.

Hinweis aufgrund des Heartbleed-Lücke in OpenSSL: Wenn Sie davon betroffen sind, sollten Administratoren bei der Behebung des Heartbleed-Bugs in OpenSSL vorsichtig sein. Ein einfacher Renewal des bestehenden Zertifikats reicht nicht aus, so PSW GROUP-Geschäftsführer Christian Heutger. „Stattdessen sollte das alte Zertifikat gegen ein komplett neu erstelltes ausgetauscht werden". Beim Renewal-Prozess wird zwar ein neues Zertifikat generiert, aber dieses weist noch den alten privaten Schlüssel auf.