[Info] Update-Check: JuisCheck für Windows

[DickS]

Hat jemand eine Liste mit allen AVM-Hardwaregeräte? Alle Boxen, DECT, Smarthome, etc für JUIS App? Das wäre super, wenn es hier geteilt werden kann.

 

[Grisu_]

Dann schau dir mal die div. Juis Excel-Listen an etwa aus #340.

 

[HarryP_1964]

Kann mir jemand sagen, was ich bei der DECT500 ändern muss, damit bei aktueller FW kein Update mehr angezeigt/gefunden wird:



Danke!

Harry

 

[Grisu_]

Könnte bitte jemand auf diesen Beitrag https://www.ip-phone-forum.de/threads/update-check-juischeck-für-windows.301927/post-2384145 eingehen oder ist es wieder einmal ein Einzelfall?

 

[fda89]

Ist in der Vergangenheit sonst schon mal irgendjemandem aufgefallen, daß man sich mit dem Juis.exe das MyFritz völlig durcheinanderbringen kann?

Krasse Sache dass AVM scheinbar die persönlichen Daten von MyFritz mit denen von Juis verknüpft.
Nach der DSGVO hast du das "Recht auf Datenübertragbarkeit" deiner Daten. Frag doch einfach AVM!

Hier steht übrigens nichts von Juis: https://avm.de/datenschutz/
Auch nichts dass jede Seriennummer gespeichert wird, zb "A.IV. Registrierung / Einrichten eines Benutzerkontos "

 

[Grisu_]

Kann nur sagen, daß zigfach Boxen austragen und erneut mit Konto verknüpfen nichts gebracht hat, bis ich zufällig bei einer den Query im Juis gemacht hab, und von allein sind die Daten im Konto bei dieser Box aufgeschienen.
Dann noch die beiden anderen zeitversetzt und selbes Bild, brauchte sie auch gar nicht entfernen und neu hinzufügen, Mesh-Aktiv Zeile war Sekunden (oder Minuten) später da und auch die Firmwaredaten nebem dem Box-Bildchen.
Konnte ich also 3x mit einer 7582 verifizieren die alle ident als Client-LAN-Mesh mit Einstellungsübernahme im Einsatz sind.

AVM hat mir gratuliert, daß ich den Fehler beheben konnte - haha, die werden sich meine Datenschutzbeschwerden anhören, jede einzelne Zeile zu schreiben ist sinnlos und könnte stattdessen besser bei einem Bier vergeudet oder genossen werden.

 

[fda89]

Ich hab mir das nochmal angeschaut. Es schient so dass AVM jede "juis"-Abfrage analysiert, mitloggt und verknüpft! Und das über Jahre hinweg speichert.

Zuerst hab ich mich in mein MyFritz Konto eingeloggt. Dieses ist schon älter und benutze es normal nicht. In diesem sind meine IPs sogar noch aus dem Jahr 2017 gespeichert.
Durch meine Tests heute sind nur noch die bis 2018 zu sehen. Scheinbar hält AVM nicht viel von Datensparsamkeit und löscht alte Daten nicht nach einer gewissen Zeit


