ein paar Beobachtungen zum Thema Passwort

[Jirka]

Hallo,

ein paar Beobachtungen zum Thema Passwort (Firmware 9.24.0196).

1) Das Geräte-Passwort darf max. 15 Zeichen lang sein, ein Passwort eines Admins 16 Zeichen. Warum das so ist, keine Ahnung. Ist man mit einem Admin-Zugang eingeloggt (also nicht mit dem Geräte-Passwort), so lehnt ein 'passwd' auf der Konsole jedoch ein 16-stelliges Passwort ab.

2) Ein Administrator mit eingeschränkten Zugriffs-Rechten unterliegt ja gewissen Einschränkungen, wie es der Name schon sagt. Er hat aber auch das Recht, den Parameter /Setup/Config/Enforce-Password-Rules (LANconfig: Geräte-Passwort-Richtlinie erzwingen) zu ändern. Damit ist er in der Lage, einen funktionalen Administrator ohne Passwort oder mit einfachem Passwort ("admin admin") anzulegen (mit eingeschränkten Rechten). Es steht die Frage im Raum, ob das als ok angesehen wird, oder ob man eher die Auffassung vertritt, dass einem Admin mit eingeschränkten Rechten eine derartige Verletzung der Geräte-Passwort-Richtlinie (und damit der Sicherheit, insbesondere von WAN-Seite) besser nicht erlaubt werden sollte.

3) Durch das Einspielen der schon etwas älteren Beta 9.24.0099 (und vermutlich auch durch eine darauffolgende Release-Version - kann das mal jemand überprüfen, der keine Betas einspielt?) wurde das Geräte-Passwort ohne zu fragen und meines Wissens ohne dass es dokumentiert ist, in den Parameter /Setup/CWMP/Connection-Request-Password kopiert (LANconfig: Management -> CWMP/TR-069 -> Passwort für Verbindungsanfrage (ist ausgegraut, erscheint erst nach aktivieren von CWMP)). War das so beabsichtigt? Es lassen sich zwei denkbare Sicherheitsprobleme ableiten (ohne dass CWMP eingeschaltet ist/wird): a) Man gibt mit einem 'readscript' (der kompletten Konfig) unbemerkt das Geräte-Passwort weiter, auch wenn man sich in der Vergangenheit sicher sein konnte, dass ein 'readscript' kein Geräte-Passwort enthält. b) Das Geräte-Passwort wird geändert, weil das Geräte-Passwort mit anderen Parteien geteilt wird. Der neue Admin kann nun das ursprüngliche Passwort auslesen, was der ursprüngliche Admin nicht weiter geben wollte. Ich kann nur dazu raten, ein Script in sämtliche Router einzuspielen, was CWMP zurück auf die Defaultwerte setzt.

4) In WEBconfig unter Systeminformation -> Dienste fehlt SNMPv3.

Vielen Dank und viele Grüße,
Jirka

[Dr.Einstein]

Hi Jirka,

3) Durch das Einspielen der schon etwas älteren Beta 9.24.0099 (und vermutlich auch durch eine darauffolgende Release-Version - kann das mal jemand überprüfen, der keine Betas einspielt?) wurde das Geräte-Passwort ohne zu fragen und meines Wissens ohne dass es dokumentiert ist, in den Parameter /Setup/CWMP/Connection-Request-Password kopiert (LANconfig: Management -> CWMP/TR-069 -> Passwort für Verbindungsanfrage (ist ausgegraut, erscheint erst nach aktivieren von CWMP)). War das so beabsichtigt? Es lassen sich zwei denkbare Sicherheitsprobleme ableiten (ohne dass CWMP eingeschaltet ist/wird): a) Man gibt mit einem 'readscript' (der kompletten Konfig) unbemerkt das Geräte-Passwort weiter, auch wenn man sich in der Vergangenheit sicher sein konnte, dass ein 'readscript' kein Geräte-Passwort enthält. b) Das Geräte-Passwort wird geändert, weil das Geräte-Passwort mit anderen Parteien geteilt wird. Der neue Admin kann nun das ursprüngliche Passwort auslesen, was der ursprüngliche Admin nicht weiter geben wollte. Ich kann nur dazu raten, ein Script in sämtliche Router einzuspielen, was CWMP zurück auf die Defaultwerte setzt.

