Alte UPnP-Schwachstelle auf neue Weise

Alles Neue ist ein gut vergessenes altes (oder besser ein sehr gut vergessenes altes). Natürlich ist es richtig, neue Schwachstellen zu überwachen, aber Sie sollten alte nicht vergessen. Besonders wenn der Hersteller sich erlaubt, sie zu „vergessen“. Jemand muss sich erinnern. Andernfalls werden wir immer wieder auf denselben Rechen treten.

Der Artikel wird sich auf einen alten konzentrieren, aber wie sich herausstellte, hat er bis heute nie seine Relevanz verloren, das UPnP-Loch.



PS Ich werde den Anbieter nicht anrufen, er ist daran nicht schuld, aber andererseits gibt es eine klare Kontrolle der Sicherheitsrichtlinien, die es in Verbindung mit der Netzwerkarchitektur ermöglicht haben, diese Sicherheitsanfälligkeit auszunutzen. Wie immer laufen die Sterne zusammen. Der Anbieter installierte Router in seinem Netzwerk für Clients mit den erforderlichen Chips und verband sie mit einer externen IP-Adresse. Ja, die meisten Ports wurden gefiltert, aber aus irgendeinem Grund nicht 52869.

PPS Alle Ereignisse ereigneten sich Ende 2018. Helden sind fiktiv und Zufälle mit echten Persönlichkeiten sind zufällig.


Die erste Erwähnung der Sicherheitsanfälligkeit erfolgte 2014: tyk
Versuche, den Hersteller zu kontaktieren, brachten wenig Erfolg und die Sicherheitslücke wurde veröffentlicht. Die einzige Gegenempfehlung war:

"... Einschränkung der Interaktion mit dem Dienst ... Nur Clients und Server, die eine rechtliche Verfahrensbeziehung haben ... sollten in der Lage sein, mit ihm zu kommunizieren."

Im miniigd SOAP-Dienst liegt ein Fehler vor. Das Problem besteht in der Verarbeitung von NewInternalClient-Anforderungen, da Benutzerdaten vor einem Systemaufruf nicht gelöscht werden können. Ein Angreifer kann diese Sicherheitsanfälligkeit verwenden, um Code mit Root-Rechten auszuführen.

Das heißt, Auf allen Routern mit UPnP Version 1.0 können Sie beliebigen Remotecode ausführen.
Ohne Genehmigung. Von der Wurzel. Großartig, richtig?

Jeder kann auf Github ein fertiges Plugin für Metasplit finden, dessen Leistung von den verbrannten Stühlen unserer Dienstingenieure getestet wurde.
Es war unerwartet und machte überhaupt keinen Spaß.

Eine kurze Chronologie der Ereignisse dieses Tages:

14:00 Im technischen Support erhalten Abonnenten Anrufe ins schlecht funktionierende Internet.

• Symptome auf der Clientseite: "Es funktioniert langsam, nach einem Neustart funktioniert es eine Weile einwandfrei, dann wieder langsam."
• Symptome seitens des Geräts: Ein kleiner Anstieg des Datenverkehrs und der CPU-Auslastung wurde auf die vom Client generierte Auslastung abgeschrieben.

Einzelne Anwendungen werden registriert, um die Leitung auf Administratoren oder die Abreise des Installateurs zu überprüfen. Es gibt keine gemeinsame Vorlage für Maßnahmen. Nichts ist klar.

15:00 Die Anzahl der Anträge beginnt, die Durchschnittstemperatur im Krankenhaus zu überschreiten, und einzelne Anträge werden zu Anträgen für mehr mit der Art "Unfall". Anträge werden an leitende Administratoren gesendet, um Netzwerksegmente zu überprüfen.

15:20 Admins schließen Massenabstürze, weil Es gibt keine Probleme im Netzwerk, alle Kundenanfragen von verschiedenen Verbindungspunkten sind einzeln. (Zum Beispiel: Der Switch ist voll mit aktiven Teilnehmern, funktioniert aber für einen nicht gut.) In diesem Moment fallen die Appelle und alles beruhigt sich. Jemand macht (endlich) darauf aufmerksam, dass alle Anwendungen für schlechte Arbeit mit demselben Routermodell ausgeführt wurden. Alle zusammen geben vor, dass alles in Ordnung ist.

15:30 Wieder der Zustrom von Anträgen von Abonnenten, wieder die Registrierung eines Massenunfalls und die Übertragung an die Admins. In diesem Moment wird klar, dass etwas wirklich nicht stimmt und etwas getan werden muss (wer mit dem Kundendienst zusammengearbeitet hat, wird verstehen, wie schwierig es manchmal ist. Kunden lügen immer , und manchmal liegt die erste Zeile darin, die Aufgabe weiter zu eskalieren). .

15:35 Der diensthabende Ingenieur erhält eine Anfrage für ein Problem mit dem Kundendienst. Ruft eine Liste aller Clients, ihres Verbindungstyps und Gerätemodells ab. Und dann beginnt ein bisschen Magie.




