Après mon premier
article publié sur codeby, qui est entré dans le top 3 des publications de la semaine, j'étais très motivé pour écrire le suivant. Mais la 11e année impose des restrictions sur le temps libre pour préparer l'examen et les olympiades. Par conséquent, j'écris la seconde seulement après quelques mois après avoir
quitté toutes les Olympiades .
Cette publication parlera d'un cas intéressant où une vulnérabilité trouvée sur une ressource impliquait une chaîne de recherche sur plusieurs autres sites.
Début
Tout a commencé par la vérification du site d'un grand fabricant de produits forgés. Le compte personnel de l'utilisateur n'était pas là et la zone de recherche de vulnérabilité n'était pas trop étendue.
Lors du test du formulaire de soumission de commande, un certain nombre de vulnérabilités y ont été découvertes.
Tout d'abord, il s'agit d'un XSS stocké assez standard dans les données de l'acheteur, avec lequel cet enchevêtrement s'est étiré. XSS est standard, et l'absence d'un indicateur «httponly» sur un cookie n'était clairement pas standard. Plusieurs fois, j'ai reçu des cookies de divers sites, mais je n'ai jamais reçu d'autorisation, et j'ai commencé à douter que dans la nature, il y avait des sites qui n'utilisaient pas le drapeau «httponly», car son utilisation réduit considérablement le risque d'attaques XSS. C'était d'autant plus surprenant de rencontrer un tel événement sur le site d'une grande entreprise. Mais, il s'est avéré que le service qui a permis cette surveillance était beaucoup plus important que ce à quoi je m'attendais. Mais plus sur cela après.
J'ai substitué les cookies reçus et me suis connecté au compte crm du système du site (je n'ai pas pu résister, pour la première fois, j'ai eu de la chance). Les droits n'étaient pas administrés, mais ils étaient suffisants pour accéder à toutes les statistiques sur les commandes, y compris et les données clients.
J'ai fait des captures d'écran pour prouver l'existence d'une vulnérabilité et envoyé un rapport. Plus d'une semaine s'est écoulée et je n'attendais plus de réponse. Selon les statistiques, si vous ne recevez pas de réponse dans les trois jours, vous pouvez les oublier. Mais après 8 jours, une réponse inattendue est venue. Et plus encore, ils ont été les premiers à me payer pour la vulnérabilité trouvée.
Pour revenir au test du formulaire de soumission de commande, j'ai également trouvé une vulnérabilité iDOR qui vous permet de modifier le prix de la commande en modifiant les paramètres «json_order [0] [price]» et «json_order [0] [total]» dans la requête POST domain.ru/shop.php . La substitution du lien de commande dans la même requête dans le champ json_order [0] [href] a conduit à une RFI.
Aucune réponse n'a été reçue au message concernant les nouvelles trouvailles ...
Continuation
Sur ce site de GRC, le système n'était pas auto-écrit, mais était fourni pour le paiement par un service bien connu. Après leur erreur avec le cookie, il était logique de supposer qu'il y aurait d'autres vulnérabilités.
Si le script que j'ai envoyé via le bon de commande a fonctionné, il n'y a pas eu de validation de champ à la fois sur le site souhaité et dans le système crm. x2. Par conséquent, après avoir reçu un compte d'essai, j'ai commencé par rechercher les champs vulnérables à xss.
Après de longs voyages à travers le vaste système de GRC, plus d'une douzaine de champs avec une validation insuffisante ont été identifiés. Quelque part, vous pouviez insérer directement la balise de script, quelque part vous deviez utiliser des scripts en ligne du type "onmouseover = alert ()". De plus, à certains endroits, il était possible d'incorporer un script, mais à certains endroits, je me demande quelle logique ils ont été guidés par l'ajout de filtrage à certains endroits et pas à d'autres? Du point de vue de l'objectif logique des champs, je n'ai pas vu de modèle. Dans certains endroits, où presque tout le monde ne va pas, tout a bien fonctionné, mais, par exemple, ils n'ont pas pris la peine d'ajouter un filtrage au nom de la contrepartie.
La plupart des domaines vulnérables n'ont pas pu être influencés de l'extérieur. Ils ne peuvent être utilisés que par les employés pour renforcer leurs droits dans le système, ce qui est également important.
Sur xss c'était fini, il était possible de passer à des choses plus intéressantes.
Je n'ai jamais recherché de vulnérabilités CSRF auparavant, les sites que j'ai testés n'étaient pas dans la classe contre laquelle ils utiliseraient le phishing. Par conséquent, je ne voulais pas déranger ni les propriétaires de sites présentant des vulnérabilités qui ne seraient jamais utilisés contre eux. C'était un cas radicalement différent. Ce système de GRC était populaire, il était également utilisé par les grands magasins en ligne, et il y avait la possibilité de connecter les caisses des points de vente au détail hors ligne, ce qui rendait le problème de sécurité encore plus important.
Étonnamment, il n'y avait aucune protection contre la CSRF. Il a été possible d'envoyer des demandes, les contrôles n'ont été effectués nulle part.
- Changer les informations de compte? - s'il te plait
- Changer le nom et le prix des marchandises? - Pas question
Dans le même temps, les cookies contenaient quelque chose appelé "csrftoken".
Ensuite, j'ai toujours pensé, quel est l'intérêt de mettre le jeton csrf dans les cookies? Sur Google, j'ai découvert qu'il existe un moyen plutôt pratique de se protéger contre csrf avec un jeton dans les cookies et de le dupliquer dans une demande de publication, dans laquelle vous n'avez pas besoin de stocker le jeton sur le serveur. Plus de détails
ici .
Mais dans notre cas, seulement la moitié du travail a été effectué, le jeton a été placé dans des cookies et il était absent dans les demandes au serveur. Et plus encore, sa suppression complète des cookies n'a rien changé. Pourquoi a-t-il été ajouté?
En conjonction avec le csrf découvert, notre xss, non accessible auparavant de l'extérieur, obtient une seconde vie. Après tout, nous n'avons pas besoin d'accéder à notre compte pour modifier les champs vulnérables.
De plus, grâce à la substitution du type mime du fichier, il était possible de télécharger des fichiers arbitraires sur le serveur. Mais le serveur a été configuré correctement et les scripts php n'y ont pas été exécutés.
Plus intéressant encore. Toutes les données sur les marchandises que la boutique en ligne a extraites de crm. C'est-à-dire nom, description, photo. Le lien vers l'image du produit était «yyyy.domain.ru/file/get/id=xxx». Pour que la boutique en ligne puisse prendre des images, ils doivent avoir des droits de lecture pour tout le monde. 122.
Après avoir vérifié les chemins le long desquels d'autres fichiers plus privés sont stockés, j'ai vu la même URL. Cela ne semble pas surprenant, ils ont probablement d'autres droits d'accès. Pas plus bas que 022. Mais, la réalité s'est avérée être légèrement différente, ils ont également eu un accès gratuit pour les utilisateurs non autorisés.
- Avez-vous fait une demande d'importation de données de commande dans un fichier exel? - Génial, maintenant tout le monde peut le télécharger.
Peut-être que cet identifiant ressemblait à "yt5bjFb54hb # HJ% $ p" et n'a pas cédé à la force brute? Non non plus. Tous les fichiers d'identification avaient un format numérique et étaient de l'ordre de plusieurs milliers. Protection contre les brutus, je ne l'ai pas non plus remarqué. Après avoir scanné tous les identifiants de 1 à 10000 obstacles ne se sont pas rencontrés. Répété plusieurs fois, personne n'était intéressé par une telle activité.
Ils ont répondu à mon rapport en 3 jours.
Concernant l'absence de drapeau, httponly a déclaré qu'il manquait "Apparemment il y a longtemps, depuis la mise à jour de la version php". Allumé le même jour.
Selon xss, ils ont dit que tout le monde sait que le filtre a été désactivé au début de l'été (à l'époque, c'était déjà en août), cela n'explique bien sûr pas pourquoi il y avait un filtrage quelque part, mais pas quelque part, mais supposons que nous ne l'avons pas remarqué incohérence. Ils ont également assuré que le filtre serait lancé dans quelques jours. En fait, il s'est avéré que dans quelques mois. Mais ici, je les comprends parfaitement: j'ai également prévu de commencer à préparer les examens dans quelques jours ...
Le téléchargement de fichiers arbitraires sur le serveur ne les préoccupait guère, car ils ne sont pas exécutés sur le serveur, ce qui signifie qu'il n'y a rien à craindre. Ce n'est qu'au moment de la rédaction de l'article, j'ai eu une idée si un site qui est déjà sur un hébergement autre que crm essaie de prendre une image du produit pour la vitrine, mais reçoit un script php, l'exécutera-t-il? Ou du fait qu'il est destiné à la balise img, sera-t-il traité uniquement comme une image? Ou cela dépend-il des paramètres du serveur? Veuillez répondre aux personnes compétentes.
La réponse au rapport csrf s'est avérée assez intéressante. Ils ont répondu par une question: "Que considérez-vous comme un jeton de protection contre les attaques csrf?" Vraiment, de quoi je parle?
Ils ont dit à propos de l'accès gratuit à tous les fichiers qu'ils n'avaient pas pris en compte ce moment. Fermé immédiatement.
Je dois dire que c'était la seule fois où je m'attendais vraiment à recevoir une récompense en espèces. Le site est grand, sauf crm il n'y a toujours pas un projet payant. Magazine en ligne populaire. Mais il n'a reçu qu'une reconnaissance verbale.
Je dois les remercier, je suis devenu encore plus calme sur la question du paiement. Travailler dans un but de gratitude sous quelque forme que ce soit ne mènera finalement à rien. Vous vous habituerez à tous les éloges et autres honneurs, et ils cesseront de vous satisfaire. Et si vous avez tout fait pour eux, le sens de faire quelque chose sera perdu. Et vous ne pouvez pas perdre le plaisir du processus de votre activité, résoudre de nouveaux problèmes, créer quelque chose de nouveau. Travaillez pour le plaisir, même si cela peut sembler banal. Le travail au cours duquel vous ne remarquez pas comment les heures passent, comment le soleil a réussi non seulement à dépasser l'horizon, mais à se lever à nouveau à cause de cela.
'' '
Nous sommes satisfaits des petits, le bonheur n'est pas en gros argent
"Faites ce que vous aimez" - apprécié dans nos cercles
'' '© Kolya Manyu - Chaque jour
Fin
Dans le cadre du support technique du site précédent, le système de réception de tickets tiers UserEcho a été utilisé. Je n'ai pas manqué de le vérifier. Dans les rêves, bien sûr, il était possible d'avoir la possibilité de lire n'importe quel billet privé. Naturellement, je n'ai pas réussi. Je devais me contenter de peu.
Lors du test de l'API fonctionnant avec des tickets, aucune anomalie n'a d'abord été remarquée, le droit de ne pas regarder chez quelqu'un d'autre, de ne pas y souscrire n'était pas possible. Mais, après une étude plus approfondie du site, il s'est avéré que les développeurs ont fait une petite faille.
Dans le profil, vous pouvez trouver une section sur la gestion de vos billets, elle indique ceux auxquels vous êtes abonné ou auxquels vous étiez déjà abonné.
Si nous envoyons une demande de désinscription du ticket de quelqu'un d'autre, nous sommes, comme prévu, informés que nous n'avons pas de droits sur cette action. Mais en même temps, il est inclus dans notre liste de billets, comme l'un de ceux pour lesquels nous étions abonnés plus tôt. Ainsi, nous avons la possibilité de connaître son nom et son URL au format "ticket_name_name_in_translate". Ce mal, bien sûr, n'en a pas porté. Dans de très rares cas, il sera possible d'apprendre quelque chose d'important et de précieux du nom. Mais c'était mieux que de ne rien avoir du tout.
Après quelques semaines, le bug a été corrigé.
Je remercie tous ceux qui ont lu jusqu'au bout!