Sicherheitslücke VPN Server OpenVPN

[TeQuiLLaXY]

Hallo Zusammen,

bin seit ein paar Wochen Besitzer einer DS112 und habe vorgestern versucht mir einen VPN Zugang über OpenVPN einzurichten. Hat soweit auch funktioniert, habe den Zugang aber wieder deaktiviert weil ich mich seltsamerweise auch mit Benutzern anmelden konnte, denen ich den Zugang in den VPN Server Einstellungen eigentlich verwehrt hatte.
Heute habe ich dann einen Testbenutzer angelegt, ein wenig geforscht um herauszufinden wann und wieso ich mich mit gesperrtem Benutzer trotzdem anmelden konnte und bin zum folgendem - in meinen Augen sehr erschreckenden - Ergebnis gekommen.

Benutzer: Test
Passwort: Test
Gruppenzugehörigkeit: users

In den Privilegien habe ich den Benutzer erstmal für OpenVPN freigeschaltet und mehrere Verbindungsversuche mit den folgenden Benutzer-/Passwortkombinationen vorgenommen

1. Test/Test -> Verbindung erfolgreich (OK, Passwort korrekt und Benutzer ist lt. Konfiguration berechtigt)
2. Test/test -> Verbindung abgewiesen (OK, Passwort nicht korrekt)
3. test/test -> Verbindung erfolgreich (nicht OK, Passwort wie bei 2. Versuch nicht korrekt)
4. test/testa -> Verbindung abgewiesen (OK, Passwort nicht korrekt)
5. test/TEST -> Verbindung erfolgreich (nicht OK, Passwort wie bei 2. Versuch nicht korrekt)

Meiner Meinung nach hätte nur der erste Versuch gelingen dürfen, es scheint aber so, als wenn das Kennwort, sobald man den Benutzer nicht mehr mit korrekter Groß-/Kleinschreibung eingibt, auch nicht mehr auf korrekte Groß-/Kleinschreibung getestet werden würde.
Das alleine fand ich schon nicht besonders beruhigend, das eigentliche Problem war damit aber natürlich noch nicht gefunden.
Entzieht man dem Benutzer das Privileg sich per OpenVPN zu verbinden, kann er sich weiterhin verbinden wenn er nicht die korrekte Groß-/Kleinschreibung für den Benutzernamen verwendet.
Ich habe dem Benutzer "Test" also das Privileg entzogen und die gleichen Verbindungsversuche wie zuvor lieferten folgendes Ergebnis:

1. Test/Test -> Verbindung abgewiesen (OK, Passwort korrekt aber Benutzer ist lt. Konfiguration nicht berechtigt)
2. Test/test -> Verbindung abgewiesen (OK, Passwort nicht korrekt)
3. test/test -> Verbindung erfolgreich (nicht OK, Passwort nicht korrekt UND Benutzer lt. Konfiguration nicht berechtigt)
4. test/testa -> Verbindung abgewiesen (OK, Passwort nicht korrekt)
5. test/TEST -> Verbindung erfolgreich (nicht OK, Passwort nicht korrekt UND Benutzer lt. Konfiguration nicht berechtigt)

Die Konfiguration des VPN Servers habe ich nicht verändert, ist alles im Originalzustand.

Hat das schon jemand anderes festgestellt und gibt es möglicherweise sogar eine Möglichkeit diesen Fehler zu beheben? Die Verwendung von Client Zertifikaten wollte ich erstmal aussen vor lassen, da wird's nur schwieriger zu testen ob es dort evtl. auch Probleme gibt

Achso, meine DSM Version ist 4.1-2668 und der VPN Server 4.1-2262.


Schöne Grüße,
Marco

 

[atarifreak]

sicher, dass da nicht irgendein Caching das Problem ist?
dann würde ich das unbedingt dem Support melden!

 

[TeQuiLLaXY]

Hi,

