Angreifer über SSL Verbindung

[G4rfi3ld]

Hallo

ich habe derzeit folgende Frage zu klären finde aber im Netz wenig brauchbares dazu.

Netzaufbau einer kleinen Firma wie folgt:

Router Cisco RV130 mit aktiver Firewall und statischer IP (ohne Fernzugriff)
In der Firewall gibt es 3 Portweiterleitungen zum Server allesamt nicht auf Standard Ports und gesichert.

Dahinter als Server Synology 1515+ im LAN mit 3 weiteren PC's
Der Zugriff von mehreren Homeoffice Usern soll über verschlüsselte WebDAV erfolgen
der Zugriff der mobilen User über die Synology (private) Cloudstation ebenfalls verschlüsselte Verbindung

Auf der Administrationsseite der NAS können nur 2 Adminaccounts via https Verbindung anmelden mit 2 Stufen Authentifierung (Google Authenticator), alle anderen Benutzer haben nur Zugriff auf die freigegebenen Ordner.

Folgende Fragen gäbe es auf die ich keine Antwort finde:

Szenario 1 - Besteht die Chance, dass, sollte ein Angreifer Zugriff direkt auf die NAS bekommen, und es auch noch gelingen die NAS zu übernehmen, und gleichzeitig eine erlaubte WebDAVs Verbindung bestehen, kann der Angreifer diese Verbindung benutzen um von der NAS auf den fremden Rechner zu gelangen?

Szenario 2 – Der Angreifer hat zusätzlich auch die Kontrolle über einen Windows Rechner im lokalen Netzwerk, und Userzugang und/oder Adminzugang auf der NAS, kann damit die neu aufbauende oder bereits bestehende WebDAV Verbindung benutzt werden um auf den fremden Rechner zu gelangen ?

Szenario 3 – Gäbe es überhaupt eine Variante mit der ein Angreifer durch eine gesicherte WebDAV Verbindung Zugriff auf das Fremdnetz bekommt, oder würde nur die IP Adresse des gegenübers leichter herausfindensein, da ja mit WebDAV eine IP-IP Verbindung besteht die aus den Logs auslesebar sein müsste, aber der Angreifer müsste trotzdem den fremden Rechner/Netzwerk getrennt neu attackieren ?

Sollten noch Angaben fehlen kann ich diese so ich diese weiss gerne noch nachschieben.

Danke im voraus

 

[testm]

Wie sehen den die Firewall-Regel aus und was meinst du mit "gesichert"?
Worauf ich hinaus will:
->Sowohl CloudStation als auch WebDav sind TCP basiert sollte also nur dieses Protokoll freigegeben werden. Hier muss auch die Richtung mitbeachtet werden.
> PS: Die hier bestehenden Verbindungen bestehen zwischen den beiden Sockets, womit jeweils nur eine Anwendungen angesprochen werden kann (WebDav/Cloudstation).
Das schwächste Glied wären hier die jeweiligen Anwendungen
->befinden sich die Clients (also lokale Rechner) in einem anderem Netz und gelten hier andere Regel (offensichtlich sind hier die oben genannten Freigaben nicht erforderlich)?

Sowohl WebDav als auch CloudStation sind mit Sicherheit nicht unverwundbar nur weil diese TSL oder dergleichen benutzen.
Skriptkiddy anfällig dürften beide Services nicht mehr sein und für jemanden mit entsprechenden Know-How ist ein kleines Unternehmen wohl nicht attraktiv genug.

 

[p4n0]

Der richtige Weg waere ein VPN, darueber kannst Du bedenkenloser auf die Syno zugreifen.
Ich würde mich nicht trauen das Ding vom WAN aus direkt zugänglich zu machen.

Grueße

 

[TCM]

TLS ist hier nicht "sicherer". Es erhöht die Angriffsfläche enorm. Der Angreifer kann ja schließlich auch einfach TLS verwenden und damit nicht nur am HTTP/WebDAV rumprobieren, sondern er hat gleichzeitig noch eine TLS-Implementierung vor sich, die Lücken aufweisen kann.

