Habe mir heute mal meinen Cisco Linksys WAG120N unter die Lupe genommen und auch gleich eine sehr lustige Sicherheitslücke entdeckt.
Gleich vorneweg, ein mögliches Angriffsszenario bedarf ein wenig Fingerspitzengefühl, da wir vor der eigentlichen Lücke einen htaccess überwinden müssen, mit ein wenig Kreativität könnte so ein Angriff allerdings gelingen.
Wie würde so ein fiktives Angriffsszenario aussehen?
Man lockt einen potentiellen Linksys WAG120N Nutzer auf seine Seite und bringt ihn dazu sich auf seinem Router einzuloggen.
Vielleicht beginnen wir mit der Meldung:
“Nutzt Ihr Linksys auch diese Firmware: V1.00.12, dann sollten Sie hier weiterlesen”.
Am Anschluss einen etwas längeren Text gefolgt von einem, na sagen wir mal:
<?php sleep(60);?>
Soviel zur fiktiven Vorbereitung, jetzt bräuchten wir noch eine entsprechende Lücke im System (der htaccess ist nun lange genug geöffnet).
Ich schaute mir also einmal den Request an um irgend eine Angriffsmöglichkeit zu finden:
Da die Linksys Macher mit der Möglichkeit eines XSRF Angriffes mit Sicherheit gerechnet haben, bauten Sie in den Request so Sachen ein wie: sysname, sysPasswd und sysConfirmPasswd.
Wir müssen hierbei wissen, dass der Standardlogin admin / admin lautet.
Wenn wir uns obiges Bild anschauen, dann sehen wir – Benutzer: admin stimmt, Passwort: 123456 – das ist aber nicht mein Passwort …
Meine Überlegung:
Die Macher wussten ganz genau, dass ein plain Request ohne weitere Schutzmechanismen eine Gefahr darstellt vielleicht waren Sie einfach zu faul was passendes zu coden und machtes es ähnlich wie die Hainschwebfliege in der Tierwelt.
Ich beschnitt also den entsprechenden Request um meine Überlegung zu testen.
… und um sicher zu sein, dass nicht irgend eine generierte Session im Browser als Schutzmechanismus wütet, löschte ich die cookies und schickte dann die beschnittene Anfrage ab … und siehe tada, wir haben die Remote-Verwaltung aktiviert.
So lange noch kein Securityfix besteht, sollten alle WGA120N Nutzer folgendes beherzigen:
Einloggen – Änderungen vornehmen etc. – Browser ganz schließen (löscht den htaccess).
Eine Meldung an Cisco wurde bereits verschickt.
Cisco Linksys WAG120N Sicherheitslücke http://goo.gl/fb/U1o25
Verstehe ich das richtig, dass man im LAN den “Admin” dazu bringen soll, über eine manipulierte Seite, auf den Router zuzugreifen? Wozu soll ich denn den String noch manipulieren, wenn man das Passwort ohnehin snifft. Oder meinste, dass man den manipulierten String durchs htaccess bekommt? Irgendwie kapier ich das nicht.
hoohead: Der Linksys wird durch einen htaccess geschützt. Der “Admin” soll sich nicht durch eine manipulierte Seite einloggen (das wäre dann Phishing und keine Sicherheitslücke), sondern einfach einen neuen Tab aufmachen und sich in seinen Router ganz normal einloggen (er will ja nachschauen welche Version er hat).
Der htaccess bleibt dann im Browser gespeichert und muss bei weiteren Zugriffen nicht nochmal eingegeben werden (zumindest lange genug um so einen Angriff durchzuführen).
Das was diesen Angriff etwas schwer (aber nicht unmöglich) macht ist die Tatsache, dass sich der “Admin” anschließend wieder zu unserer Seite begibt und diese dann so lange geöffnet lässt, wie wir unser Zeitfenster vorgeben (die PHP sleep Funkion).
Dahinter steckt dann ein per Javascript generierter Request der die gewünschten Änderungen vornimmt.
Also:
Wir schätzen wie lange ein User benötigt sich in seinen Router einzuloggen == Zeit1.
Wir schätzen wie lange der User max unsere Seite geöffnet lässt == Zeit2.
Zeit2 muss > Zeit1
sleep(xx) == Zeit1 + Toleranz aber < Zeit2 - Toleranz
Wie gesagt etwas tricky das ganze, aber nicht unmöglich.
Eine weitere Möglichkeit wäre per chat, hier könnten wir dann komplett ohne Zeitfenster arbeiten:
Angreifer: Hast Du auch die Funktion bla in Deinem Router aktiviert.
Admin: Hab nachgeschaut, ja - nein, bla ....
Angreifer: Schau mal hier: http://evil.site/ .
Ok hab’s gepeilt. Eine Sache noch: Haste den Post-String mit ‘ner anderen IP abgesetzt, wärend htacces offen war? Ich dachte eigentlich, dass nur die IP zugriff hat, die den htacces aufmacht.
hoohead: Oben ist ein Link zum Thema XSRF
Der Referer ist übrigens auch nur fake: setup.cgi?next_file=Security.htm
Auch hier wurde der Anschein erweckt, als würde dieser überprüft werden.
[...] Vermutlich wurde die Opfer IP per PHP ausgelesen, ein Ajax Request generiert in den auch gleich ein Authorization: Basic (bei htaccess Logins) mit eingepackt und dann eine Art XSRF Angriff ausgeführt (wie ich ihn neulich am Linksys demonstriert habe). [...]