samedi 3 octobre 2015

Capture sur réseau filaire

Comment capturer des flux sur un réseau filaire ?

Tôt ou tard, lors de pentest ou reverse engineering de boite noire, il est nécessaire de capturer des flux sur un réseau filaire. Depuis un système informatique, il suffit de faire la capture tout simplement.

Quand il s’agit de capturer le flux, sur un réseau filaire, d’un périphérique matériel comme un routeur ou switch, ou un dispositif multimédia comme une Set-Top-Box ou une SmartTV ou encore de systèmes plus particuliers comme une box domotique ou une Femtocell, il faut disposer d’un équipement spécifique. 


Les équipements sur le marché

Traditionnellement, il faut utiliser un TAP réseau, spécifiquement dédié à l’interception, mais ces appareils sont coûteux.. Un TAP économique ne permet de rediriger qu’un simplex (un sens de trafic) sur un autre port ce qui s’avère inexploitable dans la pratique.J'en possède un qui ne me sert à rien...

Autrefois, un simple hub, donc la caractéristique est d’être un répéteur multi-port, était utilisé pour écouter tout le trafic, simplement en se connectant sur un port. J'ai deux vieux hub FastEthernet que j'utilise fréquemment et que j'ai gardé précieusement. Mais aujourd'hui, je dois de plus en plus souvent capturer des flux sur des interfaces GigaEthernet

Le marché ne propose plus que des commutateurs (switch), parfois improprement appelés Hub par le service Marketing du fabricant ou du vendeur. Malheureusement, le fonctionnement d’un switch est basé sur une matrice qui commute les trames d’un port à l’autre, améliorant la bande passante disponible pour chaque port, mais en isolant les différents trafics. Ce principe est donc incompatible avec l’interception. 

Pour résoudre ce problème de capture, il faut disposer d’un swicht professionnel, qui offre des fonctions de port mirroring. Le port mirroring permet de dupliquer un trafic d’un port vers un port dédié à la capture.

Sur Internet, il y a de vieux Hubs d’occasion, mais ceux-ci ne supporte généralement pas de GigaEthernet, et sont parfois des équipements avec 8 ou 16 ports plutôt encombrant. Quoi qu'il en soit, ils restent difficiles à trouver aujourd'hui. J'en ai acquis deux en 2007 et déjà ils étaient rares.

Les modèles entrée de gamme de switch 5 ports GigaEthernet (RJ45) chez Cisco ou HP, qui disposent de port mirroring sont dans des gammes de prix allant de 200 à 300 €. Dualcomm propose quelques produits 5 ports GigaEthernet supportant du port mirroring dans une gamme de prix de 150 à 170 $, mais ils sont difficiles à acheter. CyberData a des dispositifs avec juste 3 ports pour du mirroring aux environs de 120 à 130 $. Je n'en ai jamais eu entre les mains.

Dans la gamme professionnel, chez Netgear, il y a la gamme ProSafe, dont le switch 5 ports GigaEthernet GS105Ev2 supporte le port mirroring. Il est disponible à la vente chez quelques enseignes pour ~30 € hors frais de port.


Capturer le flux avec Linux

Enfin, par souci d’exhaustivité, il est possible d’utiliser un PC sous Linux et de capturer le trafic en activant le forwarding IP. Le PC est alors un routeur. Sinon, avec du ARP poisoning, il est possible d'acheminer le trafic vers la station d'écoute en usurpant la passerelle par défaut. Une autre méthode au niveau de la couche 2 est de faire du du bridging avec deux interfaces réseaux pour intercepter le trafic sur le système hôte Linux. Dans tous ces cas de figure, le trafic est intercepté mais peut aussi être altéré en espace utilisateur. 

Il m’est arrivé aussi de positionner une règle iptable sur un routeur OpenWRT pour dupliquer le trafic d'une IP source vers l'IP de la station d’écoute. Un petit routeur OpenWRT ou DD-WRT économique et peu encombrant fait l’affaire. Cela a été quelque fois un mode opératoire en l'absence de switch pro.


Le switch Netgear ProSafe GS105Ev2


J’ai déjà évoqué ce switch Netgear ProSafe économique. J’en ai acquis un pour disposer d’un équipement dédié, à faible encombrement, pour m’accompagner lors de pentests.

L'inconvénient de ce switch est qu’il n’est manageable que depuis Windows. En effet, il faut installer l’utilitaire Netgear, qui s’appuie sur Adobe Air et requiert aussi l’installation de WinPCAP.