Das heißt nicht, dass man auf TLS verzichten soll. Wenn das aber ein festdefinierter Benutzerkreis ist, würde ich das alles hinter ein VPN stecken, wie bereits gesagt wurde.

 

[testm]

@TCM: Es stimmt zwar, dass du die Bugs von TSL-Implementierung zusätzlich als Angriffsfläche bietest, allerdings ist es nur eine Vorsichtsmaßnahme, womit man hier TSL und die Aplikationen bezwingen müsste, denn selbst wenn man TSL irgendwie überwingen könnte, so hat man nach wie vor lediglich eine TCP-Verbindung, die bekanntlich lediglich zwei Sockets verbindet.
In dem Fall kann man mit simpelster Mathematik nachweisen, dass die Gefahr eines erfolgreichen Angriffs unter Verwendung von TSL sinkt und nicht steigt.
VPN würde natürlich eine gute Alternative darstellen.

 

[TCM]

@TCM: Es stimmt zwar, dass du die Bugs von TSL-Implementierung zusätzlich als Angriffsfläche bietest, allerdings ist es nur eine Vorsichtsmaßnahme, womit man hier TSL und die Aplikationen bezwingen müsste, denn selbst wenn man TSL irgendwie überwingen könnte, so hat man nach wie vor lediglich eine TCP-Verbindung, die bekanntlich lediglich zwei Sockets verbindet.
In dem Fall kann man mit simpelster Mathematik nachweisen, dass die Gefahr eines erfolgreichen Angriffs unter Verwendung von TSL sinkt und nicht steigt.
VPN würde natürlich eine gute Alternative darstellen.

Wovon redest du? Um an den HTTP-Stack und die Webanwendung zu kommen, muss man kein TLS "bezwingen". Man baut einfach eine Verbindung auf, wie das von TLS vorgesehen ist. Das war doch gerade meine Aussage. TLS hindert einen Angreifer an gar nichts, bietet selbst aber zusätzliche Angriffsfläche.

TLS hindert einen Angreifer, der in der Leitung sitzt, Pakete _anderer_ Verbindungen im Klartext abzufangen oder zu verändern, was hier aber nicht das Szenario ist.

Edit: Ich sage auf keinen Fall, dass man TLS weglassen soll. Selbst mit einem VPN sollte man es einfach trotzdem benutzen. Zur Minimierung der Angriffsfläche sollte jedoch ein VPN zum Einsatz kommen.

 

[testm]

Man muss schon TLS "bezwingen", denn an Benutzername/Password für die Anwendungen kommst du bei einer verschlüßelten Verbindung nicht so einfach dran.
Bugs in der TSL-Implementierung würden also im Vergleich zu der Nutzung ohne TSL im Zweifel keine Verschlechterung der Sicherheitsituation führen, was du selbst, laut deinem letzten Post, nicht anzweifelst.
Foglich führt es nicht zu mehr Angriffsfläche und erschwert MITM's.
VPN's sind im Grunde auch keine Hexenwerk und nutzen je nach Typ auch die selbe TSL-Implementierung.

 

[TCM]

Du wirfst einfach alles durcheinander.

Man muss schon TLS "bezwingen", denn an Benutzername/Password für die Anwendungen kommst du bei einer verschlüßelten Verbindung nicht so einfach dran.

Davon war überhaupt keine Rede. Ich habe ausdrücklich gesagt, dass TLS dagegen schützt, dass man Inhalte _fremder_ Verbindungen sieht. Das ist für das Szenario "Lücke in der TLS-Implementation" aber völlig belanglos, weil der Angreifer nicht fremde Verbindungen abhört, sondern eigene Verbindungen aufbaut, um den TLS-Stack anzugreifen.

Es geht darum, dass der Code, der TLS abhandelt, über das Internet erreichbar ist. Jeder kann eine TLS-Verbindung aufbauen. TLS bietet keine Zugriffskontrolle. Damit hat man auf dem Server Code laufen, der TLS abhandelt, die Webanwendung und den HTTP-Server, für jeden erreichbar. Eine Lücke in einer dieser Komponenten kann dazu führen, dass ein Angreifer lokale Rechte bekommt oder Serverdaten ausliest (s. Heartbleed). Warum jetzt eine zusätzliche Komponente (TLS) sicherer sein soll, musst du mal erklären.

