Army
Anmeldungsdatum: 30. Mai 2006
Beiträge: 1574
|
Lunar hat geschrieben: Ich würde einfach mal behaupten, dass die meisten Telekom-Kunden die mitgelieferten AP/Router-Mühlen nie wechseln, solange sie funktionieren. Eine Attacke, welche nur auf die Standard-Telekom-Hardware zugeschnitten ist, dürfte also schon eine gute Erfolgsquote erzielen. Es ist also gar nicht unbedingt notwendig, die SOAP-URL herauszufinden.
Also ich hab hier nen Telekom-Router und ich wüsste nicht, dass ich bei der Einrichtung da was geändert hätte, aber UPnP ist deaktiviert ☺
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
Army hat geschrieben: Lunar hat geschrieben: Ich würde einfach mal behaupten, dass die meisten Telekom-Kunden die mitgelieferten AP/Router-Mühlen nie wechseln, solange sie funktionieren. Eine Attacke, welche nur auf die Standard-Telekom-Hardware zugeschnitten ist, dürfte also schon eine gute Erfolgsquote erzielen. Es ist also gar nicht unbedingt notwendig, die SOAP-URL herauszufinden.
Also ich hab hier nen Telekom-Router und ich wüsste nicht, dass ich bei der Einrichtung da was geändert hätte, aber UPnP ist deaktiviert ☺
Das war hier auch so, dass muss aber nicht so bleiben! Die Telekom-Software für Windows - die leider immer noch viele verwenden - verwendet UPnP zur Routerkontrolle (man kann damit die Internetverbindung über ein Trayicon trennen oder herstellen). Außerdem steht in diverse Filesharing-Tutorials, UPnP sollte aktiviert sein, damit die Filesharing-Software die Ports automatisch freigeben kann. Gründe, UPnP zu aktivieren, gibt es für den unbedarften User genug 😉
|
Szegey
Anmeldungsdatum: 2. Oktober 2006
Beiträge: 116
|
Ich finde diese Lücke schon recht beunruhigend. Was mir nicht ganz klar ist: Eine XSS-Attacke ziehlt doch auf die Web-Konfigurationsoberfläche des Routers (ich beziehe mich dabei auf das Beispiel von Adna rim ). Wie das genau mit UPnP zusammenhängt verstehe ich nicht. Bzw. wenn ich den Zugriff auf die Web-Konfiguration über WLAN verhindere, sind zumindest Clients im kabellosen Netz kein Risiko mehr, oder? Unabhängig davon funktioniert UPnP sowohl kabelgebunden als auch kabellos. Um abschätzen zu können, inwieweit der eigene Router gefährdet ist, müsste man wissen, welche Teile der UPnP-Api implementiert sind. Gerade setDNS macht mir da schon Sorgen. Die Firmware meines Routers (Linksys WRT54GL) ist opensource und ich hab mir den Quellcode mal runtergeladen. Nicht, dass ich besonders viel damit anfangen könnte, dennoch habe ich mal ganz blauäugig "SetDNSServer" in meine Desktopsuche eingegeben und schon eine interessante Datei der Firmware gefunden: "x_lanhostconfigmanagement.c". Darin fand ich zu meiner Beruhigung:
...
/*
NotImplemented - prints an error message on the console and returns 0 parameters to the caller.
*/
...
#define SetDNSServer NotImplemented
#define DeleteDNSServer NotImplemented So weit so gut. Weiteres:
/*
DefaultAction - Returns all 'out' parameters with values taken from the corresponding 'relatedStateVariable'. This function actually covers the behavior of
a surprisingly large number of UPnP actions.
*/
#define GetDHCPServerConfigurable DefaultAction
#define GetDHCPRelay DefaultAction
#define GetSubnetMask DefaultAction
#define GetAddressRange DefaultAction Wie es scheint sind die meisten Set-Anweisungen nicht implementiert. Allerdings findet sich weiter unten:
static Action _SetDNSServer = {
"SetDNSServer", SetDNSServer,
(Param []) {
{"NewDNSServers", VAR_DNSServers, VAR_IN},
{ 0 }
}
}; Jetzt bin ich irgendwie schon wieder so schlau als wie zuvor, da mir für die Interpretation des Quelltextes das tiefere Wissen fehlt... Bei mir ist UPnP nicht eingeschaltet, insofern weiß ich, dass mein Netzwerk - zumindest in diesem Fall - relativ sicher ist. Opensource ist schon was feines, auch wenn mir jetzt nach der Durchsicht (wenn man meinen laienhaften Ansatz so bezeichnen kann) nicht völlig klar ist, welches Risiko ich mit eingeschaltetem UPnP eingehen würde. Vielleicht hat ja jemand von euch den gleichen Router und ein wenig mehr Ahnung, denn es würde mich schon interessieren, inwieweit das Gerät gefährdet ist.
|
otzenpunk
(Themenstarter)
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
Szegey hat geschrieben: Eine XSS-Attacke ziehlt doch auf die Web-Konfigurationsoberfläche des Routers (ich beziehe mich dabei auf das Beispiel von Adna rim ). Wie das genau mit UPnP zusammenhängt verstehe ich nicht.
Die UPnP-Befehle werden über das SOAP-Protokoll abgesetzt, dass auf HTTP aufbaut. D.h. alles, was HTTP-Anfragen senden kann, kann prinzipiell UPnP nutzen. (Wenn es auch etwas kompliziert wird, weil man das Protokoll zum Auffinden von UPnP-Diensten damit nicht benutzen kann. Man muss also mehr oder weniger raten, auf welcher IP man welche Befehle absetzen kann.) JavaScript beinhaltet eine Routine, die XmlHttpRequest heißt, und mit der man solche Befehle absetzen kann. Allerdings hat diese Routine einen Sicherheitsmechanismus, der "Same Origin Policy" heißt und beinhaltet, dass der Browser solche XmlHttpRequests nur an denselben Server schickt, von dem er die Webseite mit dem Code erhalten hat. Ein JavaScript von www.evil.com kann also keine XmlHttpRequests an deinen Router veranlassen. Wenn die Routeroberfläche aber eine XSS-Lücke beinhaltet, erscheint das JavaScript, als würde es vom Router selbst kommen, und der XmlHttpRequest wird ausgeführt. Flash hat keine Same Origin Policy. Die entsprechenden Routinen können zu allen Servern Kontakt aufnehmen. Deswegen braucht man keine XSS-Lücke, um diesen Trick mit Flash durchzuziehen.
|
Szegey
Anmeldungsdatum: 2. Oktober 2006
Beiträge: 116
|
Danke, otzenpunk, jetzt hab ich es verstanden. 💡
|
Army
Anmeldungsdatum: 30. Mai 2006
Beiträge: 1574
|
Lunar hat geschrieben: Außerdem steht in diverse Filesharing-Tutorials, UPnP sollte aktiviert sein, damit die Filesharing-Software die Ports automatisch freigeben kann.
Also ich hab mich mit solchen Netzwerk-Geschichten noch nie so sehr befasst und kenn mich damit auch nicht wirklich aus, aber in meim ktorrent wird mir immer angezeigt, dass keine eingehenden Verbindungen aufgebaut werden können. Das liegt wohl am deaktivierten UPnP. Aber ich kann trotzdem wunderbar runterladen und auch hochladen. Ich frage mich, wo da letztendlich der Unterschied liegt zu einem aktivierten UPnP. Glaub ich aktivier es mal kurz (wird hoffentlich nix bei passieren 😉 ), das interessiert mich jetzt schon ein bisschen.
|
Blattlaus
Anmeldungsdatum: 29. März 2006
Beiträge: 1399
|
otzenpunk hat geschrieben: Flash hat keine Same Origin Policy.
Flash hat eine same origin policy!
|
Teetrinker
Anmeldungsdatum: 21. März 2006
Beiträge: 1202
|
Blattlaus hat geschrieben: Der Punkt heißt Portforwarding oder NAT.
Portforwarding ist schon richtig, NAT ist etwas anderes. NAT (Network Adress Translation) übersetzt grob gesagt, die vom User festgelegten IP-Adressen des lokalen Netzwerkes auf die vom Provider dynamisch vergebene. Ohne NAT würde gar nichts funktionieren (es sei denn, man hat eine feste IP-Adresse, aber wer hat die schon). Also, UPnP kann und sollte man deaktivieren, NAT ist ja gerade der Sicherheitsaspekt bei der Verwendung eines Routers. Weil die Rechner im lokalen Netzwerk eben von außen gar nicht zugänglich sind, sondern nur der Router.
|
otzenpunk
(Themenstarter)
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
Teetrinker hat geschrieben: Portforwarding ist schon richtig, NAT ist etwas anderes.
Portforwarding ist auch eine Art von NAT, nämlich Destination NAT (oder DNAT). Teetrinker hat geschrieben: NAT (Network Adress Translation) übersetzt grob gesagt, die vom User festgelegten IP-Adressen des lokalen Netzwerkes auf die vom Provider dynamisch vergebene.
Was du meinst ist Masquerading bzw. Source NAT. In beiden Fällen ersetzt der Router eine Adresse im Paket durch eine andere und merkt sich gleichzeitig die Verbindung, um die Antworten korrekt wieder zurück zu übersetzen. Teetrinker hat geschrieben: NAT ist ja gerade der Sicherheitsaspekt bei der Verwendung eines Routers. Weil die Rechner im lokalen Netzwerk eben von außen gar nicht zugänglich sind, sondern nur der Router.
Das ist nicht ganz richtig. Der Sicherheitsaspekt (eigentlich eher ein nützliches Abfallprodukt des NAT) ist, dass man im lokalen Netz nicht-routbare IP-Adressen verwendet. NAT ermöglicht es bloß, trotz dieser nicht-routbaren Adressen mit dem Rest des Internets zu kommunizieren. Masquerading klappt auch, wenn die Adressen alle fest und öffentlich sind. Z.B. könnte man in einer Firma zwar öffentliche IP-Adressen haben - weil einige Server nach außen hin erreichbar sein sollen - aber alle Verbindungen nach außen maskieren, damit die einzelnen IPs nicht in irgendwelchen Access-Logs auftauchen. In diesem Fall sind die Rechner sehr wohl von außen erreichbar, solange der Zugriff nicht durch eine Firewall eingeschränkt wird. Und wenn man sich die Diskussion um den "Bundestrojaner" ansieht, bin ich mir auch nicht mehr ganz sicher, ob private RFC1918-Adressen unter keinen Umständen geroutet werden. Wer den Router vor deinem NAT-Gerät kontrolliert (die Gegenstelle beim Provider), kann theoretisch eine Route bspw. nach 192.168.0.0/16 einrichten, die auf deinen Anschluss zeigt, und dein Router wird die Pakete glücklich ins interne Netz weiterreichen. Sobald der Bundestrojaner auf einer gesetzlichen Grundlage steht, rechne ich fest damit, dass die Ermittlungsbehörden die Provider genau dazu zwingen werden, wenn das ihnen Zugriff auf das interne Netz eines Verdächtigen beschert.
|
Teetrinker
Anmeldungsdatum: 21. März 2006
Beiträge: 1202
|
otzenpunk hat geschrieben:
Portforwarding ist auch eine Art von NAT, nämlich Destination NAT (oder DNAT).
OK, ist vielleicht eine Definitionssache. Bei uns wurde allerdings immer zwischen Portforwarding und NAT unterschieden. otzenpunk hat geschrieben:
Was du meinst ist Masquerading bzw. Source NAT. In beiden Fällen ersetzt der Router eine Adresse im Paket durch eine andere und merkt sich gleichzeitig die Verbindung, um die Antworten korrekt wieder zurück zu übersetzen.
Genau das meinte ich. Wobei ich NAT eher von Windows her kenne und Masquerading aus der Linux/Unix-Umgebung. Also nur zwei Begriffe für eine Sache. otzenpunk hat geschrieben: Der Sicherheitsaspekt (eigentlich eher ein nützliches Abfallprodukt des NAT) ist, dass man im lokalen Netz nicht-routbare IP-Adressen verwendet.
Naja, davon war ich ausgegangen. An die Sache mit den routbaren Adressen hinter einem NAT-Router hatte ich allerdings nicht gedacht. Wie gut, dass man nie auslernt. 😀 Was den Bundestrojaner angeht, so glaube ich, dass man sich sowieso nicht dagegen schützen kann. Man darf ja nicht vergessen, dass es dabei nicht um irgendwelche Hacker geht, die illegalerweise irgend jemanden abhören. Hier geht es um Gesetze. Da wird der Provider dazu verdonnert eine entsprechende Schnittstelle bereit zu stellen und gut ist. Und wenn dann zu viele Leute anfangen, ihren Datenverkehr oder ihr gesamtes System zu verschlüsseln, dann wird dies eben per Gesetz verboten. Klingt vielleicht etwas weit hergeholt aber mittlerweile traue ich unseren Politikern alles zu. Vielleicht werden ja auch irgendwann Internetzugänge für Privatleute verboten. Denn: "Das Netz ist böse! Da tummeln sich nur Verbrecher, Kinderschänder und Terroristen. Und ohne Internet keine Verbrechen." (Ist zwar nicht von Schäuble, könnte es aber.) OT, ich weiß. Ich höre ja auch schon auf 😀
|
otzenpunk
(Themenstarter)
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
Teetrinker hat geschrieben: OK, ist vielleicht eine Definitionssache. Bei uns wurde allerdings immer zwischen Portforwarding und NAT unterschieden.
Umgangssprachlich ist das auch so. Ich wollte nur ein bisschen klugscheißen. 😉 Das iptables-Target für Portforwarding heißt aus diesem Grund übrigens DNAT. Es gibt auch SNAT und dessen Unterschied zum speziellen Fall des MASQUERADING wird in der iptables-Manpage ganz gut erklärt.
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
otzenpunk hat geschrieben: Und wenn man sich die Diskussion um den "Bundestrojaner" ansieht, bin ich mir auch nicht mehr ganz sicher, ob private RFC1918-Adressen unter keinen Umständen geroutet werden. Wer den Router vor deinem NAT-Gerät kontrolliert (die Gegenstelle beim Provider), kann theoretisch eine Route bspw. nach 192.168.0.0/16 einrichten, die auf deinen Anschluss zeigt, und dein Router wird die Pakete glücklich ins interne Netz weiterreichen. Sobald der Bundestrojaner auf einer gesetzlichen Grundlage steht, rechne ich fest damit, dass die Ermittlungsbehörden die Provider genau dazu zwingen werden, wenn das ihnen Zugriff auf das interne Netz eines Verdächtigen beschert.
Ein guter Router sollte aber fähig sein, WAN-Pakete zu blocken, welche Adresse aus dem internen Netz tragen.
|
mpathy
Anmeldungsdatum: 23. Dezember 2004
Beiträge: 284
Wohnort: Ingersheim
|
Lunar schrieb: Blattlaus hat geschrieben: - Da somit somit weder Flash noch JS den UPnP Service entdecken können bleibt da nur die Option das sie die SOAP Url erraten
Ich würde einfach mal behaupten, dass die meisten Telekom-Kunden die mitgelieferten AP/Router-Mühlen nie wechseln, solange sie funktionieren. Eine Attacke, welche nur auf die Standard-Telekom-Hardware zugeschnitten ist, dürfte also schon eine gute Erfolgsquote erzielen. Es ist also gar nicht unbedingt notwendig, die SOAP-URL herauszufinden. Blattlaus hat geschrieben: Summa: Das ganze ist nicht so dramatisch wie es klingt. UPnP sollte man aber trotzdem deaktivieren, man muss ja nicht blind in ein potentielles (wenn auch nicht ganz so scharfes Messer) laufen. Man braucht es ohnehin fast nie.
Man könnte UPnP auch guten Gewissens als Sicherheitslücke bezeichnen. Es ist schon irgendwie mutig, Anwendungen oder Geräten die Konfiguration eines APs ohne Authentifizierung zu erlauben. Dafür braucht man schon ein gewissen Grundvertrauen in die Menschheit 😉
Ich zum Beispiel bräuchte DRINGEND eine sichere Variante, Kontakt über einen Port mit einem DAU aufzunehmen, ohne das dieser irgendwas selber einstellen muss, sondern dies per UPNP gemacht wird.
Geht dabei um Fernwartung - und die Art von Hilfe benötigen nun mal die Leute am ehesten, die am wenigstens dazu in der Lage wären, auch nur im entferntesten so etwas wie eine Port-Umleitung auf dem Router im Webinterface (oder gar Telnet *g*) einzugeben. Und später diesen Port am besten wieder schließt. UPNP an sich ist ne nette Sache, aber nicht perfekt.
|