Cet outil Netgear procède à une découverte des switchs sur le LAN et les affiche dans son interface graphique. Ensuite, il suffit de choisir le switch à manager parmi ceux découverts. Il est possible d’assigner un nom à l’équipement, de changer son mot de passe (password par défaut) et de définir sa configuration IP (DHCP ou statique). Il supporte la gestion de QoS et de VLAN mais surtout, un onglet permet de définir le port mirroring en cochant le(s) port(s) source(s) à écouter et le port de destination (celui auquel se connecte l’ordinateur d’interception).  


Interface de découverte de switch
L’avantage est que lorsque la configuration est faite, elle est stockée en mémoire non volatile et permet de se passer de Windows et du soft propriétaire. Un accès SSH, telnet ou même HTTP aurait été plus judicieux que d'installer un outil exotique… 

Port mirroring du port 5 vers 1

Côté avantage du produit, j’ai défini un mirroring permanent du port 1 vers le port 5. Il suffit de connecter l’équipement à écouter sur le port 1, et la station d’écoute sur le port 5 pour capturer le trafic. La capture fonctionne bien et supporte Ethernet en 10/100/1000. Les diodes frontales indiquent la présence de trafic par clignotement et la configuration du port avec un code sur 2 diodes pour Ethernet / FastEthernet / GigaEthernet.

Projet ngadmin pour Linux

En capturant les échanges, on découvre des paquets qui comportent la chaîne “NSDP” (Netgear Switch Dicovery Protocol), il s'agit d'un protocole de gestion de périphérique réseau conçu par Netgear. Un projet Open Source pour Linux existe, il s'agit de ngadmin. Il est accessible via git. Voici les instructions pour le build manquantes sur le package du site :
$ git clone http://git.darkcoven.tk/c/ngadmin.git
$ cd ngadmin
$ autoreconf -i
$ ./configure
$ make
$ sudo make install

$ sudo ldconfig

Apparemment, le code a changé de place avec un script autogen.sh  :

git clone https://github.com/Alkorin/ngadmin
$ cd ngadmin
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
$ sudo ldconfig

Les outils nécessaires pour construire le script configure et les makefiles sont :
$ sudo apt-get install automake m4 autoconf libtool libreadline-dev

Pour le manuel en ligne :
$ man ngcli

Si l'interface âr défaut n'est pas eth0 :
$ ngcli -i <dev>

L'utilisation est plutôt intuitive, il  faut d'abord scanner le réseau pour découvrir les switchs présents, puis configurer le mot de passe avant d'executer la commande login pour le switch avec lequel on souhaite interagir. Après, la commande mirror [disable|set|show] permet de gérer le port mirroring de façon conviviale:
$ ngcli 
> help
Available commands:
bitrate cabletest defaults firmware help igmp list login loop mirror name netconf password ports qos quit restart scan stormfilter tree vlan
> scan
Num Mac               Product  Name       IP           Ports Firmware
0   c0:ff:d4:b7:ab:2f GS105Ev2 gigaswitch 192.168.1.97 5     V1.4.0.2
found 1 switch(es)

> list 
Num Mac               Product  Name       IP           Ports Firmware
0   c0:ff:d4:b7:ab:2f GS105Ev2 gigaswitch 192.168.1.97 5     V1.4.0.2
found 1 switch(es)

> password set password
> login 0 

> mirror show
destination: 5
ports: 1
> mirror set
usage: mirror set <destination port> clone <port1> [<port2> ...]
> mirror set 2 clone 3
> mirror show
destination: 2
ports: 3
> quit


Netgear a publié de nouveaux outils et firmware disponible là : https://www.netgear.com/support/product/GS105Ev2.aspx#ProSAFE%20Plus%20Configuration%20Utility%20v2.7.8
Il y a notamment un outil de découverte NSDP disponible pour Mac OS, Windows et Linux (en mode graphique). L'utilitairer de configuration reste uniquement sous Windows.

La doucmentation est disponible là : https://www.netgear.com/support/product/GS105Ev2.aspx#docs

Mode batch

La commande en ligne permet d'interprèter un fichier batch contenant une liste de commande. le script shell suivant montre un exemple.

$ cat ng-config-ls.sh
#!/bin/bash

BATCH=cmds.txt

MAC="c0:ff:d4:b7:ab:2f"
PASS="password"
DEV=$(ifconfig | grep -B1 192.168.1 | grep UP | cut -f1 -d':')

