Eigener Updateserver

candyman666 · 25 Dez 2015

Hallo Forum,

gibt es eine Möglichkeit für das Onlineupdate die URL zu ändern? Hintergrund ist folgender, ich habe einige Boxen mit freetz an verschiedenen Standorten. Dort habe ich bei einigen das Problem, das es nicht immer einen Laptop oder PC gibt. Meistens nur ein Tablet oder ein Telefon. Nun wäre es ja die einfachste Möglichkeit, wenn ich einfach auf Onlineupdate drücken könnte. Nur sind die Boxen halt alle mit freetz geflasht.

Es wäre super, wenn ich auf meinen Server die fertigen Freetzimages hochladen könnte und sich die Boxen diese per Knopfdruck, oder per regelmäßigen Cronjob abholen würden.
Hat da jemand eine Idee von euch, oder gibt es schon ein fertiges Paket zum installieren?

Viele Grüße
Candyman

PeterPawn · 25 Dez 2015

candyman666 schrieb:
gibt es eine Möglichkeit für das Onlineupdate die URL zu ändern?

Gibt es ... reicht aber nicht aus. Die Abfrage nach einer neuen Version sieht so aus:

Code:

POST /Jason/UpdateCheck HTTP/1.1
Host: jws.avm.de:80
Content-Length: 841
Content-Type: text/xml; charset="utf-8"
SOAPAction: "http://jason.avm.de/updatecheck/BoxFirmwareUpdateCheck"


<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:j="http://jason.avm.de/updatecheck/">
<soap:Header/>
<soap:Body>
<j:BoxFirmwareUpdateCheck>
<j:RequestHeader>
[COLOR="#0000FF"]<j:Nonce>w2t3/KGlwDO/agYJx4pukQ==</j:Nonce>[/COLOR]
<j:UserAgent>Box</j:UserAgent>
<j:ManualRequest>true</j:ManualRequest></j:RequestHeader>
<j:BoxInfo>
<j:Name>FRITZ!Box 7490</j:Name>
<j:HW>185</j:HW>
<j:Version>113.06.50</j:Version>
<j:Revision>32007</j:Revision>
<j:Serial>0896D7CAFE01</j:Serial>
<j:OEM>avm</j:OEM>
<j:Lang>de</j:Lang>
<j:Annex>B</j:Annex>
<j:Lab></j:Lab>
<j:Country>049</j:Country>
<j:UpdateConfig>1</j:UpdateConfig></j:BoxInfo></j:BoxFirmwareUpdateCheck></soap:Body></soap:Envelope>

Das ist sicherlich noch nicht das Problem, aber die Antwort ist es dann ("aufgehübscht" für übersichtlichere Anzeige):

Code:

Date: Fri, 25 Dec 2015 15:45:05 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 1447
Content-Type: text/xml;charset=utf-8

<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Body ID="Body">
    <BoxFirmwareUpdateCheckResponse xmlns="http://jason.avm.de/updatecheck/">
      <BoxFirmwareUpdateCheckResult>
        <ResponseHeader>
          [COLOR="#0000FF"]<Nonce>w2t3/KGlwDO/agYJx4pukQ==</Nonce>[/COLOR]
        </ResponseHeader>
        <UpdateCheckResult>
          <CheckIntervall>168</CheckIntervall>
          <Found>false</Found>
          <Version></Version>
          <DownloadURL></DownloadURL>
          <InfoURL></InfoURL>
          <InfoText></InfoText>
          <HintURL></HintURL>
          <Priority>1</Priority>
          <AutoUpdateStartTime>0</AutoUpdateStartTime>
          <AutoUpdateEndTime>0</AutoUpdateEndTime>
          <AutoUpdateKeepServices>true</AutoUpdateKeepServices>
        </UpdateCheckResult>
      </BoxFirmwareUpdateCheckResult>
    </BoxFirmwareUpdateCheckResponse>
