Ich recycle mal einen Artikel vom dieser heise Security Test News. Passt (leider) auch zu diesem Artikel:
"Die Fernwartung von Routern über die TR-Protokolle darf als gescheitert angesehen werden. "
Krasse Fehlinformation, das nervt so... Nach allem was wir wissen war auf den Routern der TR-064(!) Port offen.
TR-064 hat mit Fernwartung der Operators genau gar nichts zu tun
Das ist ein Protocol um das Geraet aus dem LAN(!) automatisiert konfigurieren zu koennen, so aehnlich wie das Admin GUI aber halt nicht fuer Menschen sondern fuer client seitige Software.
TR-064 Basic Message Flow
Client ---- HTTP(s) TR-064 Request ---> CPE (Job, "Hier, neuer NTP Server")
<CPE macht und tut, aendert z.B. ihre config>
Client <----HTTP(s) TR-064 Response --- CPE (JobResult, "Habs getan, noch was?")
Der TR-064 Server Prozess auf der CPE hat also Zugriff auf die Config, auch schreibend und kann alle State Infos abfragen. Riesenprozess, Riesenrechte, so wie der CPE Admin GUI Prozess.
Hat NIX mit Fernwartung zu tun: Der Standard heisst deshalb auch so:
TR064: DSL Forum, LAN(!!)-Side DSL CPE Configuration, 2004
(die "!!" von mir)
Das einige CPE Hersteller den Zugriff auf den TR-064 server auch ueber das WAN(!) ermoeglichen ist deren Sache und man kann sie dafuer berechtigt schelten. Das machen die meistens um lustige Apps zur Kundenbindung liefern zu koennen, die als Client dann die CPE reprovisionieren koennen.
TR-064 wird aber NIEMALS fuer **Operator** Fernwartungszwecke benutzt - weil dafuer gibts TR-069.
TR-069 hat neben Security auch den ganz einfachen Vorteil dass man fuer TR-064 als Client blockend warten muss waehrend der TR-064 Server auf der CPE die Jobs ausfuehrt - was bei paar Mio CPEs nicht so ganz einfach waer.
Bei TR-069 nicht:
So funktioniert TR-069
hoffe so vereinfacht, dass es sogar ein Heise Redakteur endlich mal kapieren koennte(?)
Das ist eine typische TR-069 Session:
CPE: Customer Premise Equipment, steht daheim, z.B. ein DSL Router
ACS: AutoConfig.Server, steht beim Provider
CPE --HTTPs request--> ACS (TR-069 Inform, "hallo hier bin ich, hast du was fuer mich?")
CPE <-HTTPs response- ACS (Job, "Jau, hab was, gib mir mal deine DSL Signalqualitaet")
<cpe fuehrt den Job aus, macht und tut, ACS beantwortet in der Zeit andere Informs)
CPE --HTTPs request--> ACS (JobResult, "Hier die Messwerte, soll ich was aendern?")
CPE <-HTTPs response- ACS (NoJob, "Nee, passt schon, bis dann in einer Stunde,
servus, meld mich wenn ich vorher was brauch.")
Diese sog. TR-069 Inform requests schickt die CPE z.B. nach dem Booten, so dass die nach dem Auspacken und erstem Anschliessen sinnvoll konfiguriert werden kann.
Aber auch periodisch immer wieder mal, so dass die Provider des Nachts z.B. Firmware Updaten koennen aber auch einen Eindruck von der Netz und Servicequalitaet da draussen erhalten.
WICHTIG:
1. Der Server dem sich die CPE hingibt ist FIX. Bei grossen Providern wie der DTAG ist der hart in der Firmware eingebrannt, den kann man nicht einfach mal aendern.
2. Der Server kann alles machen auf der CPE, ausser [wlan/sip/ppp/...]Passwoerter abfragen, die darf sie ihm nicht geben. Er kann sie aber aendern / initial setzen.
3. Der Server hat ca. die gleichen Rechte wie ihr auf dem Admin Frontend des Routers im Experten Modus.
4. Der Server muss, im GGs zu TR-064 nicht warten auf das Job Ergebnis, kann in der Zwischenzeit was anderes tun, und die CPE schickt das Ergebnis als neuen request.
Der CNR Port 7547
Um diesen Port dreht sich eine Menge von heise gestreutem FUD und es wird suggeriert als gingen da drueber reconfig. Vorgaenge, so wie bei TR-064.
Total falsch.
Der Port dient einzig und allein dafuer die CPE auch mal ausser der Reihe dazu zu bringen einen Inform (s.o.) an den ACS zu senden (in der sequenz oben um das "meld mich wenn ich vorher was brauch" zu ermoeglichen).
Deshalb heisst der Connection Request Port.
M.W.n. ist der einzige Use Case fuer den man diesen Port braucht: *Real Time Support*
Also wenn meine Mama bei der Telekom anruft "Das Internet geht nicht gscheid" dann will der Supporter wissen wie's dem Router grad *jetzt* geht und auch detailliertere Infos haben als die, welche eh periodisch abgefragt werden (s.o.).
Dann klickt er einen Knopf auf seinem Support GUI des Servers, das schickt diesen "Connection Request" an Port 7547 der CPE von meiner Mama und diese meldet sich beim Server zurueck, mit einem Inform.
Der Server weiss dann dass der Supporter grad was wissen will und reagiert mit entsprechenden Jobs, welche die CPE ausfuehrt und gibt dem Supporter die Daten die er braucht um meiner Mama zu helfen.
Das aktuelle Problem da draussen
Der Server fuer den CNR use case ist bei einigen Software Staenden da draussen kompromittierbar und wurde angegriffen.
TR-069 ist ziemlich clever designed dahingehend dass der CNR server wirklich nicht viel koennen muss, der muss nur auflegen und einen anderen Prozess (den Tr-069 Inform) starten sonst nix. Leichtgewichtiger und by design sicherer kann man m.A.n. das nicht machen, der 10 Dollar Router Hersteller muss nur einen std. off the shelf http server starten der nix kann ausser TR-069 Informs starten. Sonst keine Rechte noetig. Gutes Design wuerd ich sagen, nicht "gescheitert". Das einzige security Problem des TR-069 CNR ports: DDOS Attacke auf den ACS - mit wenig Benefit fuer den Hacker, der Provider kann halt dann nicht mehr Fernwarten, so what.
Vergleicht das z.B. mal mit dem was ein SNMP/SSH/TELNET/Syslog/GUI Server koennen muss und was es da an Attack Vektoren gibt...
Nun, trotzdem haben es CPE Hersteller offensichtlich geschafft, das Ding kompromittierbar zu programmieren oder, wie es aussieht, den CNR Use Case mal eben in den riesen TR-064 server Prozess reinzubacken.... und damit TR-64 flows aus dem Internet zu erlauben.
Weil der Prozess war ja grad da und hey, kann HTTP, wie praktisch.
Da denkt der Billighersteller halt dann gradaus und zieht nicht eigens dafuer, wie von TR-069 dringend empfohlen, einen eigenen Prozess fuer den CNR use case hoch.
Ungefaehr so schlau als sich mit der Kreissaege die Fingernaegel zu schneiden, weil laeuft ja grad, aber man kann Dummheit nie ganz abstellen, vor allem bei Kostendruck.
Das Problem mit TR-069
Kein Problem mit TR-069.
Ausser man stellt, wie heise, Fernwartung an sich in Frage(?)
Dann waer die Gegenfrage: Warum?
Dazu:
Ihr erinnert euch noch an die Zeiten vor TR-069, mit den lustigen Windoofs CDs? Ohne Fernwartung mussten die Provider das irgendwie ueber die Windows Muehle des Endkunden hinkriegen, den Router startklar zu machen. Windows Fehlercodes waren damals auf mittlerer Abteilungsleiter Ebene bekannt und Millionen Euro Support Kosten wurden auf uns alle umgelegt: Um die 50 Euro pro Jahr und Kunde gemittelt(!) hab ich mal gehoert.
In anderen Worten: Privacy Verletzungen, (Deep) Content Inspection, Meta Daten Korrelation(...) das sind Dinge ueber die man sich imho heutzutage aufregen sollte - aber TR-069 hat damit genau gar nix zu tun und was heise hier macht ist einfach nur arm.
Merci fuers Lesen und sorry fuer mein Tastaturlayout ohne Umlaute, hab mich beim Proggen voll auf US/English eingeschossen ;-)
Servus,
F.
Das Posting wurde vom Benutzer editiert (30.11.2016 13:52).