Prüfung zum Registered Information Security Specialist – Herbst 2023 (Reiwa 5), Nachmittag, Aufgabe 2 erklärt – Dateien, die über das Gäste-WLAN entwendet werden

Das Anschließen von USB-Sticks wurde verboten. Auch das Speichern von Dateien auf der lokalen Festplatte wurde untersagt. Der Datenverkehr zu vom Unternehmen nicht freigegebenem Webmail und Cloud-Speicher wurde gesperrt. Das Anhängen von Dateien an E-Mails wurde verboten. Der interne Dateiserver wurde abgeschafft.

Trotzdem lassen sich geschäftliche Dateien noch hinaustragen.

Aufgabe 2 der Nachmittagsprüfung Herbst 2023 (Reiwa 5) zum Registered Information Security Specialist spielt bei Bekleidungsunternehmen M, das all diese Maßnahmen bereits umgesetzt hat, und lässt die Prüflinge die verbliebenen Lücken aufdecken¹. Dieser Artikel ist der zweite Teil einer Serie, die an die Erklärung zu Aufgabe 1 (Stored XSS) anschließt, und der behandelte Bereich verschiebt sich dabei von der Webanwendung hin zu dem internen Netzwerk und der Geräteauthentifizierung.

Während Aufgabe 1 fragte, „wo die vor der Webanwendung aufgereihten Maßnahmen durchbrochen wurden“, fragt Aufgabe 2, „welchen Geltungsbereich der Entwurf der Maßnahmen eigentlich schützen sollte“. Keine der Maßnahmen von Unternehmen M ist falsch. Prüft man aber die Grenze, die jede einzelne abdecken sollte, Stück für Stück, ist genau daneben eine Lücke offen.

Was Sie aus diesem Artikel mitnehmen, sind neben Musterlösungen und deren Begründung für jede Teilaufgabe praxistaugliche Prüfpunkte zu drei Bereichen: WLAN, Serverzertifikate und Beschränkungen auf die Quell-IP-Adresse. Er ist so geschrieben, dass Leserinnen und Leser, die für die Prüfung lernen, die Abschnitte nach Teilaufgabe lesen können, während wer nur die praktische Perspektive braucht, direkt bei Kapitel 11 und 12 einsteigen kann.

1. Zunächst das Ergebnis

• Das Schlupfloch war der Besprechungsraum. Unternehmen M verbot das Mitbringen privater PCs, aber dieses Verbot galt nur für den Büroraum – der Besprechungsraum war ausgenommen. Im Besprechungsraum sind sowohl das Mitarbeiter-WLAN als auch das Gäste-WLAN verfügbar
• Für Mitarbeitende gibt es zwei Wege des Datenabflusses. Die Methode, die MAC-Adresse zu fälschen und sich mit dem Mitarbeiter-WLAN zu verbinden, und die Methode, sich einfach mit dem Gäste-WLAN zu verbinden. Letztere ist deutlich einfacher – nötig ist nur der an Gäste ausgegebene Pre-Shared Key
• Der Cloud-Speicher (Dienst B) war auf „Anmeldung nur von der globalen IP-Adresse von Unternehmen M aus“ beschränkt. Doch auch der Datenverkehr des Gäste-WLANs wird durch dieselbe NAT auf dieselbe globale IP-Adresse umgesetzt, wodurch diese Beschränkung glatt umgangen wird. Eine Beschränkung auf die Quell-IP-Adresse erlaubt nicht das Gerät, sondern alle, die sich einen Ausgang teilen
• Ein gefälschter AP samt gefälschter Website eines externen Angreifers scheitert an der Prüfung des Serverzertifikats. Wirksam sind dabei zwei Punkte: „wurde es von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt“ und „stimmt der Servername im Zertifikat mit dem Verbindungsziel überein“. Laut IPAs Auswertungskommentar war die Erfolgsquote bei der Teilaufgabe zu genau diesen zwei Punkten gering
• Selbst ein versehentlich eingegebenes http:// führt trotzdem zu einem Zertifikatsfehler, weil HSTS vor der Verbindung auf HTTPS umschaltet. Und bei einem Host, für den HSTS aktiv ist, darf dem Benutzer keine Möglichkeit angeboten werden, die Warnung zu ignorieren und fortzufahren
• Auch die reguläre Dateifreigabefunktion wird zu einem Weg des Datenabflusses. Es genügt, als externe Empfängeradresse die eigene private E-Mail-Adresse anzugeben. Eine Freigabe durch Vorgesetzte war zwar vorgesehen, doch manche Vorgesetzte prüften den Empfänger nicht
• Die Gegenmaßnahmen ruhen auf drei Säulen. Das Mitarbeiter-WLAN wird auf EAP-TLS mit einem Client-Zertifikat pro Gerät umgestellt, und der private Schlüssel wird im TPM abgelegt, sodass er den Geschäfts-PC nicht verlassen kann. Das Gäste-WLAN wird vom Netzwerk von Unternehmen M getrennt (oder erhält eine eigene globale Ausgangs-IP-Adresse). Und nicht mehr benötigte VLANs, Filterregeln und SSIDs werden gelöscht

2. Zum Quellmaterial – Herkunft und Umgang in diesem Artikel

Behandelt wird die folgende Aufgabe.

Quelle: Prüfung zum Registered Information Security Specialist, Herbst 2023 (Reiwa 5), Nachmittagssitzung, Aufgabe 2

IPA erklärt, dass für die Nutzung ihrer veröffentlichten früheren Prüfungsaufgaben, sofern gesetzlich nichts anderes bestimmt ist, weder eine Genehmigung noch eine Nutzungsgebühr erforderlich ist. Das bedeutet aber nicht, dass auf das Urheberrecht verzichtet wird: Die Quelle muss in der Form „Geschäftsjahr, Prüfungstermin, Prüfungskategorie, Zeitabschnitt, Aufgabennummer usw.“ angegeben werden, und falls eine Aufgabe verändert wurde, muss auch dies vermerkt werden².

Dieser Artikel gibt die Abbildungen und Tabellen aus dem Aufgabenheft nicht wortgetreu wieder. Wo eine Grafik zur Erklärung eines Mechanismus nötig ist, wurde sie durch eine von uns erstellte vereinfachte Darstellung mit Zusammenfassung ersetzt. Auch der Wortlaut der Teilaufgaben und der Musterlösungen wird zusammengefasst. Das Original-Aufgabenheft, die Musterlösungen und der Auswertungskommentar lassen sich kostenlos von der IPA-Website herunterladen; wir empfehlen, sie beim Lesen griffbereit zu haben^{1 3 4}.

Zuordnung der Teilaufgaben zu diesem Artikel

Sie können gern direkt bei der Teilaufgabe einsteigen, die Sie interessiert.

Umgang mit dem Text des Aufgabenhefts in diesem Artikel

Damit sich das Original mitverfolgen lässt, hier eine Übersicht, was womit geschehen ist.

3. Der Schauplatz – was Unternehmen M „bereits getan hatte“

Unternehmen M ist eine Tochtergesellschaft von Unternehmen L, tätig im Bekleidungsgeschäft, mit 100 Mitarbeitenden. Das Bürogebäude liegt an einer belebten Hauptstraße im Zentrum Tokios. Dieser eine Satz wird später noch wichtig.

Im Vorjahr hatte ein Mitarbeiter von Unternehmen M eine auf dem internen Dateiserver gespeicherte vertrauliche Produktdesigndatei auf einen USB-Stick kopiert und zu einem Konkurrenten mitgenommen. Auf Anweisung der Muttergesellschaft L läuft seitdem eine Überarbeitung der Sicherheitsmaßnahmen. Bereits umgesetzt sind diese drei Änderungen:

• Auf den an Mitarbeitende ausgegebenen Notebooks (im Folgenden „Geschäfts-PC“) wurde eine Software zum Schutz vor Informationslecks installiert und so konfiguriert, dass: der Anschluss externer Speichermedien wie USB-Sticks gesperrt ist; das Speichern von Dateien auf der lokalen Festplatte außer bei der Softwareinstallation verboten ist; der Datenverkehr zu vom Unternehmen nicht freigegebenem Webmail und Cloud-Speicher blockiert wird; die Installation nicht freigegebener Software verboten ist; und das Anhängen von Dateien beim Versenden von E-Mails verboten ist
• Der Speicherort für geschäftliche Dateien wurde auf den bereits genutzten Cloud-Speicher (im Folgenden „Dienst B“) konzentriert, dessen Einstellungen überarbeitet wurden
• Der interne Dateiserver wurde abgeschafft

Der vorherige Vorfall folgte dem Weg „interner Dateiserver → USB-Stick“, sodass beide Enden dieses Wegs verschlossen wurden. Die Logik ist schlüssig.

Netzwerkaufbau

