80,443 - Pentesting Web Methodology
Last updated
Last updated
Si vous êtes intéressé par une carrière en piratage et pirater l'impossible - nous recrutons ! (maîtrise du polonais écrit et parlé requise).
Le service web est le service le plus commun et étendu et de nombreux types de vulnérabilités différents existent.
Port par défaut : 80 (HTTP), 443 (HTTPS)
Dans cette méthodologie, nous allons supposer que vous allez attaquer un domaine (ou sous-domaine) et uniquement celui-ci. Vous devriez appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert avec un serveur web indéterminé dans le périmètre.
Vérifiez s'il existe des vulnérabilités connues pour la version du serveur en cours d'exécution. Les en-têtes HTTP et les cookies de la réponse pourraient être très utiles pour identifier les technologies et/ou la version utilisée. Un scan Nmap peut identifier la version du serveur, mais les outils whatweb, webtech ou https://builtwith.com/: pourraient également être utiles.
Recherchez les vulnérabilités de la version de l'application Web ici
Quelques astuces pour trouver des vulnérabilités dans différentes technologies bien connues utilisées :
Tenez compte du fait que le même domaine peut utiliser différentes technologies sur différents ports, dossiers et sous-domaines. Si l'application Web utilise une technologie/plateforme bien connue répertoriée précédemment ou autre, n'oubliez pas de rechercher sur Internet de nouvelles astuces (et faites-le moi savoir !).
Si le code source de l'application est disponible sur github, en plus de réaliser un test White box de l'application par vous-même, il y a des informations qui pourraient être utiles pour le test Black-Box actuel :
Y a-t-il un fichier Journal des modifications ou Lisez-moi ou Version ou tout autre élément avec des informations de version accessibles via le web ?
Comment et où sont sauvegardées les informations d'identification ? Y a-t-il un fichier (accessible ?) avec des informations d'identification (noms d'utilisateur ou mots de passe) ?
Les mots de passe sont-ils en texte brut, chiffrés ou quel algorithme de hachage est utilisé ?
Utilise-t-il une clé principale pour chiffrer quelque chose ? Quel algorithme est utilisé ?
Pouvez-vous accéder à l'un de ces fichiers en exploitant une vulnérabilité ?
Y a-t-il des informations intéressantes dans les problèmes github (résolus et non résolus) ? Ou dans l'historique des validations (peut-être un mot de passe introduit dans une ancienne validation) ?
Si un CMS est utilisé, n'oubliez pas d'exécuter un scanner, peut-être que quelque chose de juteux est trouvé :
CMSMap: (W)ordpress, (J)oomla, (D)rupal ou (M)oodle
À ce stade, vous devriez déjà avoir des informations sur le serveur web utilisé par le client (si des données sont fournies) et quelques astuces à garder à l'esprit pendant le test. Si vous avez de la chance, vous avez peut-être même trouvé un CMS et exécuté un scanner.
À partir de ce point, nous allons commencer à interagir avec l'application web.
Pages par défaut avec des informations intéressantes :
/robots.txt
/sitemap.xml
/crossdomain.xml
/clientaccesspolicy.xml
/.well-known/
Vérifiez également les commentaires dans les pages principales et secondaires.
Forcer des erreurs
Les serveurs web peuvent avoir un comportement inattendu lorsqu'ils reçoivent des données étranges. Cela peut ouvrir des vulnérabilités ou révéler des informations sensibles.
Accédez à des pages fictives comme /whatever_fake.php (.aspx,.html,.etc)
Ajoutez "[]", "]]", et "[[" dans les valeurs des cookies et des paramètres pour créer des erreurs
Générez une erreur en donnant une entrée comme /~randomthing/%s à la fin de l'URL
Essayez des verbes HTTP différents comme PATCH, DEBUG ou incorrect comme FAKE
Si vous découvrez que WebDav est activé mais que vous n'avez pas suffisamment d'autorisations pour télécharger des fichiers dans le dossier racine, essayez de :
Forcer les identifiants par brute force
Télécharger des fichiers via WebDav dans le reste des dossiers trouvés à l'intérieur de la page web. Vous pouvez avoir les autorisations pour télécharger des fichiers dans d'autres dossiers.
Si l'application ne force pas l'utilisation de HTTPS à un moment donné, alors elle est vulnérable aux attaques de l'homme du milieu (MitM)
Si l'application envoie des données sensibles (mots de passe) en utilisant HTTP. Alors c'est une vulnérabilité élevée.
Utilisez testssl.sh pour vérifier les vulnérabilités (dans les programmes de prime de bug, ces types de vulnérabilités ne seront probablement pas acceptés) et utilisez a2sv pour re-vérifier les vulnérabilités:
Lancez une sorte d'araignée à l'intérieur du web. Le but de l'araignée est de trouver autant de chemins que possible à partir de l'application testée. Par conséquent, le crawling web et les sources externes doivent être utilisés pour trouver autant de chemins valides que possible.
gospider (go) : Araignée HTML, LinkFinder dans les fichiers JS et sources externes (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
hakrawler (go) : Araignée HML, avec LinkFider pour les fichiers JS et Archive.org comme source externe.
dirhunt (python) : Araignée HTML, indique également les "fichiers juteux".
evine (go) : Araignée HTML interactive en CLI. Il recherche également dans Archive.org.
meg (go) : Cet outil n'est pas une araignée mais peut être utile. Vous pouvez simplement indiquer un fichier avec des hôtes et un fichier avec des chemins et meg récupérera chaque chemin sur chaque hôte et enregistrera la réponse.
urlgrab (go) : Araignée HTML avec des capacités de rendu JS. Cependant, il semble qu'il ne soit pas maintenu, la version précompilée est ancienne et le code actuel ne compile pas.
gau (go) : Araignée HTML qui utilise des fournisseurs externes (wayback, otx, commoncrawl).
ParamSpider : Ce script trouvera des URL avec des paramètres et les listera.
galer (go) : Araignée HTML avec des capacités de rendu JS.
LinkFinder (python) : Araignée HTML, avec des capacités de beauté JS capable de rechercher de nouveaux chemins dans les fichiers JS. Il pourrait également être intéressant de jeter un coup d'œil à JSScanner, qui est un wrapper de LinkFinder.
goLinkFinder (go) : Pour extraire des points de terminaison à la fois dans la source HTML et les fichiers javascript intégrés. Utile pour les chasseurs de bugs, les équipes rouges, les ninjas de la sécurité de l'information.
JSParser (python2.7) : Un script python 2.7 utilisant Tornado et JSBeautifier pour analyser les URL relatives à partir de fichiers JavaScript. Utile pour découvrir facilement les requêtes AJAX. Semble ne pas être maintenu.
relative-url-extractor (ruby) : Étant donné un fichier (HTML), il extraira les URL en utilisant une expression régulière astucieuse pour trouver et extraire les URL relatives des fichiers moches (minifiés).
JSFScan (bash, plusieurs outils) : Rassemble des informations intéressantes à partir de fichiers JS en utilisant plusieurs outils.
subjs (go) : Trouver des fichiers JS.
page-fetch (go) : Charge une page dans un navigateur sans tête et imprime toutes les URL chargées pour charger la page.
Feroxbuster (rust) : Outil de découverte de contenu mélangeant plusieurs options des outils précédents.
Javascript Parsing : Une extension Burp pour trouver des chemins et des paramètres dans les fichiers JS.
Sourcemapper : Un outil qui, étant donné l'URL .js.map, vous fournira le code JS beatifié.
xnLinkFinder : C'est un outil utilisé pour découvrir des points de terminaison pour une cible donnée.
waymore : Découvrir des liens à partir de la machine wayback (en téléchargeant également les réponses dans le wayback et en recherchant plus de liens).
HTTPLoot (go) : Crawler (même en remplissant des formulaires) et trouver également des informations sensibles en utilisant des regex spécifiques.
SpiderSuite : Spider Suite est un avancé multi-fonction GUI web security Crawler/Spider conçu pour les professionnels de la cybersécurité.
jsluice (go) : C'est un package Go et outil en ligne de commande pour extraire des URL, des chemins, des secrets et d'autres données intéressantes du code source JavaScript.
ParaForge : ParaForge est une simple extension Burp Suite pour extraire les paramètres et les points de terminaison de la requête afin de créer une liste de mots personnalisée pour le fuzzing et l'énumération.
Commencez la force brute à partir du dossier racine et assurez-vous de faire une force brute sur tous les répertoires trouvés en utilisant cette méthode et tous les répertoires découverts par l'Exploration d'araignée (vous pouvez effectuer cette force brute de manière récursive et ajouter au début de la liste de mots utilisée les noms des répertoires trouvés). Outils :
Dirb / Dirbuster - Inclus dans Kali, ancien (et ** lent **) mais fonctionnel. Autorise les certificats auto-signés et la recherche récursive. Trop lent par rapport aux autres options.
Dirsearch (python) : Il n'autorise pas les certificats auto-signés mais permet une recherche récursive.
Gobuster (go) : Il autorise les certificats auto-signés, il n'a pas de recherche récursive.
Feroxbuster - Rapide, prend en charge la recherche récursive.
wfuzz wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
ffuf - Rapide : ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
uro (python) : Ce n'est pas une araignée mais un outil qui, étant donné la liste des URL trouvées, supprimera les URL "dupliquées".
Scavenger : Extension Burp pour créer une liste de répertoires à partir de l'historique de burp de différentes pages.
TrashCompactor : Supprime les URL avec des fonctionnalités dupliquées (basées sur les imports JS).
Chamaleon : Il utilise wapalyzer pour détecter les technologies utilisées et sélectionner les listes de mots à utiliser.
Dictionnaires recommandés :
Dictionnaire inclus dans Dirsearch
raft-large-directories-lowercase.txt
directory-list-2.3-medium.txt
RobotsDisallowed/top10000.txt
/usr/share/wordlists/dirb/common.txt
/usr/share/wordlists/dirb/big.txt
/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Notez que chaque fois qu'un nouveau répertoire est découvert lors d'une attaque par force brute ou d'une exploration, il doit être soumis à une attaque par force brute.
Vérificateur de liens brisés : Trouvez les liens brisés à l'intérieur des fichiers HTML qui pourraient être sujets à des prises de contrôle.
Sauvegardes de fichiers : Une fois que vous avez trouvé tous les fichiers, recherchez des sauvegardes de tous les fichiers exécutables (".php", ".aspx"...). Les variations courantes pour nommer une sauvegarde sont : file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp et file.old. Vous pouvez également utiliser l'outil bfac ou backup-gen.
Découverte de nouveaux paramètres : Vous pouvez utiliser des outils comme Arjun, parameth, x8 et Param Miner pour découvrir des paramètres cachés. Si possible, vous pourriez essayer de rechercher des paramètres cachés dans chaque fichier web exécutable.
Tous les wordlists par défaut d'Arjun : https://github.com/s0md3v/Arjun/tree/master/arjun/db
Param-miner "params" : https://github.com/PortSwigger/param-miner/blob/master/resources/params
Assetnote "parameters_top_1m" : https://wordlists.assetnote.io/
nullenc0de "params.txt" : https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773
Commentaires : Vérifiez les commentaires de tous les fichiers, vous pouvez y trouver des identifiants ou une fonctionnalité cachée.
Si vous participez à un CTF, une "astuce" courante est de cacher des informations à l'intérieur des commentaires à droite de la page (en utilisant des centaines d'espaces pour que les données ne soient pas visibles si vous ouvrez le code source avec le navigateur). Une autre possibilité est d'utiliser plusieurs nouvelles lignes et de cacher des informations dans un commentaire en bas de la page web.
Clés API : Si vous trouvez une clé API, il existe un guide indiquant comment utiliser les clés API de différentes plateformes : keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird
Clés API Google : Si vous trouvez une clé API ressemblant à AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik, vous pouvez utiliser le projet gmapapiscanner pour vérifier quelles APIs la clé peut accéder.
Buckets S3 : Lors de l'exploration, vérifiez si un sous-domaine ou un lien est lié à un bucket S3. Dans ce cas, vérifiez les permissions du bucket.
Pendant l'exploration et l'attaque par force brute, vous pourriez trouver des choses intéressantes que vous devez remarquer.
Fichiers intéressants
Recherchez des liens vers d'autres fichiers à l'intérieur des fichiers CSS.
Si vous trouvez un fichier .env, des informations telles que des clés API, des mots de passe de bases de données et d'autres informations peuvent être trouvées.
Si vous trouvez des points de terminaison API, vous devriez également les tester. Ce ne sont pas des fichiers, mais ils ressembleront probablement à des fichiers.
Fichiers JS : Dans la section d'exploration, plusieurs outils permettant d'extraire des chemins à partir de fichiers JS ont été mentionnés. Il serait également intéressant de surveiller chaque fichier JS trouvé, car dans certaines occasions, un changement peut indiquer qu'une vulnérabilité potentielle a été introduite dans le code. Vous pourriez par exemple utiliser JSMon.
Déobfuscateur et désassembleur JavaScript : https://lelinhtinh.github.io/de4js/, https://www.dcode.fr/javascript-unobfuscator
Embelleur JavaScript : http://jsbeautifier.org/, http://jsnice.org/
Déobfuscation JsFuck (javascript avec les caractères : "[]!+" https://ooze.ninja/javascript/poisonjs/)
TrainFuck: +72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.
À plusieurs reprises, vous devrez comprendre les expressions régulières utilisées, cela sera utile : https://regex101.com/
Vous pourriez également surveiller les fichiers où des formulaires ont été détectés, car un changement dans le paramètre ou l'apparition d'un nouveau formulaire peut indiquer une nouvelle fonctionnalité potentiellement vulnérable.
403 Forbidden/Basic Authentication/401 Unauthorized (contournement)
403 & 401 Bypasses502 Proxy Error
Si une page répond avec ce code, il s'agit probablement d'un proxy mal configuré. Si vous envoyez une requête HTTP comme : GET https://google.com HTTP/1.1 (avec l'en-tête host et d'autres en-têtes courants), le proxy tentera d'accéder à google.com et vous aurez découvert une SSRF.
Authentification NTLM - Divulgation d'informations
Si le serveur en cours d'exécution demandant une authentification est Windows ou si vous trouvez une connexion demandant vos identifiants (et demandant un nom de domaine), vous pouvez provoquer une divulgation d'informations.
Envoyez l'en-tête : “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=” et en raison du fonctionnement de l'authentification NTLM, le serveur répondra avec des informations internes (version de IIS, version de Windows...) à l'intérieur de l'en-tête "WWW-Authenticate".
Vous pouvez automatiser cela en utilisant le plugin nmap "http-ntlm-info.nse".
Redirection HTTP (CTF)
Il est possible de placer du contenu à l'intérieur d'une redirection. Ce contenu ne sera pas affiché à l'utilisateur (car le navigateur exécutera la redirection), mais quelque chose pourrait être caché à l'intérieur.
Maintenant qu'une énumération complète de l'application web a été effectuée, il est temps de vérifier de nombreuses vulnérabilités possibles. Vous pouvez trouver la liste de contrôle ici:
Web Vulnerabilities MethodologyTrouvez plus d'informations sur les vulnérabilités Web dans:
Vous pouvez utiliser des outils tels que https://github.com/dgtlmoon/changedetection.io pour surveiller les pages à la recherche de modifications qui pourraient introduire des vulnérabilités.
Si vous êtes intéressé par une carrière en piratage et pirater l'impossible - nous recrutons ! (maîtrise du polonais à l'écrit et à l'oral requise).