# -- Create a batch file containing commands

cat << EOF > $BATCH
name show
firmware show
netconf show
list
ports state
ports statistics show
mirror show
quit
EOF

echo "[*] Display config of Netgear Prosafe switch GS105Ev2 (on dev: $DEV)"
ngcli -i $DEV -m $MAC -p $PASS < $BATCH


Execution:

$ ./ng-config-ls.sh 
[*] Display config of Netgear Prosafe switch GS105Ev2 (on dev: fibre0)
scan... done
login... done
gigaswitch
V1.4.0.2
DHCP : no
IP : 192.168.1.97
Netmask : 255.255.255.0
Gateway : 192.168.1.1
Num Mac Product Name IP Ports Firmware
  0 c0:ff:d4:b7:ab:2f GS105Ev2        gigaswitch                      192.168.1.97        5 V1.4.0.2

found 1 switch(es)
port 1: down
port 2: 1000M full-duplex
port 3: 1000M full-duplex
port 4: 1000M full-duplex
port 5: down
Port             Received                 Sent           CRC errors
   1            862532791          35475805793                    0
   2          19220858434         338862320567                    0
   3         107140899658         272389080547                    0
   4         623058922101         127056668540                    0
   5                    0                    0                    0
port mirroring is disabled



Conclusion

Tout black box hacker doit disposer d’un équipement de capture pour réseau filaire. Ce switch est économique (~30 €) et gigaEthernet, il supporte le port mirroring et possède un faible encombrement permettant de l’emmener partout.

L’inconvénient d'un utilitaire disponible uniquement sous Windows n’est pas un vrai problème car une alternative open source en ligne de commande existe. A défaut, une configurartion statique permet de se sortir de ces contraintes, mais on aurait aimé un accès ssh, telnet ou encore http pour fonctionner avec tout type de station de travail sans devoir installer des logiciels. 

samedi 26 septembre 2015

Le marché du zero day

Zerodium, mouchard et marché du 0day

Aujourd’hui, les agences gouvernementales (et les cybercriminels) utilisent principalement l’ingénierie sociale ou des accès physiques pour compromettre un système, ordinateur ou smartphone, dans l’optique d’y installer des outils de surveillance et d’interception, en clair un "mouchard" ! 

Les évolutions attendues de ces modes opératoires sont d’obtenir un accès facilement, rapidement et à distance sur les équipements ciblés. La compromission à distance de système informatique et l’installation furtive du mouchard est devenue 
le vecteur d’attaque de choix car l'ingénierie sociale est risquée et l'accès physique à l’équipement (Evil maid attack) bien souvent compliqué à entreprendre. 

Ces nouvelles méthodes, proches de celles de séries TV, ne sont pas de doux rêves de scénaristes mais elles requièrent néanmoins la disponibilité et la mise en oeuvre de 0-day exploitables sur un ensemble assez large d’applications, systèmes d’exploitation et architectures matérielles.

Déjà, un processeur Baseband 
(System-On-Chip avec un RTOS qui gère l'interface radio mobile, l'accès à la SIM et les piles protocolaires) d'un smartphone haut de gamme bien connu a été pris la main dans le sac entrain d'exfiltrer des données à distance en accédant au système de fichiers en mémoire flash sur une partition dédiée au SoC Applicatif du smartphone. Ce cas de figure reste probablement une situation exceptionnelle, car l'exploitation de processeur Baseband avec un firmware propriétaire et fermée est une tâche plutôt complexe. Des méthodes plus accessibles sont disponibles en ciblant directement les processeurs Applicatifs des smartphones devenus de véritables ordinateurs grand public. Les régulières découvertes de malwares sur les « app stores » sont un exemple tangible d'une évolution des vecteurs d'attaque. 

En partant de ce constat, les agences gouvernementales telles que la NSA, le GCHQ, le BND, la DGSE et bien d’autres, se sont dotées d’expertises humaines pour développer les outils nécessaires en provoquant une certaine pénurie 
de profils d’experts. Malgré tout, cela semble être insuffisant. Pour compléter leur démarche, les grandes agences de renseignement se fournissent aussi auprès d’acteurs spécialisés comme Vupen Security.
Vupen a changé d’activité en 2010 pour rejoindre ce marché plus rémunérateur, avant de s’implanter dans le Maryland à Annapolis à une demi-heure de Fort Meade, lieu de villégiature de la NSA... Ce changement est intervenu dans un contexte défavorable pour la full-disclosure de vulnérabilités avec la jurisprudence, confortée par la cours de cassation, interdisant la divulgation publique d’exploits, alors cœur d’activité de Vupen. Depuis, l’actualité a confirmé que la NSA, le BND allemand ainsi que Hack Team étaient clients de Vupen. 