hab die VPN Funktion wie gesagt erstmal wieder deaktiviert aber mich eben nochmal kurz damit beschäftigt.
Es ist sicher kein caching Problem, habe es eben sogar von einer frischen VM aus probiert und der Effekt ist der gleiche. Habe zuerst den Benutzer klein geschrieben und konnte mich sofort anmelden obwohl der Benuter eigentlich nicht berechtigt dazu ist. Danach den Benutzernamen groß geschrieben und wie gewünscht wurde der Zugang verwehrt solange die Berechtigung nicht gesetzt war.

Und wo ich schonmal dabei war habe ich das gleiche nochmal über PPTP probiert, der Effekt ist ähnlich wenn auch nicht exakt der gleiche, bedeutet:
Bei PPTP muss das Kennwort immer exakt geschrieben sein, sobald ein Buchstabe nicht mehr mit korrekter Groß-/Kleinschrift angegeben wurde, wird der Zugang verwehrt, ABER ich kann mich auch über PPTP mit einem Benutzer anmelden welcher die Berechtigung dazu nicht hat indem ich den Benutzernamen nicht mit korrekter Groß-/Kleinschrift angebe, das Passwort muss aber stimmen. Mit dem Benutzer aus dem letzten Beitrag bedeutet das wenn der Benutzer für PPTP gesperrt ist

1. Test/Test -> Verbindung abgewiesen (OK, Passwort korrekt aber Benutzer ist lt. Konfiguration nicht berechtigt)
2. test/test -> Verbindung abgewiesen (OK, Passwort nicht korrekt aber Benutzer ist lt. Konfiguration nicht berechtigt)
3. test/Test -> Verbindung erfolgreich (nicht OK, Passwort korrekt aber Benutzer ist lt. Konfiguration nicht berechtigt)

Ich vertraue der ganzen VPN Funktion von Synology irgendwie nicht und deaktiviere das daher weiterhin, habe es soeben dem Synology Support gemeldet und melde mich wieder sobald ich Neuigkeiten habe.

Grüße,
Marco

 

[fpo4711]

Hallo,
Du schreibst leider nicht wie Du das überhaupt getestet hast aber ich hab da so ein paar Vermutungen. Ich denke mal Du hast sowohl die DS als auch deinen PC in einem gemeinsamen Subnetz und versuchst Dich dann auf die DS zu wählen. Hier nur mal der kurze Hinweis zu VPN (Client-Subnetz ungleich Tunnel-Subnetz ungleich Ziel-Subnetz). Das heißt wahrscheinlich läuft dein Datenverkehr gar nicht über das VPN sondern direkt auf die DS. Ansonsten keine Priviliegien des Benutzers für VPN dann auch kein Zugriff auf VPN.

Und warum hast Du solch ein komisches Zugriffmuster. Wahrscheinlich den Gastzugang aktiviert. Somit wäre dann auf jeden Fall der Zugriff mit dem User "Test" klar - Hier muß das Passwort stimmen. Bei User "test", sofern der nicht vorhanden ist, greift dann der Gastzugang.

Prüfe doch mal ob Du überhaupt per VPN zugreifst und wenn nicht, dann schaffe eine Testumgebung die auch VPN nutzt. Obere Subnetzregel beachten! Denn solltest Du aus dem gleichen Subnetz dich mit dem VPN-Server verbinden so führt das mit Sicherheit eventuell auch zu solch kuriosen Ergebnissen auf Grund von Cache und Routing.

Gruß Frank

 

[TeQuiLLaXY]

Hallo Frank,

die Verbindung habe ich bisher auf drei verschiedene Weisen getestet.

1) Von meinem Laptop im Netzwerk eines Kunden. OpenVPN Verbindungen wurden explizit freigeschaltet damit ich wenn ich vor Ort bin auch an Daten aus unserem Firmennetzwerk komme. Das war der erste Versuch und da ist mir aufgefallen dass ich mich halt mit einem Benutzer anmelden konnte der das eigentlich nicht dürfte sobald ich im Benutzernamen nicht auf Groß-/Kleinschreibung achte

