Ein TK-Dienstleister hatte nach Aussage eines Bekannten LAN-Zugriff auf eine be.ip und dabei angeblich ein ihm nicht bekanntes Passwort für die Konfiguration ausgelesen und die be.ip umkonfiguriert. Geht das wirklich so leicht?
be.ip Passwort-Hack
- Ersteller neuber18
- Erstellt am
-
- Schlagworte
- be.ip passwort
Die Benutzernamen+Passwörter sollten sicherlich verschlüsselt im Endgerät gespeichert sein.
Vielleicht wurde lediglich dieser Zugang für die elmeg be.IP-Familie benutzt?
Vielleicht wurde lediglich dieser Zugang für die elmeg be.IP-Familie benutzt?
Es lag nicht mehr das Standard-Passwort vor, welches auf dem Router aufgeklebt war, sondern ein geändert. Also war es normalerweise nicht bekannt.
Der Router wurde auch nicht zurückgesetzt, sondern in der bestehenden Konfiguration vom TK-Dienstleister geändert.
Was ist denn ein Zugang für die elmeg be.IP-Familie?
Der Router wurde auch nicht zurückgesetzt, sondern in der bestehenden Konfiguration vom TK-Dienstleister geändert.
Was ist denn ein Zugang für die elmeg be.IP-Familie?
Mehr Details wären nicht schlecht.
Verstehe ich es richtig, dass das Kennwort nicht bekannt war und der TK-Dienstleister es dann geschafft haben soll, auf die be.IP zu kommen, und die Konfig geändert (inkl. neues Kennwort) hat?
Kann es sein, dass im Zuge des "Suchens" nach dem Kennwort der TK-Dienstleister eine alte exportierte Konfigdateit gefunden hat (.cf-File)?
Diese lassen sich bekanntlich auch ohne Verschlüsselung erstellen und dann stehen die Kennworte im Klartext drin.
Verstehe ich es richtig, dass das Kennwort nicht bekannt war und der TK-Dienstleister es dann geschafft haben soll, auf die be.IP zu kommen, und die Konfig geändert (inkl. neues Kennwort) hat?
Kann es sein, dass im Zuge des "Suchens" nach dem Kennwort der TK-Dienstleister eine alte exportierte Konfigdateit gefunden hat (.cf-File)?
Diese lassen sich bekanntlich auch ohne Verschlüsselung erstellen und dann stehen die Kennworte im Klartext drin.
Genau. Ein Zugriff auf das Kunden-Netzwerk war bereits physikalisch nicht möglich. Also auch keine alten Sicherungen von Konfigurationsdateien. Es scheint also einen Trick zu geben, mit dem die be.ip Passwort ausplaudert...
Hi,
das geht mir zu schnell, um zu glauben, dass es eine Hintertür geben soll.
Das Szenario ist nach wie vor völlig unklar.
Was heißt " Ein Zugriff auf das Kunden-Netzwerk war bereits physikalisch nicht möglich"?
Oder anders gefragt:
War der TK-DL vor Ort?
Wenn ja, warum soll ein physischer Zugriff nicht möglich sein, nur, weil man das Kennwort des Routers nicht kennt?
Wenn nein: Ist es ein neuer TK-DL? Wenn nein: Ich betreue etliche Kundenrouter und wähle mich bei Bedarf per VPN ein. Natürlich habe ich Backups der Konfigs in der Kundenablage. Es könnte also durchaus sein, dass der TK-DL in seiner Ablage eine alte Konfig gefunden hat.
Frag' doch mal deinen Bekannten nach konkreten Infos. Das Thema ist durchaus interessant.
das geht mir zu schnell, um zu glauben, dass es eine Hintertür geben soll.
Das Szenario ist nach wie vor völlig unklar.
Was heißt " Ein Zugriff auf das Kunden-Netzwerk war bereits physikalisch nicht möglich"?
Oder anders gefragt:
War der TK-DL vor Ort?
Wenn ja, warum soll ein physischer Zugriff nicht möglich sein, nur, weil man das Kennwort des Routers nicht kennt?
Wenn nein: Ist es ein neuer TK-DL? Wenn nein: Ich betreue etliche Kundenrouter und wähle mich bei Bedarf per VPN ein. Natürlich habe ich Backups der Konfigs in der Kundenablage. Es könnte also durchaus sein, dass der TK-DL in seiner Ablage eine alte Konfig gefunden hat.
Frag' doch mal deinen Bekannten nach konkreten Infos. Das Thema ist durchaus interessant.
"TK-Dienstleister" = Provider? Da gibt's doch meiner Erinnerung nach eine Zugriffsmöglichkeit für den Provider über das Protokoll TR-069, sofern das nicht im Router deaktiviert wurde. Wobei ich nicht weiß, wie das bei de be.ip ist, ich kenne das nur von der Fritzbox.
Glaube nicht, dass er mit TK-DL den Provider meint.
Der Zugriff durch den Internetprovider geht meines Wissens nicht bei Bintecs be.IP, zumindest nicht standardmäßig. Ob sich das einrichten lässt, weiß ich nicht. Ich käme nie auf die Idee sowas zu benutzen
Vielleicht bei der Digitalisierungsbox, da die ja eine (Telekom-) abgeänderte Firmware hat. Aber er sprach ja von einer be.IP.
Der Zugriff durch den Internetprovider geht meines Wissens nicht bei Bintecs be.IP, zumindest nicht standardmäßig. Ob sich das einrichten lässt, weiß ich nicht. Ich käme nie auf die Idee sowas zu benutzen
Vielleicht bei der Digitalisierungsbox, da die ja eine (Telekom-) abgeänderte Firmware hat. Aber er sprach ja von einer be.IP.
Einen TK-Dienstleister, der sich nicht die Konfig in seinen eigenen Einflussbereich wegspeichert bei jedem Zugriff kann ich mir (fast) nicht vorstellen.
Von daher halte ich es ebenfalls bei derzeitiger Informationslage für den wahrscheinlichsten Fall.
Ungeachtet unserer Vermutungen sollte @neuber18 das bei seinem Bekannten nochmal genauesten hinterfragen.
Von daher halte ich es ebenfalls bei derzeitiger Informationslage für den wahrscheinlichsten Fall.
Ungeachtet unserer Vermutungen sollte @neuber18 das bei seinem Bekannten nochmal genauesten hinterfragen.
Im ersten Post steht was von Zugriff über LAN, im 6. Post war angeblich kein physikalischer Zugriff möglich?
Ein TK-DL, den ich bezahle, der dann auf meinem Router (ohne meinen Auftrag) was ändert ist auch seeeehr fragwürdig...
Ich würde mich da auch über mehr Informationen freuen. Ich setze die be.IP plus bei mir daheim ein...
Ein TK-DL, den ich bezahle, der dann auf meinem Router (ohne meinen Auftrag) was ändert ist auch seeeehr fragwürdig...
Ich würde mich da auch über mehr Informationen freuen. Ich setze die be.IP plus bei mir daheim ein...
Habe nun weiter angefragt:
TK-DL war vor Ort, hatte zugriff nur auf die be.ip LAN-Buchsen.
Das eigentliche lokale Kunden-Netzwerk kann von der be.ip aus nicht gesehen werden kann, abgesichert hinter zwischengeschalteter Firewall.
Es kann nicht ausgeschlossen werden, dass der Dienstleister ältere Konfigurationen hatte, wo allerdings andere Passworte verwendet waren.
Bearbeitet wurde aber von ihm die aktuelle Konfig der be.ip, die nachher wieder mit dem gleichen aktuellen Passwort vorgelegen hat.
Es sieht also so aus, als gäbe es ein Hintertürchen über eine Art "Superuser" o.ä. - das wäre ein nicht akzeptables Sicherheitsloch.
### Zusammenührung Doppelpost by stoney ###
Der TK-Dienstleister hat ja im Auftrag des Kunden gearbeitet und was an der Router-Konfig geändert.
### Zusamenführung Doppelpost by stoney ###
TR-069 war aus, der VDSL100-Anschluss soll von der Telekom stammen, wobei der Bekannte keinen Wartungsvertrag dort laufen hat.
Zuletzt bearbeitet von einem Moderator:
Bzgl. Backdoor sind die deutschen BND-Gesetze gemacht und kürzlich erneuert worden.
Aber gibt es auch eine Backdoor für Servicemitarbeiter und Kunden?
Nein!
Die schauen in die Röhre ... ohne Licht am Ende zu erblicken.
Aber gibt es auch eine Backdoor für Servicemitarbeiter und Kunden?
Nein!
Die schauen in die Röhre ... ohne Licht am Ende zu erblicken.
Es gibt mehrere mögliche Ursachen für die Konfigurationsänderung:
1.) Das aktuelle Zugangspasswort war im Browser eines Rechners gespeichert.
2.) Der Dienstleister hatte physikalischen Zugang zur be.IP und konnte diese somit starten und dafür sorgen das sie ohne Konfiguration gestartet wurde um dann eine ältere exportierte Konfiguration einspielen.
3.) Irgendwer hat dem Dienstleister das aktuelle Passwort verraten.
1.) Das aktuelle Zugangspasswort war im Browser eines Rechners gespeichert.
2.) Der Dienstleister hatte physikalischen Zugang zur be.IP und konnte diese somit starten und dafür sorgen das sie ohne Konfiguration gestartet wurde um dann eine ältere exportierte Konfiguration einspielen.
3.) Irgendwer hat dem Dienstleister das aktuelle Passwort verraten.
NDiIPP
IPPF-Promi
- Mitglied seit
- 13 Apr 2017
- Beiträge
- 9,795
- Punkte für Reaktionen
- 2,346
- Punkte
- 113
Oder 4.) (beziehungsweise als Ergänzung zu 2. denn eine ältere Konfiguration widerspricht der Schilderung in #12):
Bei physischem Zugang zum Gerät sind die darauf gespeicherten Informationen prinzipiell als kompromittiert zu betrachten, dafür muss noch nicht einmal eine Sicherheitslücke oder irgendein Backdoor verantwortlich sein sondern ist einfach mit dem Umstand zu erklären, dass das Gerät selbst Zugriff auf diese Informationen (hier Zugangsdaten zum Gerät) haben muss um damit auch "arbeiten" zu können.
Auch wenn diese Informationen verschlüsselt im Speicher des Gerätes abgelegt sein sollten ist das eben noch kein Schutz denn das Gerät muss diese Informationen auch wieder selbst entschlüsseln können und das, was das Gerät selbst kann, könnte theoretisch auch jeder dritte der physischen Zugang auf dieses Gerät hat(te).
Die Frage wäre dann lediglich wie aufwendig das bei einer be.IP tatsächlich ist. Aber spätestens beim aufschrauben des Gerätes (sind ja nur 4 kleine Schrauben, schon hat man das PCB der be.IP vor sich) kann man auf den darin verbauten 32MB NOR-Flashbaustein (Macronix MX29GL256F im TSOP-Gehäuse) zugreifen und mit geeigneter Ausrüstung komplett auslesen. Dann müsste man "nur" noch die darin verschlüsselt gespeicherten Informationen entschlüsseln, vorausgesetzt das BOSS verschlüsselt diese überhaupt (um ehrlich zu sein würde es mich nicht wirklich wundern wenn die Daten im Flash sogar unverschlüsselt abgelegt sind, die Konfigurationsdatei kann man ja bspw. ebenfalls auf Wunsch komplett unverschlüsselt exportieren und es würde mich nicht wundern, wenn diese im Flashspeicher der be.IP ebenfalls unverschlüsselt vorzufinden ist).
Ansonsten müsste man eben noch die Verschlüsselungsmethode herausbekommen was aber vermutlich auch kein unlösbares Problem darstellen muss, denn wie oben schon erwähnt muss die be.IP dazu ja selbst in der Lage sein auf die Informationen in unverschlüsselter Form zuzugreifen und daher müssen diese auch mit nicht (wirklich) geheimen Passwörtern oder Schlüsseln (zumindest wenn man den kompletten Inhalt des Flashspeicher hat) entschlüsselt werden können, oder wenn dann lediglich individuell bspw. anhand der MAC-Adresse oder Seriennummer (was wiederum kein Geheimnis wäre).
Und auch ob dazu das Aufschrauben der be.IP tatsächlich notwendig ist um an die Informationen zu kommen ist nicht wirklich sicher, Zugriff auf den Bootloader reicht vielleicht auch schon aus (die be.IP + hat ja netterweise eine RS-232 Schnittstelle die man dafür vielleicht bereits verwenden könnte). Und vielleicht kann man auch bereits über die LAN-Port der be.IP auf den Bootloader zugreifen (bei einem Geräteneustart), wie bei vielen anderen Geräten auch.
Dieses Hintertürchen bei physischem Zugang zum Gerät gibt es praktisch bei fast jedem Gerät, das lässt sich schwer vermeiden, ist quasi prinzipbedingt kaum vermeidbar.
Das heißt übrigens nicht, dass der Dienstleister in diesem Fall tatsächlich diese Methode angewendet haben muss (aber ausschließen würde ich es auch wieder nicht, insbesondere wenn sich dieser mit der be.IP vielleicht tatsächlich gut auskennt, zumindest wenn er etwas mehr weiß als das was Bintec auf den üblichen Schulungen so preisgibt).
Wenn er im Auftrag des Kunden gearbeitet hat wird er das Passwort entweder schon gehabt haben (weil es ihm vielleicht auch ein Mitarbeiter schon mal im Rahmen eines früheren Auftrag mitgeteilt hat) oder er hat es am gleichen Tage bei einem Mitarbeiter erfragt. Oder aber er hat tatsächlich aufgrund des physischen Zugang zum Gerät oder zu den LAN-Ports eine Möglichkeit genutzt die komplette Konfiguration auszulesen (Spekulation).
Bei physischem Zugang zum Gerät sind die darauf gespeicherten Informationen prinzipiell als kompromittiert zu betrachten, dafür muss noch nicht einmal eine Sicherheitslücke oder irgendein Backdoor verantwortlich sein sondern ist einfach mit dem Umstand zu erklären, dass das Gerät selbst Zugriff auf diese Informationen (hier Zugangsdaten zum Gerät) haben muss um damit auch "arbeiten" zu können.
Auch wenn diese Informationen verschlüsselt im Speicher des Gerätes abgelegt sein sollten ist das eben noch kein Schutz denn das Gerät muss diese Informationen auch wieder selbst entschlüsseln können und das, was das Gerät selbst kann, könnte theoretisch auch jeder dritte der physischen Zugang auf dieses Gerät hat(te).
Die Frage wäre dann lediglich wie aufwendig das bei einer be.IP tatsächlich ist. Aber spätestens beim aufschrauben des Gerätes (sind ja nur 4 kleine Schrauben, schon hat man das PCB der be.IP vor sich) kann man auf den darin verbauten 32MB NOR-Flashbaustein (Macronix MX29GL256F im TSOP-Gehäuse) zugreifen und mit geeigneter Ausrüstung komplett auslesen. Dann müsste man "nur" noch die darin verschlüsselt gespeicherten Informationen entschlüsseln, vorausgesetzt das BOSS verschlüsselt diese überhaupt (um ehrlich zu sein würde es mich nicht wirklich wundern wenn die Daten im Flash sogar unverschlüsselt abgelegt sind, die Konfigurationsdatei kann man ja bspw. ebenfalls auf Wunsch komplett unverschlüsselt exportieren und es würde mich nicht wundern, wenn diese im Flashspeicher der be.IP ebenfalls unverschlüsselt vorzufinden ist).
Ansonsten müsste man eben noch die Verschlüsselungsmethode herausbekommen was aber vermutlich auch kein unlösbares Problem darstellen muss, denn wie oben schon erwähnt muss die be.IP dazu ja selbst in der Lage sein auf die Informationen in unverschlüsselter Form zuzugreifen und daher müssen diese auch mit nicht (wirklich) geheimen Passwörtern oder Schlüsseln (zumindest wenn man den kompletten Inhalt des Flashspeicher hat) entschlüsselt werden können, oder wenn dann lediglich individuell bspw. anhand der MAC-Adresse oder Seriennummer (was wiederum kein Geheimnis wäre).
Und auch ob dazu das Aufschrauben der be.IP tatsächlich notwendig ist um an die Informationen zu kommen ist nicht wirklich sicher, Zugriff auf den Bootloader reicht vielleicht auch schon aus (die be.IP + hat ja netterweise eine RS-232 Schnittstelle die man dafür vielleicht bereits verwenden könnte). Und vielleicht kann man auch bereits über die LAN-Port der be.IP auf den Bootloader zugreifen (bei einem Geräteneustart), wie bei vielen anderen Geräten auch.
Dieses Hintertürchen bei physischem Zugang zum Gerät gibt es praktisch bei fast jedem Gerät, das lässt sich schwer vermeiden, ist quasi prinzipbedingt kaum vermeidbar.
Das heißt übrigens nicht, dass der Dienstleister in diesem Fall tatsächlich diese Methode angewendet haben muss (aber ausschließen würde ich es auch wieder nicht, insbesondere wenn sich dieser mit der be.IP vielleicht tatsächlich gut auskennt, zumindest wenn er etwas mehr weiß als das was Bintec auf den üblichen Schulungen so preisgibt).
Wenn er im Auftrag des Kunden gearbeitet hat wird er das Passwort entweder schon gehabt haben (weil es ihm vielleicht auch ein Mitarbeiter schon mal im Rahmen eines früheren Auftrag mitgeteilt hat) oder er hat es am gleichen Tage bei einem Mitarbeiter erfragt. Oder aber er hat tatsächlich aufgrund des physischen Zugang zum Gerät oder zu den LAN-Ports eine Möglichkeit genutzt die komplette Konfiguration auszulesen (Spekulation).
Leicht OT: Gilt das noch immer? Wenn ja, wie? Wann immer ich eine .cf exportiere, bis auf den Header ist das irgendwie verschlüsslet/verschleiert oder irgendwas. Gibt es hier eine Möglichkeit, die gesamte Config ohne Verschlüsselung mit klartextPWDs zu exportieren?
Bei der be.IP Plus kann man ja alles über den SNMP-Browser einsehen oder SSH verwenden, mit der kleineren bi.IP (ohne Plus) klappt das soweit ich weiss nicht.
Wäre für ein wenig Hilfe dankbar...
Nein, bei der be.IP (ohne plus) gibt es keine Möglichkeit, die config unverschlüsselt zu exportieren.
Sch...ade ;-)
Ich nehme mal an, es existiert auch kein decryptor oder etwas anderes zum Dateiformat (vermutlich irgendein gz, xz, bz2 oder auch nur rotXY)
Dann muss ich mich wohl doch mal durch die Warteschlange der Telekom wühlen, äehm wählen und warten....
NDiIPP
IPPF-Promi
- Mitglied seit
- 13 Apr 2017
- Beiträge
- 9,795
- Punkte für Reaktionen
- 2,346
- Punkte
- 113
BTW: Und bei der be.IP plus klappt es weiterhin mit dem unverschlüsselten Export:
Wie schon erwähnt bei der ohne plus jedoch nicht und auch nicht bei den Digitalisierungsboxen Standard, Smart und Premium.
Wie schon erwähnt bei der ohne plus jedoch nicht und auch nicht bei den Digitalisierungsboxen Standard, Smart und Premium.
Neueste Beiträge
-
[Frage] Variierende W-LAN Abdeckung
- Letzte: Master1
-
[Sammlung] FRITZ!Smart Gateway - Labor/Inhaus 7.90/08.00 (Zyklus 'Smart24P1 (NL1)')- Letzte: Michel aus Lönneberga
-
[Sammlung] FRITZ!Box 4050, 5690 Pro, 6860 5G und 7690- Letzte: Brown
-
AVM Thermostate mit Zigbee Sensoren
- Letzte: Erforderlich
-
Wer versucht mich da zu hacken?- Letzte: Gildehauser
-
DX800A Verbindungsassistent fehlt- Letzte: chrsto
