Designfehler in TCP RFC

Moin,

wer gestern und heute die News gelesen hat, der wird über den Beitrag zum TCP Fehler in Linuxkernel gestolpert sein.

Was ist passiert ?

Einigen findigen Forschern/Hackern ist es gelungen, einen Designfehler in einem per RFC vorgegebenen Standard zu finden. Damit ist es möglich eine TCP Verbinden zu beeinflussen z.b. Sie von extern zu beenden oder Daten einzuschleusen. Wählt der Angreifer das Paket günstig aus, kann er z.b. Schadcode in eine Webseite einschleusen auf dem Web von Server zum Betrachter. Er kann auch herausbekommen, ob Server A mit einer xbeliebigen anderen IP Adresse grade eine Kommunikation hat.  Was aber nicht geht ist, herauszubekommen, mit wem ein an der Verbindung beteiligter spricht, wenn man nicht genau auch der IP sucht. Mit anderen Worten, man müßte sehr viele Kombinationen durchprobieren, und zwar genau während eine Verbindung besteht.

Möglich wird das über einen festen globalen Zähler, der es durch geschicktes Ausnutzen von Datenpaketen und deren Antworten erlaubt, vorherzusehen, wie die nächste gültige Sequenznummer in einem TCP Paket aussehen wird, so daß man als Angreifer genau diese Sequenznummer benutzen kann.

Die Bewertung

Gerade bei Webseiten werden die TCP Verbindungen aber i.d.R. sehr schnell wieder geschlossen, so daß der Angreifer schon verdammt viel Glück haben muß. Interessanter sind Angriffe schon auf Downloadportale, wo die Verbindungen auch mal eine Stunde vorhanden sind, weil GBweise Daten transportiert werden. Allerdings dabei einen funktionierenden INJECT hinzubekommen, in eine unbekanntfortgeschrittene Datenübertragung, wäre praktisch unmöglich.

Der Angriffsvektor ist zwar heftig, aber muß schon genau wissen wen man angreifen will. Zufällige Besuche von IP A auf Server B beim Surfen sind also extrem unwahrscheinlich als Ziel.

Zudem kommt ein Laufzeitproblem im Netz dazu, so daß man selbst als Angreifer in der Nähe des Ziels  sein müßte, da mit jedem HOP im Netz, die Laufzeitschwankung größer wird und man ungenauere Werte ermittelt. Je ungenauer der Wert den man als Angreifer für die nächsten Sequenznummer ermittelt, desto niedriger die Erfolgsrate.

Gegenmaßnahnen

Serveranbieter, die Linux einsetzen, können jetzt einfach den globalen counter individuell hochsetzen, so daß ScriptKids, die Tools zum Injecten einsetzen werden, eine schlechte Ausgangsbasis haben. Und das geht so :

Fedora/RedHat/CentOS:

  1. echo “net.ipv4.tcp_challenge_ack_limit = 999999999”  > /etc/sysctl.d/1-tcp-challenge-ack.conf
  2.  “sysctl -p” zum Updaten der Konfiguration eingeben.

Ubuntu/Debian/Mint:

  1. Open /etc/sysctl.conf, append a command “net.ipv4.tcp_challenge_ack_limit = 999999999”.
  2. Use “sysctl -p” to update the configuration.

Ich für meinen Teil würde empfehlen, den Wert nicht auf 99999999 zusetzen, sondern den Wert per $Random zu setzen. Das verwirrt die Angreifer noch viel mehr. Und per Cronjob einmal die Minute den Randomwert ändern 😀 Dann hat man schon genau das, was den Kernelpatch später auch ausmachen wird 😀

F5 Firewalls ?

Wer täglich die Warnung des Cert liest, wird die Firma F5 mit Ihren Firewalllösungen kennen, ob wir Sie mögen sollten, ist eine andere Sache. Jedenfalls sind die in letzter Zeit Dauergäste in den Emails des Cert.

Heute konnte ich in einer Meldung zu einem lokalen Kernelprivilegienescalation Problem folgendes lesen:

Version 1 (2015-04-30 14:38)
Neues Advisory
Version 2 (2015-05-04 11:00)
Für die Distributionen Fedora 20, 21 und 22 stehen Sicherheitsupdates zur Behebung der Schwachstelle bereit. Die Updates für Fedora 20 und 21 befinden sich im Status ‚testing‘, das Update für Fedora 22 im Status ’stable‘.
Version 3 (2015-05-06 09:32)
Canonical stellt für die Distributionen Ubuntu 12.04 LTS inkl. Trusty HWE, Ubuntu 14.04 LTS inkl. Utopic HWE, Ubuntu 14.10 und Ubuntu (vivid) Sicherheitsupdates zur Behebung der Schwachstelle bereit.
Version 4 (2016-02-01 10:49)
F5 Networks informiert über die betroffenen Produkte und Versionen. Unter anderem ist BIG-IP Protocol Security Module (PSM) in den Versionen 10.1.0 – 10.2.4 und 11.0.0 – 11.4.1 verwundbar. Um Angriffe zu vermeiden, sollten nur vertrauenswürdige Administratoren Zugang zu der erweiterten Shell haben. Im Appliance-Modus kann die Schwachstelle nicht ausgenutzt werden, da Benutzer in diesem Modus keinen Zugriff auf die erweiterte Shell haben.
Quelle:
DFN-CERT Services GmbH

Da ich natürlich zuerst lese, um was es geht und welche Plattform betroffen ist, fiel mit nicht sofort auf, daß es sich um Kernel 4.0.1 handelte, da entgegen sonst üblichen Emails der Kernel gar nicht genannt wurde. (Das DNF Cert schickt manchmal Emailteaser für Ihr Webangebot rum, für den Fall egal.)

Wenn man nun genauer hinschaut, muß man schon etwas stutzen, da Version 1 der Meldung vom 30.4. 2015 ist und erst heute, am 1.2.2016 F5 merkt, daß sie auch betroffen sind. Von einer Firma aus dem Securitybereich, erwarte ich mir mehr, wenn jede Linuxdesktopdistribution schneller ist, als meine Firewalllösung.

Vielleicht mag der eine oder andere ja mal einen Kommentar dazu abgeben.

Wie schnell sollte eine Unternehmensfirewall reagieren ?

Was ist das maximal Grenze, die noch akzeptabel ist, klar sofort die Norm sein sollte.