Modifiziertes gw-schedule-Script V2 (2009-12-21)

fixt Sicherheitslöcher in den US-Trust-Tools

Die US-Trust-Tools haben mehrere Sicherheitslöcher, die teilweise bekannt sind.
Ein konkretes Beispiel, womit ich mich im Juli 2009 an Brian Roode (NJ6N), den Autor der dsync-Server-Software und der dsync-Scripte gewendet habe, ist das gw_schedule Tool. (auf jedem DStar-Gateway-Server am US-Trust-System unter /dstar/scripts/gw_schedule zu finden)

Dieses Tool öffnet einen Zugang vom Internet mit root-Rechten nicht nur zum DStar-Gateway, sondern indirekt zu dem ganzen Netz in dem es betrieben wird.



Funktionsweise von gw_schedule:

Das Script verbindet sich per cron gesteuert alle 15 Minuten mit dem Server dsyncg2.dstaruser.org (genauer gesagt, es verbindet sich zu einem Server, der sich unter diesem Hostnamen meldet)

Die komplette Kommunikation läuft ohne jede Authentifizierung, unverschlüsselt im Klartext.
Weder der dsync-Server weiß also welcher Client sich anmeldet, noch das Client-Script, ob es wirklich beim richtigen Server gelandet ist.

Der Verbindungsaufbau erfolgt über Hostnamen, nicht per fixer IP (d.h. „DNS-Spoofing leicht gemacht“).

Das Script gibt es zum Analysieren der Kommunikation und Funktion für Jedermann frei Haus zum Runterladen im Web.
Adressen und alles was man sonst zum Hacken braucht stehen drin.

Auf dem vom Script erreichten Server liegt eine ASCII-Tabelle, mit dem Namen „schedule_data“, die Felder sind per Tab separiert.

Diese Tabelle ist offen zugänglich und für Jedermann per Browser abrufbar.
Es hat folgendem Aufbau (Muster):

200907171435    DB0LJ   status

200907171515    DB0MYK  sendfile        http://dstar.prgm.org/test.sh       test.sh

200907171516    DB0MYK  runscript       test.sh

200907171640    DB0LJ   runscript       test1.sh



Dies ist eine Musterdatei, die liegt auf meinem Server, ist getestet und mit dem gw_schedule-Script voll funktionsfähig!
Eine Anleitung, wie man das mit dem eigenen Gateway ausprobieren kann gebe ich gerne per EMail.

Vorne steht die genaue Uhrzeit, wann ein bestimmtes Gateway eine Funktion ausführen soll.

Danach folgt das Call des Gateways, was etwas tun soll. Dort kann auch der Platzhalter „ALL“ stehen, dann machen das alle eingeschalteten Gateways zur angegebenen Zeit weltweit.

Danach folgt ein Befehl, der ausgeführt werden soll:

o   Das kann z.B. der Befehl „status“ sein, dann meldet das Gateway seinen Status an den Server zurück.

o   „Sendfile“ veranlasst das Gateway sich aus dem Internet von irgendeiner nachfolgend angegebenen Adresse ein File runter zu laden und unter dem Namen am Ende der Zeile lokal abzulegen.
„File“ kann alles sein, von einem Script bis hin zum fertigen Installationspaket für einen SSH-Tunnel zu einem Rechner im Internet.

o   Der Befehl „runscript“ führt das dahinter angegebene Script mit root-Rechten aus („root“ ist der Administrations-Account auf LinuX-Systemen). Das kann das File sein, was gerade von irgendwo geladen wurde oder eine neue Firewall-Config, ein Script was die Passwortdatei modifiziert oder ersetzt, beliebige Useraccounts anlegt, Dstar-User anlegt oder die Festplatte neu partitioniert und formattiert..

o   Es gibt noch mehr Befehle, die der Server akzeptiert, aber die 2 letzten reichen um ein Gateway komplett neu aufzusetzen.