Autsch, Volltreffer. Habe hier auch Geräte, die davon betroffen sind, alle größer als 9.24RU2. Ist mir ehrlich gesagt überhaupt nicht aufgefallen. Gut, dass meine Änderungsskripte immer ein default -r enthalten. Danke für die Information.

Gruß Dr.Einstein

[LoUiS]

Hi,

1) Das Geräte-Passwort darf max. 15 Zeichen lang sein, ein Passwort eines Admins 16 Zeichen. Warum das so ist, keine Ahnung. Ist man mit einem Admin-Zugang eingeloggt (also nicht mit dem Geräte-Passwort), so lehnt ein 'passwd' auf der Konsole jedoch ein 16-stelliges Passwort ab.

Dies ist in der Tat ein Fehler auf der CLI, der Benutzer mit Admin-Rechten sollte sein Passwort auch an dieser Stelle mit 16 Zeichen setzen koennen. -> Bugreport

2) Ein Administrator mit eingeschränkten Zugriffs-Rechten unterliegt ja gewissen Einschränkungen, wie es der Name schon sagt. Er hat aber auch das Recht, den Parameter /Setup/Config/Enforce-Password-Rules (LANconfig: Geräte-Passwort-Richtlinie erzwingen) zu ändern. Damit ist er in der Lage, einen funktionalen Administrator ohne Passwort oder mit einfachem Passwort ("admin admin") anzulegen (mit eingeschränkten Rechten). Es steht die Frage im Raum, ob das als ok angesehen wird, oder ob man eher die Auffassung vertritt, dass einem Admin mit eingeschränkten Rechten eine derartige Verletzung der Geräte-Passwort-Richtlinie (und damit der Sicherheit, insbesondere von WAN-Seite) besser nicht erlaubt werden sollte.

Es gibt im LCOS keine Rechte pro Menuepunkt, deshalb ist das ok.

3) Durch das Einspielen der schon etwas älteren Beta 9.24.0099 (und vermutlich auch durch eine darauffolgende Release-Version - kann das mal jemand überprüfen, der keine Betas einspielt?) wurde das Geräte-Passwort ohne zu fragen und meines Wissens ohne dass es dokumentiert ist, in den Parameter /Setup/CWMP/Connection-Request-Password kopiert (LANconfig: Management -> CWMP/TR-069 -> Passwort für Verbindungsanfrage (ist ausgegraut, erscheint erst nach aktivieren von CWMP)). War das so beabsichtigt? Es lassen sich zwei denkbare Sicherheitsprobleme ableiten (ohne dass CWMP eingeschaltet ist/wird): a) Man gibt mit einem 'readscript' (der kompletten Konfig) unbemerkt das Geräte-Passwort weiter, auch wenn man sich in der Vergangenheit sicher sein konnte, dass ein 'readscript' kein Geräte-Passwort enthält. b) Das Geräte-Passwort wird geändert, weil das Geräte-Passwort mit anderen Parteien geteilt wird. Der neue Admin kann nun das ursprüngliche Passwort auslesen, was der ursprüngliche Admin nicht weiter geben wollte. Ich kann nur dazu raten, ein Script in sämtliche Router einzuspielen, was CWMP zurück auf die Defaultwerte setzt.

Vorab, ich persoenlich halte das weitergeben von Admin Scripten, ohne diese ausreichend zu pruefen, fuer zumindest fahrlaessig. Ich will hier aber keine Diskussion darueber vom Zaun brechen. Zum eigentlichen Umstand: Das Passwort soll nicht an diese Stelle kopiert werden, dies ist ein Fehler. In den aktuellen 10er Builds ist das Verhalten bereits korrigiert.

4) In WEBconfig unter Systeminformation -> Dienste fehlt SNMPv3.

Das ist eine Tabelle fuer Dienste mit offenen Ports. SNMP mit Port 161 wird dort angezeigt.


