Récemment, j'ai commencé à recevoir une proposition pour vérifier le fonctionnement de divers services pour les erreurs et les vulnérabilités. Et dans de telles propositions, j'essaie de travailler pour le résultat et de tirer le maximum de plaisir du processus. Mais le résultat du dernier «projet» m'a choqué pour le moins.
On m'a demandé de tester le fournisseur d'hébergement.
Je ne dévoilerai pas le nom. Et dans mon histoire, j'utiliserai le nom Hoster. Avec le site lui-même, le service d'hébergement était tout à fait standard. Offres d'achat de certificats VDS, Domaines, SSL.
Tout d'abord, j'ai été surpris de la façon dont le compte personnel de l'utilisateur a été mis en œuvre. Une preuve de propriété de l'adresse e-mail lors de l'inscription n'était pas requise. Autrement dit, vous pouvez vous inscrire avec l'adresse e-mail steve.jobs@apple.com. Ou mieux encore, support@hoster.com.
Mais heureusement, par analogie avec
cette histoire , la divulgation d'informations sensibles du service support desk n'a pas eu lieu.
Cependant, cela s'est produit lorsque j'ai créé une demande de support de test et vérifié immédiatement la disponibilité des demandes d'ID voisines pour d'autres demandes de support. Étonnamment, ils étaient disponibles. Et il a été possible d'observer qui et quoi s'inscrit auprès de l'hébergeur. Et à quels problèmes les utilisateurs sont-ils confrontés? En général, la vulnérabilité IDOR standard, qui maintenant ne surprendra personne. Bien sûr, elle a été immédiatement corrigée.
Il y avait aussi plusieurs endroits avec Stored XSS. Il y avait également Blind XSS qui m'a retourné le cookie de l'administrateur de service. Grâce à ce XSS, j'ai pu découvrir où se trouve l'interface administrateur, et en général, elle a révélé beaucoup d'informations intéressantes.
- Combien d'utilisateurs actifs.
- Combien de domaines sont contrôlés.
- Combien de VDS sont déployés.
Et bien plus encore ...
Il y a eu diverses erreurs avec les jetons CSRF, qui ont permis au nom de l'utilisateur de faire beaucoup de choses dangereuses dans votre compte. Et s'il y avait des endroits où les jetons CSRF étaient transférés, alors ils étaient simplement transférés. Personne n'avait prévu de les vérifier sur le backend. À la suite de mes découvertes, une partie de la fonctionnalité a été complètement désactivée. Par exemple, il a été décidé de supprimer temporairement l'authentification 2FA, car elle n'a pas eu lieu dans la mise en œuvre.
Au cours de mon travail, j'ai fait attention non seulement aux problèmes de sécurité, mais aussi aux erreurs de mise en œuvre ou aux problèmes de fonctionnement de certaines fonctionnalités. J'aime QA ne pouvait pas passer comme ça. En conséquence, mon outil de suivi des problèmes a atteint le chiffre - 22. Autant de problèmes dans l'ensemble que j'ai trouvés et résolus (extrêmement remarquable).
Les résultats ont été plus que convaincants. Et j'avais déjà prévu de terminer ce projet. Mais pour une raison quelconque, je me suis de nouveau souvenu du problème du manque de confirmation du propriétaire de l'adresse e-mail lors de l'inscription. Et il a commencé à trouver des situations dans lesquelles cela peut créer un maximum de problèmes pour l'hébergement et ses propriétaires. À un moment donné, j'ai commencé à penser aux relations des propriétaires de ce service d'hébergement avec d'autres projets de la même entreprise que je connaissais. Après quelques minutes, j'ai enregistré un compte avec l'adresse e-mail d'un autre projet de la même entreprise (que ce soit support@example.com). J'ai ensuite réussi à lier le domaine example.com à mon compte créé suppot@example.com. Mais je ne pouvais toujours pas contrôler le contenu du domaine lié.
Mais il pourrait parfaitement pêcher avec des e-mails au nom du service example.com.
L'origine des lettres de réponse n'est pas claire. Parce que je me suis répondu à une telle lettre test. Mais je n'ai pas reçu la réponse elle-même. Il a probablement disparu en réponse au véritable propriétaire du compte de messagerie support@example.com.
Et puis quelque chose s'est produit pour lequel j'ai décidé d'écrire cet article.
J'ai réussi à résoudre le sous-domaine oublié. Vulnérabilité de prise de contrôle de sous-domaine classique. Vous pouvez en savoir plus à ce sujet
ici .
Je ne sais pas pourquoi, mais j'ai essayé d'ajouter une liaison à un domaine inexistant. Et je l'ai fait.
Le sous-domaine a été ajouté avec succès et je pouvais contrôler le contenu de ce sous-domaine. Et le contenu a été affiché.
Mais ça ne peut pas être pareil! Comment ça?! Après tout, la vulnérabilité de reprise de sous-domaine classique ne fonctionne qu'avec les sous-domaines existants.
Cette situation ne me convenait absolument pas. Autrement dit, j'ai pu contourner les niveaux de validation de mon attitude envers example.com, qui n'est jamais le mien (probablement grâce à
exemple .com au nom de mon compte). Mais comment est-il possible d'ajouter des sous-domaines et de les contrôler sans vérifier les composants dans les enregistrements A, TXT, CNAME ...?
Habituellement, je vois cela - nous vous ajouterons un sous-domaine, seulement vous prouvez que vous pouvez le faire. Allez ajouter à TXT ce hachage
ololopyshpyshpyshbdysh123 .
Mais il n'y avait rien de tel. Vous voulez un sous-domaine admin.example.com? Pas de problème!
Comme si une vulnérabilité Subdomain Takeover V2.
En raison de la capacité de communiquer rapidement avec les propriétaires du service d'hébergement testé - Pandora m'a ouvert cette boîte.
Il s'est avéré ce qui suit. L'hébergement a fonctionné via CloudFlare. Et il a travaillé d'une manière très rusée.
Je vais essayer d'expliquer en termes simples.
En gros, je vous le dis, venez à moi, je vous accueillerai. Déléguez-moi vos domaines.
Et puis j'envoie tous les appels entrants sans discrimination à CloudFlare, les considérant comme corrects.
Et si vous m'avez fait confiance avec le domaine vasya.ru, et qu'un voisin est venu zapiliter le site avec test.vasya.ru et me l'a également donné pour l'hébergement, alors mon serveur, ayant accès à CloudFlare et ayant déjà des droits sur vasya.ru, a ajouté le troisième niveau sans problème domaine pour un voisin et toutes les règles, rapidement et sans aucun doute. Pour tous les DNS, les informations correctes de CloudFlare sont arrivées. Et CloudFlare me fait confiance.
Bien entendu, les hébergeurs configurent généralement leurs services DNS. Mais ici, il s'avère qu'ils ont triché et transfèrent simplement tout à CloudFlare à partir d'un seul utilisateur.
Nous avons donc une prise de contrôle de sous-domaine god_mode. Certes, cela ne fonctionnait qu'avec les adresses que l'hébergement contrôle déjà. Mais en conjonction avec le panneau d'administration du service précédemment découvert - cela pourrait jouer un tour à la fois à l'hôte et aux clients du service d'hébergement.
À l'heure actuelle, presque toutes les vulnérabilités et erreurs critiques ont été corrigées. Et j'espère que personne ne décidera de ces délices architecturaux après avoir lu cette histoire.
PS: Les commentaires et suggestions sur l'article sont les bienvenus. Un merci spécial à
Patriot2k pour ses conseils techniques! Je suis également ouvert aux suggestions pour tester quelque chose d'intéressant.