Ancienne vulnérabilité UPnP d'une nouvelle façon

Tout ce qui est nouveau est un ancien bien oublié (ou mieux, un ancien très bien oublié). Bien sûr, il est correct de surveiller les nouvelles vulnérabilités, mais il ne faut pas oublier les anciennes. Surtout quand le constructeur se permet de les «oublier». Quelqu'un doit se souvenir. Sinon, nous marcherons sur le même râteau encore et encore.

L'article se concentrera sur un ancien, mais il s'est avéré qu'il n'a jamais perdu sa pertinence à ce jour, le trou UPnP.



PS Je n'appellerai pas le fournisseur, il n'est pas coupable de cela, mais d'un autre côté il y a une claire surveillance des politiques de sécurité qui, couplée à l'architecture réseau, a permis d'exploiter cette vulnérabilité. Comme toujours, les étoiles convergent. Le fournisseur a installé des routeurs sur son réseau aux clients avec les puces nécessaires et l'a connecté avec une adresse IP externe. Oui, la plupart des ports ont été filtrés, mais pour une raison quelconque, pas 52869.

PPS Tous les événements se sont produits fin 2018. Les héros sont fictifs et les coïncidences avec de vraies personnalités sont aléatoires.


La première mention de la vulnérabilité remonte à 2014: tyk
Les tentatives de contacter le fabricant n'ont pas été couronnées de succès et la vulnérabilité a été publiée. La seule recommandation de contre-réaction était:

"... restreindre l'interaction avec le service ... Seuls les clients et les serveurs qui ont une relation procédurale légale ... devraient pouvoir communiquer avec lui."

Une faille existe dans le service SOAP miniigd. Le problème est le traitement des demandes NewInternalClient en raison de l'impossibilité d'effacer les données utilisateur avant d'effectuer un appel système. Un attaquant pourrait utiliser cette vulnérabilité pour exécuter du code avec les privilèges root.

C'est-à-dire Sur tous les routeurs avec UPnP version 1.0, vous pouvez exécuter du code à distance arbitraire.
Sans autorisation. De la racine. Super, non?

Tout le monde peut trouver un plugin prêt à l'emploi pour le métasplit sur github, dont les performances ont été testées par les chaises brûlées de nos ingénieurs de service.
C'était inattendu et pas du tout amusant.

Une brève chronologie des événements de cette journée:

14:00 Dans le support technique, les abonnés commencent à recevoir des appels vers Internet qui fonctionne mal.

• Symptômes côté client: "ça marche lentement, après un redémarrage ça marche bien pendant un moment, puis encore lentement."
• Symptômes de la part de l'équipement: une petite augmentation du trafic et des charges CPU ont été annulées sur la charge générée par le client.

Les applications individuelles sont enregistrées pour vérifier la ligne pour les administrateurs ou pour le départ de l'installateur. Il n'y a pas de modèle d'action commun. Rien n'est clair.

15:00 Le nombre d'applications commence à dépasser la température moyenne à l'hôpital et les applications individuelles commencent à sculpter en applications pour plus avec le type d '"Accident". Les demandes sont soumises aux administrateurs supérieurs pour vérifier les segments de réseau.

15:20 Les administrateurs arrêtent les accidents de masse, car Il n'y a aucun problème sur le réseau, toutes les demandes des clients provenant de différents points de connexion sont uniques. (Par exemple: le commutateur est plein d'abonnés actifs, mais il ne fonctionne pas bien pour un). En ce moment, les appels tombent et tout se calme. Quelqu'un fait attention (enfin) que toutes les applications pour mauvais travail étaient avec le même modèle de routeur, tout le monde prétend que tout va bien.

15h30 Encore une fois l'afflux de candidatures d'abonnés, encore une fois l'enregistrement d'un accident de masse et le transfert aux admins. En ce moment, il devient clair que quelque chose ne va vraiment pas et que quelque chose doit être fait (qui a travaillé avec le service client comprendra à quel point il est parfois difficile de le faire. Les clients mentent toujours , et parfois la première ligne se trouve pour intensifier la tâche) .

15:35 L' ingénieur de service reçoit une demande de problème avec le service client. Obtient une liste de tous les clients, leur type de connexion et le modèle de périphérique. Et puis un peu de magie commence.




15:40 L' ingénieur exécute la liste des clients à travers tous les diagnostics qui sont, chaque routeur a été vérifié selon toutes les métriques standard et ... rien n'a été trouvé. Un routeur est comme un routeur. Oui, le CPU a augmenté, mais les indicateurs ne sont pas critiques, mais il verse du trafic quelque part, ce qui signifie que cela fonctionne.