[COLOR="#FF0000"]    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <Reference URI="#Body">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <DigestValue>qzG6/hvbuSpVXh9BXAwwox1pdLE=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>S7Qyy6STTeQYLshSsKYjVwyrYRUibs6kWXfDVCUlQ+pH6SjeqeMZv+aaMTiKxFzQFH4VJjWPYVxc8NY8mWR0kEw1222igzt6cxe31z6YILjGk3ubn/YjBZ5ESSHQHGvsYJKTkALbLvXefufSJawqIyYFLSfwPMEkSurkHyzGM0=</SignatureValue>
    </Signature>[/COLOR]
  </S:Body>
</S:Envelope>

Solange Du nicht schon vorher in der Box den passenden Public-Key hinterlegt hast, klappt schon mal das Signieren nicht. Ich bin nicht mal sicher, ob es am Ende einer aus /etc/avm_firmware_public_key[1-3] ist, der Public-Key aus dem MyFRITZ!-Zertifikat (etc/jasonii_root_ca.pem) - der immerhin in der libjasonclient.so wenigstens erwähnt wird, wobei er da auch für andere Zwecke (verify für den MyFRITZ!-Dienst) gebraucht wird - oder sogar ein an dieser Stelle fest einkompilierter Key für das Signieren von Update-Anfragen (es gibt in der libjasonclient.so am Ende drei Strings, die so etwas sein könnten). Auch müßte man wohl DNS-Abfragen für ~~"jason.avm.de"~~ "jws.avm.de" spoofen, dieser Name taucht nur fix in der libjasonclient.so auf und ist nicht konfigurierbar (wie einige andere intern verwendete DNS-Namen von AVM-Services auch nur dort zu finden sind).

Ohne die passende Antwort auf die Versionsabfrage macht die FRITZ!Box jedenfalls auch kein Online-Update - wenn Du ein signiertes Firmware-Image hättest und Deinen eigenen ACS in der Firmware hinterlegen würdest, könntest Du es über TR-069 anstoßen (wenn Du den "kleinen Rest" des Protokolls auch noch richtig behandelst). Ist aber auch nicht wirklich simpel ... ich würde gar nicht erst auf den AVM-Mechanismus an dieser Stelle zurückgreifen.

Ich hatte etwas ähnliches mal bei NOR-Modellen erstellt und auch längere Zeit in Benutzung, wo die Boxen von sich aus in regelmäßigen Abständen auf dem konfigurierten WebDAV-Server nach neuen Images gesucht haben und ich für ein Update nur das passende File dort ablegen mußte. Aber diese Dateien waren mit dem jeweiligen internen Kennwort der FRITZ!Box verschlüsselt (und zusätzlich dem aktiven WLAN-Namen und -PSK, damit da eine event. bei AVM vorhandene Datenbank mit MAC-Adressen und WLAN-Keys von der Produktion ins Leere läuft) und damit immer nur genau für diese eine Zielbox bestimmt - schon damit da niemand durch Austausch des Images auf dem Server angreifen konnte, wenn das einer von einem Provider war.

Heutzutage mache ich das bei den NAND-Modellen analog und lasse das neue Image auf demselben Wege schreiben, wie "modfs" arbeitet ... im Prinzip ist es also ein "modfs" ohne weitere Änderungen (was dann ungefähr dasselbe ist, was /var/install von AVM auch macht, nur ein kleines bißchen im Ablauf geändert, weil es sofort passiert und nicht erst in "/var/post_install" geschrieben wird).

Aber in jedem Falle vermeide ich (und das solltest Du auch, wenn es machbar ist) die Verwendung der AVM-Mechanismen ... selbst für TR-069-Updates braucht es offenbar signierte Images, das Ergebnis eines solchen Downloads muß durch "firmwarecfg stream" durch, bevor es akzeptiert wird. Die Prüfung selbst (also das Berechnen des Hashes in der Box) erfolgt über die libfwsign.so (signature_stream_init/write/exit) - da kann man sich zwar ansehen, was AVM verwendet (MD5-Hashes und RSA-Sig), aber das auch noch zu spoofen oder durch eigene Funktionen oder Wrapper zu ersetzen, ist (zumindest für meinen Bedarf) witzlos.

Da reicht mir eine eigene Absicherung der Identität des Urhebers eines Update-Images dann aus (PGP kennt die Box ja leider nicht, man muß also OpenSSL bemühen, wenn man signieren will und das braucht ein eigenes Binary, weil AVM auch kein universelles "openssl" beilegt) und anstelle irgendwelcher Signaturen bin ich eben auf den Trichter verfallen, das direkt für jede Box so zu verschlüsseln, daß nur sie es lesen kann.

