tothi/pwn-hisilicon-dvrExploit de preuve de concept et divulgation de vulnérabilité pour les appareils DVR/NVR HiSilicon hi3520d. Démontre une RCE via l'interface web, des identifiants backdoor et une analyse de débordement de tampon.
= Piratage de DVR HiSilicon Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Contents :image_width: 100%
[abstract] Ce rapport divulgue des vulnérabilités graves (avec une preuve de concept (PoC)) des dispositifs DVR/NVR construits avec le HiSilicon hi3520d et des systèmes sur puce (SoC) similaires. L’exploitation des vulnérabilités mène à une exécution de code à distance non autorisée (RCE) en utilisant uniquement l’interface web, entraînant la prise de contrôle totale de l’appareil exploité. En raison de l’absence de firmwares mis à niveau, l’utilisation de ces appareils n’est pas recommandée. Le fournisseur a été contacté avant décembre 2016, mais toujours aucune réponse. La date de publication de la divulgation est février 2017.
== préface
Il y a quelques années, j’ai acheté un DVR chinois bon marché sur eBay. Le logo de démarrage de l’appareil indique : « SECULINK - Security Monitoring ». En tant que passionné de sécurité informatique, j’ai décidé d’examiner de plus près l’appareil pour voir à quel point ce service de surveillance est « sécurisé ». En cherchant sur Google, j’ai trouvé des documents intéressants, mais en creusant plus profondément, j’ai découvert des problèmes beaucoup plus intéressants et beaucoup plus graves (0-day) concernant l’appareil.
Examinons l’intégralité de la session de piratage depuis le début. (Les nouvelles découvertes personnelles seront mentionnées au même titre que les anciennes, déjà connues.)
== exploration du DVR
D’abord, nous devons apprendre l’interface utilisateur officielle, puis creuser plus profondément, peut-être essayer d’obtenir le firmware. Les chances de trouver des vulnérabilités augmentent avec le firmware.
=== le DVR au premier coup d’œil
Le DVR destiné aux tests porte la marque « Seculink ».
image::./seculink_device.png[Appareil DVR Seculink]
Interfaces physiques disponibles :
Interfaces utilisateur officielles :
L’interface de configuration directement accessible est protégée par l’authentification utilisateur (nom d’utilisateur, mot de passe). Le superutilisateur par défaut est « admin », le mot de passe par défaut est vide.
Après avoir défini un mot de passe fort, l’utilisateur peut se sentir en sécurité en pensant que sa vue des caméras n’est pas accessible aux autres. Les gens redirigent souvent le port web (tcp/80) du DVR vers le WAN depuis leur LAN sécurisé afin d’accéder aux flux du DVR depuis l’extérieur (on peut le vérifier par exemple avec une recherche Shodan appropriée ;) ).
=== obtention du firmware
Il existe peut-être de nombreuses façons d’obtenir le firmware :
Bien que la dernière méthode (téléchargement) fonctionne ici et soit la plus simple, essayons la première, car elle donne aussi d’autres informations sur l’appareil.
=== scan des services
Faisons un scan complet des ports sur le DVR. Notez que le scan SYN (par défaut lorsqu’il est exécuté en root) est très lent en raison des paquets abandonnés, mais le scan complet par connexion TCP se termine en quelques minutes.
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
Résumé et tests manuels :
Notez que l’ouverture du flux rtsp nécessite également des identifiants.
Il convient de noter ici que l’appareil est probablement un système de type Linux.
La connexion au port 9527/tcp (avec un netcat brut) affiche la console
de l’application avec des messages de journalisation et une invite de connexion. La connexion avec n’importe lequel des
identifiants définis de l’application fonctionne. Saisir help après l’
invite donne une courte description des commandes de la console. La commande
shell semble être la plus intéressante. Oui, elle donne un shell root à
l’appareil. ;)
Notez qu’il s’agit manifestement d’un grave problème de sécurité, car aucun utilisateur (à faibles privilèges) de l’application ne devrait obtenir un shell root sur l’appareil automatiquement.
=== shell root
L’exploration de l’appareil dans le shell root (par exemple avec dmesg) montre
clairement que le DVR exécute un noyau Linux (version 3.0.8), possède
un CPU ARMv7 et que le modèle de SoC est hi3520d.
D’après la liste des processus en cours d’exécution (ps), il est clair que l’application
DVR est /var/Sofia, qui écoute également sur 34568/udp et
34569/udp en plus des ports tcp ci-dessus détectés par nmap
(netstat -nlup).
D’après la liste des disques montés (commande mount), il est clair que l’
image du firmware se trouve dans les périphériques /dev/mtdblockX (où X=0,1,2,3,4,5).
Le firmware est petit et donc limité, nous devons donc faire preuve de créativité si nous voulons copier des fichiers vers/depuis l’appareil. Heureusement, NFS est pris en charge : configurer un serveur NFS sur notre machine de bureau et le monter depuis le DVR résout le problème :
Maintenant, obtenir le firmware est simple :
Nous pouvons obtenir les fichiers (pas seulement les images brutes) :
=== interface telnet
Pour accéder à l’appareil via l’interface telnet (port 23/tcp),
il nous faut peut-être des identifiants du système d’exploitation. En regardant /etc/passwd, nous avons le
hash du mot de passe pour l’utilisateur root :