En mai 2015, Vupen a cessé d’exister puis, en juillet, est né Zerodium dont les fondateurs ne sont autres que Chaouki Bekrar et Isabelle Gorius anciens dirigeants de Vupen. A contrario de Vupen, Zerodium s’ouvre au marché des 0day en qualité d’acquéreur de vulnérabilités en lançant un programme Bounty de 1 000 000 $ pour la compromission d’IOS 9.  

Reward  $1.000.000

Le marché du 0day


Le marché du 0day possède ses propres règles et modes opératoires. Le vendeur est soit un indépendant (chercheur en sécurité), soit une société spécialisée comme Vupen. Les acheteurs sont principalement des cybercriminels ou des gouvernements (services de police ou de renseignement). Certains sont les deux ! Les gouvernements utilisent les 0days pour se prémunir de Cyberattaque mais aussi dans un cadre de programme de sécurité offensive. 

Certains de ces acteurs achètent des exploits pour permettre l’installation furtive de logiciels espions tandis que d’autres sont de simples courtiers de 0day. Les utilisateurs finaux sont toujours des gouvernements ou des cybercriminels de tout poil.

Le cadre législatif en France


En France, l’article R.226 du code pénal devenait insuffisant pour pratiquer des interceptions légales. De nos jours, il est simple de communiquer avec un PC ou smartphone sans passer par des services téléphoniques classiques fixes ou mobiles. En outre, il est possible de chiffrer ses communications de bout en bout. Il devient donc nécessaire pour la justice et la police de pouvoir intercepter les communications numériques à la source, sur ordinateur et smartphone. La législation a évoluée (LOPSSI, LPM, Loi renseignement, etc.) et les derniers arrêtés publiés en juillet 2015 vont permettre aux forces de police et de renseignement intérieur d’utiliser les fameux mouchards en France. 

La LOPPSI de 2010 a prévu que les services de police puissent intercepter les communications : « un dispositif technique ayant pour objet, sans le consentement des intéressés, d'accéder, en tous lieux, à des données informatiques, de les enregistrer, les conserver et les transmettre, telles qu'elles s'affichent sur un écran pour l'utilisateur d'un système de traitement automatisé de données ou telles qu'il les y introduit par saisie de caractères ». 

Comme un logiciel espion s’installe sur le système informatique à la source de la production des données, il devient possible d’intercepter toute information avant un éventuel chiffrement. 

En France, ces dispositifs doivent être homologués comme pour les interceptions légales téléphoniques. C’est régit par l’article R.226-3 du code pénal. Les logiciels de captation doivent être homologués, à défaut, tout contrevenant, même autorisé à pratiquer des écoutes, tombe sous le coup de la loi. Le ministre de la justice a publié une circulaire explicative là. 

L’arrêté du 4 juillet 2012 « fixant la liste d'appareils et de dispositifs techniques prévue par l'article 226-3 du code pénal » n’avait pas non plus été mis à jour depuis la loi contre le terrorisme. Cet oubli empêchait donc la commercialisation sous contrôle des mouchards. Ce nouveau manque a été corrigé au Journal officiel.
L’examen par la CNIL du projet de décret autorisant le traitement des données captées est

Voilà pour les mouchards, mais que sait-on du marché amont, celui du 0day qui permet de déployer des mouchards de manière furtive sur des systèmes informatiques distants ? 


Le marché du 0day

Après le piratage de la société italienne Hacking Team, la divulgation par Wikileaks des données techniques et commerciales exfiltrées met en lumière le marché des exploits 0day.

La tarification

Dans les documents de Hacking Team, les tarifs de vente d’exploits Flash sans exclusivité par Vitaly Toropov, (chercheur en vulnérabilité moscovite) sont fixés de 35 à 45 000 $, tandis que les ventes d’exploits avec exclusivité atteignent 3 fois ces prix. 

Vulnerabilities Brokerage International quand à elle, pratique des remise de 20% pour des exploits Firefox sans exclusivité.

La période probatoire