Oui, le service UPnP tourne sur le port 52869. Oui, il y a encore un tas de ports ouverts, ouverts signifie qu'ils sont nécessaires (logique de fer), et cela s'est toujours retourné et il n'y a pas eu de problèmes (autre argument de logique de fer). La connexion directe à ce modèle de routeur n'est pas possible (franchement, c'est possible, mais à l'intérieur de la boîte occupée et des politiques de l'entreprise fortement allégées, une telle promenade autour des appareils clients était fortement déconseillée). Tout s'est à nouveau levé.

16:00 Ce n'est que maintenant que nous découvrons qu'il y a des problèmes. L'ingénieur en service rend compte à son superviseur, et le superviseur nous appelle au sujet de ses suppositions concernant le port 52869 et demande de l'aide.

16:05 Ensuite, tout s'est passé très rapidement. Le même modèle de routeur est inclus sur le banc de test, l'adresse IP est prise du client problématique et accrochée sur celui de test. Le Wirehark est activé. C'est pour intercepter les requêtes sur l'appareil.

Afin d'intercepter les demandes du routeur (à cette époque, le schéma général de la façon dont l'interaction était encore inconnue), le client est isolé dans le segment de test et tout son trafic est mis en miroir vers la machine de test la plus proche où un autre wirehark est levé.

On attend plus loin, on regarde l'écran.

Les hacks étaient déjà pris de cette façon - assez efficacement et ont donc décidé de ne pas changer leurs habitudes.

16:10 Alors que wirehark bruit, Google présente une vulnérabilité CVE-2014-8361 à propos de laquelle elle est signalée aux ingénieurs. L'ingénieur, sans l'écouter, prend une décision (et, en principe, logique) - le filtre de ce port à la frontière. Aussitôt dit, aussitôt fait.


16:25 On nous dit que tout remake de merde Misha n'a pas fonctionné. Et nous savions déjà que cela ne fonctionnerait pas. À ce moment-là, ils avaient déjà frappé sur le routeur de test, levé l'inverse sur un autre port et commencé à l'utiliser pour le port DDOS-a à 1900 (!) En utilisant une autre vulnérabilité. Seigneur, quelle poubelle qui fuit


La chose la plus intéressante est que les règles de pare-feu sur l'appareil ont été modifiées et que nmap n'affiche plus les ports ouverts de l'extérieur. Ce n'est que lors d'un vidage du trafic qu'il a été possible de détecter des demandes sur ces ports. C'est-à-dire un attaquant après piratage a bloqué l'accès aux autres. Pas une approche hi-tech, mais bravo quand même.

16:30 Une conférence se réunit avec les questions "qui est à blâmer et quoi faire." Les ports 1900 et 52869 ont été interdits. Des tentatives sont en cours pour réparer quelque chose sur des appareils piratés. Redémarrer - n'a pas aidé, l'idée de reflasher a été immédiatement rejetée. Oui, il existe une telle fonctionnalité, il était possible de réorganiser à distance le logiciel via TR069 avec un bouton sur tous les appareils. Mais depuis l'appareil n'était pas la première fraîcheur, mais le nombre de clients était important - un certain pourcentage d'appareils briqués créerait des problèmes.

16:40 Pour résumer: les appareils sont piratés, participent au minimum aux ddos ​​et transmettent quelque chose quelque part sur le canal crypté. (Tous sur différents ports). Il n'est pas possible d'entrer à l'intérieur, le vendeur a refusé l'accès complet via ssh à l'appareil et voir ce qu'il était impossible d'y arriver. La console est protégée par mot de passe.

Quelque part vers 17h00, il a été décidé de coudre l'appareil comme le moyen le plus rapide. Après avoir clignoté et redémarré, tout est revenu à la normale.

Au lieu de totaux

Malheureusement, nous n'avons pas pu résoudre complètement ce problème.

Par «décider», j'entends obtenir des informations de piratage complètes et mettre à jour nos politiques pour contrer cela à l'avenir. Oui, toutes les tâches ne sont pas résolues avec succès et comme nous le souhaiterions. C'est normal. Bien qu'insultant.

S'il est bon de chercher sur le shodan,
vous pouvez trouver quelque chose
pour les expériences:
d'une manière ou d' une autre
mais je ne vous l'ai pas dit.