15:40 Der Techniker führt die Client-Liste durch alle Diagnosen, jeder Router wurde gemäß allen Standardmetriken überprüft und ... es wurde nichts gefunden. Ein Router ist wie ein Router. Ja, die CPU hat zugenommen, aber die Anzeigen sind nicht kritisch, aber sie leiten irgendwo Verkehr ab, was bedeutet, dass es funktioniert.

Ja, der UPnP-Dienst dreht sich auf Port 52869. Ja, es gibt immer noch eine Menge offener Ports, offen bedeutet, dass sie benötigt werden (Eisenlogik), und es drehte sich immer um und es gab keine Probleme (ein weiteres Argument der Eisenlogik). Ein direktes SSH zu diesem Routermodell ist nicht möglich (ehrlich gesagt ist dies möglich, aber innerhalb der stark reduzierten Busybox- und Unternehmensrichtlinien wurde von einem solchen Rundgang durch Clientgeräte dringend abgeraten). Alles stand wieder auf.

16:00 Erst jetzt stellen wir fest, dass es einige Probleme gibt. Der diensthabende Ingenieur meldet sich bei seinem Vorgesetzten, und der Vorgesetzte ruft uns wegen seiner Vermutungen zu Port 52869 an und bittet um Hilfe.

16:05 Dann ging alles sehr schnell. Das gleiche Routermodell ist auf dem Prüfstand enthalten, die IP-Adresse wird vom Problemclient übernommen und an den Testclient gehängt. Der Wireshark ist eingeschaltet. Dies dient zum Abfangen von Anforderungen an das Gerät.

Um Anforderungen vom Router abzufangen (zu diesem Zeitpunkt war das allgemeine Schema, wie die Interaktion noch unbekannt war), wird der Client im Testsegment isoliert und der gesamte Datenverkehr auf die nächste Testmaschine gespiegelt, auf der ein anderer Wireshark ausgelöst wird.

Wir warten weiter, wir schauen auf den Bildschirm.

Hacks wurden bereits auf diese Weise gefangen - recht effizient und beschlossen daher, die Gewohnheiten nicht zu ändern.

16:10 Während Wireshark raschelt, gibt es in Google eine Sicherheitslücke CVE-2014-8361, über die Ingenieure informiert werden. Der Ingenieur trifft, ohne zuzuhören, eine Entscheidung (und im Prinzip logisch) - den Filter dieses Ports an der Grenze. Kaum gesagt als getan.


16:25 Uns wird gesagt, dass alle Remake-Scheiße Mischa nicht funktioniert hat. Und wir wussten bereits, dass das nicht funktionieren würde. Zu diesem Zeitpunkt hatten sie bereits an den Testrouter geklopft, das Reverse ausgelöst und einen anderen Port verwendet und ihn für DDOS-a bis 1900 (!) Port mit einer anderen Sicherheitsanfälligkeit verwendet. Herr, was für eine undichte Mülltonne


Das Interessanteste ist, dass die Firewall-Regeln auf dem Gerät geändert wurden und nmap jetzt keine offenen Ports von außen anzeigt. Nur in einem Verkehrsdump konnten Anforderungen an diesen Ports erkannt werden. Das heißt, Ein Angreifer blockierte nach dem Hacken den Zugang zum Rest. Kein High-Tech-Ansatz, aber trotzdem mutig.

16:30 Eine Konferenz versammelt sich mit den Fragen "Wer ist schuld und was zu tun?". Die Ports 1900 und 52869 wurden gesperrt gelassen. Es wird versucht, etwas auf gehackten Geräten zu reparieren. Neustart - hat nicht geholfen, die Idee des Reflashing wurde sofort abgelehnt. Ja, es gibt eine solche Funktion, dass es möglich war, Software über TR069 mit einer Taste auf allen Geräten aus der Ferne neu anzuordnen. Aber seitdem Das Gerät war nicht die erste Frische, aber die Anzahl der Kunden war groß - ein bestimmter Prozentsatz der gemauerten Geräte würde Probleme verursachen.

16:40 Zusammenfassend: Die Geräte werden gehackt, nehmen an einem Minimum an ddos ​​teil und übertragen irgendwo auf dem verschlüsselten Kanal etwas. (Alle an verschiedenen Ports). Der Zugang ist nicht möglich. Der Anbieter hat den vollständigen Zugriff über ssh auf das Gerät verweigert und festgestellt, was nicht möglich war, um dorthin zu gelangen. Die Konsole ist passwortgeschützt.

Kurz vor 17:00 Uhr wurde beschlossen, das Gerät als schnellsten Weg zu nähen. Nach dem Flashen und Neustarten wurde alles wieder normal.

Anstelle von Summen

Leider konnten wir dieses Problem nicht vollständig lösen.

Mit "entscheiden" meine ich, vollständige Hacking-Informationen zu erhalten und unsere Richtlinien zu aktualisieren, um dem in Zukunft entgegenzuwirken. Ja, nicht alle Aufgaben werden erfolgreich und wie gewünscht gelöst. Es ist in Ordnung. Obwohl beleidigend.

Wenn es gut ist, nach dem Shodan zu suchen,
du kannst dir etwas finden
für Experimente:
so oder so
aber das habe ich dir nicht gesagt