Dann habe ich eine 7490 für MyFritz registriert. Mit deren Seriennummer (kann jeder Gerät im LAN mit http://fritz.box/jason_boxinfo.xml ermitteln) habe ich dann diverse Anfragen über Juis gestellt.


Man kann scheinbar nur durch Kenntnis der Seriennummer das komplette MyFritz manipulieren:
- Zugangsart von Internet: DSL / mitbenutzen / keine
- Mesh-Status des Gerätes: kein mesh / master / slave
- Die installierte Fritzos Version und dadurch eventuell vorhandene Updates
- Die installierte Revision, wichtig bei Labor
- Das Modell des Gerätes. Ich habe nur eine ungültigen Zustand hinbekommen, und es wurde als Bezeichnung der Hostname angezeigt. Geht aber bestimmt auch, ich hatte aber keine Lust mehr
- Die private IP des Gerätes wird von AVM in MyFritz gespeichert
- Es gibt noch andere "flags" in juis die ich nichz ausprobiert habe, zb verbundene SmartHome Geräte

Für mich bedeutet das als Konsequenz


Und auf keinen Fall Juis mit echter Seriennummer abfragen! Am besten MyFritz dann noch mit freetz entfernen...

---

Witzig in diesem Zusammenhang ist noch dass AVM sich ein Zertifikat für *.myfritz.net hat ausstellen lassen: https://transparencyreport.google.c.../CkpCJ+EgdN3wv82/nUHDC89fW4Pgf3agcNvvORy08c4=
Dh dadurch wird MITM für MyFritz und die AVM Apps ermöglicht

 

[eisbaerin]

Scheinbar hält AVM nicht viel von Datensparsamkeit

Das ist IMO mindestens hier im Forum bekannt.
Die wissen IMO auch alle Geräte die sich im Mesh befinden und auch alle Clients die sich irgendwo und irgendwann mal angemeldet haben.

Die Clients werden sogar in der Config mit abgespeichert. WOZU?

Früher bei der guten alten FB7170 war das noch nicht so.
Wieso werden wir immer mehr von AVM ausgehorcht und überwacht?

Aber das schlimmste für mich:
Alle schreien nach Mesh und wollen es haben.
Ich dagegen suche schon lange nach einer Möglichkeit das Mesh abzuschalten.
Aber da gibt es IMO keine, da es zu sehr integriert wurde.
Warum wohl?

 

[PeterPawn]

dass AVM sich ein Zertifikat für *.myfritz.net hat ausstellen lassen

Das ist aber auch nicht das erste dieser Art ... damit nicht der Eindruck entsteht, das gäbe es erst seit Sept. 2019.

Das Vorgängerzertifikat war dieses:

Google Transparency Report

transparencyreport.google.com

... und genau dessen Existenz war ein entscheidender Punkt, der mich auch schon in der Vergangenheit zu meiner nachdrücklichen Warnung vor der Benutzung von MyFRITZ!-Namen beim WAN-Zugriff auf FRITZ!Box-Dienste veranlaßte.

AVM hat hier sowohl die Hoheit über den DNS-Server als auch über dieses Zertifikat ... wenn man dort also die Abfrage nach dem Namen einer konkreten/bestimmten FRITZ!Box mit der Adresse eines eigenen Servers beantwortet und dieser dann beim TLS-Zugriff das Wildcard-Zertifikat präsentiert, während er als "Proxy" für den Zugriff auf die FRITZ!Box (also effektiv als "Man in the middle" - MITM) arbeitet, dann bemerkt der Kunde/Besitzer/Benutzer (bzw. sein Browser) da nicht das geringste Problem - während man mit einer, auf diesem Weg "mitgelesenen", SID für eine administrative Sitzung selbst allen möglichen Unsinn anstellen kann.

Da braucht man schon ein überbordendes Vertrauen in den Hersteller, für das es - zumindest in meinen Augen - keinen belastbaren Grund gibt ... bisher hat sich AVM für meine Begriffe beim Datenschutz nicht wirklich mit Ruhm bekleckert und die "Verknüpfung" der Daten aus verschiedenen Quellen war/ist ebenfalls schon länger bekannt. Wobei AVM da auch immer wieder ein paar Änderungen vornimmt ... ich weiß nicht, wievielen Benutzern es auffällt, daß irgendwelche Mails zu Problemen in einer FRITZ!Box nicht mehr zwingend von dieser selbst kommen (also nur die Box und der dort konfigurierte Mail-Server involviert sind) - es gibt mittlerweile auch Umstände, bei denen die Box nur noch den MyFRITZ!-Service "triggert" und wo dieser dann seinerseits Mails (an die im MyFRITZ!-Konto hinterlegte Adresse) versendet - da ist AVM natürlich dann auch immer "bestens informiert", was da auf der FRITZ!Box des Kunden gerade gehauen und gestochen ist.

Zwar prüfen die Apps von AVM meines Wissens gar nicht das präsentierte Zertifikat an sich, sondern den darin beglaubigten öffentlichen Schlüssel - so daß diese Apps also tatsächlich (wenn dort wenigstens alles mit rechten Dingen zugeht und sie nicht den öffentlichen Schlüssel des Wildcard-Zertifikats ebenso "durchwinken" - der hat sich auch mit dem "renew" im Sept. 2019 nicht geändert, wenn ich das richtig sehe und ist somit praktisch "konstant") so einen zwischengeschalteten Proxy erkennen würden. Aber das "entlastet" AVM natürlich nicht von der Verantwortung für diese Sicherheitslücken ... die einzige "Absicherung" für den Kunden ist die Annahme, daß AVM in der Lage ist, den privaten Schlüssel für dieses Zertifikat so zu verwahren, daß kein Unbefugter in seinen Besitz kommt (das Zertifikat an sich ist ja nicht "geheim" und kann von jedem gefunden werden).

Da sämtliche (externen) Dienste einer FRITZ!Box eben über den einen, gemeinsamen Port für den HTTPS-Server zugänglich sind (die Apps verwenden ja auch diese Schnittstelle), gibt es für den Kunden/Besitzer, der Apps benutzen will, auch keine andere/bessere Art der Absicherung gegen (zumindest machbare, was noch nicht impliziert, daß sie auch stattfinden) Übergriffe von AVM, als die Verwendung eines anderen DynDNS-Namens und eines (eigenen) Zertifikats für diesen DynDNS-Namen - zumal AVM ja auch die (automatische) Anforderung eines LE-Zertifikats auf genau diese Domain "myfritz.net" (bzw. auf den MyFRITZ!-Namen) im FRITZ!OS beschränkt und damit den (arglosen) Benutzer ein weiteres Mal dazu "bewegen" will, doch bitteschön die Domain zu benutzen, für die man sich ein solches Wildcard-Zertifikat besorgt hat.

Nun kann man solche "Vorbehalte" zwar auch mit "Aluhut-Träger" abtun ... aber Transparenz, auch in der Kommunikation gegenüber dem Kunden, ist für mich etwas deutlich anderes, als das was AVM da (und eben schon seit Jahren, womit ja auch schon länger die Gelegenheit zur offensiven Klarstellung/Kommunikation besteht) betreibt.

Man kann jedenfalls (für jemanden, der die Zusammenhänge versteht) auch einigermaßen glaubhaft begründen, warum man besser auf die Benutzung von MyFRITZ!-Namen beim Zugriff aus dem WAN verzichtet ... oder eben damit lebt, daß man seine gesamte Sicherheit am Ende in die Hände von AVM legt (was man sicherlich mit dem FRITZ!OS oder bei Benutzung einer FRITZ!App ohnehin machen muß und so "richtig freche Backdoors" - wie bei anderen Routern - hat man bei AVM auch noch nicht gefunden, das waren bisher fast immer "Programmierfehler"), was - ausgehend von Gottvertrauen - AVM dann automatisch in die Rolle eines "höheren Wesens" erhebt, für die man sich dort - zumindest nach meiner Ansicht - noch nicht wirklich qualifiziert hat.

 

[fda89]

Mir war bislang noch nicht klar dass AVM wirklich die durch verschiedene Dienste gesammelten Daten verknüpft und so im Google-Stil ein riesiges Profil erstellt.

Es gibt auch Zertifikate für AVM die nur diese wirklich notwendigen Hostnamen enthalten:
- myfritz.net
- www.myfritz.net
- sso.myfritz.net
- gateway.myfritz.net
- static.myfritz.net

Google Transparency Report

transparencyreport.google.com

Dieses wird auch präsentiert wenn man https://www.myfritz.net/ im Browser öffnet

Mein Link zum Wildcard oben war nur ein Beispiel, es gibt viele aktive davon die sich nur in der Seriennummer unterscheiden. zb
- https://transparencyreport.google.c.../jLGOFLBuzC7EeV6nwAPszWTUCC4MQkD1E8NIpXbwjiQ=
- https://transparencyreport.google.c.../qbzU9BkA8YkKDT22IUPPq1+nn8Ps66pgJfHxX+KIOhc=

 

[Grisu_]

@PeterPawn: Darf ich dich dazu bitte noch um eine kurze Bemerkung bitten, da ich dein ausführlich geschriebenes nicht so recht verstehe in der Tiefe.
Ich habe meine Boxen in MyFritz registriert jedoch unter Freigabe die beiden Punkte 'Internetzugriff auf die FRITZ!Box über HTTPS aktiviert' sowie 'Internetzugriff auf Ihre Speichermedien über FTP/FTPS aktiviert' deaktiviert (letzteres öffne ich höchstens selten temporär nur bei Bedarf).
Siehst du dann auch noch eine latente oder realistisch größere Gefahr?
Benötige MyFritz nämlich um auf eine entfernte Fritte zu kommen, die ich mit Freigabe->VPN eingebunden habe um ggf. einem Bekannten zu helfen, was wirklich anstandslos ohne jegliche Probleme bislang funktioniert hat.
'VPN-Verbindung dauerhaft halten' habe ich dabei nicht aktiviert, weiß nicht ob das wirklich zur Sicherheit beiträgt, aber schaden kanns wohl kaum und funktioniert so auch perfekt mit vielleicht 1s Verzögerung beim Erstzugriff.

 

[Micha0815]

Benötige MyFritz nämlich um auf eine entfernte Fritte zu kommen, die ich mit Freigabe->VPN eingebunden habe um ggf. einem Bekannten zu helfen, was wirklich anstandslos ohne jegliche Probleme bislang funktioniert hat.

Weshalb muss es unbedingt Myfritz als genutzter DynDNS-Anbieter sein? Ich habe einige FBs im Fern-Zugriff-/VPN-Portfolio und alle historisch bei spdns.de (seinerzeit kostenlos) registriert?
Der Hinweis

gibt es für den Kunden/Besitzer, der Apps benutzen will, auch keine andere/bessere Art der Absicherung gegen (zumindest machbare, was noch nicht impliziert, daß sie auch stattfinden) Übergriffe von AVM, als die Verwendung eines anderen DynDNS-Namens

Hier zumindest scheint der Fernzugriff https... und VPN unter Auslassung von MyFritz zu funktionieren. Ob diverse AVM-Android-APPs (Fon/SmartHome/MyFritz) über das WLAN eingerichtet unter MyFritz-Unterlassung arbeiten?
Das Problem, auf diversen FBs eigene Zertifikate zu erstellen, ist auch nicht ganz trivial
LG

 

[Grisu_]

Weshalb muss es unbedingt Myfritz als genutzter DynDNS-Anbieter sein?

Muß natürlich nicht, ist aber halt sowas von einfach auch für Laien auf dem Gebiet und funktioniert einwandfrei und zudem mit der Box schon quasi mitbezahlt.
Daher die Frage nach den damit verbliebenen Gefahren.

 

[Eisvogel63]

v2.0.3 (2020/10/16)
-------------------
Change: 'Upgrade' predefined DECT base to FRITZ!OS 7.21.
Change: No firmware major version warning if Hardware == FirmwareMajor
        for Hardware >= 249 (FRITZ!Powerline 1260v2). This limit is an
        educated guess and may change in the future.
New: Support for LabPLUS firmware type string (build type 1007)
Fix: Highlight new updates also for DECT devices.
Fix: Beta (Labor) DECT firmware cannot be found with beta (Labor)
     FRITZ!OS version (wrong FRITZ!OS version format in query).

Download: JuisCheck

 

[fda89]

@Eisvogel63
Könntest du noch "Informationen anzeigen" für Dect-Geräte freischalten, bzw downloadbar machen?
Beispiel:

Firmware

http://download.avm.de/dect/0606/psq19/06.06.04.94.avm.de.upd
http://download.avm.de/dect/0607/psq19/06.07.04.94.avm.de.upd

Changelog

http://download.avm.de/dect/0606/psq19/info_06.06.04.94.txt
http://download.avm.de/dect/0607/psq19/info_06.07.04.94.txt

Es gibt aber nicht für jede Firmware so eine Datei!

 

[Ralf-Fritz]

Funktioniert super die Version 2.03

 

[Eisvogel63]

Könntest du noch "Informationen anzeigen" für Dect-Geräte freischalten, bzw downloadbar machen?

Tut mir leid: in der Antwort vom AVM-Server ist kein Link zu diesen Informationen enthalten (und ich möchte auch nicht danach raten). Der Update-Server für DECT-Firmware ist leider viel primitiver als JUIS.

 

[fda89]

Deshalb die Beispiele, so kannst du einen Alghorythmus bauen der die URLs errechnet

 

[Eisvogel63]

Der Dateiname wird bei AVM von Hand erstellt. Auch wenn der heute so aussieht und vielleicht auch morgen, übermorgen könnte er wieder anders sein. Außerdem müsste ich die Datei probeweise herunterladen um zu wissen ob sie überhaupt existiert. Definitiv keine gute Idee. Ich habe besseres zu tun.

 

[NDiIPP]

Tut mir leid: in der Antwort vom AVM-Server ist kein Link zu diesen Informationen enthalten

Dem muss ich mal widersprechen:

Check per juis_check for new FRITZ!Fon C4 Firmware with HW-226

===================================
Variables set:

Serial="000000000000"
Major="154"
Minor="7"
Patch="21"
Build="82154"
Name="FRITZ!Box7590"
HW="226"
OEM="avm"
Lang="de"
Annex="B"
Country="049"
Public="1"
type="1001"
hostname="226.jws.avm.de"
nonce="xxxxxxxxxxxxxxxxxxxxxx=="

===================================
Sent request:
POST /Jason/UpdateInfoService HTTP/1.1
Host: 226.jws.avm.de:80
Content-Length: 1124
Content-Type: text/xml; charset="utf-8"
Connection: close

<?xml version="1.0"?>
<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:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
  <soap:Header/>
  <soap:Body>
    <e:DeviceFirmwareUpdateCheck>
      <e:RequestHeader>
        <q:Nonce>xxxxxxxxxxxxxxxxxxxxxx==</q:Nonce>
        <q:UserAgent>TestClient</q:UserAgent>
        <q:ManualRequest>true</q:ManualRequest>
      </e:RequestHeader>
      <e:BoxInfo>
        <q:Name>FRITZ!Box7590</q:Name>
        <q:HW>226</q:HW>
        <q:Major>154</q:Major>
        <q:Minor>7</q:Minor>
        <q:Patch>21</q:Patch>
        <q:Buildnumber>82154</q:Buildnumber>
        <q:Buildtype>1001</q:Buildtype>
        <q:Serial>000000000000</q:Serial>
        <q:OEM>avm</q:OEM>
        <q:Lang>de</q:Lang>
        <q:Country>049</q:Country>
        <q:Annex>B</q:Annex>
        <q:Flag>prov_acs</q:Flag>
        <q:UpdateConfig>1</q:UpdateConfig>
        <q:Provider>oma_lan</q:Provider>
      </e:BoxInfo>
      <e:DeviceInfo>
        <q:Type>2</q:Type>
        <q:MHW>08.01</q:MHW>
        <q:Version>04.56</q:Version>
        <q:Serial>000000000000</q:Serial>
        <q:Lang>de</q:Lang>
      </e:DeviceInfo>
    </e:DeviceFirmwareUpdateCheck>
  </soap:Body>
</soap:Envelope>

===================================
Received response:
HTTP/1.1 200 OK
Connection: close
Download-Delay: 3536
Content-Type: text/xml;charset=UTF-8
Content-Length: 2077
Date: Fri, 16 Oct 2020 16:57:50 GMT
Access-Control-Allow-Origin: http://scope.avm.de
Access-Control-Allow-Headers: content-type

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
  <soap:Body ID="Body">
    <ns2:DeviceFirmwareUpdateCheckResponse xmlns:ns2="http://juis.avm.de/updateinfo" xmlns:ns3="http://juis.avm.de/response" xmlns:ns4="http://juis.avm.de/request">
      <ns2:ResponseUpdateInfo>
        <ns3:ResponseHeader>
          <ns3:Nonce>xxxxxxxxxxxxxxxxxxxxxx==</ns3:Nonce>
        </ns3:ResponseHeader>
        <ns3:UpdateInfo>
          <ns3:CheckInterval>168</ns3:CheckInterval>
          <ns3:Found>true</ns3:Found>
          <ns3:Name>C4 PSQ19</ns3:Name>
          <ns3:Version>4.57</ns3:Version>
          <ns3:Type>1</ns3:Type>
          <ns3:DownloadURL>http://download.avm.de/dect/0801/psq19/08.01.04.57.avm.de.upd</ns3:DownloadURL>
          <ns3:InfoURL>http://download.avm.de/dect/0801/psq19/info_08.01.04.57.de.txt</ns3:InfoURL>
          <ns3:InfoText/>
          <ns3:HintURL/>
          <ns3:IconURL/>
          <ns3:Priority>1</ns3:Priority>
          <ns3:AutoUpdateStartTime>0</ns3:AutoUpdateStartTime>
          <ns3:AutoUpdateEndTime>0</ns3:AutoUpdateEndTime>
          <ns3:AutoUpdateKeepServices>true</ns3:AutoUpdateKeepServices>
        </ns3:UpdateInfo>
      </ns2:ResponseUpdateInfo>
    </ns2:DeviceFirmwareUpdateCheckResponse>
    <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/2001/04/xmldsig-more#rsa-sha256"/>
        <Reference URI="#Body">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <DigestValue>yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy==</SignatureValue>
    </Signature>
  </soap:Body>
</soap:Envelope>

======= end of debug output =======
Found newer version : 4.57

Check DECT-Firmware per juis_check beendet.

Und daran hat sich in den letzten Jahren eigentlich auch nichts geändert. Die "Info.txt" war immer im Feld "InfoURL" in der Antwort des JUIS zu finden (falls JUIS eine entsprechende .txt für die jeweilige Version bekanntgibt), auch wenn man für DECT-Geräte anfragt (um dem Punkt "Auch wenn der heute so aussieht und vielleicht auch morgen, übermorgen können er wieder anders sein." zu entgegnen).


Edit:
Hier eine entsprechende JUIS-Abfrage für ein DECT-Device aus dem Jahre 2018:
https://www.ip-phone-forum.de/threads/neues-c5.280918/post-2279816