2) Von einem Rechner innerhalb meines Heimnetzwerks über OpenVPN. Die Verbindung macht natürlich wenig aber hier ging es lediglich darum zu testen ob der VPN Server mir den Zugriff erlaubt, das sich der Rechner schon im gleichen Netzwerk wie die DS befindet dürfte meiner Meinung dafür egal sein. OpenVPN fragt nach Benutzer & Passwort um die "unsinnige" VPN Verbindung aufzubauen und gibt eine Rückmeldung ob der Zugriff genehmigt oder verweigert wurde. Es geht hier also erstmal garnicht darum ob ich nach der Verbindung Daten mit der DS oder anderen Geräten im Netzwerk austauschen kann sondern lediglich darum ob die Verbindung aufgebaut werden kann, und dass ich halt nicht möglich wenn Benutzer/PW korrekt geschrieben sind und der Benutzer keine Erlaubnis dafür hat aber sobald man im Benutzernamen an mindestens einer Stelle die Groß-/Kleinschreibung vertauscht sagt kann die OpenVPN Verbindung aufgebaut werden und das dürfte meiner Meinung nach nicht sein

3) Von meinem Android Gerät über PPTP. Das Gerät ist nicht im WLAN, die Verbindung wird über die Datenverbindung des Telefons aufgebaut und hier ist es ebenfalls so dass ich die Verbindung aufbauen kann sobald ich mindestens einmal Groß-/Kleinschreibung tausche obwohl der Benutzer für PPTP gesperrt ist.

Ich verstehe gerade nicht was du an dem Zugriffsmuster seltsam findest, Variante 2 aus dem gleichen Netzwerk macht natürlich keinen Sinn aber war ja auch nur zum testen gedacht, die anderen beiden sind denke ich völlig normale Umgebungen dafür
Der Gastbenutzer ist übrigens nicht aktiviert und den Benutzer "Test" habe ich nur angelegt um diese VPN Problematik mal genauer unter die Lupe zu nehmen, ist etwas angenehmer als immer ein langes Passwort einzugeben und auch übersichtlicher und einfacher zu erkennen wenn man es hier postet.

Grüße, Marco

 

[fpo4711]

Hallo Marco,

ich mußte ja erst mal ausloten wie das zu Stande kommt. Ich prüfe das gleich mal in meiner Umgebung. Melde mich wieder.

Gruß Frank

 

[fpo4711]

Hallo Marco,

da werde ich mich Morgen wohl mal mit den Kollegen beraten müssen. Ich kann Dir das nur bestätigen. Hab folgende Möglichkeiten unter 4.1.2668 und VPN-Server 1.1.2262 auf einer DS1812+ getestet.

Benutzer Test PW Test

1.) Test Test = Zugriff
2.) Test test = Kein Zugriff
3.) test Test = Zugriff
4.) test test = Zugriff
5.) test testa = Kein Zugriff

Erinnere mich vage es gab bei openvpn einen Konfigurationsparameter case-senitiv. Komisch ist nur, und ich glaube das geht Dir auch so, das ich dies beim User ja noch tolerieren könnte aber beim Passwort nicht. Vor allen auch der kuriose Zugriff von 2.)

Ich hab da auf jeden Fall erst mal keine Erklärung für. Sorry, vieleicht hat ein anderer User weitere Erkenntnisse.

Gruß Frank

 

[TeQuiLLaXY]

Hallo Frank,

das ging ja fix.

Ja, sehr kurios alles. Vor allem wenn man jetzt in den Einstellungen des VPN Server den Haken für den Benutzer "Test" bei OpenVPN wegnimmt funktioniert 1.) zwar nicht mehr, was ja auch logisch sein sollte, aber 3.) und 4.) klappt trotzdem noch

Bin mal gespannt ob und wenn ja wann synology mir antwortet

Grüße, Marco

 

[fpo4711]

Hallo Marco,

bestätigt! Wird ja immer bunter. Hab alle User deaktiviert. Sollte also keiner mehr Zugriff haben. Und "test" / "test" wird ganz locker verbunden. Da hat wohl einer den berühmten "test" User im Release vergessen zu entfernen.

Gruß Frank

 

[TeQuiLLaXY]

Guten Morgen Frank,

