Sicherheit

[Cuidas]

Mir wurde jetzt zum zweiten Mal im letzten halben Jahr der TS-Server gehacked. So langsam kotzt mich die Sache an, vor allem, weil ich nicht weiss, wie der %&$!§"§$ das geschafft hat. Ich geb meinem Server jetzt noch eine letzte Chance. Nur würde mich bevor ich den Server neu einrichte mal interessieren, wie ihr eure Server absichert. Im Forum tauchen immer mal wieder Tips auf, aber vielleicht können wir das hier ja mal sammeln! Und bitte keine Tips, wie ich den Linux-Server an sich absichere, sondern nur rein das Teamspeak! Der/Die Hacker hatten definitiv keinen Zugriff auf meinen Linux-Server!

Ich danke euch schon mal!

[AndreasB]

nochmal zu den "hackermethoden". also es gibt da eigentlich nur zwei möglichkeiten: entweder derjenige hat dein SA passwort erraten oder er hat diese berühmte tastenkombination von einem SA bekommen und hat somit auch SA. um das mit der tastenkombi ausszuschließen registriere deine ganzen servadmins und nimm unter SA benutzerrechten einfach die <privilegegrantSA> und <revokeSA> raus. dann kannste wenigstens noch in deinen TS admin bereich, falls du schneller als der overtaker bist. wenn du superadminrechte hast ist das sowieso egal.

[Cuidas]

Danke für den Tip, aber ich muss dir widersprechen:

Es gibt mehr Methoden, als diese 2! Denn

-Meine SAs hatten so wenig Rechte, einen SA-Account zu knacken hätte ihm gar nichts grossartiges gebracht....

-Und mein Superadmin-Passwort zu knacken, da brauchts schon irgendwelche hellseherischen Fähigkeiten! ;)

Also muss der Kerl anders zugegriffen haben. Aber Brain hat mir da per PM schon weitergeholfen!

[guldi]

Dann wärs toll wenn du (oder Brain) die Tips hier posten würdest, ansonsten ist diese Thread vollkommen nutzlos !
Thx

[AndreasB]

jepp! her damit .... :rolleyes:

[Brain]

Es geht im Prinzip darum, daß es sehr wahrscheinlich ist, anderen "Befehle" unterzuschieben, da bei der Benutzeridentifikation nicht konsequent noch die IP-Adresse mit einbezogen wird.
Das kann jeder mit dynamischer IP-Adresse (deutsche Telekom z.B.) der einen remote laufenden Teamspeak-Server hat im Selbstversuch ausprobieren.
Erstmal die logging-Einstellungen an damit man was im Log hat, dann connecten. Wenn man auf dem Server ist ins Log schauen. Da steht die aktuelle IP-Adresse, nennen wir sie jetzt mal IP1 drin. Schaun wir in den Client, IP-Adresse anzeigen, zeigt auch IP1.
Jetzt kommt der Trick mit doppeltem Boden ;)
Internetverbindung trennen und gleich wiederherstellen. Das ist wichtig damit es keinen Timeout gibt. Jetzt hat man auch einen neue IP-Adresse, nenen wir sie mal IP2. Schaun wir nochmal in den Client, er zeigt IP2 an. Labern und so geht immer noch, falls Leute im Channel sind merken die noch nicht mal daß du kurz ohne Internetverbindung warst, denn du bist ja nicht aus dem Teamspeak geflogen.
Wenn man parallel dazu eine SSH-Sitzung laufenläßt (TCP-Verbindung) oder ein Spiel, z.B. Unreal Tournament (UDP) fliegt man in beiden Fällen raus - der Spieler wird nicht nur anhand einer internen ID-Nummer sondern auch anhand seiner IP-Adresse identifiziert. Nur bei Teamspeak fliegt man nicht da die Identifizierung der Benutzer anscheinend nach erfolgreichem Aushandeln der Verbindung nur noch über die pid erfolgt.

Mit Kenntnis des von Teamspeak verwendeten Übertragungsprotokolls und der pid (die einfach zu erraten ist, weil immer mit 1 angefangen wird) könnte man im Namen anderer "Befehle" absetzen, also z.B. Privatnachrichten verschicken. Vielleicht kann man das noch ausbauen und sich von dem Benutzer auch noch den Voicestream schicken lassen um ungesehen mithören zu können.

Auf die Art und Weise wäre es theoretisch möglich, einen Teamspeak-Server zu übernehmen indem man auf die Art und Weise einfach den Admin "übernimmt". Folglich wäre die einzige Art der Verteidigung gegen diese Art von Angriff, einfach nur noch als unregistrierter oder registrierter Benutzer auf den Server zu gehen, bloß nicht mit SA-Rechten, oder alternativ die SA-Rechte entsprechend beschneiden. Alles was sonst noch an Verwaltungsarbeit anfällt würde ich dann per TCPQuery erledigen. Das ist zwar umständlich, geht aber auch.


Soweit meine Beobachtungen und Interpretation derselben :)

[R. Ludwig]