Bugs in der TSL-Implementierung würden also im Vergleich zu der Nutzung ohne TSL im Zweifel keine Verschlechterung der Sicherheitsituation führen

Nur wenn man falsche Annahmen macht.

VPN's sind im Grunde auch keine Hexenwerk und nutzen je nach Typ auch die selbe TSL-Implementierung.

VPNs bieten aber Zugriffskontrolle und stellen somit eine zusätzlich Hürde dar, bevor man an den Webserver gelangt.

 

[G4rfi3ld]

Also

da ja einige Fragen aufgetaucht sind, werde ich versuchen diese einmal ohne Verweis auf den Fragesteller zu beantworten.

Regeln der Firewall sind einfach, bis auf den Port für https, WebDAV (s) und Cloudstation (s) ist kein Port der Firewall offen.
Einen Webserver oder ähnliches gibt es gar nicht, Web ist bei einem eigenen Hoster.

Aus meiner Sicht ist die wahrscheinlichkeit das die beiden Synologyspezifischen Anwendungen bereits erfolgreich systematisch gehackt werden können gleich null, sonst wären die Foren und diversen Computerseiten voll damit, das plötzlich alle Server die diese Dienste nutzen erfolgreich angegriffen werden. (oder täusche ich mich da?)

Die nächste Frage wäre was ein Angreifer mit einem "Zugang" über einen Port auf dem Server anstellen kann, denn dafür müsste es ja ebenfalls bekannte Lücken im Betriebsystem der Synology geben oder?

Die Frage ist aber wenn, angenommen, ein Benutzer vollen Serverzugriff hätte, könnte er dann die WebDAV(s) Verbindung zu einem Client nutzen um diesen anzugreifen?

 

[TCM]

bis auf den Port für https, WebDAV (s) und Cloudstation (s) ist kein Port der Firewall offen.
Einen Webserver oder ähnliches gibt es gar nicht

Wenn HTTPS offen ist und irgendwas auf dem Port lauscht und HTTP verarbeitet, dann nennen wir das mal vereinfacht Webserver.

Aus meiner Sicht ist die wahrscheinlichkeit das die beiden Synologyspezifischen Anwendungen bereits erfolgreich systematisch gehackt werden können gleich null, sonst wären die Foren und diversen Computerseiten voll damit, das plötzlich alle Server die diese Dienste nutzen erfolgreich angegriffen werden. (oder täusche ich mich da?)

Ist schon richtig. Aber man will ja nicht reagieren, sondern am besten vermeiden.

Die nächste Frage wäre was ein Angreifer mit einem "Zugang" über einen Port auf dem Server anstellen kann, denn dafür müsste es ja ebenfalls bekannte Lücken im Betriebsystem der Synology geben oder?

Genau. Aber nicht alle Lücken werden zuerst von den Guten entdeckt. Falls es um eine Lücke geht, die der breiten Öffentlichkeit noch unbekannt ist und schon ausgenutzt wird, müsste man erstmal anhand eines Datenlecks bemerken, dass da irgendwas nicht stimmt. Deswegen macht man ja diese Sicherheit in Schichten, damit man Angriffsflächen minimiert.

Die Frage ist aber wenn, angenommen, ein Benutzer vollen Serverzugriff hätte, könnte er dann die WebDAV(s) Verbindung zu einem Client nutzen um diesen anzugreifen?

Wenn die Clientsoftware dann noch Lücken hat, ist auch das prinzipiell möglich. Grundlegend ist immer dann Vorsicht geboten, wenn Software fremden Input verarbeitet. Das gilt immer und überall. Der Trick ist, zu erkennen, ob und wann Input von "vertrauenswürdig" zu "fremd" umschwenken kann.

Wenn das alles zu theoretisch klingt, dann mach einfach, wie du denkst. Die Wahrscheinlichkeit, damit Schiffbruch zu erleiden, ist vermutlich auch ziemlich gering. Ich würde sowas jedenfalls nicht ohne VPN machen.

 

[p4n0]

Ich versteh den TE nicht so richtig wieso man sich so hartnaeckig gegen eine bessere und sicherere Loesung straeuben kann.