Da ich darüber nicht nur komplette Firmware-Updates mache, sondern auch Konfigurationen und einzelne zusätzliche Binaries tauschen lassen kann, ist es in der überwiegenden Zahl der Fälle ohnehin eine speziell für die betreffende Box maßgeschneiderte Änderung und da macht der zusätzlich auszuführende Schritt mit der passenden Verschlüsselung nicht so viel aus. Da die Box die Dateien dann auch gleich nach dem erfolgreichen Update noch vom Server löschen darf, entfällt auch die "Versionsverwaltung" an dieser Stelle und ich muß mir keine Gedanken machen, welche Änderungen schon übernommen wurden und welche nicht.

Wenn man es also einfach selbst lädt (wie es ja z.B. Freetz auch macht im CGI) und dann die notwendigen Schritte per Skript ausführt, ohne das "firmwarecfg" von AVM zu bemühen, bekommt man es hin ... das Risiko des unbeaufsichtigten Updates bei NOR-Boxen bleibt natürlich bestehen, deshalb gibt es an den wenigen verbliebenen NOR-Boxen auch immer ein aktuelles Recovery-Programm auf dem USB-Stick, was vor Ort notfalls unter telefonischer Anleitung dann benutzt werden muß - braucht aber natürlich den passenden PC.

candyman666 · 25 Dez 2015

Vielen Dank für die ausführliche Antwort. Kann ich die Scripte von Freetz einfach benutzen? Wenn ja, welche sind das?
Kannst du mir vielleicht ein kleines Beispiel geben, wie du es gelöst hast? Du scheinst dir ja schon mehr Gedanken über dieses Thema gemacht zu haben.

koyaanisqatsi · 25 Dez 2015

Moins

Vielleicht noch interessant in diesem Zusammenhang...
Beim Firmwareupdate/Pseudoflash wird auch auf eingesteckten USB Speicher nach Konfigurationdateien gesucht...

ps

Code:

15752 root      3328 S    /bin/tr069starter ZTE-MMCStorage-00
15910 root      3328 S    /bin/tr069starter SanDisk-Cruzer-01

Da jetzt mal mit strings (erweiterte busybox) reingeguckt...

Code:

/var/media/ftp/SanDisk-Cruzer-01/mips/busybox-1.21 strings /bin/tr069starter

...der relevante Text...

Code:

