LED On/Off

``` Et voilà je peux activer/désactiver les LEDs de mon switch avec un script sur le réseau ! Mais attendez ... Où ai-je passé mes cookies d'authentification de la session ?! Ok, l'endpoint des LEDs n'est pas sécurisé, c'est curieux ... Et les autres ? ```bash curl "http://192.168.1.1/port_setting.cgi?portid=16&state=0&speed=1&flowcontrol=0&apply=Apply"

``` Pareil pour désactiver un port ?! On peux donc passer outre l'authentification Web si on connait les endpoints pour lire et modifier la configuration du switch ?! Contact avec le support =========== Pour moi, s'agissant déjà d'un problème et sachant que cela peut prendre du temps, je contacte le support de TP-Link par téléphone et en créant un ticket pour leur fournir les informations nécessaires : le nom du produit, sa version hardware, son numéro de firmware et les requêtes CURLs envoyées ainsi que leurs résultats. Au téléphone, je tombe sur une personne qui ne comprend pas bien mon problème, les mots API et CURL posent problèmes, mais elle me met rapidement en attente pour un passage au support L2. Cette nouvelle personne écoute et comprends mon problème, mais ce switch n'est pas disponible dans le labo de test, le technicien me propose de faire un teamviewer pour mieux cerner le problème, malheureusement je n'avais pas pensé à cette proposition et mon organisation à ce moment là n'était pas prêt pour le faire. Il me dit qu'il va échanger avec l'équipe sécurité à propos de ce ticket et me recontactera prochainement. Cela me semble curieux, je pensais que quelque chose m'avait échappé et que le support allait rapidement pointer mon erreur. Investigations =========== Premiers pas ----------- Pendant mon attente au téléphone, je continue mes tests pour bien cerner le problème. J'essaye à partir d'un autre périphérique du réseau et les requêtes ne passent pas, la configuration du switch n'est donc pas accessible en lecture/écriture à tous, heureusement ! Je retourne sur mon navigateur et regarde les headers des requêtes et là, pas de cookies. D'ailleurs le switch ne m'en a jamais envoyé et c'est là que je comprends qu'il s'agit juste d'une authentification par IP précédemment autorisée par liste blanche grâce à l'authentification web. Et en effet il suffit que je me déconnecte de l'interface d'administration pour que les requêtes CURL ne fonctionnent plus. On notera également que cela à pour conséquence que l'ouverture de l'interface à partir d'un autre navigateur sur le même périphérique est d'office considéré comme authentifié. (Heureusement qu'une restauration ou un reset redémarre le switch en coupant les connexions existantes et alerterait l'administrateur, sinon j'imagine qu'avec un peu d'ingénierie sociale on pourrait vite récupérer un accès permanent !) Le problème est donc très localisé et difficile à exploiter pour un attaquant, mais il reste présent. Hardware et firmwares ----------- Renseignons-nous davantage sur ce [TP-Link TL-SG1016DE](https://www.tp-link.com/en/support/download/tl-sg1016de). Il existe en différentes révisions hardwares : - v1, premier firmware 2013年03月07日, dernier firmware 2013年10月23日 - v2, premier firmware 2015年12月18日, dernier firmware pareil - v3, premier firmware 2017年05月30日, dernier firmware 2018年11月07日 - v4, premier firmware 2020年01月15日, dernier firmware pareil - v4.20, premier firmware 2021年06月09日, dernier firmware 2021年06月09日 (mais numéro de version différent) - v4.26, firmwares non disponibles ?! - v6, premier firmware 2022年07月16日, dernier firmware 2022年09月05日 Le mien est un v4.20 et possède bien le dernier firmware disponible : TL-SG1016DE(UN) V4.2 20210512. Utilitaires d'administration ----------- Ce switch étant manageable uniquement par interface Web et ne fournissant pas de SNMP, peut-être que des gens ont développé un utilitaire pour le contrôler et aurait déjà rencontré ce problème ? Et je trouve en effet quelques projets en ce sens : - [https://www.npmjs.com/package/tplink-smarthome-api](https://www.npmjs.com/package/tplink-smarthome-api) - [https://pypi.org/project/tplink-wr-api/](https://pypi.org/project/tplink-wr-api/) - [https://github.com/pklaus/smrt](https://github.com/pklaus/smrt) - [https://github.com/psmode/essstat](https://github.com/psmode/essstat) Vulnérabiliés ----------- Et c'est donc le README.md du projet [essstat](https://github.com/psmode/essstat) qui me confirme l'existence de ce problème et son __antériorité__ ! __2017__ !> The Easy Smart Switch family has a number of unresolved vulnerabilities, including [CVE-2017-17746](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17746). As described in [https://seclists.org/fulldisclosure/2017/Dec/67](https://seclists.org/fulldisclosure/2017/Dec/67), once a user from a given source IP address authenticates to the web-based management interface of the switch, any other user from that same source IP address is treated as authenticated.> The Python scripts in this project should be used only from a host that does not have general user access. Voilà les ressources que j'ai pu trouvé sur des vulnérabilités trouvées sur certains switchs TP-Link: - [https://chmod750.wordpress.com/2017/04/23/vulnerability-disclosure-tp-link/](https://chmod750.wordpress.com/2017/04/23/vulnerability-disclosure-tp-link/) - [https://www.chrisdcmoore.co.uk/post/tplink-easy-smart-switch-vulnerabilities/](https://www.chrisdcmoore.co.uk/post/tplink-easy-smart-switch-vulnerabilities/) - [https://www.trenchesofit.com/2018/08/13/why-tplink-why/](https://www.trenchesofit.com/2018/08/13/why-tplink-why/) On notera au passage quelques autres points, notamment : - il n'y a pas de vérification coté backend sur la longueur du champ utilisateur, uniquement coté client. - le mot de passe est limité à 16 caractères alphanumériques Surface d'attaque et contre-mesures ----------- A ce moment là, je réfléchis à la surface d'attaque que cela représente pour moi, simple particulier mais passionné. Un programme malveillant sur mon ordinateur pourrait modifier la configuration de mon switch à mon insu, sans même avoir besoin de récupérer mes cookies. Et si je configure mon switch à partir d'une ip NAT, j'ouvre également la porte à d'autres périphériques sur le réseau. Cela me semble désagréable, peut-être un poil risqué, mais il y a sûrement moyen d'améliorer ça. Après tout, cela n'est possible qu'à partir des ports marqués comme faisant partie du VLAN d'administration. Il me suffit donc de bien configurer ce VLAN et les ports associés pour limiter les risques à un niveau disons acceptable. Désillusion ----------- Simplement je n'arrive à mettre la main sur ce paramètre dans l'interface, impossible de configurer le VLAN ID d'administration ! Et en effet, un commentaire sur [Amazon](https://www.amazon.fr/gp/customer-reviews/R1ITZE3MBN2B1Q?ASIN=B00DBRPKS6) confirme mes craintes.> tous les ports appartiennent d'office au VLAN d'administration 1. Il n'est pas possible de changer ce N° de VLAN d'admin. Et est considérée comme appartenant au VLAN d'administration, toute trame Ethernet véhiculant de l'IP appartenant au réseau sur lequel a été configuré l'interface IP d'administration du switch. Par défaut c'est 192.168.0.1/24. Il en résulte que tout PC configuré avec une IP sur ce même réseau IP 192.168.0.1/24, permet d'administrer le switch, qu'on l'ai branché sur les ports qui tagguent, ou sur les ports ordinaires de n'importe quel VLAN !!> Ce n'est pas très sécure, mais la séparation des VLAN, fonctionne bien pourvu qu'on n'utilise surtout pas d'adresses IP sur ces VLAN, qui seraient comme par "hazard" dans l'intervalle du réseau d'admin !!!! En réalité, j'avais déjà lu ce commentaire avant mon achat, mais comme chacun devrait le savoir il est fortement déconseillé d'utiliser le VLAN 1 ou alors de le réserver pour l'administration de périphériques étant par défaut configuré sur celui-ci. Et donc, pour moi il suffisait de limiter les ports membres du VLAN 1 pour réduire la surface d'attaque, sauf que non. Cela n'a pas d'effet et tous les ports permettent de dialoguer en HTTP avec le switch sur son IP, il suffit à n'importe quel périphérique de configurer une ip statique appartenant au même réseau. Les problèmes identifiés =========== - interface d'administration uniquement accessible en HTTP - limitation de la longueur du mot de passe à 16 caractères - authentification basée sur l'IP après connexion, et non sur une session HTTP(s) par cookie - impossibilité de modifier le VLAN ID d'administration - impossibilité de configurer le switch de façon à répondre uniquement aux requêtes provenant de certains ports Conclusion =========== Quoi retenir de tout ça ? Sur ce produit ----------- - le switch fait globalement son travail et les points relevés ici ne posent peut-être pas problème à la clientèle ciblée par ce produit très accessible financièrement et techniquement et qui ouvre la voie à la gamme des switchs manageables - si vous voulez un switch très facilement scriptable par requête HTTP, c'est un excellent produit :D - honnêtement ce genre de problème sur un matériel vendu malgré tout pour des professionnels m'interpelle. Certes je doute que beaucoup de PME y voient un soucis, mais à l'heure où il y a de la double authentification partout, voir de l'authentification bricolée par simple IP avec une activation sur du HTTP (impossible de passer sur du HTTPS) me semble être une hérésie. - le problème est identifié depuis des années sur d'autres modèles de la gamme et n'est toujours pas corrigé ! - je vais le remplacer par un [Netgear GS724Tv4](https://www.netgear.com/support/product/GS724Tv4.aspx) pour le double du prix, totalement sur-dimensionné pour mon réseau et mes usages actuels, mais me propose beaucoup plus de fonctionnalités et de sécurité, notamment le HTTPS pour l'administration web, la configuration du VLAN d'administration, le SNMPv3, le [RMON](https://fr.wikipedia.org/wiki/RMON), le DHCP Snooping, les VLAN MAC, 2 ports SFP, la double gestion des firmwares, l'inspection ARP dynamique, etc. De façon générale ----------- - se renseigner davantage sur les failles de sécurité avant l'achat d'un matériel aussi "sensible" - l'authentification c'est mieux quand elle est vérifiée correctement, partout et tout le temps - continuer à être curieux, voir comment les produits fonctionnent et toujours essayer de bricoler :p Les questions que je me pose ----------- - est-ce que ça méritait vraiment un journal ? 😅 - est-ce que vous faites la même analyse que moi ? Le réseau n'est pas vraiment mon cœur de métier après tout, je fais peut-être une erreur d'analyse du risque ou tout simplement de configuration ? - quelle est votre stack réseau à la maison ?