Ich wollte hier beim Router (ein DLINK DIR-615 rev D3) ein paar Einstellungen verändern, hauptsächlich upnp deaktivieren und den WLAN-Kanal ändern (hier senden zu viele auf dem gleichen Kanal).
Allerdings wusste ich mein Passwort für das Webinterface des Routers nicht mehr. Das Gerät zurückzusetzen hätte bedeutet, dass ich den WLAN Key erneut einspeichern müsste (gut, Copy&Paste, aber das wäre doch langweilig...).
Also bin ich in meinen eigenen Router "eingebrochen".
Bei meinem ersten Ansatz versuchte ich über eine PHP Schwachstelle das Admin Passwort zu ändern. Hängt man die richtigen Parameter an die URL einer Seite des Admininterfaces an, so bekommt man die Seite angezeigt:
http://192.168.0.1/tools_admin.php?NO_NEED_AUTH=1&AUTH_GROUP=0
Allerdings lässt sich so das Passwort nicht ändern, und auch andere Einstellungen funktionieren nicht.
Ansatz Nummer 2 besteht aus dem Nutzerzugang, den diese Router standardmäßig haben. Benutzername "user" und ein leeres Passwortfeld erlauben Einsicht in die Einstellungen, mehr allerdings nicht.
Die Sicherheitslücke in libupnp wollte ich nicht ausnutzen, da dazu deutlich mehr Aufwand nötig gewesen wäre. Außerdem kann sich ein Fehler dort vermutlich im Schlimmsten Fall so auswirken, dass der Router nicht mehr funktioniert, was nun wirklich nicht Sinn der Sache ist.
Angeblich gibt es die Möglichkeit, per telnet auf den Router zuzugreifen. Bei mir konnte ich aber keinen laufenden telnetd finden, nmap zeigte mir auch keine dementsprechenden Ports an.
Also wollte ich versuchen, einen telnetd zu starten. Dazu fand ich im Internet mehrere Wege beschrieben:
curl --data "cmd=telnetd" http://192.168.0.1/command.php
curl --data "SSID=telnetd" http://192.168.0.1/version.txt
curl --data "exeshell=telnetd" http://192.168.0.1/tools_vct.php
Keine davon funktionierte, auch nicht in Verbindung mit meinem ersten Ansatz.
Eine weitere Möglichkeit funktionierte leider auch nicht:
curl http://192.168.0.1/apply.cgi?admin_password=pwdpwd&admin_password1=pwdpwd&admPass2=pwdpwd
Was aber funktionierte ist die HNAP Schwachstelle. Wichtig ist dabei nur, das leere XML-Tag DeviceName aus SetDeviceSettings.xml nicht zu entfernen.
Natürlich darf das alles nur am eigenen Router ausprobiert/durchgeführt werden!
Keine Kommentare:
Kommentar veröffentlichen