TR-069, die Telekom, und das, was wirklich geschah

Wie lief die versuchte Übernahme von 900.000 Routern ab, über die halb Deutschland gerade diskutiert? Was ist in technischer Hinsicht geschehen? Die Analyse der betroffenen Geräte liefert einige Antworten auf diese Fragen.

Am Montag und Dienstag versetzte ein Ausfall mehrerer hunderttausend Telekom-Router die deutsche Cyberlandschaft in Aufruhr. Dass der Ausfall mit einem Angriff in Verbindung steht, wurde recht früh von Telekom und Innenministerium bestätigt.

Das Einfallstor, so stellte sich bald heraus, war eine offen dem Internet ausgesetzte Fernwartungsschnittstelle. Ein kurzes Lauschen auf Port 7547 einer öffentlichen IP bestätigte (spätestens) nach wenigen Minuten eine Angriffswelle mit versuchter command injection:

telekom-code

Der abgebildete Request will eine Lücke im TR-069-Befehl für das Setzen eines NTP-Servers ausnutzen, um eine Datei von einer fremdem Domain per wget herunterzuladen und auszuführen.

Für viele (auch mich) schien der Fall klar: Die Telekom-Router schienen eine Remote Code Execution im TR-069 zu haben – viel schlimmer hätte es kaum kommen können.

Es blieb jedoch eine wichtige Frage offen: Warum stürzten die Router ab, statt sich mit der Payload zu infizieren? Die Vermutung lag nahe, dass die Angreifer einen Bug im Payload oder Exploit-Code hätten. So könnten der Crash und die ausbleibende Infektion der Geräte erklärt werden. Den Angreifern schien irgendwo ein kleiner, aber entscheidender Fehler unterlaufen zu sein, der ihnen die Übernahme von 900.000 Geräten zu verhageln schien. Oder etwa nicht?

Zumindest nicht ganz. Während viele (auch ich) sich auf das Exploit-Binary stürzten, um den Fehler zu finden, besorgte sich Ralf-Philipp Weinmann erstmal in Ruhe eines der betroffenen Geräte. Dazu hat er eine erstklassige Analyse auf Englisch verfasst, die ich hier kurz in vereinfachten deutschen Worten zusammenfassen möchte:

Seine erste Erkenntnis: Auf den Telekom-Geräten lief gar kein Linux, das Voraussetzung für das Funktionieren des Befehls im TR-069-Exploit wäre. Mit anderen Worten: Sie waren gegen den beabsichtigten Angriff immun und somit wohl kaum Ziel des Angriffs.

Die nächste Hypothese wäre gewesen, dass sie zwar die Schwachstelle im TR-069 hätten, aber aufgrund des nicht interpretierbaren Befehls abschmieren würden. Wie Ralf feststellte, führte aber ein einmaliges Senden des Exploits zu gar keiner Reaktion der Geräte. Mit anderen Worten: Sie schienen nicht nur gegen den Exploit, sondern auch gegen den TR-069-Request selbst immun zu sein. Erst durch mehrmaliges Zusenden des Requests ließen sich die Geräte langsam aus dem Tritt bringen, bis sie irgendwann gar nicht mehr reagierten.

Was war also geschehen?

Im großen weiten Internet wütet gerade eine Welle von versuchten TR-069-Angriffen. Viele vermeintlich infizierte Geräte scannen fortlaufend das Internet und sorgen dafür, dass jede öffentliche IP-Adresse annähernd im Minutentakt einem Angriffsversuch auf Port 7547 ausgesetzt ist. Die Telekom-Geräte haben den Port offen, waren jedoch gegen diesen speziellen Code-Injection-Angriffsversuch immun. Sie hatten weder die Schwachstelle noch das Betriebssystem, auf das sich dieser Exploit richtet.

Offenbar hatten sie jedoch eine DoS-Vulnerability im Interpretieren von TR-069-Befehlen. Dadurch wurden sie – von den Angreifern unbeabsichtigt – durch die Häufigkeit der Zugriffe zum Absturz gebracht. Ärgerlich für die Angreifer, ärgerlich für die Telekom, ärgerlich für die Kunden – ein bedauerliches Missverständnis, dessen Ergebnis der Ausfall von fast einer Million Internet-Anschlüsse ist, der nicht verharmlost werden sollte: Er konnte sogar ohne Absicht des Angreifers ausgelöst werden.