das ist es leider auch nicht. Funktioniert auch mit anderen Kombinationen z.B. User: "Marco", PW: "magdasnicht"
Wird der Benutzer nicht für OpenVPN freigeschaltet klappt die Verbindung mit "Marco" / "magdasnicht" nicht, aber "marco" / "magdasnicht" funktioniert wieder. Was allerdings sowohl bei dem Benutzer als auch beim Benutzer "Test" funktioniert ist ihn komplett in der Benutzerverwaltung der DS zu deaktivieren, darauf wird also schon noch geachtet.

Grüße, Marco

 

[fpo4711]

Hallo Marco,

war etwas mit dem deaktivieren von VPN-Verbindungen bzw. Einrichten von Alternativen beschäftigt.
Wir scheinen hier die gleichen Tests durchzuführen. Kann Dir das nur wieder bestätigen. Folgende Punkte haben wir weiterhin geprüft.

Das Problem besteht nicht Clientseitig - Verschiedene Clienten benutzt - Gleiches Verhalten.
Deaktivieren vom Cache bringt nichts - auth-nocache

Ich nehme das selten so schnell in den Mund, aber das scheint wirklich ein Bug zu sein. Bin mal auf die Antwort von Synology gespannt.

Gruß Frank

Und zusätzlich weiteres Gerät DS710 mit einbezogen - Gleiches Verhalten

 

[TeQuiLLaXY]

Hallo Frank,

so gravierend das Problem auch ist ist es gut zu hören dass es nichts mit meiner Konfiguration zutun hat, hätte mich auch sehr schockiert wenn es nur bei mir auftreten würde, Netzwerke und administrative Aufgaben gehören zwar nur in Ausnahmefällen zu meinem Job aber ich unterstelle mir einfach mal nicht ganz unversiert zu sein und ein recht großes Grundverständnis dafür zu haben

Ich habe eben auch eine Antwort von Synology enthalten und der Bug wurde bestätigt, angeblich wird schon eine Zeit daran gearbeitet, ich hoffe nur dass die dem Fehler eine hohe Priorität geben und es nicht noch ewig dauert bis dieser behoben wird. Wenn ich drüber nachdenke wie lange ich teilweise Fehler nicht behebe weil wichtigere Aufgaben zu erledigen sind wird mir ganz mulmig

Hier mal die Antwort von Synology

Hi ,

Thank you for the mail.

The developer confirmed that this is a known issue that our developer is currently working on. The issue will be improved in our future official update in the future. I apologize for any inconvenience.

If you have further questions or suggestions, please feel free to contact Synology support again.

Best Regard,
Hugo Chen

Schöne Grüße, Marco

 

[Puppetmaster]

...der Bug wurde bestätigt, angeblich wird schon eine Zeit daran gearbeitet...

[Ironie]
Das ist ja toll, dass Synology sich in einem sicherheitrelevanten Fall wie diesem so kommunikativ zeigt und erstmal eine Info an die User herausgibt, die dieses Sicherheitsleck beschreibt!
[/Ironie]

Oder habe ich die Meldung übersehen?

Ich habe vor einiger Zeit mal ein ähnliches Phänomen bei PPTP beobachtet: da konnte ich mich trotz nicht autorisiertem User mit ebendiesem anmelden. Damals habe ich das aber nicht weiter verfolgt.

 

[XPectIT]

...The issue will be improved in our future official update in the future....

Mir ist da zuviel von "future" die Rede um auf eine sehr schnelle Lösung zu hoffen.

 

[fpo4711]

@Marco

Ehrlich gesagt, dachte ich erst auch da versucht wieder einer einen VPN-Server in Betrieb zu nehmen der gar nicht weiß was Subnetze sind. Hat sich ja gleich mit deinem nächsten Post in Luft aufgelöst. Aber auf jeden Fall arbeitest Du hier sorgfältiger, denn Mal Gegebenheiten wie die Authentifizierung am VPN-Portal auch mal auf diesem Weg in Frage zu stellen, hab ich noch nicht gemacht. Sollte man wohl aber durchaus wie sich zeigt in die Checklisten aufnehmen.