Ciao
LoUiS

[Jirka]

Hallo LoUiS,

Es gibt im LCOS keine Rechte pro Menüpunkt, deshalb ist das ok.

alles klar. Dann könnte man unter der Prämisse, dass man ein konsistentes Verhalten anstrebt, höchstens noch verhindern, dass über WAN ein Zugriff ohne Passwort möglich ist, wie es bei dem Geräte-Passwort ja auch der Fall ist. Also derzeitige Situation im Klartext: Mit nicht gesetztem Geräte-Passwort kommt man von WAN-Seite nicht aufs Gerät. Mit nicht gesetzem Passwort bei einem Administrator hingegen schon (z. B. Benutzername admin, Passwort nicht gesetzt; ein derartiger Administrator lässt sich glaube ich nur über die Konsole erzeugen, LANconfig will in jedem Fall mind. ein Zeichen als Passwort, evt. kann man ja auch leicher dieses Verhalten ändern (auf der Konsole)). Ich stelle das hier nur in den Raum und bewerte es nicht, weswegen ich ja auch nicht von Bug gesprochen habe. Ich habe aber auch schon mal einen Kunden erlebt, der durch irgendwelche Fehler unbeabsichtigt einen Admin ohne Passwort hatte.

Vorab, ich persönlich halte das Weitergeben von Admin Scripten, ohne diese ausreichend zu prüfen, für zumindest fahrlässig.

Klar ist das fahrlässig... Aber die Leute machen es. Was meinst Du, wie ich das Problem vor einiger Zeit entdeckt habe?

Das ist eine Tabelle fuer Dienste mit offenen Ports. SNMP mit Port 161 wird dort angezeigt.

Genau. Aber nicht SNMPv3. SNMPv3 ist eingeschaltet und von WAN-Seite erlaubt (SNMPv1/v2 hingegen nicht -> Tabelle zeigt an, dass SNMP nicht erlaubt sei), aber in dieser Tabelle ist davon nichts zu sehen? Das ist ja sicherlich nicht die Intention dieser Tabelle, über SNMPv3 keine Aussagen zu treffen.

Vielen Dank und viele Grüße,
Jirka

[LoUiS]

Genau. Aber nicht SNMPv3. SNMPv3 ist eingeschaltet und von WAN-Seite erlaubt (SNMPv1/v2 hingegen nicht -> Tabelle zeigt an, dass SNMP nicht erlaubt sei), aber in dieser Tabelle ist davon nichts zu sehen? Das ist ja sicherlich nicht die Intention dieser Tabelle, über SNMPv3 keine Aussagen zu treffen.

SNMP verwendet Port 161 egal ob v2 oder v3, deshalb gibt es auch nur den Eintrag SNMP. Es gibt es keinen weitere Unterscheidung zwischen v2 oder v3.
Dass der Port auf dem WAN als geschlossen angezeigt wird, obwohl SNMPv3 erlaubt ist haettest Du auch direkt schreiben koennen. Dies ist natuerlich nicht richtig.

[Jirka]

Ja sorry. Für mich sah es so aus, als ob da SNMPv3 fehlt. Ich meine was ist da so falsch dran anzunehmen, wenn man konfigurationstechnisch SNMPv1/v2 von SNMPv3 unterscheiden kann, also das eine z. B. verbieten, das andere erlauben, dass diese (Übersichts-/Informations-)Tabelle dann das Ergebnis der Konfiguration auch getrennt wiederspiegelt. Ich meine irgendwoher muss die Tabelle ja ihre Infos beziehen, und die holt sie aus der Konfig. Wenn ich die geöffneten Dienste (nicht Ports) betrachten möchte, dann könnte es schon von Interesse sein, ob eben nur SNMPv3 erlaubt ist, oder auch SNMPv1/v2. Ansonsten muss man zum genauen Abklären der Situation eben doch noch mal in die Details der Konfig schauen. Nun kannst Du/kann man natürlich argumentieren, dass das alles ein Dienst ist, weil ja genau ein Dienst eingehende Nachrichten auf Port 161 annimmt und nicht zwei. Ja, dann ist es so. Solange die Port-Spalte aber keine Indexspalte in der Tabelle ist, und danach sieht es mir aus, würde sich die Aussagekraft der Tabelle sicherlich erhöhen, wenn SNMPv1/v2 und SNMPv3 da getrennt aufgeführt wären, auch wenn es vielleicht ein Dienst ist. Aber das ist nur meine Ansicht, ich habe mich damit nicht beschäftigt. Ich habe die Tabelle irgendwann einfach gesehen, kann mich nicht entsinnen, dass die als Feature irgendwo beworben war und was die Absicht war, damit darzustellen oder zu bewirken.

