Bonjour à tous!
Je m'appelle Andrey. Depuis 10 ans, je recherche des vulnérabilités dans divers services Web. et prêt à partager mes connaissances avec vous. En mai dernier, j'ai fait un rapport à ce sujet lors de la conférence de
Heisenbug , et maintenant je suis prêt à partager mes connaissances ici aussi, dans les espaces ouverts de Habr. Commençons donc.
Une fois, j'ai
trouvé une vulnérabilité sur les serveurs de la célèbre société Facebook. Les gars ont oublié de mettre à jour ImageMagick (la bibliothèque pour le traitement d'image) et l'ont payé :) Avec cet exemple, je voulais montrer que nous sommes tous des gens et que nous pouvons tous faire des erreurs, peu importe dans quelles entreprises et dans quelles positions nous travaillons. Le seul problème est que ces erreurs peuvent entraîner toutes sortes de risques.
Plus votre application / site Web / outil est compliqué, plus il est probable que quelque chose tourne mal.
Vous devez vérifier les vulnérabilités. Il est stupide de ne pas le faire du tout.
Les éléments suivants peuvent être des étapes de vérification des applications Web:
- Préparation:
- Définissez les points d'entrée - en fait, d'où les données peuvent provenir dans l'application;
- Identifier le stock technologique;
- Déterminez quelles vulnérabilités il est logique de vérifier;
- Vérification Vous devez vérifier toutes les vulnérabilités qui s'appliquent à l'étendue de la technologie de votre application Web;
- Analyse de code. Ne soyez pas paresseux, ne sautez pas cet article. Dans certains cas, sans accès au code, il est difficile de trouver des vulnérabilités, ce qui vous permet également de contourner le filtrage qui peut être intégré dans votre application.
Je vais parler de tout cela en détail.
Alors, préparation. Je ne me concentrerai pas sur tous les types de vulnérabilités, sinon la quantité de texte dans l'article dépassera toutes les tailles imaginables et inconcevables. Je vous conseille de commencer à apprendre à partir de la
liste des dix meilleurs projets OWASP . Toutes les quelques années,
le consortium OWASP forme une liste des vulnérabilités les plus pertinentes à l'heure actuelle. Nous en examinerons quelques-unes en détail.
Xss
XSS (cross-site scripting) est une attaque contre un utilisateur qui permet à un attaquant d'exécuter un script arbitraire dans le contexte du navigateur de sa victime. Le plus souvent, cela implique la mise en place de balises
HTML et de scripts
JS .
Exemple: à un moment donné, un tel service existait sur
Yahoo! Ad Exchange Le formulaire de récupération de mot de passe avait un paramètre "
URL de retour ". Il pourrait indiquer à quelle page retourner après le processus de réinitialisation du mot de passe. Si vous y insérez l'un ou l'autre vecteur conduisant à l'exécution du code
JS , vous pouvez obtenir tous les
cookies de l'utilisateur. Nous analyserons comment cela se produit et pourquoi.
Voici le vecteur lui-même. Tout à la fois:
Pour faire une injection, vous devez sortir du contexte de la variable dans laquelle nous nous trouvions par défaut (par défaut - c'est ce que le programmeur a supposé quand il a écrit le code).
Voici la valeur d'origine. Ceci est un comportement valide.
Nous voyons que returnURL = / login.jsp
Cela tombe dans la valeur de la
balise <input> .
Si nous ajoutons un guillemet après
jsp , nous verrons que la syntaxe
HTML a coulé. Heureusement, le langage
HTML n'est pas strict, l'analyseur va sauter et il n'y aura aucun problème:
Ajoutez un autre caractère. Ici, nous sommes complètement hors du contexte de la
balise <input> :
Maintenant, nous ajoutons l'ouverture de la
balise <svg> , et nous obtenons deux balises valides en termes de syntaxe:
Ensuite, ajoutez le vecteur d'attaque entier:
Dans ce cas, l'image
svg est dessinée. En utilisant le gestionnaire
JavaScript "
onload ", nous exécutons une alerte avec les
cookies du document. C’est tout! L'attaquant a reçu vos
cookies .
Si dans la preuve nous ne montrons que l'alerte elle-même, il ne sera pas difficile pour un attaquant d'envoyer des cookies à un serveur qu'il contrôle et, dans le pire des cas, de saisir votre compte. Voyons à quoi ça ressemble à nouveau:
Il existe également plus de vecteurs d'attaque sur le client. Je vais donner quelques exemples avec une brève description. Mais vous devez d'abord comprendre comment sortir de son contexte:
- Hors contexte. Ces 6 caractères aideront à sortir non seulement du contexte de la valeur du paramètre HTML, mais aussi de beaucoup d'autres:
-> '">
Eh bien, en fait, les deux vecteurs d'attaque les plus simples:
- Insérez des liens en particulier. Mais dans le cas général - changer l'apparence de la page. Par exemple, ils peuvent incorporer du code html dans votre page et afficher une fausse fenêtre demandant des données:
La chaîne " aaaa " pointe vers google.com . Vous pouvez voir que le lien est rendu sur la page, mais vous ne pouvez pas le voir, mais cela n'annule pas sa présence dans le code. Dans les deux cas, le dossier peut être considéré comme terminé; - Exécution de script, par exemple, interception de cookies utilisateur:
Où et comment rechercher XSS?
Tout d'abord, recherchez les fonctions de sortie des informations / données sur la page. Analyser quelles données y parviennent? Voici le concept d'une
source non fiable . Et tel est tout d'abord
votre utilisateur . Les vecteurs d'attaque peuvent être contenus dans n'importe quelle autre source: flux RSS, autres services, externes et internes.
Voici un exemple concret: je travaille pour SEMrush IT. Nous développons une plateforme en ligne, qui est un outil universel pour les spécialistes du marketing en ligne. Donc, un service a enregistré des données pour nous, l'autre en a déduit, chacune des équipes s'est appuyée les unes sur les autres, il s'est avéré que sur le deuxième service,
XSS est survenu en raison du manque de traitement approprié des données de sortie, et la première commande n'a pas jugé nécessaire de filtrer les données entrantes en aucune façon et les a gardés "
tels quels". Conclusion: si vous ne savez pas comment telle ou telle donnée est stockée, elles doivent être considérées comme non fiables. Ou convenez à l'avance de qui stocke et comment, filtre, affiche les données.
Si vous disposez déjà de données provenant de sources non fiables, je recommande:
- Etudier le filtrage des données entrantes;
- Examinez le contexte de la sortie. Dans tous les cas, XSS ne peut pas être exécuté, même en l'absence de filtrage. Par exemple, si le type de contenu de la réponse est: text / plain;
- Ne vous fiez pas au filtrage des cadres des systèmes de sécurité intégrés.
Injection SQL
Implémentation du code SQL (injection SQL anglaise) - l'introduction dans la requête de la base de données d'instructions qui n'y étaient pas impliquées.
Exemple (pas de la vie, mais aussi bon):
Nous voyons un script qui affiche une table utilisateur. Dans ce cas, il peut effectuer une recherche par nom d'utilisateur.
Sur la droite est montré à quoi ressemble la requête vers la base de données, et sur la gauche est le résultat du script dans le navigateur.
De plus, afin de tester et d'obtenir au moins un résultat primaire, nous insérons deux guillemets dans la valeur du paramètre name. Simple et double:
On voit que du point de vue de la sortie, tout s'est effondré, le tableau a complètement disparu. La demande obtient également les 2 guillemets supplémentaires. Toute la syntaxe de la requête
SQL est violée.
Si nous prenons et ajoutons une telle construction à la valeur du paramètre (
éd .: regardez dans la boîte jaune ), nous obtenons une demande absolument valide. La sortie de la page est complètement identique à la première requête, qui ne comprenait pas d'injection:
Afin de vérifier pleinement qu'il existe une vulnérabilité, nous ajoutons un deuce au lieu de l'unité:
Il s'avère que la demande devient fausse, du point de vue de la logique booléenne et, par conséquent, ne contient pas de données. Cependant, contrairement au moment où nous avons eu une erreur, nous avons la sortie de la table elle-même.
Afin de ne pas répertorier tout ce qui peut se trouver dans différents moteurs de base de données et requêtes de différents types, j'ai tout réduit à une seule ligne:
C'est quelque chose que vous pouvez essayer d'entrer dans le paramètre, puis, selon les différences dans les réponses, essayer de comprendre ce qui se passe, y a-t-il une vulnérabilité ou non? Environ 80% des cas que vous pouvez couvrir avec cette manipulation.
Il reste 20% de situations difficiles dans lesquelles il ne vous donnera aucune information, par exemple: requêtes imbriquées / filtrage et ainsi de suite. Dans ma pratique, je n'ai rencontré un semblable qu'une seule fois. Ensuite, j'ai dû contourner le filtrage côté service.
Quel est le danger en SQL?
- De l'évidence - fuite d'informations . Si un attaquant a pu générer des requêtes vers vos bases de données, il peut d'une manière ou d'une autre obtenir des valeurs qui n'étaient pas destinées à la sortie (hachages de mot de passe, adresses client, etc.);
- Changement de données . Maintenant, de nombreux développeurs utilisent des bases de données via des systèmes ORM . Ces systèmes eux-mêmes, par défaut, vous permettent de faire plusieurs requêtes à la fois, la syntaxe SQL vous permet également de le faire. S'il y a une vulnérabilité, tout peut se tourner non seulement vers la sélection des données, mais aussi vers leur modification (jusqu'à la suppression des tables, la modification de la structure de la base de données, etc.).
Dans la même situation, une augmentation des privilèges utilisateur est possible. Modifiez les champs de certaines tables (par exemple, mettez is_admins = true dans la base de données des utilisateurs ) et augmentez ainsi vos droits à l'administrateur; - DoS . Dans certains cas, une injection peut entraîner un déni de service. Plusieurs requêtes lourdes vers la base de données sont générées, lancées dans plusieurs threads et votre service peut cesser de fonctionner pendant un certain temps;
- La lecture des fichiers système est un autre désastre que l'injection SQL peut apporter. L'occurrence de ce risque dépend du système de base de données que vous utilisez, ainsi que de l'utilisateur qui travaille avec (privilégié ou non);
- RCE (Remote Code Execution) est l'exécution de code. Cela dépend directement du type de base de données utilisé (auparavant, cela était possible par défaut, avec les paramètres de base de données par défaut, dans MSSQL).
Le tableau ci-dessous montre les vulnérabilités de la requête
SQL . Bien sûr, vous n'avez pas besoin de le mémoriser. De plus, ce ne sont pas toutes les options possibles, mais simplement des exemples. Faites juste attention au fait que les endroits où l'injection dans la requête
SQL peut se produire si des données brutes y arrivent sont surlignés en rouge. Un attaquant expérimenté peut trouver un moyen d'exploiter cela. Soyez prudent et attentif.
SSRF (falsification de requête côté serveur)
Traduction littérale - fausses requêtes côté serveur. C'est-à-dire, une attaque qui vous permet de manipuler les données que vous envoyez à l'application, vous forçant à faire la demande pour ne pas où la logique métier initialement prévue.
Le fonctionnement de
SSRF est illustré dans l'image ci-dessous:
Il y a un attaquant, il y a votre serveur, qui est fermé par le
pare -
feu , mais en même temps il y a une fonctionnalité qui vous permet de faire plus de requêtes au nom du serveur.
Si cette fonctionnalité n'est pas correctement protégée et / ou incorrectement, comme cela arrive généralement :), traite les données entrantes, l'attaquant peut se tourner vers
Memcached ,
Redis ou accéder à toutes les ressources internes de la victime.
Pour un exemple plus illustratif, considérons le stand que SEMrush utilise pour la formation interne des employés.
Il est important de faire attention à la signification de "l'
URL de l'avatar ":
Ici, nous prêtons attention à 2 points:
- URL de l'avatar elle-même
- et la possibilité de le télécharger à l'aide d'un fichier.
Veuillez noter que le champ "
URL de l'avatar " est un champ de texte pour la saisie, ce qui signifie que nous pouvons manipuler cette valeur. Essayons de mettre l'avatar, peut-être, l'image la plus célèbre sur Internet - Googlebot de la page d'
erreur 404 .
Faites-le une fois:
Faites deux - cliquez sur "
Enregistrer ". Nous obtenons un robot à la place de ma photo:
Ici, il convient de prêter attention au fait que la valeur de "l'
URL de l'avatar " a changé, en un chemin local - apparemment, l'application a demandé une image, l'a enregistrée sur le serveur et a substitué une nouvelle valeur.
Nous continuons. Dans le champ "
URL avatar ", entrez le
fichier de valeur
: /// etc / passwd . Cette conception vous permet d'accéder à la structure du fichier. Dans certaines bibliothèques qui fonctionnaient avec
HTTP , par défaut, la structure de fichiers est activée et reçoit des données des serveurs sur lesquels elles ont été lancées:
Que se passe-t-il après avoir cliqué sur le bouton "
Enregistrer "? ..
Premièrement, l'image est devenue «
chauve-souris » et, deuxièmement, le chemin d'accès au fichier a changé.
Si nous essayons de demander cette image dans le navigateur, ils ne nous montreront rien (le fichier est «
cassé »). Mais nous ne sommes pas le premier jour de la sécurité de l'information, nous savons quoi faire :) Par de simples manipulations nous obtenons le contenu du fichier sur notre ordinateur:
Ainsi, à l'aide de cette vulnérabilité, en tant qu'attaquant, je peux obtenir tous les codes source de votre service et d'autres données disponibles pour lecture à l'utilisateur qui exécute le service Web.
Regardons les dangers de SSRF:
- Balayage de port. Pour un réseau externe, votre service est un point d'entrée et 2 ports (http et https). En scannant les ports depuis l'intérieur de votre infrastructure, un attaquant peut détecter les ports ouverts;
- Contournez l'authentification basée sur l'hôte. À quoi ça sert? Il est possible qu'au sein de votre structure, il existe des services qui ne sont disponibles que pour certaines ressources (lire: liste blanche IP). Donc, si votre serveur vulnérable est dans la liste blanche, vous avez accès aux services qui lui sont disponibles et, par conséquent, vous pouvez les manipuler;
- En poursuivant le développement de l'attaque susmentionnée, vous pouvez continuer à exploiter les programmes vulnérables s'exécutant sur l'intranet ou sur le serveur local. Très souvent, il existe des situations où l'infrastructure interne, inaccessible de l'extérieur, est mal surveillée (les versions / correctifs de sécurité, etc. ne sont pas toujours mis à jour). Cela peut également entraîner des attaques et des vols de données;
- Lecture des données locales. Je l'ai montré ci-dessus avec un exemple. Vos configurations peuvent être lues et accessibles, jetons et mots de passe.
Où chercher SSRF?
Ce n'est pas une vulnérabilité standard. Il peut être trouvé dans différents endroits, souvent dans les endroits les plus inattendus. Dans cette situation, la technique «regardez ici, mais vous ne pouvez même pas regarder ici» ne fonctionne pas.
Signes d'un éventuel
SSRF :
- Webhook . S'ils sont mal configurés, si le pare-feu est mal configuré sur les serveurs à partir desquels les Webhooks effectuent des requêtes, une vulnérabilité peut être obtenue;
- Conversion HTML . Essayez d'incorporer une construction d' URL <iframe> , <img> , <base> , <script> ou CSS qui pointe vers un service interne;
- Téléchargez les fichiers supprimés . Rappelez-vous l'exemple d'avatar? Lorsqu'un utilisateur a la possibilité de télécharger des données par URL sur le serveur, cela pose de gros problèmes. Essayez d'envoyer l'URL avec le port et voyez quel contenu est téléchargé.
Comment rechercher SSRF?
XXE (entité externe XML)
Je vais commencer l'histoire, comme toujours avec un exemple, pour que ce soit plus clair:
Dans le service SEMrush susmentionné, il existe un tel outil qui traite de l'analyse de contenu. L'utilisateur introduit l'URL de son site ou d'un site concurrent et avant de l'analyser, le service télécharge ce contenu même. Regardez comment cela se produit sur la vidéo:
Pour télécharger, le service accède au site spécifié et le robot télécharge le fichier
sitemap.xml . Et c'est le
XML même dont nous parlons dans ce bloc.
Dans la vidéo, nous pouvons observer comment le site attaquant a ajouté une définition de l'entité externe
XXE à
sitemap.xml , qui pointe vers "
file: /// etc / hosts ". Sur les systèmes Linux, il s'agit d'un fichier qui décrit quelle adresse IP correspond aux hôtes s'il n'y a pas d'enregistrements
DNS pour eux.
Ensuite, l'attaquant indique dans la
balise <loc> l' expansion de cette variable. Après avoir analysé le
XML, après avoir traité tout le
XML dans le compartiment, il insérera la valeur qui était dans "
file: /// etc / hosts " dans la variable d'
emplacement (surlignée en rouge dans la vidéo).
L'attaquant lance le lancement de notre analyseur, va dans les journaux, et ici une ligne apparaît, surlignée en blanc sur la vidéo. Il s'agit du contenu du fichier "
file: /// etc / hosts " obtenu dans la requête
GET dans les journaux d'un serveur contrôlé par celui-ci.
Et ensuite? L'attaquant vérifiera qu'il avait raison. Il changera le nom du fichier en "
fichier: /// etc / fstab ", réexécutera l'analyseur et obtiendra des statistiques sur les processus en cours d'exécution.
Et enfin: "
file: /// etc / hostname ", démarrez l'analyseur, accédez aux journaux et obtenez le
nom d'hôte de la machine sur laquelle nous sommes.
Il s'agit d'un vrai bug découvert par une personne réelle qui n'est pas liée à notre entreprise. J'ai dû saupoudrer de la cendre sur ma tête et payer de l'argent :)
Un autre exemple de
XXE :
Supposons que nous ayons un certain
point final , il s'appelle -
example.com/xxe .
Nous lui envoyons la structure
XML → en
XML nous déclarons l'entité
→ l'entité
se réfère au fichier système
/ etc / passwd et s'ouvre plus loin dans le corps de la réponse → nous obtenons le contenu de ce fichier en réponse.
Il convient de noter que cela ne se produit pas aussi souvent que nous le souhaiterions.
Pourquoi ça marche?
Les documents
XML sont un format de données structuré qui, entre autres, vous permet de décrire les types de données qu'il peut contenir à l'aide d'une balise
DOCTYPE spéciale.
Définition du type de données (DTD) - La définition des types de données à l'intérieur de ce document
XML . Il existe trois options sur la façon dont cela peut être fait:
- Si le document prend en charge la DTD . L'exemple ci-dessous montre du XML dans lequel il y a une structure de commande, il y a un élément de produit et un élément de comptage (probablement: le numéro d'inventaire du produit et le nombre d'articles dans la commande). L'ordre est le parent de ces deux éléments:
- DTD externes sur le serveur local.
Nous faisons la même chose que dans le premier mode de réalisation, mais nous faisons toutes les définitions dans un fichier séparé, qui se trouve sur le serveur local:
- DTD externes sur un serveur tiers:
Si vous êtes un lecteur attentif, vous avez probablement corrélé le fait que la possibilité de faire de telles demandes sur votre service et de demander des schémas
DTD externes est une vulnérabilité en soi, dont nous avons parlé ci-dessus, à savoir la vulnérabilité
SSRF .
Un événement courant: les développeurs corrigent la vulnérabilité
XXE , mais oublient d'interdire le traitement des
DTD externes et d'obtenir
SSRF . Des conséquences fatales n'en découleront pas, mais vous ne devez pas l'oublier.
Que sont les entités en XML?
Entités en
XML . Qu'est ce que c'est C'est l'occasion de définir certaines valeurs et de les transformer en variables. Les entités ont trois types différents:
Prédéfini - prédéfini. Semblable au code
HTML , permet d'utiliser les caractères qui font partie de la syntaxe de la langue, comme structure de texte. Ici, ils sont donnés à titre d'exemple, afin que vous compreniez ce que c'est. Oui, dans la plupart des attaques, ils ne sont pas utilisés, mais peuvent être nécessaires dans certains cas exceptionnels.
Général et
paramètre . C'est la même chose, seule la syntaxe de leur déclaration change et comment ils peuvent être appelés après la déclaration
Où chercher XXE ?
Plusieurs options:
- Traitement XML dans n'importe quelle manifestation:
- Convertissez HTML en d'autres formats;
- Gestion des formats docx , xlsx et similaires.
Comment les chercher?
L'image montre juste un exemple à partir duquel commencer. Ce n'est pas une clé universelle. Il doit être optimisé pour les formats que vous utilisez dans le service à l'étude.
La première chose que nous faisons: déclarer une certaine entité
Z , qui accède à l'hôte contrôlé par l'hôte attaquant, la développe dans le corps du document
XML .
Ici, la deuxième option est possible - juste l'essence de
Parameter . Diffère de la première annonce (signe
% ). Et pour revenir à cette essence, le corps du document n'est plus nécessaire. Nous pouvons y accéder directement dans la structure
DOCTYPE et exposer cette entité:
Le troisième scénario consiste à voir si la possibilité de demander
DOCTYPE à des services externes est activée ou désactivée:
Ensuite, nous regardons la sortie d'un serveur que nous contrôlons. Si nous voyons un appel à
URL / vérification à partir de diverses adresses
IP , cela signifie qu'avec une grande probabilité, la vulnérabilité est passée, et nous avons juste besoin de trouver comment obtenir des données plus intéressantes pour nous.
Quel est le danger de
XXE ? J'écrirai brièvement et point par point:
- Lecture de fichiers locaux;
- Accès aux ressources locales;
- Analyse de port / hôte
- Wrappers de texte brut . C'est l'occasion d'accéder à vos services qui fonctionnent sur le protocole texte brut;
- Exécution de code à distance (pas souvent). Il est désactivé par défaut;
- DoS . Du fait que les entités peuvent être concaténées, il est possible d'obtenir facilement une augmentation exponentielle de la quantité de mémoire occupée par ces paramètres. Le résultat est une attaque de milliards de rires . En d'autres termes, vous surchargez simplement la mémoire du serveur attaqué.
En conclusion, je dirai que tout cela (l'article et toute connaissance que vous avez acquise) n'a pas de sens sans application pratique. Par conséquent, je vais vous poser des questions sur une vraie bagatelle: pensez à l'application que vous avez écrite / testée hier et essayez de vérifier les vulnérabilités. Existe-t-il des formulaires de saisie ou
un traitement
XML ? Cette application est-elle protégée? Le filtrage est-il ajouté et la
DTD est-elle désactivée?
Ouvrez le manuel
SQLmap et découvrez comment vérifier votre application avec. S'il ne trouve rien, prenez un autre outil et examinez-le, puis testez votre application pour détecter d'autres vulnérabilités. Comme je l'ai dit au début, l'article examine seulement quelques vulnérabilités, mais des
milliers d'entre elles .
Je ne pense pas que vous puissiez écrire du code absolument sûr. Il y a toujours des vulnérabilités, vous ne les avez tout simplement
pas encore trouvées .