ubuntuusers.de

Die Leute von gnucitizen.org haben ein paar Artikel veröffentlicht, wie Angreifer ohne weiteres mit Hilfe präparierter Javaskripte oder Flash-Objekte eure Router umkonfigurieren können. Z.B. könnte ein Angreifer auf diese Art und Weise zusätzliche Portforwarding-Regeln einrichten und damit Dienste aus dem LAN nach außen zugänglich machen, oder gleich den DNS-Eintrag verbiegen um mit Hilfe eines eigenen DNS-Servers das Opfer auf manipulierte Webseiten umzuleiten. (Z.B. Phishing selbst wenn man die URL der Bank von Hand eingibt.)

Die Schwachstelle, die ausgenutzt wird, heißt Universal Plug and Play (UPnP). Entgegen dem, was in dem Wikipedia-Artikel steht, muss allerdings der PC nicht zuerst mit Schadsoftware infiziert werden, um dem Angreifer die Möglichkeit zur Routerumkonfiguration zu eröffnen. (Außer man sieht das Flash-Plugin an sich schon als Schadprogramm an. 😉 )

UPnP ist ein Protokoll, dass keinerlei Authentifizierung benutzt und quasi jedem Benutzer eines LANs erlaubt, ohne Passwort den Router umzukonfigurieren. Diese Sicherheitslücke ist also kein Bug in einem bestimmten Router, der gefixt werden kann, sondern eine prinzipiell vorhandene Lücke in einem unsicheren Protokoll by design. (Dreimal dürft ihr raten, welcher Softwaremonopolist dieses Protokoll erfunden hat. 😉 ) Die einzige Möglichkeit dem zu entgehen, ist UPnP auf dem Router zu deaktivieren. Dann funktionieren vielleicht ein paar P2P-, IM- oder VoiP-Programme nicht mehr richtig, weil sie ihr Portforwarding nicht mehr einrichten können, aber das ist eben der Preis der Paranoia.

Die anonyme Natur von UPnP bietet an sich schon große Risiken. Wer gerade nichts zu tun hat, kann sich ja mal in seiner Gegend umsehen und testen, bei wie vielen öffentlichen Hotspots er den Router manipulieren könnte. (Bitte nicht wirklich machen - ihr macht euch dadurch strafbar.) Die Artikel von Gnucitizen beschreiben jetzt, wie man das auch von außen ausnutzen kann, indem man einfach einen Benutzer dazu bringt, in seinem Browser ein völlig unverfängliches Objekt auszuführen.

Zum einen funktioniert das mit JavaScript, aber weil die dafür notwendige XmlHttpRequest-Routine Verbindungen nur zum selben Server aufbaut, von dem die Webseite stammt, benötigt der Angreifer eine Cross-Site Scripting-Lücke in der Weboberfläche des Routers. Solche Lücken sind gar nicht mal so selten, und vor allem: Wer patcht schon regelmäßig seinen DSL-Router, wenn ein Firmwareupdate rauskommt? Allerdings müsste der Angreifer dafür wohl wissen, welchen Router das Opfer verwendet. (Auch nicht so ein großes Problem, wenn man z.B. den mitgelieferten Router des Providers verwendet.)

Noch universeller ausnutzbar ist die Lücke durch Flash. Die navigateToURL- und URLRequest-Funktionen besitzen nicht dieselbe Einschränkung auf den Serverhost, wie XmlHttpRequest in JavaScript. Das einzige was der Angreifer wissen/erraten muss, ist die interne IP-Adresse des Routers und im Falle von Port-Forwarding die interne IP des Rechners, auf den der Port umgeleitet werden soll.

Betroffen sind übrigens nicht nur Router, sondern auch Kameras, Drucker, Mobiltelefone, Multimediageräte, etc. mit UPnP-Unterstützung, obwohl es da wahrscheinlich etwas mehr Phantasie braucht, um einen Anwendungszweck zu finden.

http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5
http://www.gnucitizen.org/blog/hacking-the-interwebs
http://www.gnucitizen.org/blog/flash-upnp-attack-faq

otzenpunk hat geschrieben:

Dreimal dürft ihr raten, welcher Softwaremonopolist dieses Protokoll erfunden hat.

Intel? Ach, halt, die waren Hardwaremonopolist... und von denen ist auch die Spezifikation für IGDs.

Dass UPnP grundlegend unsicher ist ist nichts neues - neu ist die Methode, über JavaScript oder FlashScript den internen Rechner dazu zu bringen, die Änderungen vorzunehmen.
Entsprechend war es schon immer galoppierender Wahnsinn, UPnP auf Hotspots einzusetzen - allerdings hängen Konfigurations-Möglichkeiten eben stark vom upnp-daemon ab. Und wenn da einige Provider Passwort-Resets, etc. einbauen, ist das unverantwortlich... aber hey, die lassen auch ein Default-Passwort zur Remoteadministration stehen.

Mal ganz dumm gefragt: Wie sieht es da mit den Fritz!Boxen aus?
Ich habe da mal geschaut, und nur einen Punkt gefunden:

Statusinformationen über UPnP übertragen (empfohlen) bei den Netzwerkeinstellungen.
Wäre das so eine Option, wo sich das deaktivieren empfiehlt?

Die ersten Dinge die ich bei meinem Router gemacht habe:

1. Routerpasswort geändert.
2. Router-IP-Adresse geändert (siehe dazu auch hier.)
3. Remote-Zugriff deaktiviert.
4. UPnP deaktiviert (Ports die ich brauche z.B. für BitTorrent schalte ich selber frei, und zwar nur dann, wenn ich sie brauche).