Der VPN-Server von Synology nutzt hier wohl einen RADIUS-Server für die Authentifizierung wo dann wahrscheinlich auch das Problem liegen dürfte. Konnte das aber mangels Zeit noch nicht gegenprüfen. Hier auch immer die Stellen zu suchen wo dann was konfiguriert ist, ist ja auch eine Wissenschaft für sich.

Auf jeden Fall erstmal vielen Dank für die Info, ohne derer ich bis Heute nichts von der Lücke gewußt hätte.

Gruß Frank

 

[TeQuiLLaXY]

Ich denke auch dass ein Update dafür wohl noch etwas auf sich warten lassen wird. Die DSM 4.1-2668 gibt es ja mittlerweile schon seit über 2 Monaten und in der 4.2er beta wird nichts von dem Problem erwähnt und das VPN Server Paket in der Live Demo hat auch noch die gleiche Version wie auf meiner DS

@Frank
Ja ich versuche mich i.d.R. vorher zumindest ein wenig zu informieren ob das Problem nicht schon längst bekannt ist und versuche auch herauszufinden wie man es genau reproduzieren kann, hilft ja keinem weiter wenn ich behaupte dass ich die Verbindung aufbauen konnte aber selber nicht mehr weiß wie ich das gemacht habe, das würde ich mir ja selber nicht glauben und ich habe selber ein paar spezielle Kunden die mir auf die Art versuchen das Leben schwer zu machen indem sie mir Fehler mitteilen wollen aber nichtmal ansatzweise wissen wie sie reproduziert werden können und dann noch nichtmal wissen was als Fehlermeldung ausgegeben wurde weil die einfach ohne zu lesen weggeklickt wurde.

Zu sehr wollte ich die VPN Geschichte auch eigentlich garnicht auf Fehler untersuchen, wollte nur testen ob das deaktivieren der Berechtigung auch funktioniert und dass ich da den Benutzer nicht korrekt geschrieben habe und mich dadurch weiterhin verbinden konnte war purer Zufall, hätte ich den Benutzer damals korrekt eingegeben wäre die Verbindung fehlgeschlagen und mir wäre die Lücke vermutlich auch nicht so schnell aufgefallen.

Grüße, Marco

 

[fpo4711]

@Marco
Die meisten Endeckungen sind eben eher zufällig Es ist definitiv der RADIUS Server der hier sein O.K. für den Zugriff gibt. Will jetzt auch ehrlich nicht mehr weiter einsteigen. Warte einfach auf's Update. Hab jetzt dort wo der SynoVPN in Betrieb war einfach Alternativen gewählt.

RADIUS nutzt man, ich hab mal gelernt was er tut und aus.

Aber wen es interresiert hier der Log bei einem eingetragenen User "Test" mit Passwort "Test". Das Log bezieht sich auf einen Zugriff mit dem kleingeschriebenen User "test" und dem Passwort "test" der folglich keinen Zugriff erhalten sollte.

rad_recv: Access-Request packet from host 127.0.0.1 port 51447, id=252, length=127
        User-Name = "test"
        User-Password = "test"
        NAS-IP-Address = 127.0.0.1
        NAS-Port = 1
        Service-Type = Outbound-User
        Calling-Station-Id = "192.168.192.28"
        NAS-Identifier = "OpenVpn"
        Acct-Session-Id = "E81E043DBD8E95033000503819B9857C"
        NAS-Port-Type = Virtual
# Executing section authorize from file /var/packages/VPNCenter/target//etc/raddb/sites-available/default
+- entering group authorize {...}
++[preprocess] returns ok
++[mschap] returns noop
[suffix] No '@' in User-Name = "test", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
++[unix] returns notfound
[smbpasswd] Added LM-Password: '01FC5A6BE7BC6929AAD3B435B51404EE' to config_items
[smbpasswd] Added NT-Password: '4A1FAB8F6B5441E0493DC7D41304BFB6' to config_items
[smbpasswd] Added SMB-Account-CTRL-TEXT: '[U          ]' to config_items
++[smbpasswd] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing LM-Password from hex encoding
[pap] Normalizing NT-Password from hex encoding
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /var/packages/VPNCenter/target//etc/raddb/sites-available/default
+- entering group PAP {...}
[pap] login attempt with password "test"
[pap] Using LM encryption.
[pap]   expand: %{User-Password} -> test
[pap] LM-Hash of test = 01fc5a6be7bc6929aad3b435b51404ee
[pap]   expand: %{mschap:LM-Hash %{User-Password}} -> 01fc5a6be7bc6929aad3b435b51404ee
[pap] User authenticated successfully

