Angriffe auf der Leitung und auf Dienste

Der Networking-Track hat dir den TLS-Handshake und die Zertifikatsprüfung bereits gezeigt. Die Sicherheitsfrage danach ist enger und nützlicher: Was kann ein Angreifer auf dem Pfad noch tun, wenn TLS korrekt implementiert ist? Die Antwort ist mehr als nichts und viel weniger als alles, und interessant ist genau, wo die Grenze verläuft. Alles Folgende setzt voraus, dass das Protokoll korrekt umgesetzt ist. Kaputte Implementierungen sind ein eigenes Thema und ein viel selteneres, als die Schlagzeilen nahelegen. TLS gibt dir drei Dinge. Vertraulichkeit, damit die Bytes auf der Leitung nicht lesbar sind. Integrität, damit ein verändertes Byte erkannt und nicht akzeptiert wird. Und Authentifizierung des Servers, damit du weißt, dass der vereinbarte Schlüssel zu dem Namen gehört, den du angefragt hast. Auf das Letzte zielen Angreifer tatsächlich, denn es hängt von etwas außerhalb des Protokolls ab: deinem Trust Store. Kann ein Angreifer ein Wurzelzertifikat auf deinem Gerät installieren, oder wurde die von dir benutzte Software schon mit einem ausgeliefert, dann gelingt der Handshake, das Schloss erscheint, und der Verkehr wird in der Mitte entschlüsselt. Das ist keine TLS-Schwachstelle. Das ist TLS, das genau wie entworfen arbeitet, mit einem Vertrauensanker, der dort nicht hingehört. Der andere Weg ist einfacher und braucht gar keine Kryptografie: eine Seite, die wie die Anmeldeseite aussieht und es nicht ist. TLS kann nicht helfen, denn das Zertifikat einer ähnlichen Domain ist für diese Domain völlig gültig.

ARP hat keine Authentifizierung. Ein Host fragt, wem eine IP-Adresse gehört, jeder darf antworten, und die Antwort wird zwischengespeichert. In einem Netz, dessen Switch du kontrollierst, ist das ein beherrschbares Problem; in einem geteilten Netz ist es ein Freifahrtschein. Der Angriff ist nicht exotisch und bricht nichts: Er muss nur wiederholt ankündigen, dass eine bestimmte Adresse an deiner MAC hängt, damit die Opfer ihren Verkehr zuerst zu dir schicken. In ein Netz zu wechseln, das dir nicht gehört, ist die praktische Maßnahme, und sie wirkt besser als jede Software, die man hinterher installiert. Warum das auch für verschlüsselten Verkehr zählt, sind die Metadaten. Ein Angreifer auf dem Pfad kann deine Bytes vielleicht nicht lesen, aber er sieht, mit welchen Adressen du sprichst, wann, wie oft und wie viel. Er kann sich auch entscheiden, nicht weiterzuleiten, und verwandelt damit eine passive Position in eine Dienstblockade. Verteidigung am Endpunkt heißt, die Gateway-Adresse an eine bekannte MAC zu binden oder ein VPN zu nutzen, das den gesamten Verkehr zu einem Punkt tunnel, dem du vertraust. Verteidigung am Switch heißt Funktionen, die Ankündigungen verwerfen, die von einem Port nicht kommen dürfen. Beides ist real; keines davon gibt es im Konferenz-WLAN. Die Idee der Faelschung ohne Mechanik. Schaedlich ist nicht die falsche Antwort selbst, sondern ihr Zwischenspeichern.

who has 192.168.1.1? tell 192.168.1.50     <- gateway ARP, normal
who has 192.168.1.1? tell 192.168.1.77     <- repeated, from a laptop

victim ARP cache
  192.168.1.1  ->  MAC of 192.168.1.77    <- poisoned entry

result: victim sends gateway-bound traffic to the laptop first

mitigation  dynamic ARP inspection on the switch
mitigation  port security, one MAC per port
mitigation  encrypted protocols with certificate checkingDer Mechanismus in der Detailtiefe, die zur Verteidigung noetig ist. Er funktioniert, weil die Antwort ohne jeden Beweis geglaubt wird.