@brain:
das taktisch schon ganz richtig. nur fehlt da noch etwas ohne das dieses nicht klappen wird. da muss schon jemand extrem brutforcen oder man in the middle spielen.

[Brain]

Ah, ich nehme an es gibt im Stream-Protokoll ein Äquivalent zur TCP-Sequenznummer? Hoffentlich ist die auch lang genug und zufällig genug damit man sie nicht einfach erraten oder gar berechnen kann.

[R. Ludwig]

4 byte haben wir spendiert.
wie der zufall halt so berechenbar ist...

[Brain]

32 Bit, das sollte ausreichend sein. Was passiert eigentlich mit Paketen die eine Sequenznummer tragen die in der "Zukunft" liegt?

[R. Ludwig]

wenn der unterschied zur aktuellen nicht zu hoch ist werden sie, kommt allerdings noch auf den type an, zwischen gespeichert.

[d3NaTI0n]

sehr interresannte discussion hier... glei ma gereggt.

Also ich vermiete selber server und habe einen hack oder "overtake" gerade eben miterlebt... wie der des genau gemacht hat weis ich ned... nur dass er sich selber rechte geben konnte wie er auf dem server war. Das heisst entweder per telnet eben oder er hat reconnectet. Meiner meinung nach hat er man in the middle gespielt, was bei ts nich schwer sein sollte, oder wird die verbindung verschlüsselt übertragen?? kann ich mir ned vorstellen wegen der performance...

Ich hatte vor kurzen eine 3-tage schulung über ipv6 und diverses anderes. Ein teil davon war auch datenpackete zu zerlegen, sprich in header footer usw.

Das war sehr interesannt, und ich mus LEIDER sagen datenpackete zu manipulieren ist sehr sehr einfach. Demnach seh ich kein problem diverse abgesendete daten von einen SA so zu manipulieren dass sich daraus eine befehlskette wie "gib mir SA, banip..." ergibt. Ich versuche dass jetzt bei einen meiner server nachzuvollziehen, hab aber noch keine ahnung WIE ich die daten eines SA´s abfange... seine ip zu erhalten sollte eigentlich auch kein problem sein. Leider funktioniert des bei mir jedoch noch nicht, schuld ist dass fastpath des test- sa´s denke ich.

Somit bleibt dass alles für mich vorerst theorie.

mfg
dee

[d3NaTI0n]

hab mich bissl rumgehört... gegen man in the middle sicherheitsmaßnamen bei linux/unix:

(zitat von http://www.computec.ch/dokumente/spoofing/ip-spoofing2/ip-spoofing2.html)

"...Vorsicht ist besser als Nachsicht...

Eine einfache Lösung, um diesen Angriff zu verhinden ist es, nicht auf die Adressenbasierte Authentifizierung zu vertrauen. Schalte alle r* Befehle ab.
Entferne alle .rhosts-Dateien und leere die /etc/hosts.equiv Datei. Dies wird alle User zwingen, andere Mittel für einen "Remote Access"
zu versuchen (telnet, ssh, skey, usw.).

Wenn Deine Site eine direkte Verbindung zum Internet hat, kannst Du Deinen Router als Hilfe nutzen. Als erstes stellst Du sicher, dass nur die Hosts
in Deinem internen LAN Vertrauensverhältnisse aussprechen können (kein interner Host sollte einen Host ausserhalb des LANs vertrauen). Dann filtere
einfach jeden Verkehr von ausserhalb (aus dem Internet) aus.

Eine offensichtliche Methode, um IP-Spoofing zu unterbinden, ist die Notwendigkeit, jeglichen Netzwerkverkehr zu verschlüsseln oder authentifizieren zu lassen. Während bereits verschiedene derartige Lösungen existieren, wird es aber noch eine Weile dauern, bis solche Mittel zu Defacto-Standards werden.

Da die Sequenznummern nicht zufällig gewählt werden (oder zufällig erhöht werden), ist diese Attacke hier wirksam. Bellovin hat einen Fix für TCP
geschrieben, dass eine Partitionierung der Sequenznummer-Bereiche enthält. Jede Verbindung würde nach wie vor inkrementiert werden, jedoch würde es keine offensichtliche oder angedeuteten Beziehung zwischen der Nummerierung in diesen Bereichen geben. Empfohlen wird folgende Formel:

ISN=M+F(localost,localport,remotehost,remoteport)
M ist ein 4 Mikrosekunden-Timer und F ist ein kryptografischer Hash. F darf nicht von ausserhalb her berechenbar sein, ansonsten kann der
Angreifer weiterhin die Sequenznummern errechnen. Bellovin schlägt vor, dass F ein Hash von der Verbindungs-ID und ein geheimer Vektor ist (eine
zufällige Nummer oder ein Host-abhängiges Geheimnis verbunden mit der Boot-Zeit der Maschine). "

dabei gehts um die verhinderung von ip-spoofing, auch man in the middle genannt, womit man wie im lezten post beschrieben einen ts server durch datenverkehr manipulation "hacken" kann