Viele Grüße,
Jirka

[Jirka]

Wenn man sich die Tabelle unter LCOS 10.00.0135 anschaut, dann sind da auch Differenzen, die ich mir so nicht erklären kann. Wieso ist SIP-ALG plötzlich auf Port 65060? Ist die 6 davor ein Schreibfehler? Oder wurde da der Port geändert? Und wenn ja, warum?
Und bei LANCAPI soll plötzlich Zugriff von WAN-Seite aus möglich sein? Wo kann man das abstellen?!
Oder wird LANCAPI jetzt von WAN-Seite erlaubt, während SIP-Benutzer von WAN-Seite verboten sind?

2017-02-28 16_08_31-Lancom1781VAW - Verbunden als root.png

Viele Grüße,
Jirka

P.S.: Ich stelle gerade fest, dass der Fehler mit LANCAPI über WAN auch in der 9.24 ist. Oder ist das gar kein Fehler? Weil es gab ja mal einige, die LANCAPI über VPN genutzt haben, wo dann hier im Forum darauf hingewiesen wurde, dass es ja eine LANCAPI sei und keine WANCAPI. Aber über WAN?

[MoinMoin]

Moin Jirka!

Die LANCAPI war schon immer vom WAN aus erlaubt. Das hat nur bisher Neimand bemerkt. Um das loszuwerden mußt du die Access-Lite unter /Setup/LANCAPI/Access-List verwenden. Oder den Port 75 ins Nirvana umleiten.

Edit: Sobald TFTP nicht erlaubt ist, funktioniert auch die LANCAPI nicht. Wenn also TFTP auf dem WAN zu ist, kommt auch keine Verbindung zum LANCAPI-Seerver zustande.

Ciao, Georg

[Jirka]

Hi Georg,

Sobald TFTP nicht erlaubt ist, funktioniert auch die LANCAPI nicht.

stimmt, da war doch mal einer hier im Forum, der TFTP lokal aus hatte und bei dem dann kein LANCAPI ging - ich erinnere mich. Aber auch erst jetzt, wo Du es sagst.

Wenn also TFTP auf dem WAN zu ist, kommt auch keine Verbindung zum LANCAPI-Server zustande.

Genau. Und damit ist die Anzeige in der Tabelle also falsch, denn sowohl beim LANCOM in dem Screenshot oben, als auch in dem mit der 9.24 ist TFTP von WAN-Seite nicht erlaubt. Somit müsste das gefixt werden, indem geschaut wird, wie TFTP eingestellt ist und dementsprechend der Zustand richtig angezeigt werden.

Danke für die Aufklärung.

Viele Grüße,
Jirka

EDIT:

Die LANCAPI war schon immer vom WAN aus erlaubt. Das hat nur bisher niemand bemerkt.

Das ist doch jetzt aber nicht Dein Ernst? Oh je, da draußen gibt es ewig viele LANCOMs, die TFTP auf WAN-Seite aktiv haben (insbesondere Altbestand) und nicht wenige davon sind an ISDN angeschlossen und haben die LANCAPI aktiv. Und zack kann ich ohne Passwort darüber teure Telefongespräche verursachen? Wenn das so ist, müssen die Postings hier auf der Stelle gelöscht werden. Das wäre ja eine massive Sicherheitslücke und für die Geräte wird es kein Sicherheitsupdate mehr geben nach der neuen Regel.

[beki]