Was hat die Telekom falsch gemacht?

  1. Der TR-069-Port hätte über das Internet nicht von arbiträren IP-Adressen erreichbar sein dürfen – dafür gibt es ACLs, Firewalls und getrennte Management-Netze. Darauf wurde die Telekom schon 2014 von ihren eigenen Kunden aufmerksam gemacht.
  2. Die Verarbeitung der TR-069-Befehle hat darüber hinaus einen Fehler, der vermutlich im Verantwortungsbereich des Zulieferers der Geräte liegt. Entsprechend blockiert die Telekom gerade Zugriffe von außen auf diesen Port und versorgt die Geräte mit Firmware-Updates.

Vielen Dank an dieser Stelle an Ralf-Philipp, der der Angelegenheit in Ruhe auf den Grund gegangen ist, während viele (andere, inklusive mir) zunächst auf der falschen Fährte waren, dass die Telekom-Router tatsächlich Ziel und nicht etwa Kollateralschaden der Angriffswelle waren.

Der Beitrag erschien zuerst auf dem Blog von Linus Neumann. Er war außerdem bei den tagesthemen zu Gast, um über den Angriff auf die Telekom zu berichten.

Deine Spende für digitale Freiheitsrechte

Wir berichten über aktuelle netzpolitische Entwicklungen, decken Skandale auf und stoßen Debatten an. Dabei sind wir vollkommen unabhängig. Denn unser Kampf für digitale Freiheitsrechte finanziert sich zu fast 100 Prozent aus den Spenden unserer Leser:innen.

