Category Archives: Security

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 😀

Microsoft verliert Schlüssel für Secure Boot Hintertür!

Posted on by

„It’s True — There is no such backdoor that only its creator can access.“

Meint, es gibt keine Hintertür in Produkten, die nur der Hersteller nutzen kann.

Die Firma Microsoft hat irrtümlich die Schlüssel für eine Hintertür zum UEFI Secure-Boot veröffentlicht.M$ hatte für Entwickler eine Funktion im UEFI Boot zum Debuggen signiert, die ganz am Anfang läuft. Diese schaltet dann die Signaturchecks für das OS ab, was dazu führt, daß nun Jeder auf jedem Rechner alles installieren und starten kann. Also genau das, was Secure Boot eigentlich verhindern sollte.

Der Gag: Microsoft kann es nicht mehr beheben.

Linux Distributionen nutzen bislang einen eigens von Microsoft signierten Key zum Starten, wenn Sie unter Secure Boot funktionieren sollen. Dies dürfte damit überflüssig geworden sein 😀

Quelle: thehackernews.com

Update:

Zur Klarstellung: Einen „Schlüssel“ im Sinne eines RSA-Schlüssels gibt es nicht. Es gibt signierte Bootmanager für UEFI, die die Abschaltung der anderen Bootmanager erlauben. Das ist der „Schlüssel“ zur Hintertür um Secure Boot zu umgehen.

BSI versendet Emails ohne TLS Verschlüsselung

Posted on by

Mit Werbewirksamen Aktionen haben große Hoster wie 1und1, DTAG, GMX & Co. vor 2 Jahren damit geworben, daß sie auch endlich SSL/TLS zum Verschlüsseln von Emails auf dem Transportweg einsetzen. Die DTAG (Deutsche Telekom AG ) fiel dabei besonders negativ auf, weil sie der letzte Hoster in Deutschland war, der TLS aktiviert hat.

Heute nun mußten die Admins der Firma Evolution Hosting, die seit Anbeginn der TLS Era SSL und TLS Verbindungen zu Ihren Emailservern unterstützt hat, feststellen, daß ausgerechnet das Bundesamt für Sicherheit in der Informationstechnik (BSI) noch EMailserver aus der digitalen Steinzeit nutzt, die nicht per se TLS zum Senden von Emails benutzen.

Opensource Emailserver wie Exim oder PostFix senden grundsätzlich mit aktiviertem TLS, wenn der empfangene Server das zuläßt.

Damit ist das BSI aber nicht alleine, denn Massenemails werden auch von anderen prominenten TLS Verweigerern weiterhin ungeschützt verschickt, teilweise mit Kundenummer und Anschrift im Emailnachrichtenteil. Mit dabei sind u.a.:

otto.de
deichmann.com
weltbild.de
buerger-cert.de  (BSI)
braunschweiger-zeitungsverlag.de

Dabei schneiden sich diese Unternehmen selbst ins Fleisch, denn immer mehr Server nehmen nur noch TLS Verschlüsselte Verbindungen an, da Spambots i.d.R. unverschlüsselt senden wollen. Dementsprechend groß war der Spameinbruch, nachdem EvH diese Option für seine Kunden aktiviert hatte.

Ein Lichtblick

Das BSI hat innerhalb von 20h reagiert und Abhilfe versprochen:

Sehr geehrte/r Frau/Herr *******,

vielen Dank für den Hinweis. Wir werden dies abstellen.

Mit freundlichen Grüßen
das Team CERT-Bund