Die generelle Funktionalität finde ich sehr gut, das ist für Leute, die von Linux keine Ahnung haben – die einfach nur ein Gateway betreiben wollen ohne einen Linux- oder Netzwerk-Admin-Lehrgang zu machen - absolut genial.
Kritisch ist die Sicherheit dieser Sache, denn das Ganze läuft ohne jede Authentifizierung.

Damit kann ich jedes Gateway stoppen, starten, stören, neu formatieren, Passwortdateien austauschen, Emails versenden und beliebige Dinge downloaden oder aber z.B. auch einen Tunnel vom Gateway ins Internet aufbauen und damit ein Loch in die Firewall eines Routers bohren, um von außen ins Netz einzu- steigen in dem das Gateway hängt. Es besteht damit nicht nur eine Gefährdung des DStar-Gateways, wo mancher sagt „das ist mir egal, da sind keine kritischen Daten drauf, das installiere ich schnell neu“, es besteht auch die Gefahr für das Netz in dem das Gateway betrieben wird.

Ich halte es für fair, wenn die Sysops von Gateways am US-Trust-System diese Sicherheitslücke zumindest kennen, dann können sie selbst entscheiden, ob sie sie in Kauf nehmen.

Ich selbst betreibe das betreffende Script aus den angegebenen Gründen bei DB0MYK schon lange nicht mehr (bei http://dsyncg2.dstarusers.org/index.php?gw_status=DB0MYK zu erkennen).

Ich stelle diese modifizierte Script-Version gerne zur Verfügung, sie schließt diese Lücke, es bleiben dann noch ein paar andere kleinere. 

Mit dieser Scriptversion sind keine automatischen Updates mehr möglich, sie werden zwar vom Server geladen und eine Benachrichtigung erstellt, sie werden aber nicht ausgeführt.
Auch die Befehle "Reboot" und "Stop" werden ignoriert.

Wer übrigens meint, das Flagfile "gw_schedule.noupdate" würde dasselbe bewirken, der irrt sich.
Das Herunterladen und Ausführen von Scripts wird von gw_schedule ungeachtet dieses Flags direkt durchgeführt!
Das Flag hat nur Einfluss auf Script-Updates, die von "update_scripts_g2" durchgeführt werden.


Mein Tip solange diese Funktion vollkommen ohne Authentifizierung abläuft:
Herunterladen von automatischen Updates ja, aber vor dem Ausführen zuerst hineingucken oder Rückmeldungen anderer abwarten, die den notwendigen Sachverstand haben.

Kurz zu den Änderungen und zur Installation:
Ich habe bewusst nicht gross "dran rumgebastelt" und irgendwelche schwer zu durchschauenden Dinge eingebaut. Es ist nicht meine Absicht Perl-unerfahrene Sysops zu verunsichern.
Im modifizierten Script sind die "gefährlichen Aktionen" auskommentiert.
Man lässt am besten das Original auf der Platte, spielt das neue unter einem anderen Namen auf und ändert den Aufruf in der Crontab entsprechend auf den neuen Namen ab (crontab -e). Bei mir sieht das dann so aus:

# US Root Administration Scripts
#0-59/15 * * * * /usr/bin/perl /dstar/scripts/gw_schedule
0-59/15 * * * * /usr/bin/perl /dstar/scripts/gw_schedule.dl5di

Die erste Zeile / Das Original wurde auskommentiert, die zweite startet meine eigene Scriptversion.

Das verhindert, dass das Script auf der Statusseite als "modifiziert" angezeigt wird, es wird weiterhin die Checksumme des Originals geprüft, aber die modifizierte Version genutzt.
(Das funktioniert bei anderen geänderten Dateien natürlich auch, z.B. wenn man Zugriff auf die Datenbank von einem anderen PC erlauben will und dazu die postgres.conf ändert)

 

Vy 73 

Hans-Jürgen, DL5DI
http://dl5di.prgm.org
SysOp @DA5UDI, DB0LJ, DB0MYK

Packet-Radio-Gruppe-Mittelrhein e.V.
http://www.prgm.org
Tel.: 02652 - 93 83 77
Skype: DL5DI