39 Ergänzungen

  1. Schöne kurze Zusammenfassung ohne Hysterie.
    Leider sind die üblichen verdächtigen Massenmedien bereits auf den Panikzug aufgesprungen und fabulieren von einer supergefährlichen Cyberattacke und wir werden alle störben.
    Die Unsicherheitsbehörden reiben sich die Hände, weil man hier wieder mal super erweiterte Befugnisse fordern kann.
    Alles wie gehabt und man kommt sich echt vor wie in einer anstrengenden Zeitschleife.

    1. Der war es meistens nicht. Egal ob es U-Boote in schwedischen Gewässern sind (im Kalten Krieg waren es Amis, letztens Deutsche) oder Hack-Angriffe auf Sony. Aber er eignet sich einfach zu gut als Sündenbock und irgendwas bleibt beim BILD-Leser immer hängen.

  2. Prima und danke für die Aufklärung, Herr Neumann. Auch ich war auf einer falschen Fährt. Allerdings hatte ich die Vermutung, dass die Telekom eine eigene Schlamperei vertuschen wollte, indem so ein Cyber- Angriff gerade recht kam. OK, ganz so falsch ist diese Vermutung auch nicht, da ja seit 2 Jahren bekannte Sicherheitslücken quasi ignoriert wurden. Ich dachte aber eher an ein automatisches Firmware- Update, was fehlerhaft war und die Routerkonfiguration falsch eingestellt hätte. Tatsächlich lag das nahe, da nicht, wie auch hier beschrieben im Artikel, die Speedports abgestürzt waren. Denn einige Telekom- Kunden konnten eine Internetverbindung herstellen, indem sie auf den Endgeräten als DNS- Server die IP- Adresse 8.8.8.8 des Google- DNS Servers eingetragen hatten. Es wäre nicht möglich gewesen, über eben einen abgestürzten Router ins Internet zu gelangen. Also kann die These, dass durch Überlastung die betroffenen Speedports abgestürzt wären, nicht korrekt sein. Und natürlich kann man auch nicht russische Cyber- Soldaten, wie allerdings geschehen, für einen vermeintlich gezielten Hackerangriff verantwortlich machen.

    1. Natürlich, durch die DoS-Vulnerability auf den Speedports sind die DNS-Proxys/Server auf den Geräten abgestürzt und durch den alternativen DNS-Server hat man dies umgangen.

      1. Unter „Abstürzen“ verstehe ich etwas anderes, Philipp. Portscanning ist kein DDoS. Und auf den Speedports sind keine DNS- Proxys/Server, sondern lediglich Einträge davon, die den Router dazu veranlassen, Adressanfragen von den dort angegeben Servern zu beantworten bzw. aufzulösen.

        1. Auf den Speedports läuft ein DNS-Server. Die Hostnamen der dhcp Clients werden da eingetragen und er dient als Cache für den Telekom DNS Server

          1. Also Router stellen Dienste bereit wie DNS und DHCP. Durch DDoS-Attacken können diese eben schon beiinträchtigt werden. Die meisten haben sich nen anderen DNS am Rechner geändert. Und dann gings wieder weil der Dienst nicht vom Router kam. Uns selbst wenn er am Router geändert wird ist es plausibel keinen von der Telekom zu nehmen weil dieser grad nicht wirklich mit dem Telekomnetz kommunizieren kann wegen tausender Anfragen von verrückt spielenden Routern.

        2. „Portscanning ist kein DDoS“

          Kann man so pauschal nicht sagen, bei einem schlecht programmierten Dienst, der z.B. über inetd getriggert wird kann ein Portscan durchaus zum DoS mutieren! :)

  3. Soweit, so gut. Meine Fritz!Box, nicht bei Telekom, mit bis Montag nachmittags offenem Port wurde nicht gekapert. Nachdem ich vom Problem las, schloss ich den Port. Im Falle einer Infektion hätte das die Schadware mit busybox iptables -A INPUT -p tcp –destination-port 7547 -j DROP selbst getan und zusätzlich ein firmware – update mit busybox killall -9 telnetd über Telnet verhindert. Die genannten Befehle standen in einem Artikel von Golem.

    Viel wesentlicher scheint mir die Frage, ob man derartig anfälligen Geräten nicht Trojaner unterjubeln könnte, die den gesamten Traffic des Rechners abschnorcheln. Dann können sich BND&co. nämlich den Versuch den Rechner selbst zu kapern sparen. Dann fliegen sie auch nicht durch irgendwelche Zufälle auf. Was könnte man dagegen unternehmen?

    Es gibt genug gewiefte Technologien Trojaner auf den Rechnern selbst zu verstecken, aber wenn die Dinger genau am Flaschenhals sitzen, über den der gesamte Traffic läuft, besteht keinerlei Risiko für die Spione. Das Problem scheint deutlich größer zu sein, als ein mehr oder weniger mißglückter Angriff. Dann bräuchten die bösen Buben nur noch https über gefälschte Zertifikate knacken und würden von 99% der Rechner alles realtime mitlesen. 1% hätte meinetwegen VPN. Oder verstehe ich das falsch?

    1. Machbar ist natürlich vieles- aber wenn du den ganzen Traffic auf der Box spiegeln und ausleiten willst, bräuchtest Du doppelte Bandbreite nach außen. Merkt der Kunde. Oder Du filterst auf der Box vor, aber dafür haben die vmtl zu wenig Rechenleistung. Kann mich aber irren.

    2. Meine Fritzbox verwendet einen anderen Port, wenn man die Fernwartungsfunktion aktiviert. Vielleicht war das der Grund, weshalb FritzBoxen nicht betroffen waren? Und womöglich gibt es in FritzBoxen eine sicherere Authefitizierung als bei Speedports?

      1. Fritzboxen verwenden 8089 oder so. Die von den Providern ausgelieferten Boxen haben meist den Port offen. Bei den gekauften nicht. Generell ist es zu empfehlen das die Hersteller einen festdefinierten IP-Bereich hinterlegen mit denen die Boxen kommunizieren dürfen weil das TR069 Protokoll wohl weitere Lücken haben könnte. Die aktuelle Schwachstelle mit NTP kam wohl erst Anfang November raus. Aber eine andere schon vor 2 Jahren. Da hätte die Telekom schon reagieren können was den Zugriff auf die offene Schnittstelle anbelangt.

  4. Ich finde den Artikel auch als angenehm sachlich, bin aber im Zweifel ob der Angriff wie geschildert komplett beleuchtet ist.

    Erstens ist im TR069 Protokoll festgelegt, dass „von außen“ keine Verbindung für Konfigurationszwecke aufgebaut werden kann – dies kann nur von innen (vom Router her) geschehen. Von außen kann man nur anklopfen und um Herstellung einer solchen Verbindung bitten. Diese erfolgt dann aber nur zu vorkonfigurierten Servern und nicht zum unberechtigtem Anklopfer. Dass ein solches „Anklopfen“ zu einem Denial-of-Service gesteigert werden, kann ist bei sehr hohem Aufkommen plausibel. Falls der Router schlecht programmiert ist, reicht dafür vielleicht schon eine geringe Rate an Verbindungsanfragen. Damit wäre der Ausfall von Routern plausibel erklärbar.

    Warum aber versucht zweitens jemand eine Command-Injection auf dem TR069 Port? Das erscheint mir sinnfrei, denn der Router müsste ja zuerst die Verbindung aufbauen, bevor er als Wert für den Namen eines Zeitservers eine kleine Abfolge von Linux-Kommandos akzeptieren könnte. Da stimmt also die Reihenfolge nicht und der Angreifer würde sich selbst ein Bein stellen bevor er den ersten Schritt tun kann.
    Das im Blog von Ralf-Philipp Weinmann auch erwähnte TR064 Protokoll wäre ein mögliches Einfallstor, denn da wird eine Methode zum Setzen der NTP-Server angeboten. Aber auch da bleiben Fragen offen: TR064 Kommandos sind für die Verwendung ausschließlich im LAN vorgesehen; das von außen übers WAN zu probieren deutet darauf hin, dass der Angreifer weiß/vermutet dass sich einige Router da ganz und gar nicht protokollkonform verhalten und solche Kommandos auch von außen akzeptiert. Und weiterhin ist das Setzen der NTP-Server über TR064 nur nach vorheriger Authentifizierung zulässig – also eine weitere Hürde im Angriffsfall.

    Fazit: Herr Weinmann hat nur einen Router untersucht (laut Telekom sind aber mehrere Modelle betroffen) und dieser eine Router war mittels einer lahmen DoS-Attacke schnell schachmatt zu setzen. Aber ist das Verhalten der anderen Router ähnlich? Wir wissen es bisher nicht, Die Attacke zielte ihrem Inhalt nach gar nicht auf diesen untersuchten Routertyp (schon wegen fehlendem Linux) und hat eventuell in anderen Routern mit fehlerhaften Protokollimplementierungen mehr Erfolg gehabt. Es gibt ja einige Berichte von Nutzern, die den Eindruck hatten, dass der DNS Dienst im Router lahmgelegt war, der Rest aber durchaus brauchbar lief.

    Es sind also noch wesentlich mehr Fragen offen als geklärt.

    1. Alle betroffenen Geräte stammen vom Hersteller Arcadyan, da ist die Wahrscheinlichkeit hoch, dass alle auf dem selben Kernel basieren. Durch die DoS-Vulnerability ist der DNS-Resolver auf dem Gerät abgeschmiert.

    2. Sie interpretieren mit Ihrer Aussage die Funktionsweise des TR-069 Protokolls, wie es laut Telekom hätte funktionieren sollen. Dass es nicht so war, beweist eigentlich, dass der Request erfolgreich war und die Darstellung der Telekom offensichtlich falsch.

    3. bisher gibt es kein Gerät von Arcadyan das auf die Injektion anfällig war aber auf die DDoS. Honeypots im Internet stellten fest das bei anfälligen Modems bis zu 7 Files runtergeladen wurden und die Infizierung versucht wurde aber scheiterte.

      Die Standards zur Authentifizierung im TR069-Protokoll beinhaltet dieses:
      The standard suggests the use of TLS 1.2 but doesn’t require it, and TLS would not have made a difference in this case. Authentication can happen via certificates, or TR-069 messages are encoded using SOAP. These SOAP requests include a message that is then parsed by the modem (CPE, „Consumer Premise Equipment). The standard defines a large range of required and optional features.

  5. Danke für den Artikel ohne Hysterie. Ich muß feststellen, dass mein Internet derzeit langsamer läuft und libre Office sich nicht öffnen lässt. Ob das mit dem Problem aus dem Artikel zusammen hängt? Leider ist mir als Laie nicht klar geworden, was genau zu dem Angriff der Telekom -Router geführt hatte.Ich bin keine Informatikerin.

    1. Was auf deinem Rechner passiert, hat mit dem Vorgang nichts zu tun, es ging lediglich um einen Angriff auf den Router. Die Angriffe kommen aus den tiefen des Internets.

      Das „was“ ist vermutlich, weil in einem ähnlichen Modell eines Irischen Internetproviders eine echte Lücke entdeckt wurde, daher wurde einfach weltweit nach diesem Port gescannt, der auch bei den Telekomgeräten offen ist. Das ist techn. einfach und man kann mit einem kleinen Botnetz ein paar Millionenadressen schnell scannen.

      Das muss dir keine Sorgen machen, da wie in dem Artikel beschrieben, der Telekomrouter keine Lücke hat und daher nicht infiziert wurde.

      Warum bei dir LibreOffice langsamer läuft muss also einen anderen Grund haben. Wenn das Internet gar nicht geht und du bei der Telekom bist, musst du den Router vom Netz trennen und neu hoch fahren.

  6. Bei meinem Router konnte ich das Problem mit eintragen des google-DNS-Servers lösen – ich habe danach (als es dann Montag Abend im Radio kam) nochmal den Router vom Netz genommen um die Firmeware aktualisieren zu können. Nachdem ich mir das hier durchgelesen habe, stellt sich mir nun die Frage – gibt es noch etwas zu tun/prüfen?

  7. Oh mein Gott, selbst der CCC postet diesen Mist ueber TR-069.

    Leute, die Spec ist offen:

    1. TR-069 googeln
    2. TR-064 googeln
    3. „SetNTPServers“ suchen.

    WAS WURDE DA ATTACKIERT!?

    TR-069 oder TR-064 ?

    aaargh…

    1. Die Telekom-Geräte sprechen auf dem TR-069 – aus diesem Grund ist er auch von Außen erreichbar, was er bei TR-064 nicht sein dürfte.
      Sicherlich hast du Recht, dass es nicht
      „Der abgebildete Request will eine Lücke im TR-069-Befehl…“ sondern
      „Der abgebildete Request will eine Lücke im TR-064-Befehl…“
      heißen muss.
      Krass, wie kluk du bist.
      DAS ÄNDERT ALLES!

      1. Die Telekom sprechen auf dem Port weder TR-069 noch TR-064. TR-069 nicht weil auf dem Port lt. Standard ueberhaupt nicht gesprochen wird. TR-064 auch nicht, das taten die Zyxels aus Irland aber nicht die Speedports. Die letzteren machten einfach die Graetsche bei zu vielen Anfragen, ein Bug, so what!?

        Fuer die fachlichen Fehler in dem Artikel da oben reichen zwei Haende nicht – und das aendert schon was.

        1. Die Telekom sprechen auf dem Port weder TR-069 noch TR-064.

          Pass auf, ich hab eine Idee: Geh doch jetzt einfach mal bei der Telekom philosophieren, die freuen sich sicherlich über den Besuch des einzigen Menschen, der das alles RICHTIG verstanden hat.
          Selbst die Telekom schreibt nämlich:

          Die Deutsche Telekom benutzt im Rahmen ihrer „Easy Support“ genannten Funktion zur sicheren Fernwartung der Speedport Router das durch das Broadband Forum standardisierte Protokoll TR-069.

          Lass mich raten: ALLES FALSCH!!!

          1. Sorry, du verstehst technisch nicht was ich sage. Null.

            Ist auch kein Problem, musst du auch nicht. Ich versteh z.B. *ausserhalb* TR-069 nicht besonders viel.

            Was mich aber stoert ist, dass Leute wie der Author des OPs entweder
            – ohne nen Funken zu verstehen schlicht Unsinn zu posten ODER
            – es zu verstehen und gelogene FUD zu posten, wider besseres Wissen, weils grad ins Konzept/Weltbild passt

            Nix fuer Ungut.

  8. Wenn man das Protokoll kennt dann gehts einem bei diesem Artikel hier so:

    Ein Sprecher vom CCC(!) postet einen Artikel da drueber wie gefaehrlich, dumm und unsicher doch SSH ist.

    Und belegt das, in dem er einen **Telnet ** Flow mit Root und ohne Passwort praesentiert – und drunter schreibt das sei dieses poese SSH. Ja die Kommandos auf der CLI sehen aehnlich aus.

    Noch krasser eigentlich, weil bei TR-069 sogar die ganze VerkehrsRICHTUNG andersrum ist als bei TR-064, nicht gleich wie bei SSH vs. Telnet.

    Und dann steht da, dass der Mensch in den Tagesthemen auftritt und ueber das Problem referiert.

    Und dann schreibt heise den Mist auch noch ab.

    Und dann wundert man sich dass die Leute Angst vor SSH haben.

    Ohne Worte.

    1. 1. redet er nicht davon, dass etwas „gefaehrlich, dumm und unsicher“ sei
      2. ist der Bug, den die Telekom hat, in der TR-06NEUN-Implementierung

  9. 1. redet er nicht davon, dass etwas „gefaehrlich, dumm und unsicher“ sei

    Doch, genau das tut er:
    Er redet permanent davon dass es „TR-069 Befehle“ aus dem Internet gaebe, welche interpretiert werden muessten. Z.B.: „Offenbar hatten sie jedoch eine DoS-Vulnerability im Interpretieren von TR-069-Befehlen.“
    Jedem der nen Funken nachdenkt, muss das gefaehrlich dumm und unsicher erscheinen. Er tut so als fuehrte der gezeigte Befehl nur deshalb nicht zum Supergau, weil die Arcadyan halt zufaellig die Injektion Attacke mangels Shell nicht ausfuehrte – so als waer der Rest, setzen von Config aus dem Internet heraus voellig normal.

    2. ist der Bug, den die Telekom hat, in der TR-06NEUN-Implementierung
    Der Bug war in der HTTP Implementierung und fuehrte zum DOS, mehr kann da nicht passieren, es gab bei hunderten millionen Routern bisher genau einen einzigen Fall von (proprietaerer) Firmware die mehr erlaubte als die Box zu DOSen. Und die Fernwartungsstrukturen um das so schnell beheben zu koennen wie die Telekom das heutzutage schafft noch nicht da waren!

    Eine BOX zu DOSen ist aber praktisch wertlos fuer einen Angreifer, deshalb hat TR-069 nicht mal dann ein Problem wenn der Vendor zu doof ist einen Webserver zu bauen der nichts tun muss – weil EH keiner angreift.

    WARUM hier zufaellig dauernd Angriffe auf den Port vorbeikamen lag daran dass

    – eine Eircom
    welche eine Pleite historischen Ausmasses hinter sich hat http://www.independent.ie/business/irish/eircom-emerges-from-historic-bankruptcy-26863700.html und offensichtlich ihre komplette Qualitaetssicherung entlassen musste (die merken noch nicht mal dass sie nicht ericom heissen http://broadbandsupport.eir.ie/download/zyxel/eircom_D1000.pdf)

    – im Verbund mit einer Zyxel
    welche mal eben ihr hauseigenes Betriebssystem in der Zeit von ZyNOS auf Linux umziehen musste

    beide zusammen ein unsicheres LAN Protocol im Klartext ins Internet gestellt haben.

    Und das zufaellig auf dem TR-069 CNR Port – und deshalb kriegt der CNR port der Telekom den Rotz ab.

    tl;dr: Diese DOS Attacke haette es niemals gegeben wenn dieses bescheuerte TR-064/UPNP endlich aus der Welt waer.

    Der Artikel ist bodenlos dumm bzw. ich unterstelle Absicht.

    1. „Offenbar hatten sie jedoch eine DoS-Vulnerability im Interpretieren von TR-069-Befehlen.“
      Genau das ist uns bleibt der Fall. Daran ändert auch nichts, dass der an den Port gesendete Befehl ein anderer war. Um bei deinem Beispiel zu bleiben: Wenn dein ssh-Server crasht, weil ich ihm einen Telnet-Befehl schickte, dann ist dein ssh-Server kaputt. Wenn dann dein System den Dienst verweigert, dann ist das eine DoS-Vulnerability.

      „Der Bug war in der HTTP Implementierung und fuehrte zum DOS,“
      Das ist falsch. Der Bug betrifft nicht die Implementierung von HTTP.

      Im offensichtliche Gegensatz zu dir habe ich 2 Geräte analysiert und kann bestätigen, was hier beschreiben ist.

  10. was hast den analysiert auf deinen beiden boxen wenn ich fragen darf ?
    Im Ggs. zu dir haben wir / Partner / Kunden mittlerweile die Firmwares von ca. 20 Millionen Geraeten analysiert, und zwar round the globe – ohne Probleme auf dem CNR Port.

    Und noch was:
    1. Natuerlich wars ein Problem in der HTTP Implementierung oder Konfiguration: Haette die Digest Auth gegriffen waeren die Requests einfach abgelehnt worden, Bug in der HTTP Implementierung dann. Sollte die Digest Auth aus gewesen sein (was noch nicht klar ist) wars eine Fehlkonfiguration auf dieser Ebene.

    2. Du drehst mir mein Beispiel hin wie du’s brauchst und du solltest es besser wissen: Auf Transport Ebene bezogen ist TR-069 sowas wie reverse SSH. Das Problem trat schon beim Anklopfmechanismus auf aber nicht auf den Protokollverkehrsweg selbst.
    In anderen Worten: Wie kann es wohl einen Fehler in der Interpretation eines Protokoll auf einem Port geben wenn hierbei lt. Standard das Protokoll ueberhaupt nicht gesprochen werden darf sondern genau Null Information (steht woertllich so in der Spec wie dir bekannt ist) ausgetauscht wird?

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.