Wieso ist SIP-ALG plötzlich auf Port 65060?

Der SIP-ALG ist eben etwas... "ganz besonderes". Die vom SIP-ALG verarbeiteten Pakete gehen ja nur am LANCOM vorbei, nicht hinein (das Ziel ist nicht das LANCOM). Also muss da eine Sonderlocker her. Und die sieht so aus, dass die Firewall intern bei aktiviertem SIP-ALG UDP-Pakete an Port 5060, aber nicht solche, die ans LANCOM addressiert sind, zum SIP-ALG umleitet. Dabei hört der SIP-ALG intern auf Port 65060.

Warum tut er das? Weil Port 5061 (das war der SIP-ALG Listener-Port vor der 10.00) üblicherweise (also insbesondere im Default) vom VCM TLS Server belegt wird. Außerdem lässt sich der UDP Port des VCM SIP Servers seit der 10.00 einstellen, also z.B. auf 5061. Das fand ich verwirrend (auch wenn es technisch möglich ist den TLS Server dennoch auf 5061 laufen zu lassen, die Pakete unterscheiden sich ja dann im Protokoll), also hab ich den Port auf den Phantasieport 65060 geändert.

Macht das Sinn?

[cpuprofi]

Hallo Beki,

danke für Deine Erklärung und ja dieses mach Sinn.
Jirka und meine Wenigkeit waren nur am grübeln, wieso Port 65060...

Grüße
Cpuprofi

[MoinMoin]

Moin Jirka!

Das ist doch jetzt aber nicht Dein Ernst?

Doch, das ist in der Tat mein Ernst. Kannst das ja mal ausprobieren.

Allerdings: Das LANCAPI-Protokoll ist derart kompliziert, daß sich bisher kein Freiwilliger gefunden hat, der den Client auf ein anderes Betriebssystem portieren möchte. Es gibt also nur einen einzigen Client, nämlich die LANCAPI von LANCOM. Damit müsste ein Angreifer erst mal eine passende CAPI-Applikation schreiben, um die Lücke auszunutzen. Da greift man doch lieber SIP auf einer Fritz-Box an.

Ciao, Georg

[Koppelfeld]

Jirka und meine Wenigkeit waren nur am grübeln, wieso Port 65060...

Ihr grübelt allgemein immer sehr viel.
Mit dem ALG versucht Ihr, Komplexität mit Komplexität zu bekämpfen.
Eigentlich ist schon die SIP-Protokollsuite eine überladene Zumutung.
Nun legen einige noch drauf und frickeln dran 'rum (1TR114 et al lassen grüßen. Das ist dann Zumutung zum Quadrat.
Dann gehen Hirnis her und machen NAT und STUN damit. Zumutung Kubik.
Und jetzt versucht Ihr, diesen "Stack" mit einem autooperativ arbeitenden ALG zu neutralisieren. Da sind wir bei der vierten Potenz des Wahnsinns.

Wir haben bestimmt 10 Asterisk _ohne_ irgendwelche Vorkehrungen an NAT - Gateways, simpelst mit Portforwarding 5060/UDP.

Wenn Ihr es ordentlich machen wollt:
Nehmt den VCM als 'configurable ALG'.

[cpuprofi]

Hallo Koppelfeld,

es ging, als Teilbereich, hier nicht um Dein "Lieblings Haß-Thema" SIP-ALG, sondern warum sich dessen Port geändert hat, mehr nicht.

Grüße
Cpuprofi

[Jirka]

Guten Morgen Koppelfeld,
schaust Du bitte noch mal genau in den Screenshot oben in die Zeile mit SIP-ALG? Siehst Du was? Ist da ein Haken in der Spalte aktiv?
Schaust Du noch mal meine letzten 100 Postings zum Thema SIP-ALG durch? Was habe ich da geschrieben?
Und was habe ich Dir das letzte Mal geschrieben wieviele LANCOMs haben bei mir das SIP-ALG aktiv? Genau, es war einer. Und da läuft SIP über VPN ohne NAT. Muss ich noch mehr dazu sagen?

Viele Grüße,
Jirka