LC 10.50.00290 kann kein 1780EW-4G mit 10.42.0740 konfigurieren

Fragen zur LANCOM Management Windows Software/ LANtolls: LANconfig, LANmonitor, WLANmonitor.

Moderator: Lancom-Systems Moderatoren

Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: LC 10.50.00290 kann kein 1780EW-4G mit 10.42.0740 konfigurieren

Beitrag von Koppelfeld »

Hallo,
tstimper hat geschrieben: 12 Feb 2023, 23:00 Deshalb vermute ich, das in def 10.50.1100 der OpenSSL
Fix drin sein könnte, da diese Version zeitnah nach
der 10.42.xxxx kam.
Ich frage 'mal ganz blöd, weil mir die Begriffe 'Open' und 'Secure' abgrundtief verhaßt sind:
Wozu brauchst Du einen "Open SSL Fix" ?

Aus Sicherheitsgründen administriere ich sowieso nur mit telnet, aber halt über ein dediziertes Managementnetz.

Aber die 7100+ sind doch ansonsten ganz in Ordnung bis auf das dilettantisch kaputtgespielte Webinterface ?
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: LC 10.50.00290 kann kein 1780EW-4G mit 10.42.0740 konfigurieren

Beitrag von tstimper »

Koppelfeld hat geschrieben: 13 Feb 2023, 00:03 Hallo,
tstimper hat geschrieben: 12 Feb 2023, 23:00 Deshalb vermute ich, das in def 10.50.1100 der OpenSSL
Fix drin sein könnte, da diese Version zeitnah nach
der 10.42.xxxx kam.
Ich frage 'mal ganz blöd, weil mir die Begriffe 'Open' und 'Secure' abgrundtief verhaßt sind:
Wozu brauchst Du einen "Open SSL Fix" ?
Hallo Koppelfeld,

siehe auch Thread OpenSSL 1.1.1q vs. OpenSSL 1.1.1t
fragen-zur-lancom-systems-routern-und-g ... 19799.html

Die OpenSSL library wird von vielen Hard und Software Herstellern genutzt und ist für alle SSL Verschlüssungen zuständig.
Und das ist ein Problem....
Jedachdem, wie Lancom das im LCOS implementiert hat, betrifft das dann nich nur SSH, sondern auch Telnet over SSL, IPSEC VPN,
den Zertifikatsserver, HTTPS für Config für LANconfig und WEB Zugriff, SNMPv3 fürs Monitoring.

Wenn das so ist, sind grad ALLE Lancom Router Deployments gefährdet.

Um das einschätzen zu können, benötigen wir (da kommen wier wieder zum Problem der offenenn Kommunikation von Bugs und Änderungen in den Firmware Versionen) eine klare und ofene Einschätzung von LANCOM, welche Gefährdung besteht.

Wir hatten 2021 selbst eine Sicherheitslücke gefunden und an Lancom geportet, siehe CVE-2021-33903
https://www.nmedv.de/2021/10/04/lancom- ... or-snmpv3/

Lancom nimmt das schon Ernst, auch der CVE Prozess mit Tests und Bereitstellung eines Fixes an uns uns und dann für alle Kunden war vorbildlich.

Nochmal zu m Thema. Wenn Lancom auch für VPN diese Library nimmt, bricht das alle VPN verbindungen. Und DAS ist das große Problem.
Da brauchen wir Klarheit und schnelle Fixes, Für alle sich in Betrieb befindlichen Geräte.
Koppelfeld hat geschrieben: 13 Feb 2023, 00:03 Aus Sicherheitsgründen administriere ich sowieso nur mit telnet, aber halt über ein dediziertes Managementnetz.
Telnet ist eben unverschlüsselt und Telnet over SSL ist vermutlich grad angreifbar.
Und ein dediziertes Management Netz ist, wenn es über VPN zu Filialen reicht, wiederum angreifbar.

Wie oben schon gesagt, WENN die OpenSSL Library AUCH für VPN und Zertifikate genutzt wird.
Das wissen (nur) die LCOS Entwicker.
Koppelfeld hat geschrieben: 13 Feb 2023, 00:03 Aber die 7100+ sind doch ansonsten ganz in Ordnung bis auf das dilettantisch kaputtgespielte Webinterface ?
Ja die 7100+ sind völlig ok und können noch 3-5 Jahre laufen.
Es gibt eben nur noch bis Ende September 2023 Fixes und keine neue Firmware.
Mit der LC-7100plus-10.42.1102 bit OpenSSL Fix sind die auch erstmal save.

Also das OenSSL Problem ist bitterer Ernst...

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: LC 10.50.00290 kann kein 1780EW-4G mit 10.42.0740 konfigurieren

Beitrag von backslash »

Hi tstimper
Also das OenSSL Problem ist bitterer Ernst...
so Ernst würde ich das nicht sehen, denn Openssl sagt selbst, daß man als Angreifer sowohl die CA als auch die CRL kontrollieren muß, um den Fehler triggern zu können (https://www.cve.org/CVERecord?id=CVE-2023-0286):
In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon.
Aber da natürlich nichts unmöglich ist, ist es besser ein Update einzuspielen

Gruß
Backlsash
Antworten