Ich glaube, damit habe ich schon mal einige grundlegende Lücken geschlossen (hoffe ich zumindest 😕 ).

Da bin ich ja mal positiv überascht: bei unsrem Router (Netgear 814v2)) war und ist UPnP standardmäßig deaktiviert ☺

€: komisch, in der Hilfe-Spalte steht das default "on" ist.

Ich habe keine Lust mir alle 4 verlinkten Artikel durchzulesen, aber:
- UPnP Service Discovery basiert auf UDP
- Flash hat keine UDP Socketfunktionalitäten
- JS kann überhaupt keine Sockets, nur HTTP
- Java Applets können UDP Sockets, sind allerdings auf Same Origin beschränkt, bedürfen also eine DNS-Rebinding Attacke (ich verweise dazu mal auf den gleichnamigen 24c3 Vortrag)
- Da somit somit weder Flash noch JS den UPnP Service entdecken können bleibt da nur die Option das sie die SOAP Url erraten
- ohne Skriptblocker wird man heutzutage ohnehin nur zugemüllt

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.

hab UPnP aktiv weil ich mich nicht 5 Stunden lang damit beschäftigen will welches proggi welchen Port brauch...ich hab das 1mal versucht, nach 2 Stunden arbeit ging weder Steam, noch BitTorrent noch Battlefield 2.
Fazit: UPnP ist ein Geschenkt des Himmels ☺

Ich werd nen Teufel tuen und das deaktivieren.

Außerdem hab ich NoScript und auf dem PC sind sowieso keine wichtigen Daten...und OnlineBanking...nja, das wird noch ein paar Jahrzehnte dauern bis ich das mach...viel zu unsicher.

Teetrinker hat geschrieben:

4. UPnP deaktiviert (Ports die ich brauche z.B. für BitTorrent schalte ich selber frei, und zwar nur dann, wenn ich sie brauche).

Und wie mache ich das bei meiner Fritz!Box 7170?
Wenn ich das richtig gelesen habe bei AVM, sind standardmäßig alle TCP und UDP Ports geschlossen.
In der Benutzeroberfläche kann ich auch nur Ports freigeben, aber nicht schließen.

War es das schon?

Der Punkt heißt Portforwarding oder NAT.

Wenn du Google benutzt wirst du herausfinden wie das bei deinem Router funktioniert.

Es steht garnicht fest, was für Router davon betroffen sind:

If you sniff yourself while running software that uses UPnP in the background to help you configure your router, you’ll see that UPnP is nothing more than SOAP. Our AJAX knowledge tells us about a feature that allows us to craft arbitrary XML requests: the XMLHttpRequest object. Trouble is, such object can only be used within the context of the site that the requests are submitted to. So if we host the malicious scripting code on a third-party site, and a victim user located in the same LAN as the target IGD visits such page, the request wouldn’t go through due to XMLHttpRequest same-origin policy restricition. Or put in a different way: you aren’t allowed to make XMLHttpRequests to any server except the server where your web page came from.

However, if you find a pre-auth XSS vulnerability on the target device you can bypass such restriction

Ich habe gerade mal den Login-Screen der Fritz.Box bei mir gecheckt und konnte keine XSS-Attacke triggern.

mit der neusten Firmware meiner Fritzbox hab ich sogar das Problem, dass ich ständig Reconnects hab, wenn ich uPNP an habe...

Was auch gerne vergessen wird:

UPnP/NAT-PMP-Ports werden nur bei Bedarf geöffnet und dann wieder geschlossen - teils mit dynamischer Portnummer.
Einfache Portmaps sind statisch und damit auch ein Sicherheitsrisiko.

Und Port-Trigger sind eine gute Idee, aber nicht immer funktional.

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

Exakt. (Steht aber auch in den Artikeln. 😉 )

Wo ist das Problem? In dem Beispiel im Text lautet sie /upnp/control/igd/wanpppcInternet. Ich weiß jetzt nicht, ob das für jeden Routertyp gleich ist, aber zumindest sehe ich keine individuelle Komponente für jedes einzelne Gerät, die schwierig zu erraten wäre.

Selbst wenn unterschiedliche Router unterschiedliche URLs haben:
- Für Massenexploits könnte man abhängig von der IP des Opfers die SOAP-URL und die Standard-IP des Routers verwenden, den der jeweilige Provider seinen Kunden zur Verfügung stellt.
- Für gezielte Angriffe wäre es sicher nicht prinzipiell unmöglich herauszufinden, welchen Router der Standort verwendet.

konnman hat geschrieben:

Mal ganz dumm gefragt: Wie sieht es da mit den Fritz!Boxen aus?
Ich habe da mal geschaut, und nur einen Punkt gefunden:

Statusinformationen über UPnP übertragen (empfohlen) bei den Netzwerkeinstellungen.
Wäre das so eine Option, wo sich das deaktivieren empfiehlt?

Ich hab hier bei meiner Fritz!Box noch den Punkt:
Änderungen der Sicherheitseinstellungen über UPnP gestatten
und in der Beschreibung steht auch, dass dadurch Programme u.a. selbstständig Ports öffnen können. Diese Option war bei mir aber von Anfang an deaktiviert. Die Statusinformationen sollten also keine sicherheitstechnischen Probleme bereiten. (lass mich da aber gerne eines bessren belehren)

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 😉