Lors de la conclusion de la vente, l’acheteur possède une garantie sous la forme d’une période probatoire au cours de laquelle il évalue le fonctionnement et la fiabilité de l’exploit contre les objectifs annoncés. Dans le cas des ventes de Vitaliy Toporov, cette période a été fixée à 3 jours. Vitaliy n’a pas assisté aux tests bien que cela semble être le modus operandi habituel. 

Le mode de paiement

Les modalités de paiement pour les deux premiers exploits de Vitaliy ont été de 50 % à la commande et 25 % à terme des deux mois suivants. Pour le troisième exploit, Vitaliy a demandé un paiement de 100 % à la commande en s’engageant à fournir un exploit en remplacement si un patch de sécurité intervenait avant deux mois. Hacking Team a refusé ces modalité de paiement. La confiance n’est pas de mise dans ces ventes...

Le livrable

Bah, le livrable est assez classique et consiste en une description du fonctionnement de l’exploit, accompagné du code source, d’une analyse technique décrivant : les prérequis de configuration de la cible, les vecteurs d’attaque, la mise en œuvre de l’exploitation et toute information pertinente. L’objectif du livrable est une compréhension et une prise en main rapide de l’exploit.



mardi 25 août 2015

UPnP IGD (Internet Gateway Device)

Présentation d'UPnP

UPnP (Plug and Play) est un standard accessible publiquement ici
Logo UPnP

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.

Le protocole 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 exploit UPnp IGD
Code python upnp_sploit.py



lundi 24 août 2015

Recherche de port série

Inspection visuelle du PCB

L’objet de ce nouvel article est de rechercher un accès au port série sur le PCB (Printed Circuit Board) d’un système embarqué comme un modem routeur.
Inspection visuelle du PCB
PCB d'un système embarqué
L’examen du PCB fait apparaître deux blocs de quatre contacts ressemblant fortement à des points d’accès au port série. Dans l'image ci-dessous, il s'agit de vias qui comportent des points de soudure.
Points de contact de port série ?
Contacts candidats au port série
Mais cela pourrait être de simple vias vides ou pin holes dans lesquels il faudrait souder des headers  (broches) ou utiliser des grip-fils pour connecter les points de contact.
via et broche à souder
Vias et headers à souder
Un via est un trou en métal dans le PCB qui est connecté à des pistes pour établir des liaisons électriques dans les couches de silicium.
via électronique, interconnexion sur la carte
Vias et connectique dans les couches de silicium

Le port série, console ou UART

Un port série possède traditionnellement quatre contacts :
  • GND (masse), 
  • Vcc (alimentation), 
  • Tx (transmission) 
  • Rx (réception). 
Les industriels ont besoin de disposer de ports série pour le reconditionnement ou le débogage de terminaux. Parfois, ces ports sont cachés dans d’autres interfaces physiques (prise jack, péritel, ..) ou disséminés sur le PCB. Le groupement de points de contact par quatre ainsi que la proximité du SoC (System on Chip) font de ces vias des candidats sérieux pour des ports série. Un suivi des traces (lignes métalliques) sur le PCB sur les deux faces du PCB peut confirmer cette supposition à moins que les lignes soient enfouies dans les couches de silicium. Dans ce cas, il faudrait pouvoir faire une radiographie aux rayons X.