Das Bürogebäude hat einen Büroraum und einen Besprechungsraum. Im Büroraum lässt sich das Mitarbeiter-WLAN nutzen, im Besprechungsraum sowohl das Mitarbeiter- als auch das Gäste-WLAN. Der Beamer im Besprechungsraum wird genutzt, indem entweder ein von Gästen mitgebrachtes Gerät (PC, Tablet oder Smartphone) oder ein Geschäfts-PC mit dem Gäste-WLAN verbunden wird.

Beschränkt auf das für die Erklärung Nötige, sieht das grafisch so aus:

flowchart LR
    subgraph M["Internes Netzwerk von Unternehmen M"]
        direction TB
        G["Gäste-WLAN<br/>192.168.10.0/24<br/>(nur der AP im Besprechungsraum)"]
        E["Mitarbeiter-WLAN<br/>192.168.20.0/24<br/>(Büroraum und Besprechungsraum)"]
        S["Servernetzwerk<br/>192.168.30.0/24<br/>DHCP, DNS, Verzeichnisdienst"]
        FW["FW<br/>NAT setzt die Quelle auf<br/>eine gemeinsame globale<br/>IP-Adresse um"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Dienst B<br/>(Cloud-Speicher)"]
    FW --> I["Internet"]

Die für die Teilaufgaben relevanten Spezifikationen sind diese:

Und es gibt drei Sicherheitsregeln: Das Mitnehmen von Geschäfts-PCs außer Haus ist verboten, das Mitbringen privater PCs, Tablets und Smartphones in den Büroraum ist verboten, das Hinausbringen geschäftlicher Dateien außer Haus ist ausschließlich über die Dateifreigabefunktion von Dienst B erlaubt, jeder andere Weg ist verboten.

Ist Ihnen aufgefallen, dass in der zweiten Regel „in den Büroraum“ steht? Vom Besprechungsraum ist nicht die Rede.

Wie diese Aufgabe verläuft

Frau Y aus der IT-Abteilung prüft, unterstützt von Herrn S – einem Registered Information Security Specialist bei der Muttergesellschaft L –, ob die Maßnahmen gegen einen Datenabfluss aus Dienst B ausreichend sind. Die beiden betrachten Datenabfluss durch einen externen Angreifer und Datenabfluss durch Mitarbeitende getrennt. Aufgabe 1 behandelt Ersteres, Aufgabe 2 Letzteres, und Aufgabe 3 die Ausarbeitung von Gegenmaßnahmen.

4. Gefälschtes WLAN und gefälschte Website – Teilaufgaben 1(1) und 1(2)

Frau Y bringt zuerst das Szenario ein, dass ein Gast, der das Gäste-WLAN schon einmal genutzt hat, als Angreifer aus der Nähe von Unternehmen M eine Verbindung zum Gäste-WLAN herstellt und auf Dienst B zugreift.

Dieses Szenario funktioniert, weil das WLAN-Authentifizierungsverfahren WPA2-PSK ist. PSK (Pre-Shared Key) bedeutet, wie der Name sagt, dass alle denselben Schlüssel gemeinsam nutzen. Der Pre-Shared Key des Gäste-WLANs ist dazu da, an Gäste weitergegeben zu werden. Ist er einmal weitergegeben, gibt es kein Mittel, diese eine Kenntnis rückgängig zu machen (außer den Schlüssel für alle zu ändern). Und weil das Bürogebäude an einer belebten Hauptstraße liegt, reicht das Funksignal auch außerhalb des Gebäudes.

Herrn S’ Antwort darauf ist eindeutig: Für die Anmeldung bei Dienst B sind [a] eine Benutzer-ID und [b] ein Passwort nötig. Das ist die Musterlösung für Teilaufgabe 1(1) (Reihenfolge beliebig). Sich mit dem WLAN zu verbinden bedeutet für sich genommen noch keine Anmeldung bei Dienst B.

Gefälschter AP und gefälschte Website

Daraufhin geht Frau Y einen Schritt weiter: Was, wenn man einen gefälschten AP mit denselben Einstellungen wie der AP des Gäste-WLANs und eine gefälschte Website unter derselben URL wie Dienst B einrichtet und die DNS-Konfiguration manipuliert, um Benutzer-ID und Passwort zu stehlen? Stellt man den gefälschten AP in der Nähe von Unternehmen M auf, könnte sich ein Mitarbeiter mit dem Geschäfts-PC versehentlich mit dem gefälschten AP verbinden, beim Versuch, auf Dienst B zuzugreifen, auf der gefälschten Website landen und sich dort anmelden.

Das ist der sogenannte Evil Twin. Baut man einen AP mit derselben SSID und demselben Pre-Shared Key wie das Gäste-WLAN auf, ist er aus Sicht des Geräts vom echten AP nicht zu unterscheiden. Unter WPA2-PSK kann ein Gerät über einen AP nur bestätigen, dass er denselben Pre-Shared Key kennt. Ein AP, der den Schlüssel nicht kennt, kann den Verbindungsvorgang nicht abschließen – umgekehrt heißt das aber, dass jeder, der den Schlüssel kennt, „der echte AP“ sein kann. Da es sich um einen an Gäste ausgegebenen Schlüssel handelt, muss man davon ausgehen, dass er auch dem Angreifer vorliegt.

Herrn S’ Antwort ist auch hier eindeutig. Versucht ein Mitarbeiter, über HTTPS auf die gefälschte Website zuzugreifen, zeigt der Browser eine Fehlermeldung, dass die Verbindung nicht sicher ist, und je nach dem von der gefälschten Website verwendeten Serverzertifikat einen oder mehrere der folgenden vier Punkte an:

• Dieses Serverzertifikat wurde nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt (Lücke c)
• Der in diesem Serverzertifikat angegebene Servername weicht vom Servernamen des Verbindungsziels ab (Lücke d)
• Dieses Serverzertifikat ist widerrufen
• Dieses Serverzertifikat ist abgelaufen

Die unteren beiden Punkte stehen bereits von Anfang an im Aufgabenheft; Teilaufgabe 1(2) verlangt die oberen beiden (Lücken c und d, je ≤40 Zeichen, Reihenfolge beliebig).

sequenceDiagram
    autonumber
    participant U as Geschäfts-PC des Mitarbeiters
    participant F as Gefälschter AP / gefälschte Website<br/>(Angreifer)
    participant B as Dienst B (echt)

    Note over F: Baut einen AP mit derselben SSID und<br/>demselben Pre-Shared Key wie das Gäste-WLAN auf
    U->>F: Verbindet sich versehentlich mit dem gefälschten AP
    Note over F: Manipuliert DNS, sodass die Domäne<br/>von Dienst B auf die gefälschte Website zeigt
    U->>F: Verbindet sich über HTTPS mit der URL von Dienst B
    F-->>U: Serverzertifikat der gefälschten Website
    Note over U: Prüfung scheitert<br/>- nicht von vertrauenswürdiger Zertifizierungsstelle ausgestellt<br/>- Servername im Zertifikat weicht vom Ziel ab
    Note over U: Zeigt einen Fehler an, dass die Verbindung nicht sicher ist<br/>der Anmeldebildschirm wird nie angezeigt
    Note over U,B: Es findet gar keine Kommunikation<br/>mit dem echten Dienst B statt

Was prüft die Zertifikatsvalidierung eigentlich?

Zu dieser Teilaufgabe schreibt der Auswertungskommentar:

Die Erfolgsquote bei Teilaufgabe 1(2) war gering. Selbst wenn ein Angreifer eine gefälschte Website vorbereitet, schlägt bei einem Zugriff über HTTPS die Prüfung des Serverzertifikats fehl. Die Prüfung des Serverzertifikats ist grundlegendes Wissen zur Absicherung der Kommunikation, daher sollten Prüflinge genau verstehen, was dabei konkret geprüft wird.

Mit anderen Worten: Viele wussten zwar, „dass ein Zertifikatsfehler erscheint“, konnten dies aber nicht in die vier konkreten geprüften Punkte zerlegen. Ordnet man die vier von Abbildung 2 genannten Punkte danach, wofür jede einzelne Prüfung eigentlich da ist, ergibt sich folgendes Bild:

Aus Sicht des Angreifers sind die oberen beiden Zeilen eine unüberwindbare Mauer. Ein selbstsigniertes Zertifikat scheitert am ersten Punkt, und selbst ein regulär erlangtes kostenloses Zertifikat für die eigene Domäne des Angreifers (etwa b-service.example.net) scheitert am zweiten, weil das Verbindungsziel die Domäne von Dienst B ist. Ein Zertifikat für die Domäne von Dienst B lässt sich nur erlangen, wer die Domäne von Dienst B kontrolliert. Diese Kombination der beiden Punkte darf man getrost als den eigentlichen Kern des Zertifikatsmechanismus bezeichnen.

Das Verfahren zur Pfadvalidierung von Zertifikaten regelt RFC 5280⁵, den Abgleich zwischen dem im Zertifikat angegebenen Namen und dem Namen des Verbindungsziels regelt RFC 6125⁶.

Die vier Punkte wirken nicht gleich stark

Trennen wir hier die Antwort der Prüfung vom tatsächlichen Verhalten der Browser. Die obigen vier Punkte sind das, was Abbildung 2 der Aufgabe als „Detail des möglicherweise angezeigten Fehlers“ nennt – man darf daraus nicht lesen, dass jeder Browser alle vier mit derselben Verlässlichkeit prüft.

Aussteller, Servername und Gültigkeitsdauer lassen sich alle allein anhand der Informationen beurteilen, die zum Zeitpunkt des Empfangs des Zertifikats bereits vorliegen, und werden deshalb immer geprüft. Diese drei sind es auch, die den Angriff in dieser Aufgabe stoppen.

Nur die Widerrufsprüfung liegt anders. Ob ein Zertifikat widerrufen ist, steht nicht im Zertifikat selbst; dafür müssen gesonderte Informationen abgerufen werden, weshalb dies von Implementierung und Konfiguration abhängt.

• Chrome führt normalerweise keine Online-Prüfung per OCSP oder CRL durch. Stattdessen verteilt es eine begrenzte Liste namens CRLSet, deren Hauptzweck das schnelle Blockieren von Zertifikaten im Notfall ist; aus den Widerrufslisten der Zertifizierungsstellen fließt davon nur ein Teil ein⁷
• Auch bei Implementierungen, die OCSP abfragen, ist eine „Soft-Fail“-Konfiguration weit verbreitet, die die Verbindung durchlässt, wenn keine Antwort eintrifft

Machen Sie daher „bei Schlüsselverlust einfach widerrufen“ nicht zur zentralen Säule Ihrer Gegenmaßnahmen. Ein Widerruf ist etwas, das man tun sollte, aber kein Mechanismus, der in jedem Browser jedes Nutzers zuverlässig greift. Die branchenweite Verkürzung der Zertifikatsgültigkeitsdauer der letzten Jahre ist selbst eine Antwort darauf, dass man sich auf den Widerruf nicht verlassen kann. Vermuten Sie im eigenen Unternehmen einen Schlüsselverlust, müssen Sie parallel zur Widerrufsbeantragung auch das Zertifikat austauschen und alles, was mit diesem Schlüssel geschützt war (Sitzungen, API-Schlüssel usw.), ungültig machen.

Eine Falle aus der Praxis – wer entscheidet, was eine „vertrauenswürdige Zertifizierungsstelle“ ist

Ab hier verlassen wir den Text der Aufgabe. Der erste Punkt der obigen Tabelle hängt davon ab, was dieses konkrete Gerät vertraut. Die Liste der vertrauenswürdigen Stellen führt Browser oder Betriebssystem; unter Windows entspricht das dem Zertifikatspeicher „Vertrauenswürdige Stammzertifizierungsstellen“.

Das heißt, in Situationen wie diesen besteht die erste Prüfung trotzdem:

• Das Stammzertifikat einer internen Zertifizierungsstelle (private CA) ist auf Geschäfts-PCs verteilt, und ein Angreifer hat den privaten Schlüssel dieser CA oder deren Ausstellungsprozess unter Kontrolle gebracht
• Ein Proxy oder ein Sicherheitsprodukt, das den Datenverkehr inspiziert, terminiert TLS mit einem eigenen, auf dem Gerät installierten Stammzertifikat, und dieses Produkt oder dessen Betrieb wurde von einem Angreifer kompromittiert
• Jemand hat früher, „weil ein Zertifikatsfehler erschien“, eine Ausnahme registriert oder ein selbstsigniertes Zertifikat in die vertrauenswürdigen Stammzertifikate aufgenommen

Den dritten Fall sehen wir in der Praxis wirklich sehr häufig: etwas von Hand Hinzugefügtes, um den Zertifikatsfehler eines internen Systems verschwinden zu lassen, das dann in einem Festplattenabbild fortlebt, das von Gerät zu Gerät weitergereicht wird, lange nachdem, wer es hinzugefügt hat, das Unternehmen verlassen hat. Was im Speicher der vertrauenswürdigen Stammzertifizierungsstellen liegt, ist die buchstäbliche Erklärung, wem dieses Gerät vertraut – nehmen Sie das also in Ihre Bestandsaufnahmen auf. Welche Zertifikate in welchen Speicher gehören, ist in dem praktischen Leitfaden zum Windows-Zertifikatspeicher zusammengestellt.

Zum zweiten Prüfpunkt (Übereinstimmung des Servernamens) gibt es einen eigenen praktischen Hinweis. Gegen einen Benutzer, der sich beim Domänennamen vertut, ist ein Zertifikat machtlos. Registriert ein Angreifer eine leicht zu verwechselnde Domäne wie b-serv1ce.example.com und erlangt dafür ein reguläres Zertifikat, zeigt der Browser keinen Fehler an. Was ein Zertifikat garantiert, ist, dass „der Servername des Verbindungsziels mit dem Servernamen im Zertifikat übereinstimmt“ – nicht, dass „dieser Servername auch das vom Nutzer beabsichtigte Gegenüber ist“. Ein Design, das diesen letzten Schritt nicht dem bloßen Hinsehen des Nutzers überlässt, ist genau das, was Passkeys (WebAuthn) bieten, indem der Authenticator selbst die Herkunft prüft. Mehr dazu in Warum sind Passkeys sicher?.

5. Warum es selbst nach der Eingabe von http:// noch scheitert – Teilaufgabe 1(3)

Frau Y hakt weiter nach. Was, wenn ein Mitarbeiter, noch mit dem gefälschten AP verbunden, beim Eintippen der URL von Dienst B versehentlich http:// eingibt – würde dann keine Fehlermeldung erscheinen?

Eine berechtigte Frage. Bei einer HTTP-Verbindung kommt gar kein Serverzertifikat ins Spiel. Es scheint, als könnte die gefälschte Website ohne jeden Fehler einen Anmeldebildschirm anzeigen.

Herrn S’ Antwort: „Das ist kein Problem – weil HSTS aktiviert ist, erscheint auch dann dieselbe Fehlermeldung.“ Teilaufgabe 1(3) fragt in ≤60 Zeichen, was der Browser bis unmittelbar vor der Anzeige dieser Fehlermeldung tut.

Die Musterlösung lautet: „Ersetzt den HTTP-Zugriff durch einen HTTPS-Zugriff und stellt die Verbindung her. Empfängt anschließend das Serverzertifikat von der gefälschten Website.“

Was im Browser tatsächlich passiert

HSTS (HTTP Strict Transport Security) ist ein Mechanismus, bei dem eine Website über den Header Strict-Transport-Security erklärt, „ab jetzt bitte diesen Host immer über HTTPS erreichen“, und der Browser sich das merkt. Geregelt ist das in RFC 6797⁸.

Versucht der Browser, auf einen gemerkten Host über http:// zuzugreifen, tut er Folgendes:

1. Ersetzt das URL-Schema http durch https; ist Port 80 explizit angegeben, wird er in 443 umgewandelt (RFC 6797, Abschnitt 8.3)
2. Verbindet sich dadurch über HTTPS. Da DNS manipuliert ist, ist das tatsächliche Ziel die gefälschte Website
3. Empfängt von der gefälschten Website ein Serverzertifikat
4. Die Prüfung scheitert, es kommt zum selben Fehler wie in Kapitel 4

Entscheidend ist, dass die Ersetzung in Schritt 1 abgeschlossen ist, bevor überhaupt etwas ins Netzwerk geht. Die unverschlüsselte HTTP-Anfrage wird gar nicht erst gesendet. Deshalb kommt es nie zu der Situation, dass „die Verbindung war HTTP, deshalb ist kein Zertifikat aufgetaucht“.

„Trotzdem fortfahren“ lässt sich nicht anklicken

HSTS hat noch eine weitere, praktisch sehr gewichtige Eigenschaft. Abschnitt 8.4 von RFC 6797 verlangt, dass beim Aufbau eines sicheren Kanals zu einem Host, für den HSTS aktiv ist, jeder auftretende Fehler – ob Warnung oder fatal – zum Abbruch der Verbindung führt. Abschnitt 12.1 beschreibt dieses Verhalten als „No User Recourse“ (dem Nutzer bleibt kein Ausweg) und legt fest, dass keine Option wie „Diese Verbindung ist nicht sicher, trotzdem fortfahren?“ angeboten werden darf.

Bei einem gewöhnlichen Zertifikatsfehler bieten die meisten Browser auf dem Warnbildschirm einen Weg über „Erweitert“ oder „Trotzdem fortfahren“ an. In der Praxis ist es keine Seltenheit, dass Nutzer, die an Zertifikatsfehler interner Systeme gewöhnt sind, diesen Weg reflexartig anklicken. HSTS unterbindet genau diesen Reflex. Gegen eine gefälschte Website wirkt dieses „man kann es nicht anklicken“ mitunter sogar stärker als die Zertifikatsprüfung selbst.

Die Voraussetzung von HSTS – der allererste Besuch bleibt ungeschützt

HSTS hat allerdings eine Voraussetzung. Wie Abschnitt 8.1 von RFC 6797 festlegt, wird ein Host erst dann zu einem „bekannten HSTS-Host“, wenn der Benutzeragent über einen sicheren Kanal den Header Strict-Transport-Security empfangen hat. Das heißt, dieser Browser muss die echte Website zuvor mindestens einmal über HTTPS erreicht haben.

Ungeschützt bleiben daher folgende Fälle:

• Ein gerade erst ausgegebener Geschäfts-PC, dessen allererster Zugriff zufällig unter einem gefälschten AP stattfindet
• Das Browserprofil wurde neu erstellt, oder Browserdaten wurden gelöscht, wodurch auch der HSTS-Eintrag verschwunden ist
• Die Gültigkeitsdauer des Eintrags (max-age) ist abgelaufen

Diese Erstzugriffslücke füllt die HSTS-Preload-Liste. Steht eine Domäne in der bereits im Browser eingebauten Liste, wird sie selbst beim allerersten Zugriff ohne vorherigen Besuch auf HTTPS erzwungen.

Erwägen Sie die Aufnahme der eigenen Website, sollten Sie zuerst die Voraussetzungen prüfen. Die Aufnahmebedingungen sind⁹:

• Ein gültiges Zertifikat wird bereitgestellt
• Wird auf Port 80 gelauscht, muss auf demselben Host von HTTP auf HTTPS umgeleitet werden
• Alle Subdomänen müssen über HTTPS bereitgestellt werden (einschließlich www, sofern dafür ein DNS-Eintrag existiert)
• Auf der Basisdomäne muss ein Strict-Transport-Security-Header mit max-age von mindestens 31536000 Sekunden (1 Jahr) sowie includeSubDomains und preload zurückgegeben werden

Kritisch werden der dritte Punkt und die Kombination mit includeSubDomains. Ist eine alte interne Subdomäne nur über HTTP erreichbar oder besitzt kein Zertifikat, wird sie in dem Moment, in dem die Aufnahme wirksam wird, unerreichbar. Machen Sie vor der Aufnahme eine vollständige Bestandsaufnahme aller Subdomänen.

Und eine Rücknahme ist nicht einfach. Löschanträge werden zwar grundsätzlich angenommen, aber bis die Änderung die Browser der Nutzer erreicht, können mehrere Monate vergehen, und für andere Browser als Chrome gibt es keine Garantie⁹. Gehen Sie davon aus, dass Preloading keine Einstellung ist, die man „bei einem Fehler eben rückgängig macht“.

Umgekehrt ist es auf der Nutzerseite durchaus sinnvoll, ob ein geschäftlich genutzter Cloud-Dienst HSTS unterstützt, als Punkt in die Auswahlkriterien aufzunehmen.

6. Sobald die Freigabe zur Formsache wird, wird die Freigabefunktion zum Weg des Datenabflusses – Teilaufgabe 2(1)

Ab hier geht es um Datenabfluss durch Mitarbeitende.

Herr S prüft zunächst, wie die Dateifreigabefunktion tatsächlich gehandhabt wird. Prüft der Vorgesetzte die Empfängeradresse und die Datei tatsächlich sorgfältig, bevor er freigibt? Frau Ys Antwort: „Es scheint Vorgesetzte zu geben, die das nicht prüfen.“

Daraus ergibt sich für Herrn S Teilaufgabe 2(1): Beschreiben Sie konkret in ≤40 Zeichen, wie sich die Dateifreigabefunktion missbrauchen lässt, um eine Datei von außerhalb von Unternehmen M herunterladbar zu machen.

Die Musterlösung lautet: „Die eigene private E-Mail-Adresse als Adresse des externen Empfängers angeben.“

Der Entwurf ist richtig, im Betrieb klafft eine Lücke

Die Dateifreigabefunktion von Dienst B ist gut durchdacht.

• Eine Freigabe erfordert die Genehmigung des Vorgesetzten
• Der externe Freigabelink wird weder der anfragenden Person noch dem Vorgesetzten mitgeteilt. Die anfragende Person kann den Link nicht selbst weiterleiten
• Der Link enthält eine schwer zu erratende Zufallszeichenfolge und ist einen Tag gültig

Vor allem der zweite Punkt ist ein Entwurf, der Datenabfluss von innen bewusst mitbedenkt. Und trotzdem lässt er sich durchbrechen, denn stellt man den Empfänger auf sich selbst, gelangt der „der anfragenden Person nicht mitgeteilte“ Link direkt in deren eigene Hände.

Und die Bedingung, unter der sich dieses Schlupfloch öffnet, ist genau eine: „der Vorgesetzte prüft den Empfänger nicht“. Der Genehmigungsworkflow ist unter der Annahme entworfen, dass der Genehmigende sich den Inhalt tatsächlich ansieht. Tut er das nicht, ist es nur noch ein automatisierter Zustellweg.

Die Bedingungen, unter denen eine Freigabe zur Formsache wird, sind vorhersehbar

In der Praxis liegt es meist an einem dieser Punkte, wenn eine Freigabe zur Formsache wird:

Was Unternehmen M in dieser Aufgabe vor allem fehlt, sind die letzten beiden Punkte. Wer einen Mechanismus zum Freigeben einführt, braucht auch einen Mechanismus, um sich das Genehmigte im Nachhinein anzusehen. Schon eine monatliche Liste externer Freigaben an Freemail-Domänen macht diesen Trick deutlich leichter auffindbar.

Das größere Bild, wo kleine und mittlere Unternehmen ansetzen sollten, behandelt Wegweiser durch die IPA-„Leitlinien zur Informationssicherheit für KMU“ Version 4.0.

7. Der Besprechungsraum als Schlupfloch – Teilaufgabe 2(2)

Herrn S’ nächste Frage lautet: „Lassen sich private PCs in den Besprechungsraum mitbringen?“ Frau Ys Antwort: „Das Mitbringen in den Besprechungsraum ist nicht verboten, also ja.“

Hier kommen Methode 1 und Methode 2 ins Spiel. Beide folgen derselben Handlung: Dateien mit einem privaten PC von Dienst B herunterladen und diesen privaten PC anschließend mitsamt den Dateien hinaustragen. Die auf dem Geschäfts-PC installierte Software zum Schutz vor Informationslecks hat auf einen privaten PC keinerlei Wirkung.

Methode 1 – Fälschen der MAC-Adresse

Methode 1 besteht darin, die [e] MAC-Adresse der WLAN-Schnittstelle eines privaten PCs auf die MAC-Adresse der WLAN-Schnittstelle eines Geschäfts-PCs zu ändern und den privaten PC anschließend mit dem Mitarbeiter-WLAN zu verbinden. Lücke e zu beantworten ist Teilaufgabe 2(2).

Den Zugang zum Mitarbeiter-WLAN sicherten zwei Dinge: der Pre-Shared Key von WPA2-PSK und die MAC-Adressfilterung. Beide lassen sich von Mitarbeitenden überwinden.

• Der Pre-Shared Key ist auf dem Geschäfts-PC konfiguriert, und der Mitarbeiter ist der Nutzer dieses Geräts. Da alle einen einzigen gemeinsamen Schlüssel besitzen, muss man davon ausgehen, dass „der Nutzer ihn kennen kann“
• Die MAC-Adresse lässt sich auf dem Gerät umschreiben – üblicherweise über Betriebssystemeinstellungen oder Treibereigenschaften, ohne besondere Werkzeuge. Da die MAC-Adresse in WLAN-Frames zudem unverschlüsselt übertragen wird, kann jemand, der den Funkverkehr in der Nähe empfängt, auch die MAC-Adresse eines registrierten Geschäfts-PCs in Erfahrung bringen

MAC-Adressfilterung und verborgene SSID haben durchaus Wert als Aufräummaßnahme gegen versehentliche Fehlverbindungen. Aber sie sind kein Authentifizierungsmechanismus gegen jemanden, der bewusst eindringen will. Prüfen Sie auch bei Ihrer eigenen Konfiguration, ob diese beiden mitgezählt werden, wenn Sie Ihre tatsächlichen Schutzmaßnahmen aufzählen.

Methode 2 – Einfach mit dem Gäste-WLAN verbinden

Methode 2 ist noch einfacher. Einen privaten PC mit dem Gäste-WLAN verbinden, Dateien von Dienst B herunterladen und den privaten PC mitsamt den Dateien hinaustragen. Das ist alles.

Auch das Fälschen der MAC-Adresse ist nicht nötig. Nötig ist nur der Pre-Shared Key des Gäste-WLANs, und der wird an Gäste ausgegeben. Es ist ausgeschlossen, dass ein Mitarbeiter ihn nicht kennt.

Hier stellt sich naturgemäß die Frage: War Dienst B nicht auf „Anmeldung nur von der globalen IP-Adresse von Unternehmen M aus, mit den den Mitarbeitenden von Unternehmen M zugewiesenen Benutzer-IDs“ beschränkt?

Was eine Beschränkung auf die Quell-IP-Adresse eigentlich erlaubt

Liest man die Firewall-Konfiguration in der Aufgabe, ergibt sich die Antwort. Sowohl der Datenverkehr vom Gäste-WLAN ins Internet als auch der vom Mitarbeiter-WLAN wird durch dieselbe NAT auf dieselbe eine globale IP-Adresse umgesetzt.

Aus Sicht von Dienst B lassen sich diese drei nicht unterscheiden. Die IP-Adressbeschränkung wird glatt umgangen.

Dieses Muster taucht auch außerhalb der Prüfung immer wieder auf. Eine Beschränkung auf die Quell-IP-Adresse bedeutet nicht „nur dieses eine Gerät“. Sie bedeutet „alle, die über diese globale IP-Adresse hinausgehen“. Hier typische Fälle, in denen der beabsichtigte und der tatsächlich erlaubte Bereich auseinanderfallen:

All das bedeutet nicht, dass eine Beschränkung auf die Quell-IP-Adresse nutzlos ist. Es bedeutet, sie nicht als einzige Schutzschicht einzusetzen. Erst kombiniert man eine IP-basierte Eingrenzung mit einem Mechanismus, der das Gerät selbst identifiziert (Client- oder Gerätezertifikat), und einem Mechanismus, der den Nutzer identifiziert (Mehrfaktor-Authentifizierung), kann man „diese Person, auf diesem Gerät“ ausdrücken. Genau in diese Richtung gehen auch die Gegenmaßnahmen dieser Aufgabe.

8. Das Gerät mit einem Zertifikat binden – Teilaufgaben 3(1) bis 3(4)

Als Gegenmaßnahme gegen Methode 1 entscheidet sich Unternehmen M, das Authentifizierungsverfahren des Mitarbeiter-WLANs auf EAP-TLS umzustellen und einen Authentifizierungsserver einzurichten.

Teilaufgabe 3(1) – RADIUS

Teilaufgabe 3(1) fragt nach dem UDP-basierten Protokoll, das der Authentifizierungsserver für EAP nutzt. Die Musterlösung lautet RADIUS.

Ordnet man das ein, sind drei Parteien beteiligt:

Zwischen Geschäfts-PC und AP läuft IEEE 802.1X (EAP over LAN), zwischen AP und Authentifizierungsserver RADIUS. RADIUS läuft über UDP¹⁰. Das Verfahren von EAP-TLS selbst regelt RFC 5216¹¹. Unter Windows Server übernimmt der Network Policy Server (NPS) die Rolle des Authentifizierungsservers¹².

Halten wir fest, was sich beim Wechsel von WPA2-PSK zu EAP-TLS konkret ändert.

Die letzte Zeile braucht eine Ergänzung. Bei EAP-TLS prüft der Client das Zertifikat nicht des APs, sondern des Authentifizierungsservers. Der AP ist nur ein Authenticator, der den EAP-Austausch weiterleitet; der Client bestätigt nicht die Identität des APs selbst.

Trotzdem schützt das gegen den Evil Twin aus Kapitel 4, weil das Schlüsselmaterial, das erst nach erfolgreicher Authentifizierung entsteht, nur an einen echten AP mit dem gemeinsamen RADIUS-Geheimnis gelangt. Ein AP, den ein Angreifer auf eigene Faust aufstellt, kann dieses Verfahren nicht bis zum Ende durchlaufen, sofern nicht ein echter Authentifizierungsserver dahintersteht. Was der Client direkt prüft, ist der Authentifizierungsserver; die Legitimität des APs leitet sich davon nur indirekt ab.

Das gilt allerdings nur unter einer Bedingung: Ist auf dem Client nicht konfiguriert, welcher Zertifizierungsstelle und welchem Servernamen des Serverzertifikats vertraut werden soll, lässt sich nicht erkennen, wenn ein Angreifer einen eigenen Authentifizierungsserver aufstellt. Es gibt in der Praxis tatsächlich Konfigurationen, bei denen EAP-TLS eingeführt wurde, die Prüfung des Serverzertifikats im Client-Profil aber deaktiviert blieb. Prüfen Sie bei der Einführung auch diesen Punkt.

Teilaufgabe 3(2) – Die im Auswertungskommentar genannte Fehlantwort

Frau Ys Erklärung geht so weiter: Client-Zertifikate werden über einen neu eingerichteten CA-Server ausgestellt, und statt dass Mitarbeitende sie selbst auf ihrem Geschäfts-PC installieren, werden sie über die Funktion des Verzeichnisservers auf den Geschäfts-PC gebracht. Und was einem Client-Zertifikat entspricht – [f] – wird, damit es [g] ist, im TPM des Geschäfts-PCs gespeichert und dort geschützt.

Teilaufgabe 3(2) fragt nach Lücke f. Die Musterlösung lautet privater Schlüssel.

Der Auswertungskommentar schreibt:

Die Erfolgsquote bei Teilaufgabe 3(2) war eher hoch, jedoch fanden sich vereinzelt Antworten wie „öffentlicher Schlüssel“ oder „Serverzertifikat“. PKI ist eine wichtige Technologie, die vielen Sicherheitstechniken zugrunde liegt; Prüflinge sollten daher genau verstehen, in welchem Kontext und wie sie jeweils eingesetzt wird.

Der öffentliche Schlüssel ist das, was im Zertifikat steckt und in alle Welt verteilt wird. Er muss nicht geschützt werden. Geschützt werden muss der private Schlüssel, den ausschließlich der rechtmäßige Besitzer des Zertifikats besitzen sollte. Genauer gesagt bedeutet „sich mit einem Client-Zertifikat authentifizieren“, „durch eine Signatur mit diesem Schlüssel zu belegen, dass man den privaten Schlüssel besitzt, der zum öffentlichen Schlüssel im Zertifikat gehört“. Lässt sich der private Schlüssel also vervielfältigen, verliert die Authentifizierung per Zertifikat ihren Sinn.

Was ändert sich durch die Speicherung im TPM? – Teilaufgabe 3(3)

Teilaufgabe 3(3) fragt in ≤20 Zeichen nach Lücke g. Die Musterlösung lautet: „damit er sich nicht vom Geschäfts-PC entfernen lässt“.

Liegt der private Schlüssel als Datei auf dem Gerät, ist er kopierbare Daten. Kopiert man ihn auf einen privaten PC, besteht dieser private PC die Authentifizierung wie ein Geschäfts-PC. Was als Verschluss von Methode 1 (Fälschen der MAC-Adresse) gedacht war, wird dann bloß durch „Fälschen des Zertifikats“ ersetzt.

Ein TPM kann einen Schlüssel in sich selbst erzeugen und so halten, dass er sich nicht nach außen entnehmen lässt. Operationen wie das Signieren finden im TPM statt, der Schlüssel selbst gelangt weder an das Betriebssystem noch an Anwendungen noch an Schadsoftware. Im Ergebnis ist dieser private Schlüssel an dieses eine physische Bauteil gebunden.

Bei der Umsetzung unter Windows gibt man im Schlüsselspeicheranbieter (KSP) der Zertifikatvorlage Microsoft Platform Crypto Provider an. Dieser Anbieter schützt Schlüssel mithilfe des TPM und lässt sich nicht auswählen, wenn in der Zertifikatvorlage „Export des privaten Schlüssels zulassen“ aktiviert ist¹³. Eine naheliegende Einschränkung – lässt sich der Schlüssel exportieren, ist der Schutz sinnlos.

Die Rolle des TPM als Bauteil selbst wird im Kontext der Laufwerksverschlüsselung im BitLocker-Praxisleitfaden behandelt. Der Gedanke, „den privaten Schlüssel nie außerhalb des Geräts zu lassen“, folgt derselben Entwurfsidee wie die in Warum sind Passkeys sicher? erklärten Authenticatoren.

Warum lässt sich sagen, es sei „unbedenklich“? – Teilaufgabe 3(4)

Nachdem er Frau Ys Erklärung gehört hat, antwortet Herr S: „Bei dieser Speichermethode denke ich, dass es unbedenklich ist.“ Teilaufgabe 3(4) fragt in ≤40 Zeichen nach dem Grund.

Die Musterlösung lautet: „Weil sich die für EAP-TLS nötigen Authentifizierungsdaten nur auf dem Geschäfts-PC speichern lassen.“

Verfolgt man den Gedankengang:

1. Das Client-Zertifikat wird nicht von der Mitarbeiterin selbst installiert, sondern über die Funktion des Verzeichnisservers auf den Geschäfts-PC verteilt. Die Hände der Mitarbeiterin kommen dabei nicht ins Spiel
2. Der private Schlüssel liegt im TPM und lässt sich nicht vom Geschäfts-PC entfernen
3. Folglich kann sich über EAP-TLS nur mit dem Mitarbeiter-WLAN verbinden, wer einen vom Unternehmen ausgegebenen Geschäfts-PC besitzt
4. Ein privater PC besteht die Authentifizierung auch dann nicht, wenn er die MAC-Adresse fälscht. Methode 1 ist damit verschlossen

Achten Sie auf die Formulierung „bei dieser Speichermethode“. Läge der private Schlüssel als Datei auf dem Geschäfts-PC, hätte Herr S nicht gesagt, es sei unbedenklich. Bei ein und demselben Begriff „Authentifizierung per Client-Zertifikat“ hängt der geschützte Bereich davon ab, wie der private Schlüssel gespeichert ist.

Was das TPM nicht schützt

Andererseits bedeutet die Speicherung im TPM nicht, dass alles sicher ist. Das TPM garantiert nur, dass „dieser Schlüssel sich nicht auf ein anderes Gerät vervielfältigen lässt“. Folgendes schützt es nicht:

• Wird das Gerät selbst mitgenommen. Trägt man den Geschäfts-PC hinaus, trägt man das TPM mit hinaus. Nach den Regeln von Unternehmen M ist das Mitnehmen des Geschäfts-PCs außer Haus verboten, aber eine Regel und deren technische Durchsetzung sind zweierlei. Es braucht zusätzlich eine Laufwerksverschlüsselung (einschließlich Authentifizierung vor dem Systemstart) und ein Verfahren, um das Zertifikat bei Verlust zu widerrufen
• Identitätsdiebstahl beim Nutzer. Das TPM identifiziert das Gerät, nicht, wer es bedient. Die Authentifizierung des Nutzers braucht es zusätzlich
• Schadsoftware auf dem Gerät. Der private Schlüssel lässt sich nicht auslesen, aber Code, der auf diesem Gerät läuft, kann das TPM trotzdem bitten, eine Signatur zu erstellen. Das Vervielfältigen des Schlüssels wird verhindert, nicht aber der Missbrauch während das Gerät kompromittiert ist

9. Die Ausgangs-IP-Adresse trennen – Teilaufgabe 3(5)

Als Gegenmaßnahme gegen Methode 2 (einfach mit dem Gäste-WLAN verbinden) erwägt Unternehmen M zwei Optionen: die NAT-Konfiguration der Firewall ändern oder einen externen WLAN-Dienst (Dienst D) nutzen.

Teilaufgabe 3(5) fragt in ≤70 Zeichen nach dem Inhalt der erstgenannten Änderung. Die Musterlösung lautet sinngemäß: „Für den Zugriff vom Gäste-WLAN auf das Internet eine andere Quell-IP-Adresse verwenden als die aktuell genutzte globale IP-Adresse“ (im Aufgabenheft wird diese globale IP-Adresse als a1.b1.c1.d1 bezeichnet).

Wie in Kapitel 7 gesehen, funktioniert Methode 2, weil der Datenverkehr des Gäste-WLANs über dieselbe globale IP-Adresse hinausgeht wie der der Mitarbeitenden. Also genügt es, nur das Gäste-WLAN auf eine andere globale IP-Adresse umzusetzen. Die IP-Beschränkung von Dienst B bleibt unverändert, nur der Zugriff aus dem Gäste-WLAN fällt dann aus ihrem Geltungsbereich.

Das funktioniert, weil der WAN-Seite von Unternehmen M mehrere globale IP-Adressen zugewiesen sind. Liest man die Interface-Konfiguration der Firewall im Aufgabentext, ist die WAN-seitige Subnetzmaske 255.255.255.248, also ein /29, woraus sich ergibt, dass mehr als eine nutzbare Adresse verfügbar ist. Ein unauffälliger, aber gezielt gesetzter Hinweis in den Tabellen der Aufgabe, den man genau lesen muss.

Ob sich dasselbe im eigenen Unternehmen umsetzen lässt, hängt davon ab, ob der Leitungsvertrag mehrere globale IP-Adressen erlaubt. Gibt es nur eine, entfällt diese Option; dann bleibt der im nächsten Kapitel behandelte Trennungsansatz.

10. Erst das Löschen nicht mehr benötigter Konfiguration macht die Gegenmaßnahme vollständig – Teilaufgaben 3(6) und 3(7)

Nach Abwägung entscheidet sich Unternehmen M für Dienst D.

• Im Besprechungsraum wird ein von Dienst D bereitgestellter WLAN-Router (der „D-Router“) installiert
• Auf dem D-Router werden die Funktionen DHCP-Server und DNS-Cache-Server aktiviert
• Von Gästen mitgebrachte Geräte verbinden sich ohne über das Netzwerk von Unternehmen M zu gehen über die im D-Router verbaute SIM mit dem Internet
• Der Beamer nutzt nicht mehr das Gäste-WLAN, sondern wird stattdessen per HDMI-Kabel angeschlossen

flowchart LR
    subgraph M["Internes Netzwerk von Unternehmen M (nach den Gegenmaßnahmen)"]
        direction TB
        E["Mitarbeiter-WLAN<br/>EAP-TLS + RADIUS<br/>privater Schlüssel im TPM"]
        S["Servernetzwerk"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["Besprechungsraum"]
        T["Von Gästen mitgebrachtes Gerät"]
        D["D-Router<br/>über SIM direkt ins Internet"]
        T --> D
    end
    FW --> B["Dienst B"]
    D --> I["Internet"]

Das Gästenetzwerk ist nun sowohl physisch als auch logisch vom Netzwerk von Unternehmen M getrennt. Es geht auch nicht mehr über dieselbe globale IP-Adresse hinaus.

Teilaufgabe 3(6) – Nicht mehr benötigter Datenverkehr

Sobald von Gästen mitgebrachte Geräte das Netzwerk von Unternehmen M nicht mehr nutzen, wird der bislang nötige Datenverkehr zum DHCP-Server und zum [h]-Server überflüssig. Die Musterlösung für Lücke h lautet DNS.

Da der D-Router selbst die Funktionen DHCP-Server und DNS-Cache-Server besitzt, benötigen von Gästen mitgebrachte Geräte den DHCP- und DNS-Server im Servernetzwerk von Unternehmen M nicht mehr. Liest man die Beschreibung im Aufgabentext noch einmal, steht die Antwort dort unmittelbar.

Teilaufgabe 3(7) – Alle zu löschenden Einstellungen aufzählen

Teilaufgabe 3(7) verlangt, alle Positionsnummern zu nennen, die infolge dieser Änderung aus den VLAN-Schnittstelleneinstellungen und den Filtereinstellungen der Firewall gelöscht werden sollten.

Die Antwort: Aus den VLAN-Schnittstelleneinstellungen das VLAN des Gäste-WLANs (Position 1); aus den Filtereinstellungen die Regel, die HTTP/HTTPS vom Gäste-WLAN ins Internet erlaubt (Position 1), sowie die Regel, die den Zugriff vom Gäste-WLAN auf den DNS-Dienst im Servernetzwerk erlaubt (Position 4) – also zwei Einträge. Außerdem sollte aus der AP-Konfiguration die Konfiguration der Gäste-SSID entfernt werden.

Der Auswertungskommentar schreibt:

Die Erfolgsquote bei Teilaufgabe 3(7) war hoch. Es galt, die Auswirkungen der Überarbeitung der WLAN-Umgebung auf sämtliche Filtereinstellungen der Firewall zu verstehen und entsprechend zu antworten, was angemessen verstanden wurde.

Trotz der hohen Erfolgsquote bei dieser Teilaufgabe ziehen in der Praxis nur wenige Organisationen das wirklich konsequent durch. Für das Einführen eines neuen Mechanismus gibt es Budget und Termin, für das Löschen alter Konfiguration nicht. Und vergessenes Löschen zeigt sich später auf folgende Weise:

Die Firewall in dieser Aufgabe arbeitet nach dem Prinzip, Regeln in aufsteigender Reihenfolge der Positionsnummer auszuwerten und die erste zutreffende Regel anzuwenden (das steht so ausdrücklich im Aufgabentext). Bei diesem Modell hat es denselben Effekt, eine nicht mehr genutzte Erlaubnisregel weiter oben stehen zu lassen, wie ein offenes Loch zu hinterlassen, das den Datenverkehr nie bis zur abschließenden Verbotsregel durchkommen lässt.

Verallgemeinern Sie dieses Auswertungsmodell aber nicht auf jede Firewall. Verschiedene Produkte entscheiden unterschiedlich.

Unabhängig vom Modell bleibt es gleich gefährlich, eine nicht mehr genutzte Erlaubnis stehen zu lassen. Was sich ändert, ist „warum es gefährlich ist“ und „wie man es behebt“. Prüfen Sie, welches Modell Ihre eigenen Geräte verwenden, und nehmen Sie „existieren Quelle und Ziel überhaupt noch“ als Kriterium in Ihre regelmäßigen Bestandsaufnahmen auf.

Wie sich auf der Anwendungsseite die nötigen eingehenden Regeln verwalten lassen – also das Thema der hostseitigen Firewall –, behandelt Windows-Firewall und Geschäftsanwendungen.

11. Maßnahmen, die nicht griffen, und Maßnahmen, die griffen

Fasst man diese Aufgabe auf einer Seite zusammen, ergibt sich folgende Tabelle: die Maßnahmen von Unternehmen M und wo sie jeweils überwunden wurden.

Nur die letzte Zeile hat „gegriffen“. Und so sehen die ausgearbeiteten Gegenmaßnahmen im Vergleich aus:

Vergleicht man beide Tabellen, wird der Unterschied im Charakter deutlich. Die überwundenen Maßnahmen verbieten meist ein „Mittel“, die griffigen und die ausgearbeiteten Maßnahmen ändern dagegen den „Weg“ oder die Natur des „Berechtigungsnachweises“. Sperrt man USB-Sticks, gelingt der Datenabfluss trotzdem, solange ein Weg zu den Dateien bleibt; verlängert man den Pre-Shared Key, bleibt er trotzdem ein gemeinsames Geheimnis.

12. Praktische Prüfpunkte

Hier die Prüfpunkte, um diese Aufgabe auf die eigene Konfiguration zu übertragen.

1. Lassen sich Ihre Gegenmaßnahmen gegen Datenabfluss in Wegen statt in Mitteln formulieren? Statt einer Liste von Mitteln (USB-Stick, E-Mail-Anhang, Webmail) eine „Liste aller Geräte und Netzwerke, die geschäftliche Dateien erreichen können“ erstellen. Führt auch nur ein Weg von einem unverwalteten Gerät aus zum Ziel, wird das Verbot von Mitteln einfach umgangen
2. Beschränken Ihre Mitnahme- und Mitbring-Regeln unbemerkt nur einen Ort? „Mitbringen in den Büroraum verboten“ erlaubt implizit Besprechungsraum, Empfang und Gemeinschaftsbereiche. Prüfen Sie, ob physische und Netzwerksegmentierung übereinstimmen
3. Können Sie genau benennen, welchen Bereich Ihre Beschränkung auf die Quell-IP-Adresse tatsächlich erlaubt? Zählen Sie alles auf, was über diese globale IP-Adresse hinausgeht: Gäste-WLAN, Gästenetzwerk, standortübergreifendes VPN, Sammel-Gateway für Homeoffice, Testumgebungen
4. Ist Ihr WLAN-Berechtigungsnachweis pro Gerät? Ein Pre-Shared Key ist ein Geheimnis, das alle identisch besitzen – gibt es eine Person preis, ist es für alle preisgegeben, und ein einzelnes Gerät lässt sich damit nicht gezielt sperren
5. Zählen Sie MAC-Adressfilterung und verborgene SSID zu Ihren Schutzmaßnahmen? Beide sind nur Aufräummaßnahmen gegen Fehlverbindungen, keine Authentifizierung
6. Lässt sich der private Schlüssel eines Client-Zertifikats vom Gerät entfernen? Ein als Datei abgelegter privater Schlüssel lässt sich kopieren. Geben Sie einen TPM-gestützten Schlüsselspeicheranbieter an und verbieten Sie den Export
7. Prüft ein Client mit EAP-TLS tatsächlich das Zertifikat des Authentifizierungsservers? Ist dies deaktiviert, geht die gesamte Widerstandsfähigkeit gegen einen gefälschten Authentifizierungsserver verloren
8. Kann ein Nutzer einen Serverzertifikatsfehler mit „Fortfahren“ überwinden? Konfigurieren Sie HSTS für Ihre eigenen Websites. Lassen Sie einen vernachlässigten Zertifikatsfehler eines internen Systems die Nutzer nicht lehren, „ein Fehler ist etwas, das man wegklickt“
9. Nehmen Sie den Inhalt des Speichers der vertrauenswürdigen Stammzertifizierungsstellen in die Bestandsaufnahme auf? Was dort liegt, ist die buchstäbliche Erklärung, welchen Zertifizierungsstellen dieses Gerät als echt vertraut
10. Erhalten Genehmigende im Freigabeworkflow genug Entscheidungsgrundlage? Und sieht sich später jemand die genehmigten Vorgänge an? Prüfen Sie regelmäßig Freigaben an externe Domänen und Freemail-Domänen als Liste
11. Haben Sie die Konfiguration abgeschaffter Wege tatsächlich gelöscht? VLAN-Schnittstellen, Filterregeln, SSIDs, Einträge auf Positivlisten. Geben Sie dem „Löschen“ genauso einen Termin wie dem „Neu-Einrichten“

Schluss – Eine Maßnahme ohne festgelegten Geltungsbereich schützt nicht

Fragte Aufgabe 1, „welche Phase welchen Angriffs stoppt diese Maßnahme eigentlich“, so fragt Aufgabe 2, „welchen Bereich schützt diese Maßnahme eigentlich“.

Jede Maßnahme von Unternehmen M hatte einen impliziten Geltungsbereich. Der Bereich der Software zum Schutz vor Informationslecks reichte bis zum Geschäfts-PC. Der Bereich des Mitbringverbots reichte bis zum Büroraum. Der Bereich der MAC-Adressfilterung reichte bis zu „wer nicht fälscht“. Der Bereich der Beschränkung auf die Quell-IP-Adresse reichte bis zu „alle, die über diese eine globale IP-Adresse hinausgehen“. Jeder dieser Bereiche funktionierte für sich korrekt – nur die Nahtstelle zum Nachbarn stand offen.

Das Praxisnahe an dieser Aufgabe ist, dass Unternehmen M als ein Unternehmen dargestellt wird, das seine Maßnahmen ernst genommen hat. Nach dem Vorfall im Vorjahr hat es beide Enden des Wegs verschlossen und sogar eigene Software eingeführt. Und trotzdem bleibt eine Lücke – nicht, weil die Verantwortlichen nachlässig waren, sondern weil sich beim schrittweisen Hinzufügen von Maßnahmen die Lücken zwischen ihren Geltungsbereichen nicht zeigen.

Um solche Lücken zu finden, bleibt nichts anderes übrig, als nicht eine Liste von Maßnahmen, sondern eine Liste von Wegen aufzuschreiben. Genau das taten Frau Y und Herr S in dieser Aufgabe: Sie unterteilten in „externer Angreifer“ und „Mitarbeitende“ und verschlossen für jede Gruppe die erreichbaren Wege einen nach dem anderen. Was IPA als Prüfungsziel formuliert – „die Fähigkeit, Bedrohungen in einer WLAN-gestützten Umgebung aus verschiedenen Blickwinkeln vorherzusehen“ –, ist am Ende genau diese Arbeit.

Verwandte Beratungsbereiche

Die KomuraSoft LLC behandelt Design-Reviews auf Basis einer bestehenden Netzwerk- und Geräteumgebung sowie die Umsetzung von Zertifikatsverteilung und Schlüsselschutz in Windows-Umgebungen.

• Technikberatung / Design-Review
• Windows-Entwicklung
• Fehleruntersuchung & Ursachenanalyse
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wir haben USB-Sticks verboten und auch das Speichern auf der lokalen Festplatte untersagt. Warum lassen sich trotzdem noch Dateien hinaustragen?

Weil verboten wurde, was der vom Unternehmen ausgegebene Geschäfts-PC kann – nicht der Weg zu dem Ort, an dem die Dateien liegen. In dieser Aufgabe benutzt der Mitarbeitende seinen eigenen, privaten PC. Ohne den Geschäfts-PC überhaupt anzurühren, verbindet er seinen privaten PC mit dem WLAN im Besprechungsraum, meldet sich mit seiner eigenen Benutzer-ID beim Cloud-Speicher (Dienst B) an, lädt die Dateien herunter und trägt anschließend den privaten PC selbst hinaus. Die auf dem Geschäfts-PC installierte Software zum Schutz vor Informationslecks hat auf einen privaten PC keinerlei Wirkung. Unternehmen M verbot zwar das Mitbringen privater PCs, aber dieses Verbot galt nur für den Büroraum – der Besprechungsraum war davon ausgenommen. Auch wenn man die Mittel (USB-Stick, E-Mail-Anhang, Webmail) eines nach dem anderen sperrt, gelingt der Datenabfluss trotzdem, solange ein Weg zu den Dateien offenbleibt.

Dienst B war auf „Anmeldung nur von der globalen IP-Adresse von Unternehmen M aus“ beschränkt. Warum lässt sich diese Beschränkung über das Gäste-WLAN umgehen?

Weil auch der Datenverkehr des Gäste-WLANs über dieselbe NAT derselben Firewall läuft und dabei auf dieselbe globale IP-Adresse umgesetzt wird, bevor er ins Internet geht. Aus Sicht von Dienst B sehen ein Zugriff vom Geschäfts-PC im Büro und ein Zugriff von einem privaten PC, der im Besprechungsraum mit dem Gäste-WLAN verbunden ist, wie dieselbe Quell-IP-Adresse aus. Sie lassen sich nicht unterscheiden. Eine Beschränkung anhand der Quell-IP-Adresse muss man so verstehen, dass sie nicht „nur dieses eine Gerät“ erlaubt, sondern „alle, die sich denselben Ausgang teilen“. Gäste-WLAN, standortübergreifende VPNs oder ein Sammel-Gateway für Homeoffice-Zugriffe – alles, was über dieselbe globale IP-Adresse ins Internet geht, fällt in den erlaubten Bereich.

Für das Mitarbeiter-WLAN war eine MAC-Adressfilterung eingerichtet. Ist das denn keine wirksame Gegenmaßnahme?

Nein. Denn die MAC-Adresse lässt sich auf dem Endgerät frei umschreiben. Methode 1 in dieser Aufgabe bestand genau darin, die MAC-Adresse der WLAN-Schnittstelle eines privaten PCs auf die MAC-Adresse eines registrierten Geschäfts-PCs zu ändern und sich damit zu verbinden. Da die MAC-Adresse in WLAN-Frames unverschlüsselt übertragen wird, kann jemand, der den Funkverkehr in der Nähe empfängt, auch die MAC-Adresse eines registrierten Geräts in Erfahrung bringen. Dasselbe gilt für das Verbergen der SSID. Auch wenn die SSID-Aussendung deaktiviert ist, lässt sie sich aus dem Austausch erkennen, der beim Verbindungsaufbau eines Geräts stattfindet. MAC-Adressfilterung und verborgene SSID verringern zwar versehentliche Fehlverbindungen, sind aber kein Authentifizierungsmechanismus, der eine absichtliche Verbindung verhindert.

Warum kann man sagen, dass Mitarbeitende trotz gefälschtem Access Point und gefälschter Website nicht getäuscht werden?

Weil eine gefälschte Website bei einer Verbindung über HTTPS die Prüfung des Serverzertifikats nicht bestehen kann. Abbildung 2 der Aufgabe nennt vier Punkte, die als Detail des dabei angezeigten Fehlers erscheinen können: nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt; der im Zertifikat angegebene Servername weicht vom Servernamen des Verbindungsziels ab; widerrufen; und abgelaufen. Ein Angreifer kann kein reguläres Zertifikat für die Domäne von Dienst B erlangen – ein selbstsigniertes Zertifikat scheitert daher am ersten Punkt, ein für die eigene Domäne des Angreifers regulär erlangtes Zertifikat am zweiten. Laut IPAs Auswertungskommentar war die Erfolgsquote bei der Aufgabe, die genau diese Prüfinhalte abfragte, gering. Diese vier Punkte wirken übrigens nicht gleich stark. Was den Angriff tatsächlich stoppt, sind die ersten beiden (Aussteller und Name) sowie die Gültigkeitsdauer – diese prüft der Browser immer. Die Widerrufsprüfung dagegen hängt von Implementierung und Konfiguration ab. Chrome etwa führt normalerweise keine Online-Prüfung per OCSP oder CRL durch, sondern verwendet stattdessen eine begrenzte Liste namens CRLSet, deren Hauptzweck das schnelle Blockieren in Notfällen ist. Verlassen Sie sich nicht darauf, dass ein Widerruf ein Zertifikat garantiert blockiert. Und wenn auf dem Geschäfts-PC das Stammzertifikat einer internen Zertifizierungsstelle verteilt ist und ein Angreifer deren privaten Schlüssel oder Ausstellungsprozess unter Kontrolle bringt, besteht das Zertifikat auch die erste Prüfung.

Was passiert, wenn man aus Versehen „http://“ statt der richtigen Adresse eingibt? Was genau bewirkt HSTS dabei?

Der Browser ersetzt HTTP durch HTTPS, bevor er die Verbindung aufbaut, sodass das Ergebnis wieder ein Serverzertifikatsfehler ist. HSTS ist ein Mechanismus, bei dem sich der Browser den Inhalt eines Headers merkt, den er beim letzten HTTPS-Zugriff auf diese Website erhalten hat. RFC 6797 verlangt, dass der Benutzeragent, sobald eine URL für den betreffenden Host das Schema http enthält, dieses durch https ersetzt und Port 80, falls explizit angegeben, in 443 umwandelt. Das heißt, eine unverschlüsselte HTTP-Anfrage verlässt das Gerät gar nicht erst. Noch wichtiger: Schlägt die Zertifikatsprüfung bei der Kommunikation mit einem Host fehl, für den HSTS aktiv ist, verlangt die Spezifikation, dass die Verbindung abgebrochen wird – unabhängig davon, ob der Fehler eine Warnung oder fatal ist. Es wird ausdrücklich festgelegt, dass dem Benutzer keine Option wie „Diese Verbindung ist nicht sicher, trotzdem fortfahren?“ angeboten werden darf. Voraussetzung für HSTS ist allerdings, dass dieser Browser die echte Website schon einmal über HTTPS erreicht und den Header erhalten hat. Ist der allererste Zugriff eines noch unberührten Geräts direkt eine gefälschte Website, greift HSTS nicht. Diese Erstzugriffslücke füllt die im Browser fest eingebaute Preload-Liste.

Was ändert sich, wenn der private Schlüssel eines Client-Zertifikats im TPM gespeichert wird?

Der private Schlüssel lässt sich dann nicht mehr von diesem Geschäfts-PC entfernen. Ein privater Schlüssel, der als Datei auf dem Gerät liegt, lässt sich kopieren und auf einen privaten PC übertragen – und dieser PC besteht dann die Authentifizierung, als wäre er der Geschäfts-PC. Wird der Schlüssel dagegen im TPM erzeugt und so gehalten, dass er sich nicht exportieren lässt, finden Operationen wie das Signieren ausschließlich innerhalb des TPM statt, und der Schlüssel selbst gelangt weder an das Betriebssystem noch an Schadsoftware. Im Ergebnis kann EAP-TLS nur noch von den vom Unternehmen ausgegebenen Geschäfts-PCs erfolgreich durchlaufen werden. Deshalb konnte Herr S sagen: „Bei dieser Speichermethode ist das kein Problem.“ Bei der Umsetzung unter Windows gibt man im Zertifikatvorlage-Schlüsselspeicheranbieter Microsoft Platform Crypto Provider an und lässt den Export des privaten Schlüssels nicht zu. Das TPM schützt aber nur davor, dass der Schlüssel auf ein anderes Gerät kopiert wird – wer das Gerät physisch besitzt, kann es weiterhin benutzen. Gegen Verlust oder Diebstahl des Geräts braucht es zusätzlich eine Laufwerksverschlüsselung und einen Weg, das Zertifikat zu widerrufen.

Was sollte man aus dieser Aufgabe für die eigene Praxis mitnehmen?

Vier Dinge. Erstens: Denken Sie bei Gegenmaßnahmen gegen Datenabfluss in Wegen, nicht in Mitteln. USB-Stick, E-Mail-Anhang und Webmail einzeln zu sperren, bringt nichts, wenn ein Gerät übrigbleibt, das die Dateien noch erreichen kann. Zweitens: Schreiben Sie auf, welchen Bereich eine Beschränkung auf die Quell-IP-Adresse tatsächlich erlaubt. Teilen sich Gäste-WLAN oder VPN denselben Ausgang, gehören auch sie zum erlaubten Bereich. Drittens: Machen Sie die WLAN-Authentifizierung zu einem Berechtigungsnachweis pro Gerät. Ein Pre-Shared Key ist ein gemeinsames Geheimnis, das alle identisch besitzen – gibt eine Person es preis, ist es für alle preisgegeben. Mit EAP-TLS, Client-Zertifikaten und einem privaten Schlüssel, der das TPM niemals verlässt, wird der Berechtigungsnachweis an das Gerät gebunden. Viertens: Löschen Sie Konfiguration, die nicht mehr benutzt wird. Die letzte Teilaufgabe dieser Aufgabe lässt alle VLAN-Schnittstelleneinstellungen und Firewall-Filterregeln aufzählen, die nach der Abschaffung des Gäste-WLANs übrigbleiben – laut IPAs Auswertungskommentar war die Erfolgsquote hoch, doch in der Praxis ziehen das nur wenige Organisationen tatsächlich konsequent durch.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.