hacktricks/network-services-pentesting/554-8554-pentesting-rtsp.md
2023-06-03 13:10:46 +00:00

7.8 KiB

Informations de base

Le Real Time Streaming Protocol (RTSP) est un protocole de contrôle de réseau conçu pour être utilisé dans les systèmes de divertissement et de communication pour contrôler les serveurs de diffusion en continu. Le protocole est utilisé pour établir et contrôler des sessions multimédias entre des points d'extrémité. Les clients des serveurs multimédias émettent des commandes de style VHS, telles que lecture, enregistrement et pause, pour faciliter le contrôle en temps réel de la diffusion multimédia du serveur vers un client (vidéo à la demande) ou d'un client vers le serveur (enregistrement vocal).

La transmission de données en continu elle-même n'est pas une tâche de RTSP. La plupart des serveurs RTSP utilisent le protocole de transport en temps réel (RTP) conjointement avec le protocole de contrôle en temps réel (RTCP) pour la diffusion de flux multimédias. Cependant, certains fournisseurs implémentent des protocoles de transport propriétaires. Par exemple, le logiciel serveur RTSP de RealNetworks utilisait également le transport de données propriétaire de RealNetworks (RDT).

À partir de Wikipédia.

Ports par défaut: 554,8554

PORT    STATE SERVICE
554/tcp open  rtsp

Informations détaillées

Tout d'abord, RTSP est un protocole similaire à HTTP. Il a une structure différente et des commandes de contrôle, mais son format est textuel et une fois que vous avez appris les bases des commandes et de leur interaction, il est assez facile à utiliser. La spécification de RTSP est assez simple. Voici un lien vers celui-ci:

RTSP - RFC2326

RTSP peut être accédé sans authentification (courant dans les appareils prêts à l'emploi) ou avec authentification. L'accès authentifié est similaire à HTTP dans la mesure où vous avez une authentification de base et une authentification Digest, toutes deux presque identiques à HTTP. Pour savoir si votre appareil est authentifié ou non, envoyez simplement une demande "DESCRIBE". Une demande DESCRIBE simple ressemble à ceci:

DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\n\r

Remarque: le " \r\n " supplémentaire est requis pour une réponse fiable. Certains systèmes accepteront le simple " \r\n ", mais la plupart ne le feront pas.

Cela peut être envoyé sur une socket brute. Tout comme HTTP, une réponse réussie indiquant un accès non authentifié sera disponible et contiendra un "200 OK". Dans ce cas avec DESCRIBE, il contiendra également tous les paramètres opérationnels de l'alimentation vidéo.

Si l'appareil nécessite une authentification, la réponse renvoyée contiendra "401 Unauthorized". La réponse indiquera également les mécanismes d'authentification disponibles. Si l'authentification de base est disponible, la chaîne de réponse contiendra une ligne d'information qui contient "WWW-Authenticate: Basic". Le reste des informations fournies avec l'authentification de base est largement sans importance pour effectuer l'authentification de base.

Si l'authentification Digest est requise, alors la réponse "401 Unauthorized" aura une ligne d'information contenant "WWW-Authenticate: Digest". Les informations avec la spécification Digest sont très importantes si vous allez effectuer une authentification Digest, alors ne les ignorez pas.

L'authentification de base est la voie à suivre, espérons que la réponse reçue indique qu'elle est disponible. Sinon, il existe trois méthodes différentes pour assembler un élément d'authentification Digest, donc Digest peut devenir problématique, surtout à l'aveugle (non authentifié). Le reste de cet article se concentrera sur l'authentification de base. Je pourrais écrire un article de suivi plus tard une fois que j'aurai décrypté la sauce secrète pour effectuer une authentification Digest à l'aveugle.

Pour formuler un élément d'authentification de base, il suffit de coder en base 64 <nom d'utilisateur> ":" <mot de passe> et de l'ajouter à la demande. Ainsi, une nouvelle demande ressemblerait à ceci:

DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r\n\r

Encore une fois, notez que la demande est terminée par le double " \r\n ".

La valeur YWRtaW46MTIzNA== est le nom d'utilisateur et le mot de passe concaténés codés en base 64 avec ":". Dans ce cas, j'ai utilisé "admin" / "1234". Un simple script python pour essayer cela ressemble à:

import socket
req = "DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r\n\r\n"
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.1.1", 554))
s.sendall(req)
data = s.recv(1024)
print(data)

Voilà ! Vous avez accès.

De: http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/

Énumération

Obtenons des informations sur les méthodes valides et les URL prises en charge, et essayons de forcer l'accès (si nécessaire) pour accéder au contenu.

nmap -sV --script "rtsp-*" -p <PORT> <IP>

Brute Force

Autres programmes utiles

Pour faire du brute force : https://github.com/Tek-Security-Group/rtsp_authgrinder

Cameradar

Cameradar vous permet de :

  • Détecter les hôtes RTSP ouverts sur n'importe quelle cible accessible
  • Obtenir leurs informations publiques (nom d'hôte, port, modèle de caméra, etc.)
  • Lancer des attaques de dictionnaire automatisées pour obtenir leur route de flux (par exemple /live.sdp)
  • Lancer des attaques de dictionnaire automatisées pour obtenir le nom d'utilisateur et le mot de passe des caméras
  • Générer des vignettes à partir d'elles pour vérifier si les flux sont valides et avoir un aperçu rapide de leur contenu
  • Essayer de créer un pipeline Gstreamer pour vérifier s'ils sont correctement encodés
  • Imprimer un résumé de toutes les informations que Cameradar a pu obtenir
  • https://github.com/Ullaakut/cameradar
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