L’intérêt d’un port série est d’offrir un port de debug pour accéder au chargeur de démarrage (bootloader), observer les messages du démarrage (bootloader, noyau de l'OS, application) et interagir avec le terminal via un shell ou un menu interactif en ligne de commande. Le port série offre aussi la possibilité d’extraire ou copier la mémoire ou de flasher des images en mémoire non volatile. Le port série est ainsi une cible de choix pour un attaquant.

La méthode de recherche du port série

La recherche du port série, habituellement appelé UART (Universal Asynchronous Receiver Transmitter), est réalisée avec un multimètre numérique.
Multimètre numérique sonore avec fonction hold
Multimètre numérique
La méthode de recherche consiste à procéder par élimination pour identifier le rôles des différents points de contacts possibles, puis leurs caractéristiques.
  1. L’inspection visuelle préalable permet d'identifier des contacts ou vias candidats sur le PCB.
  2. Lorsque des points de contact sont identifiés, il faut rechercher en priorité la masse (GND). Un test de continuité entre la masse sur le PCB (par exemple un shield ou une pièce métallique importante) et chaque point de contact permet de trouver celui qui est directement relié à la masse grâce au bip sonore continue émis par le multimètre.
  3. L'étape suivante consiste à identifier la broche Tx car celle-ci est facile à identifier lorsque des données sont émises. Pour cela, la séquence de démarrage est appropriée car elle génère un flux continu de données sur le port console. Une mesure de l’intensité avec le multimètre permet de détecter des fluctuations du voltage lors du boot, oscillant entre 0 et 3,6 Volts dans notre cas. Cette fluctuation est provoquée par la transmission des données.
  4. Il ne reste plus qu’à identifier Vcc et Rx. Lorsque les paramètres de la connexion UART sont identifiés grâce à Tx, (cf. pragraphe suivant) il suffit d’émettre des caractères vers l’un de ces contacts et vérifier l’écho en retour pour identifier la broche Rx.

L'adaptateur USB série

Pour se connecter au port série du PCB, un adaptateur USB série (FTDI 232) est nécessaire. Un modèle comme celui ci-dessous supporte 3,3V ou 5V et coûte quelques euros.
Adaptateur USB série FTDI
Adaptateur USB série
L'adaptateur série USB se connecte en USB sur l’ordinateur du pentesteur et sur les contacts GND, Tx et Rx du PCB.

Schéma de raccordement série
Schéma de raccordement d'un adaptateur USB série
Strap flexible grip-fil (pince)
Pince grip-fil
Les broches transmission et réception doivent être croisées entre l’adaptateur USB série et les ports sur le PCB du système analysé. Classiquement, les points de contact sont soit des vias destinés à recevoir des broches, soit des headers (broches) déjà présents. Dans le cas étudié, des points de soudure sur des vias étaient présents, mais l'accès au verso de la carte était inexploitable. Il a fallu utiliser des câbles grip-fil (strap flexible muni de pince) pour connecter l'adaptateur série.
Accès port série en action avec grip-fil sur soudure
Accès au port série avec câbles grip-fil

Le programme pilotant la liaison série

L’utilitaire utilisé sur le PC sous Linux de l'auditeur pour établir la connexion avec l’adaptateur USB série est minicom, qui utilise le pseudo périphérique /dev/ttyUSB0 pour communiquer.

$ sudo minicom –o –D /dev/ttyUSB0
Bienvenue avec minicom 2.6.1

OPTIONS: I18n
Compilé le Feb 11 2012, 18:12:55.
Port /dev/ttyUSB0

Tapez CTRL-A Z pour voir l'aide concernant les touches spéciales



Après quelques tentatives de connexion pour déterminer les caractéristiques de la communication, le port console de la carte s’avère utiliser une vitesse de transmission à 115 200 bauds, 8-bits de données, aucune parité et un bit de stop (en abrégé 115200 8N1). Le contrôle de flux matériel doit être désactivé.

L’étape suivante consiste à démarrer le modem routeur lorsque la connexion au port série via minicom est établie. Les séquences de démarrage suivantes s'affichent :
BCM3384A8 0002A080 memsys2g800x16 2p5bld1

SHMOO VER 1.17
MCB

PKID 20131007  050B6000  050B0000  04B4103E  00001C00 

S300001B7 
000011A0 
+00000004  >0000011A 
t00000020  0000003C 
@000000B4  ^0000001B 

RDEN W0 00000020  00000006  00000000 


RDLY W0 00000003 

RDQS W0
[...]
Sync: 0
MemSize:            256 M
Chip ID:     BCM3384Z-B0

BootLoader Version: 2.5.0beta1 Rev01 Release spiboot dual-flash memsys2g800x16 avs linux
Build Date: Sep  9 2014
Build Time: 19:36:18
SPI flash ID 0x010219, size 32MB, block size 64KB, write buffer 256, flags 0x2
Cust key size 128

Signature/PID: d06f


Image 1 Program Header:
   Signature: d06f
     Control: 0005
   Major Rev: 0003
   Minor Rev: 0000
  Build Time: 2015/1/13 08:19:06 Z
 File Length: 5024538 bytes
Load Address: 80004000
    Filename: EMTA62-1_NCC_1.2.3-20150113.bin
         HCS: c6fd
         CRC: 51a22add

Found image 1 at offset 30000

Enter '1', '2', or 'p' within 2 seconds or take default...

Conclusion

Voilà un accès au port série d'un modem routeur réussi. La suite est confidentielle car elle mettrait en péril le produit audité et ne respecterait pas la déontologie du ethical hacking. Sachez néanmoins qu’il a été possible de consulter le mapping de la mémoire non volatile, permettant ainsi de flasher les partitions contenant le firmware (bootloader, kernel et application) et d'extraire la clef indivuduelle du périphérique.