Vor einer Woche habe ich auf das Full Disclosure Posting zu dem Teamspeak 3 Schwachstellen hingewiesen. Dabei fiel der vom Poster benutzte Name „Hanz Jenson“. Die Redakteure von Heise.de haben etwas genauer hingeschaut, und einen Alias gefunden „ff214370685e536b9ee021c7ff6b7680bfbe6008bc29f87511b6b90256043536“.
Jetzt bleibt nur noch die Frage : Wer versteckt sich hinter diesem Sha256 Hash ?
Sachdienliche Hinweise dazu nimmt jedes Blog, Heise oder mein Briefkasten auf.
Teamspeak bietet weiterhin keinen Patch für die Lücken an, die der FullDisclosure Poster offengelegt hat. Ganz verstehen tue ich die Geheimniskrämerei nicht, denn die Lücken zu posten ist legitim um sie beseitigt zu bekommen. Natürlich wäre eine Vorab Info an TS schön gewesen. Da aber keine konkreten Exploits aufgetaucht sind, hat der Poster IMHO nichts zu befürchten, denn jeder kann zu Hause seine Programme auf Sicherheitslücken hin abchecken.
Es gibt eigentlich nur zwei Gründe wieso er sich nicht outet: Er arbeitet bei TeamSpeak , oder er hat Angst vor unserem schwammigen Hackerparagraphen. Der Hackerparagraph müßte eh mal vom Bundesverfassungsgericht abgeklopft werden, schliesslich ist in dem viel zu viel Gummi enthalten. Das verstößt sicher gegen EU Regulierungen 😉
Update vom 20.8. :
Es steht eine TeamSpeak 3.0.13.3 Downloaddatei für den Server bereit. Intressanterweise gibt den üblichen Anounce zu dieser Version nicht ( TS3 – Latest News ). Dafür aber in der Bugssektion eine rege Diskussion :
http://forum.teamspeak.com/threads/126508-0-day-vulnerabilities-in-server-3-0-13
Kleinere Zitateauswahl:
„
Teamspeak Server crash => MergedNext exploit for ver 3.0.12.4 — 3.0,13″
„Hotfix for TeamSpeak vulnerabilities [till 3.0.13]
i tested on my server working crash my server, but i added a line iptables, tools send length 315, i drop this packet on iptables and working for me
-A INPUT -p udp -m udp -j DROP –match length –length 300:350“
Anscheinend hat der Entdecker versucht, den Hersteller im Forum zu erreichen. Seine Hinweise wurden wohl als Crashes abgetan und die Sicherheitslücken unter den Teppich gekehrt. Es gab auch ein Update, aber keiner weiß, welche Lücken dort geschlossen wurden. Ich hab das auch mal kurz zusammengeschrieben: https://blog.tausys.de/2016/08/19/teamspeak-wirbel-um-0day-luecken/.
Ich setze Teamspeak seit Jahren ein und kann bestätigen, dass die Entwickler sich durch ihre Art sich selbst etwas gehoben verkörpern und man nur schwer ein ernsthaft offenes Ohr erhält.
Man sollte solche Dienste sowieso in einer virtuellen bzw. chrooted Umgebung laufen lassen damit ein potentieller Hacker nicht ausbrechen kann (Wenn der TS gehackt wird – wen interessierts..), aber wir Menschen sind zu Faul dazu – oder die Wege dahin sind bis heute viel zu kompliziert. Ein Debootstrap & co kotzt mich heute noch an, viel zu viel Aufwand bis dann alles läuft.
An mich ist ein Freund herangetreten, ob ich nicht eine TS-Instanz für ihn hosten kann. Schon damals war klar, dass ein closed source service nur in einer eignen VM möglich ist! Sofern man bereits einen laufenden Host mit anderen Guests und geeigneter Netzwerkinstallation hat, ist das Aufsetzen einer neuen VM ein Kinderspiel von vielleicht 15 Minuten, wobei die meiste Zeit für den Kopiervorgang selbst drauf geht, sofern man nicht ein Image einer Grundinstallation rumliegen hat.
Aber ja, viele Anwender dürften aus Kostengründen ihre TS-Instanz auf dem gleichen gemieteten vServer laufen lassen auf denen vielleicht auch die Webseite, das Forum, die Datenbank und was noch alles gleichzeitig liegt. Dann hat man wirklich ein Problem. TS ist ja bis jetzt nicht in der Lage, DEB- und RPM-Pakete zu bauen, noch gibt es irgendeinen Updatemechanismus für den Server. Für Anwender, die einfach nur sicher und zuverlässig einen TS-Server betreiben möchten ist das keine gute Voraussetzung.
Also TS in eine Chroot zu zwingen ist nicht so schwer. Das kann man durchaus machen. Es darf in der Chroot nur keinen User 0/Root geben.
Klar. Aber ein Problem hat man dann trotzdem noch: die Anwendung hat Zugriff auf alle Services, die auf 127.0.0.1 bzw. ::1 lauschen. Z.B. memcached, alte MySQL-Installationen, PHP-FPM und evtl. noch andere Sachen.
Was ja nicht automatisch heißt, daß ein Hacker daraus Profit schlagen könnte. Das kritischste was ich dabei sehen kann,
wäre der privligierte Versand von SPAMS über 127.0.0.1 bz. überhaupt die Möglichkeit zu haben ein Programm zu starten.
Die meisten Scriptkids versuchen nach so einem Hack einen lokalen Root Exploit zu starten, stellen fest, daß sowas in einer Chroot in Ermangelung von Root nicht geht und geben dann enttäuscht auf. Und spätestens an den Zeitpunkt hat das NIDS sie bereits gemeldet.
Nachtrag: TS3 hat 5 Tage nach dem Post von „Jansen“ einen Hotfix herausgebracht – aber es ist nicht klar, ob dieser diese Lücken schliesst oder nicht. Gibt es Informationen von „Jansen“, ob seine Exploits noch funktionieren?
Seit dieser Lücke hat TS3 drei Patches veröffentlicht, einer davon 5 Tage danach mit dem Changelog „- fixed several vulnerabilities.“
=== Server Release 3.0.13.3 19 august 2016
– fixed a problem where virtual servers refuse to start due to invalid flags or order
– fixed a crash in fix crash on servergroupautodelperm / servergroupautoaddperm
=== Server Release 3.0.13.2 15 august 2016
– fixed a crash introduced in 3.0.13.1
– fixed a deadlock in the server causing some instances to hang / be unresponsive
– fixed a crash reported by a customer.
=== Server Release 3.0.13.1 15 august 2016
– fixed several vulnerabilities.
Falls Ihr wissen wollt, wie man das mit der chroot so macht :
…/chrootwrap teamspeak /home/teamspeak/ts3server_startscript.sh start
wobei der chrootwrap ein C Programm ist das folgende Schritte durchführt:
chroot(„/opt/teamspeakumgebung“)
chdir(„/“)
SwitchUser(username)
SetLimits();
und schon ist TeamSpeak als Gefahrenstelle entschärft.
So eine Teamspeakumgebung sieht aus ein normales System, nur das alles fehlt, was Teamspeak nicht braucht und das ist der „interessante Puzzelteil“ 🙂
0 lrwxrwxrwx 1 root root 7 8. Dez 2014 bin -> usr/bin
4 drwxr-xr-x 4 root root 4096 9. Mär 13:46 dev
4 drwxr-xr-x 17 root root 4096 20. Aug 12:30 etc
4 drwxr-xr-x. 11 root root 4096 20. Aug 11:48 home
0 lrwxrwxrwx 1 root root 7 24. Feb 2014 lib -> usr/lib
4 drwxr-xr-x 2 root root 4096 14. Aug 2012 opt
0 dr-xr-xr-x 291 root root 0 20. Aug 11:46 proc
4 drwxr-xr-x 2 root root 4096 9. Mär 13:46 root
4 drwxr-xr-x 2 root root 4096 20. Aug 00:32 sbin
68 drwxrwxrwt 6 root root 65536 20. Aug 10:37 tmp
4 drwxr-xr-x 10 root root 4096 13. Aug 2015 usr
4 drwxr-xr-x 7 root root 4096 10. Feb 2015 var
/proc braucht man nicht unbedingt, /sys auch nicht.