Apples SSL Bug: Ein weiterer Man-in-the-Middle-Angriff

Das Problem

Vielleicht haben Sie schon gehört, dass vor kurzem eine schwerwiegende Schwachstelle in Apples Implementierung von SSL entdeckt wurde. Apple hat nicht viele Details genannt, aber Sicherheitsforscher, die mit dem Problem vertraut sind, haben erklärt, dass der Fehler die Möglichkeit eines Man-in-the-Middle-Angriffs (MITM) eröffnet. Das bedeutet, dass nicht gepatchte Systeme Passwörter, Kreditkartennummern oder andere sensible Informationen ausspucken können, ohne dass der Benutzer weiß, dass seine Verbindung unsicher ist. Zum Zeitpunkt der Erstellung dieses Artikels ist ein Patch für iOS 7 verfügbar, aber nicht für Mac OS X-Rechner.

Man-in-the-Middle-Angriffe auf SSL sind keineswegs neu; tatsächlich habe ich vor neun Jahren auf der RSA-Konferenz 2005 einen Vortrag über einen Malware-gestützten Man-in-the-Middle-Angriff gehalten, den einer unserer Kunden entdeckt hatte, über unsere Analyse der Funktionsweise und darüber, was man tun kann, um ihn zu verhindern.

A Fix

From the limited amount of information that’s been provided so far, it sounds like there’s not much that iOS and Mac users can do about this until a patch is released and installed. But can organizations maintain some assurance that the users communicating with them are not MITM victims? In many cases, the answer may be “yes,” with the help of client-side SSL certificates.

Um zu sehen, wie es funktioniert, schauen wir uns zunächst an, wie ein Man-in-the-Middle-Angriff funktioniert. In den meisten Fällen, in denen SSL verwendet wird, ist nur ein Zertifikat auf dem Server erforderlich, wie unten dargestellt:

To be successful, the man in the middle must be able to convince the client that it’s talking directly to their intended endpoint. This is supposed to be impossible, if SSL is implemented properly (which appears to have been Apple’s problem), and appropriate trust anchors are maintained (which is sometimes easier said than done). If either of these aren’t upheld, man-in-the-middle attacks become possible.

But in mutual, or client-side SSL, the server requires that the client provide an authentication certificate as well. In this case, the server gains a level of assurance that it’s talking directly to the client:

Now the attackers’ task becomes at least twice as difficult, as they must convince both ends of the connection that they are communicating directly with each other, rather than just one.

Obviously, this specific problem with Apple iOS and Mac OS X will eventually be patched and go away. But it will almost certainly not be the last time we hear about a possible man-in-the-middle attack, and client-side certificates can help defend against MITM attacks the next time they come up as well. It’s worth noting, for example, that the server’s demand for a client certificate prevents the attack, even if the client’s machine is still unpatched and otherwise susceptible.

Schutz des privaten Schlüssels

Bei jeder digitalen Zertifikatsimplementierung dreht sich alles um die privaten Schlüssel; wenn unser Mann in der Mitte im obigen Diagramm Zugriff auf den privaten Schlüssel des Kunden erhält, ist er wieder im Geschäft. Technologien wie On-Device Key Generation (ODKG) können dabei helfen, da sie die Orte einschränken, an denen private Schlüssel erfasst oder offengelegt werden können. Wenn Schlüssel außerhalb des Geräts generiert werden, was in mobilen oder BYOD-Szenarien häufig der Fall ist, sind sie überall dort gefährdet, wo sie erstellt, übertragen, gespeichert oder archiviert werden. Aus diesem Grund legt CSS so viel Wert auf die Aktivierung von ODKG in Szenarien, in denen dies sonst nur schwer möglich ist - einschließlich iOS- und Mac-Geräte.