DNS ist der Teil des Netzes, der einen Namen in eine Adresse verwandelt, und es wurde entworfen, als das Netz klein war und alle darin vertrauenswürdig. Ein Resolver, der Einträge annimmt, nach denen er nicht gefragt hat, und sie dann zwischenspeichert, wird sie bis zum Ablauf der Time to Live weiter ausliefern. Das ist die Form des Cache Poisoning: Der Angreifer beeinflusst eine Antwort, und der Resolver verteilt sie an jeden Client, der danach fragt. Der Cache ist es, der einen momentanen Einfluss in einen dauerhaften verwandelt, weshalb die Time to Live die Zahl ist, die entscheidet, wie schlimm es wird. DNSSEC signiert Antworten, sodass ein Resolver prüfen kann, dass ein Eintrag aus der Zone stammt, der er gehört, und nicht verändert wurde. Es verschlüsselt nichts und macht die Anfrage nicht privat. DNS over HTTPS und DNS over TLS verschlüsseln die Anfrage, damit ein Beobachter im Netz sie nicht lesen oder umschreiben kann, aber sie beweisen nicht, dass die Antwort richtig ist; sie verschieben nur, wem du vertraust, vom lokalen Netz zu dem Resolver, den du gewählt hast. Die ehrliche Zusammenfassung: Beides ist teilweise, die Verbreitung von DNSSEC ist ungleichmäßig, und der praktische Rat für Nutzer ist, einen Resolver zu konfigurieren, dem sie vertrauen, statt sich auf das zu verlassen, was das Netz ausgibt. Denial of Service ist die Angriffskategorie, in der Verteidigung wirklich schwer ist, und es lohnt, den Grund zu verstehen statt Gegenmaßnahmen zu sammeln. Filtern wirkt, wenn der bösartige Verkehr vom legitimen unterscheidbar ist. Bei einer Dienstblockade ist er das oft nicht: Die Pakete sind wohlgeformt, kommen von echten Adressen und fragen echte Seiten an. Der einzige Unterschied ist, wie viele es sind und wohin sie zielen. Eine Firewall-Regel, die den Angriff verwirft, verwirft auch die Kunden. Das ist gemeint mit der Aussage, dass man nicht filtern kann, was sich nicht von echtem Verkehr unterscheiden lässt, und das ist eine strukturelle Grenze, kein fehlendes Feature. SYN-Cookies sind die klassische Antwort, und sie sind lehrreich wegen dessen, worauf sie verzichten. Statt Zustand für jede halboffene Verbindung zu speichern, kodiert der Server das Benötigte in die Sequenznummer, die er zurückschickt, und prüft es, wenn die abschließende Bestätigung eintrifft. Der Preis ist, dass sich einige TCP-Optionen in diesem Modus nicht aushandeln lassen, die Verbindungen also etwas weniger können. Für einen öffentlichen Dienst ist das trotzdem der richtige Tausch, denn die Alternative ist, dass eine mäßige Menge gefälschter Verkehr den Dienst lahmlegt. Was SYN-Cookies nicht beheben, ist eine Flut vollständig aufgebauter Verbindungen, und deshalb geht der Rest dieser Lektion über Ratenbegrenzung. Ein Amplification-Angriff braucht vom Angreifer nicht viel Bandbreite. Er schickt eine kleine Anfrage mit gefälschter Quelladresse an einen Dienst, der eine große Antwort erzeugt, und die Antwort landet beim Opfer. Das Verhältnis zwischen Anfrage und Antwort ist der Verstärkungsfaktor, und er ist eine Eigenschaft des Protokolls, nicht des Angreifers. Die bekannten Fälle sind alles Dienste, die über UDP ohne Handshake antworten, sodass die Quelladresse nie geprüft wird. Deshalb ist ein offener Resolver, ein offener NTP-Server oder eine exponiert laufende memcached-Instanz kein neutraler Fakt über dein Netz: Es ist eine Waffe, die jemand auf Dritte richten wird, mit deiner Adresse im Absender. Verstaerkungsfaktoren nach Protokoll. Die letzte Zeile ist der Grund, warum memcached auf einer oeffentlichen Schnittstelle zum Notfall wurde und nicht zu einem Konfigurationsfehler. Die Verteidigung hat zwei Hälften, und sie gehören verschiedenen Leuten. Betreibst du den missbrauchten Dienst, schließt du ihn vom öffentlichen Internet ab: Ein autoritativer Resolver darf keine Rekursion für Fremde beantworten, und nichts, das verstärkungsanfälliges UDP spricht, sollte auf einer öffentlichen Adresse lauschen. Bist du das Ziel, brauchst du Kapazität, die dir nicht gehört, in der Praxis also einen Anbieter, der den Verkehr stromaufwärts aufnehmen und filtern kann, bevor er deine Leitung erreicht. Die unbequeme Wahrheit ist, dass die zweite Hälfte Geld kostet, proportional zum Angriff, und keine serverseitige Optimierung ersetzt das. Ratenbegrenzung ist die Maßnahme, die tatsächlich ausgerollt wird, und sie ist eine Studie über Kollateralschaden. Auf jeder Ebene, auf der man zählen kann, gibt es eine Gruppe legitimer Nutzer, die wie ein einzelner Angreifer aussieht. Nach Quelladresse zu zählen bestraft alle hinter einem gemeinsamen Büroanschluss oder einem Carrier-NAT, also die meisten Mobilnutzer. Nach Konto zu zählen erlaubt einem Angreifer mit vielen Konten, unter dem Limit zu bleiben, während ein legitimes Exportskript blockiert wird. Keine Ebene vermeidet das, denn das Limit ist eine Grenze, die durch ein Kontinuum gezogen wird, und sie schneidet immer durch jemanden. Der praktische Entwurf kombiniert mehrere schwache Signale, verteuert die Beschaffung dessen, was du zählst, und sorgt dafür, dass das Limit so versagt, dass es verschlechtert statt bricht. Jede Ebene, auf der man zaehlen kann, und der legitime Verkehr, der darin haengen bleibt. Die richtige Antwort ist meist mehr als eine davon gleichzeitig.

normal open
  client  SYN          ->  server
  server  SYN-ACK      ->  client
  client  ACK          ->  server      connection established

backlog pressure
  client  SYN          ->  server     half-open, in the backlog
  server  SYN-ACK      ->  client     no reply ever comes
  ... thousands more, backlog fills, new SYNs are dropped

SYN cookies  the server answers without storing state
             the ACK carries back everything it needs

cost to the server: one SYN, 40 bytes
cost to the attacker: one spoofed source addressEin SYN-Flood im Detail. Die Asymmetrie, auf der er beruht, ist, dass der Angreifer ein kleines Paket ausgibt und der Server Speicher und einen Timer.