tr069fwupdate [COLOR=#ff0000][B]configimportbyusb[/B][/COLOR]
/var/media/ftp/%s/%s
[COLOR=#ff0000]tr069start.config
fritzboxconfig.import
provider_default_fritzboxconfig.import
provider_add_fritzboxconfig.import[/COLOR]

...weiss aber noch nicht, ob das (eigen)nutzbar ist.

PeterPawn · 25 Dez 2015

candyman666 schrieb:
Kann ich die Scripte von Freetz einfach benutzen? Wenn ja, welche sind das?

Da sich Freetz selbst nicht um den Update-Prozeß kümmert (das einzige, was ich von Freetz an der Stelle kenne, ist die Entgegennahme eines Firmware-Uploads (/usr/mww/cgi-bin/update/*firmware.cgi) und dessen Verarbeitung (/usr/lib/mww/do_update_handler.sh), gibt es da nicht allzu viel, was man benutzen kann. Da sich das zum größten Teil auf AVM-Skripte (/var/install) stützt, benutze ich das selbst gar nicht mehr.

Kannst du mir vielleicht ein kleines Beispiel geben, wie du es gelöst hast?

Wenn Du in Form eines konkreten Skript-Files meinst: nein. Das ist zu speziell an meine eigenen Bedürfnisse angepaßt und mit einiger Wahrscheinlichkeit nicht allgemein verwendbar und die Arbeit, das auf neutral zu trimmen, ist mir zuviel ... bei zu geringem "Ertrag" beim Leser, denn das kann man ohnehin nicht 1:1 anwenden, wenn das passende Framework (YourFritz) rundherum noch fehlt und damit bin ich noch nicht so weit fertig, daß man es anderen empfehlen könnte. Ich habe bisher noch nicht eine einzige Rückmeldung erhalten, daß es sich jemand wenigstens mal angesehen hätte, obwohl es schon mind. 2 Monate auf dem Server steht und einige Male wohl tatsächlich geladen wurde (und nicht nur von Spidern kontrolliert, ob der Link hier noch stimmt).

Als kurzer Abriß, wie es (das Update, nicht das Framework) funktioniert:

- die FRITZ!Box sieht regelmäßig auf dem (ohnehin konfigurierten und damit in ihrem eigenen Dateisystem gemounteten) WebDAV-Server in einem Verzeichnis "custom/$(hostname)" nach, ob es eine Datei "control.download" gibt - jede FRITZ!Box hat da ihr eigenes "Home-Verzeichnis" auf dem Server
- diese Datei wird - so sie existiert - mittels OpenSSL (openssl enc -d -aes256) decodiert, dabei kommt ein SHA512-Hash (kann die Busybox machen, wenn man sie entsprechend konfiguriert hat) über das Box-Kennwort (mit privatekeypassword ermittelt), den eigenen Hostnamen, die WLAN-SSID des 2,4 GHz-Netzes und den WLAN-PSK (mit queries.lua ermittelt) als Kennwort für die Entschlüsselung zum Einsatz
- da steht dann ganz simpel drin, welche Dateien vom Server geladen werden sollen und was mit denen zu passieren hat
- als Operation werden verschiedene schon vorhandene Skript-Kommandos in einem dafür vorgegebenen Verzeichnis unterstützt, das geht vom simplen Kopieren an eine bestimmte Stelle bis zum Erstellen eines neuen SquashFS-Images, das in die richtige Wrapper-Partition kopiert wird
- alles Downloads wandern durch genau dieselbe Verarbeitung (werden also ebenfalls beim Download entschlüsselt), wie die o.a. "Auftragsliste" - damit kann ich (relativ) sicher sein, daß keine fremden Dateien dort eingeschmuggelt werden können, selbst wenn es ein "öffentlicher" WebDAV-Server ist/wäre
- nach der Abarbeitung der Liste wird sie ganz simpel per rm vom Server entfernt, die abgearbeiteten Dateien selbst lösche ich dann meist manuell oder lasse sie gleich stehen, denn die haben ohnehin eindeutige Namen mit Linux-Timestamps und ihrem eigenen Hash-Wert, weil es dem Automatismus egal ist, wie die heißen und ich dann Übertragungsfehler schon am Dateinamen ausschließen kann, bevor ich OpenSSL darauf ansetze
- das Einpacken solcher "Aufträge" ist natürlich auch automatisiert, die internen Kennwörter der Client-Boxen und die anderen Angaben für die Verschlüsselung stehen in einer sqlite3-Datenbank herum (ist eigentlich ein dmcrypt-Image-File und bildet somit das "Master-Password") und werden automatisch für die richtige Box dort ausgelesen (mit dem CLI-Kommando von sqlite3)
- Probleme macht das nur sehr selten, wenn es größere Downloads auf Boxen sind, die nicht genug Hauptspeicher haben, um zwei Kopien der Datei parallel zu speichern (einmal ver- und einmal entschlüsselt) - da ist dann ggf. ein Fallback auf direktes Lesen des (eben ohnehin im Dateisystem erreichbaren) Files durch das OpenSSL-Kommando angesagt ... aus historischen Gründen (die WebDAV-Sache mit "fuse" kam später erst dazu, weil damit dann auch TLS zum Server problemlos ging, was bei wget der Busybox nicht möglich war und früher mit "stunnel" ausgeglichen werden mußte) ist der vorherige Download (bzw. das Kopieren) mit anschließender Kontrolle des Hash-Wertes in den meisten Fällen noch aktiv, damit könnte ich schnell wieder auf wget oder auch auf einen FTP-Client für den Download umstellen, falls AVM "fuse" irgendwann wieder aus dem Kernel werfen sollte

Man muß sich aber gerade beim TLS einige Sachen in der AVM-Firmware ansehen bzw. am besten die libneon und davfs2 (bei AVM heißt es "mount.davfs") durch eigene Versionen ersetzen - da war früher einiges deaktiviert (alles > TLS 1.0) und ob das heutzutage an die neuen Erkenntnisse/Erfordernisse angeglichen wurde (kein SSLv3 mehr, dafür TLS bis einschließlich 1.2, die libssl.so gäbe das her), weiß ich nicht genau. SSLv3 als "no go" kann eigentlich erst in der 06.30 so richtig aktuell sein, wobei die AVM-Variante m.W. ohnehin keine Server-Zertifikate prüft und sich damit eigentlich generell disqualifiziert für meine Zwecke.

Wenn da durch DNS-Spoofing jeder x-beliebige Server mit passendem "self signed"-Zertifikat von sich behaupten kann, der richtige zu sein und sich der WebDAV-Client dort auch noch brav mit Benutzernamen und Kennwort authentifiziert (was so ein Server als MITM dann bei "basic auth" problemlos mitliest - wobei der nicht mal ständig als MITM tätig sein muß, wenn er die Credentials erst einmal abgegriffen hat), dann ist das wieder ein Ritt auf der Rasierklinge.

Auf der einen Seite will AVM sicherlich keine Server mit "self signed"-Zertifikaten generell ausschließen (der Kunde könnte ja einen eigenen haben), auf der anderen Seite ist das viel zu einfach anzugreifen, da reicht es schon, einmalig kurz den DNS-Namen des WebDAV-Servers zu kapern. Da bräuchte es also irgendwo im GUI noch die Möglichkeit, die gültigen Zertifikate (notfalls auch ganze Chains, aber eigentlich reicht ein einzelnes) irgendwie auszuwählen und festzutackern (Pinning verbreitet sich ja immer mehr).

Fest verdrahtete Zertifikatlisten oder endlose Listen von CAs sind sicherlich nicht die beste Idee - anders als irgendein Browser, wo so eine Liste schnell aktualisiert ist, ist das FRITZ!OS ja doch eher statisch ... notfalls könnte man solche Listen (bzw. Updates dafür) allerdings sicherlich von einem AVM-Server laden und irgendwo im TFFS noch mit ablegen - wenn man nicht besser wirklich mit "certificate pinning" über das GUI arbeitet, da läßt sich ja ohnehin bei AVM nur eine einzelne DAV-Verbindung konfigurieren.

@koy:
Das erfolgt beim Pseudo-Update nur dann, wenn man den USB-Teil wieder reaktiviert und die Volumes gemountet werden.

Dann erfolgt dieser Aufruf bei jedem Mounten eines Volumes zwischen der Aktivierung des FTP-Servers und des Samba-Servers, zu finden in der /etc/hotplug/udev-mount-sd.

candyman666 · 20 Feb 2016

Hallo, wollte nur kurz nen Zwischenstand abgeben und mal nachfragen, ob es bei meinem Vorgehen Bedenken gibt.
Ich habe mich jetzt zu folgendem Vorgehen entschieden.
Per Cron wird auf der Box ein Befehl ausgeführt der ein Bashscript von meinem Server lädt und ausführt. In dem Script soll(bin noch nicht soweit) zuerst ein PHP Script auf dem Server ausgeführt werden, welches die gespeicherten Softwarestände zur entsprechen Box zurückgibt. Als Identifizierung werde ich die MD5 verschlüsselte Mac-Adresse benutzen.

Code:

WebScript.php?mac=jkduhenjksjdhhdbnsjxjhdbd

Als nächstes vergleicht das Script die gesicherten Softwarestände auf dem Server mit den installierten Versionen. Sollte alles gleich sein, wird das Script beendet. Wenn es auf dem Server eine neuere Version gibt, wird der Updateprozess gestartet. Dieser Teil des Scriptes funktioniert schon ganz gut, Dank des Tips mit der Datei /var/install.

So, das war es erstmal, danke an alle, die an der Diskussion beteiligt waren.

Languages

Suche

Languages

Suche

Eigener Updateserver

candyman666

Neuer User

PeterPawn

IPPF-Urgestein

candyman666

Neuer User

koyaanisqatsi

IPPF-Urgestein

PeterPawn

IPPF-Urgestein

candyman666

Neuer User

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums