Une fois, j'ai piraté l'un des serveurs de télégramme. Non pas que ce soit quelque chose d'intéressant, et les vulnérabilités elles-mêmes sont standard. Le fait que les télégrammes soient liés à la sécurité et pourquoi au fil des ans personne n'a exploité les vulnérabilités est plutôt surprenant. Mais celui qui ne fait rien ne se trompe pas!
En mai 2017,
kyprizel a attiré l'attention sur le fait que le bureau de télégramme peut télécharger des archives ZIP sur son serveur
tdesktop.com . Comme il s'est avéré plus tard, non seulement ZIP, mais à l'intérieur il y a des informations sur le crash de l'application, afin que le développeur puisse étudier dans quelles circonstances le crash s'est produit. De plus, le développeur y accède via l'interface Web, à en juger par le formulaire d'authentification. J'ai ajouté l'hôte aux notes et j'ai oublié en toute sécurité.
Je me suis souvenu de lui après environ un an lorsque les études à venir ont été discutées lors d'un chat. À cette époque, le fichier racine était error_log, dans lequel, comme vous l'avez peut-être deviné, des erreurs ont été écrites. Au minimum, il y avait des chemins de fichiers complets, mais en plus de cela, l'erreur préférée est «Vous avez une erreur dans votre syntaxe SQL». Mais nous sommes tous paresseux, et en général, j'essaye de ne pas participer, donc tout reste tel quel.
Une autre année s'est écoulée, j'ai été invité à prendre la parole lors de la conférence
#PartyHack à Kazan. Et quand vous n'avez pas la matière pour parler, vous regardez les notes. Qu'avons-nous là-bas? Hôte suspect sur Telegram.
Comme le serveur utilisait PHP, comme en témoigne crash.php, j'ai décidé de parcourir un peu les fichiers avec cette extension, puis je suis tombé sur info.php, où se trouvait le contenu de la fonction phpinfo (). La première chose que j'ai remarquée a été d'utiliser le serveur Web Apache. Comment ça? Le télégramme entier est nginx, et voici Apache! Et qui utilise apache en 2019?
Qu'est-ce qui vous vient à l'esprit lorsque vous entendez Apache? Je me souviens immédiatement de mod_status, qui est construit avec lui par défaut. Ce module génère une page avec l'état actuel du serveur, sur les ressources système, les demandes du serveur et la vitesse de leur traitement. Le plus souvent, le chemin d'accès est / server-status, rarement juste / status. Pour comprendre à quel point cette erreur administrative est populaire, rappelez-vous simplement qu'elle s'est accrochée au site Web apache.org pendant de nombreuses années
Pendant de nombreuses années, j'ai collecté des chemins vers des fichiers et des répertoires potentiellement dangereux dans le projet fuzz.txt , donc l'état du serveur était naturellement là.En général, il convient de noter dans l'état du serveur qu'il affiche également les adresses IP des clients qui envoient des demandes au serveur. Mais dans ce cas, toutes les demandes provenaient de 127.0.0.1 au domaine virtuel preston-desktop.com. Nginx à l'avant vient de transmettre toutes les demandes à l'apache local, il n'y a donc pas eu de divulgation d'informations sur l'utilisateur. Cependant, cela valait la peine de mettre l'état du serveur à surveiller, voici un
petit script fait sur le genou qui met des lignes uniques dans la base de données sqlite. Pendant une courte période, de nombreux liens uniques ont été collectés, mais il s'agissait essentiellement de demandes de mises à jour (indiquant la version), et il n'y avait presque pas de téléchargements. Après un moment, j'ai vu l'administrateur.
Malgré le fait que notre longueur de ligne soit limitée, les journaux montrent que l'administrateur télécharge parfois les journaux d'automne pour une analyse plus approfondie, et les paramètres amusants __login et __token y sont passés. Et les requêtes POST dans la capture d'écran sont les miennes.
En regardant la source, vous pouvez remarquer deux méthodes intéressantes.
Le premier est
query_report , qui a des options supplémentaires apiid, version, dmp et plateforme. Il retourne si plus de journaux sont nécessaires sur le crash de l'application, ou si la version est déjà fraîche et des erreurs sont connues. Le mécanisme a été créé de manière à ne pas trop en obtenir, mais à ne corriger que le réel.
Le deuxième est le
rapport lui-même. Déjà sans paramètres supplémentaires. Si un mot est revenu à la demande précédente qui indique la nécessité d'envoyer un vidage, le fichier est envoyé.
Là, vous pouvez voir que les données sont envoyées en utilisant plusieurs parties, où le nom de fichier est report.telegramcrash, et son application de type de contenu / flux d'octets.
Ainsi, vous pouvez essayer de télécharger vos propres fichiers et tester les vulnérabilités associées au déballage de ZIP et d'autres éléments de téléchargement.
Et j'essaierais en outre d'envoyer une charge différente pour trouver au moins une sorte de vulnérabilité, sinon pour une astuce. Si nous substituons les noms de paramètres connus d'une autre demande pour la méthode de rapport, dont les valeurs valides que nous avons prises de l'état du serveur, nous pouvons essayer d'utiliser une attaque secrète de tous les pirates Web.
En utilisant la puissance du mégazord (guillemet simple) dans le paramètre plateforme, il a été possible d'observer le comportement anormal de la ressource.
Il y a un guillemet - une erreur, pas de guillemet - tout va bien. Pour vérifier la validité, vous pouvez écrire une expression logique, par exemple platform = mac 'AND' a '=' a. La réponse est terminée, comme avec un téléchargement de fichier réussi.
Eh bien, pas étonnant qu'ils soient venus avec l'automatisation, donc je suis en train de découpler sqlmap, qui est déjà devenu poussiéreux de l'inaction. Anticiper les questions - tout le reste était bien configuré, l'utilisateur dans le SGBD n'est pas privilégié.
Envoyée à security@telegram.org, un peu plus tard, j'ai reçu la lettre tant convoitée concernant l'octroi de 30 000 $.
Je plaisante, 2000 $ pour sqli et 500 $ pour phpinfo et l'état du serveur, ce qui est également bon. Et les loups sont en sécurité et les moutons sont pleins, ou vice versa.
Je n'ai pas piraté les utilisateurs (votre correspondance est sûre), je n'ai pas pu développer l'attaque plus loin, un serveur avec des vidages d'utilisateurs aléatoires (à savoir des vidages sur incident sans informations sur l'identifiant dans le télégramme, le téléphone, les messages et les chats) est une valeur douteuse. En théorie, il serait possible de pomper les accidents et de les étudier et les exploiter vous-même. Après avoir appris comment les télégrammes sont lâchés, il a été possible de les retirer de la victime, puis d'étudier tout ce qui peut être extrait des journaux d'automne, s'ils pouvaient être téléchargés via cette injection.
Original unique.