Wenn die Syno auf 80/443 lauscht, dann kann man dort jeden schrott hinschicken was ueber TCP zulaessig ist.
Das muss ueberhaupt gar nichts mit dem zu tun haben was die Syno da erwartet. Und genau da faengt das Problem an...

Ich will jetzt nicht sagen dass die Software grundsaetzlich schlecht oder unsicher ist aber hier bietet sich ein Angriffspunkt
der durch die Verwendung von VPN ueberhaupt erst gar nicht entstehen kann.

Also entweder richtig machen oder mit dem Risiko leben.

Grueße

 

[G4rfi3ld]

Auf 80 wartet bei mir gar nichts hätte ich eigentlich schon gesagt .. Und beide softwarepakete die ich benutzen will, haben nix mit vpn am hut .. also kann ich diese beiden ports nicht einsparen, ausser ich verzichte auf die beiden Tools das ich eigentlich nicht will/kann.

@p4n0 ich wehre mich nicht gegen vpn aber mit vpn könnte ich vielleicht den https port zumachen die beiden anderen würden bleiben, für anstatt der webdavs verbindung könnte ich ein vpn einrichten, bin ich auch schon dabei, ist aber nicht so einfach weil das ja auf jeden Fall ipsec werden muss, und da brauchen die clients wieder ein Softwaretool etc.

Aber meine eigentliche frage ob es einem angreifer möglich ist eine vorhandene webdavs verbindung zu nutzen um direkt auf den verbundenen rechner zu kommen die ist leider nach wie vor offen oder habe ich da was überlesen, das theoretisch fast alles möglich sein kann ist schon klar, die Frage ist ob es auch nur im entferntsesten Realistisch ist, oder ob der Aufwand dafür sowohl zeitlich als auch technisch das Unterfangen eigentlich verunmöglicht?

 

[fdsonne]

Aber meine eigentliche frage ob es einem angreifer möglich ist eine vorhandene webdavs verbindung zu nutzen um direkt auf den verbundenen rechner zu kommen die ist leider nach wie vor offen oder habe ich da was überlesen, das theoretisch fast alles möglich sein kann ist schon klar, die Frage ist ob es auch nur im entferntsesten Realistisch ist, oder ob der Aufwand dafür sowohl zeitlich als auch technisch das Unterfangen eigentlich verunmöglicht?

Ließ dir doch nochmal die Beiträge von TCM durch... Speziell den letzten im Thread.
Da wird das doch klar und ersichtlich erläutert...

Im Endeffekt ist ein Angriffsvektor IMMER vorhanden. Egal wie rum man es dreht oder wendet. Die Warscheinlichkeit, dass dieser Vektor ausgenutzt wird, ist eine andere Sache. Nur kann dir das bis Dato Niemand für Sachen beantworten, wo nix dergleichen bekannt ist. Bedenke, nicht bekannt heist nicht automatisch unmöglich. Sondern nicht bekannt heist eben einfach nur nicht bekannt... Vielleicht kapern da Dritte deine Hardware schon nach Lust und lange Weile und es fällt einfach überhaupt nicht auf? Möglich ist das, wenn auch ziemlich unwarscheinlich.

PS: was die VPN Geschichte angeht, wenn du VPN nutzt, dann brauchst du effektiv gar keine Ports aufmachen... Denn der Traffic verlässt den internen "secure" Bereich überhaupt nicht. Kein Forwarding für den Spaß notwendig, kein Angriffsvektor für WebDAV, HTTPS und Co. mehr vorhanden. -> DAS ist der Vorteil der Thematik.
Die Kehrseite der Medaille ist, der VPN Service bietet einen Angriffsvektor, der bei der anderen Thematik nicht vorhanden ist/war... Hier gilt es abzuwegen.
Tendentiell geht der Grundtenor aber eher in die Richtung, so wenig wie möglich Angriffsfläche zu bieten. Spezielle Systeme für VPN Einwahlen, wenn wir es mal so nennen, haben rein vom Aufbau und der Konzeptionierung her wenig Angriffsfläche... Und damit minimiert man schlicht das Risiko.