Ich denke mal hier wird mit Passwörtern die in Großbuchstaben gewandelt sind gearbeitet. Auch die Zeile mit "not found" könnte hier der Übeltäter sein.
Na dann, weiterhin viel Glück. Man liest sich.

Gruß Frank

 

[TeQuiLLaXY]

Hi,

ich habe gerade auch nochmal ein bisschen weiter geforscht aber leider noch nicht wirklich viel erreicht, das (erste) Problem liegt meiner nach schon an folgender Stelle

# Executing section authorize from file /var/packages/VPNCenter/target//etc/raddb/sites-available/default
+- entering group authorize {...}

Hier scheint der Benutzer schonmal als im Grunde privilegiert angesehen zu werden, obwohl ich ihm eigentlich die Berechtigung nicht erteilt habe. Wird der Benutzername korrekt geschrieben scheint es erstmal zu funktionieren und der Versuch wird abgewiesen

# Executing group from file /var/packages/VPNCenter/target//etc/raddb/sites-available/default
+- entering group REJECT {...}

unter /var/packages/VPNCenter/etc wird in der Datei privilege jeder Benutzer vermerkt, entweder mit =0 für nicht privilegiert oder =4 für privilegiert (nur OpenVPN), trägt man hier zusätzlich zum schon vorhandenen Eintrag "Test=0" auch noch "test=0", so kann man sich auch nicht mehr verbinden wenn man den Benutzernamen komplett klein schreibt, im Log wird wieder wie zuvor auch

# Executing group from file /var/packages/VPNCenter/target//etc/raddb/sites-available/default
+- entering group REJECT {...}

ausgegeben, würde man aber als Benutzer z.B. tEst für die Anmeldung nehmen, würde es wieder klappen, d.h. man müsste alle möglichen Kombinationen nachtragen was manuell doch recht mühsam wäre.
Versucht man einen Benutzernamen der garnicht in der Diskstation angelegt ist, erscheint ebenfalls die korrekte Meldung, das scheint aber nicht nur daran zu liegen dass dieser Benutzer garnicht in der privilege Datei vermerkt ist, den ein herauslöschen aller nicht benötigten Benutzer bringt leider auch keine Verbesserung.
Falls ich morgen noch Lust habe versuche ich mich ein wenig durch die Konfiguration des Radius Server zu kämpfen, dürfte spannend werden da ich mich bisher noch nie damit beschäftigt habe. Sehe es zwar eigentlich nicht ein dass man sich selber darum kümmern muss die Konfiguration anzupassen die die Leute bei Synology vermutlich verbockt haben, aber ich würde das gerne am Laufen haben, wer weiß wie lange Synology dafür braucht, und vielleicht packt mich ja der Ehrgeiz

Falls sich sonst jemand damit beschäftigen sollte oder sich zufällig mit der Konfiguration des Radius Server auskennen sollte bin ich natürlich für jeden Hinweis dankbar

Grüße, Marco

 

[moffer]

Sehr interessant. Habe es auch gerade getestet. Bei mir verhällt es sich genauso. Macht es Sinn, hier einen Support-Aufruf an Synology zu starten, an dem sich viele beteiligen? Ich meine, es ist ja wirklich eine große Sicherheitslücke ... So kann man den VPN Server eigentlich nur noch deinstallieren.

 

[fpo4711]

Hallo moffer,

ja Du hast recht es ist eine Sicherheitslücke. Diese als besonders groß zu bezeichnen sehe ich eine wenig anders. (Die JAVA-Lücke war groß) Es kommt eben immer darauf an, in welchem Umfeld Du den VPN-Server einsetzt. Solltest Du deinem Angreifer aber das Zertifikat vorenthalten wird's denke ich mal, doch schwierig sich Zugriff zu ergaunern.

Gruß Frank