AZERR

Traduit de Anglais vers Français - www.onlinedoctranslator.
com
OAuth 169
29
30 </corps>
31 </html>
Décomposons cela. SelonDocumentation de Google7, la réponse JSON inclut les données dans un
objet Javascript. Si une requête n'inclut pas de valeur ResponseHandler, la valeur par défaut est
google.visualisation.Query.setResponse. Ainsi, en gardant cela à l'esprit, le script de la ligne 3
commence à créer les objets dont nous avons besoin pour définir une fonction anonyme qui sera
appelée pour setResponse lorsque nous recevrons nos données avec l'objet Javascript de Google.
Ainsi, à la ligne 8, nous définissons la réponse sur leGoogleobjet à la valeur JSON de la réponse. Puisque l'objet
contient simplement du JSON valide, cela s'exécute sans aucun problème. Voici un exemple de réponse après
avoir été stringifiée (encore une fois, avec l'aimable autorisation de Rodney) :
{
"version": "0.6",
"reqId": "0",
"statut": "ok",
"sig": "405162961",
"tableau": {
"cols": [
{
"id": "A",
"label": "Compte #12345", . . .
À ce stade, les lecteurs avisés se seraient peut-être demandé ce qui était arrivé aux protections du
partage de ressources entre origines croisées ? Comment notre script peut-il accéder à la réponse de
Google et l'utiliser ? Eh bien, il s'avère que puisque Google renvoie un objet Javascript qui contient un
tableau JSON et que cet objet n'est pas anonyme (c'est-à-dire que la valeur par défaut fera partie de
setResponse), le navigateur le traite comme du Javascript valide, permettant ainsi aux attaquants de le
lire et de l'utiliser. . Pensez à l'inclusion d'un script légitime provenant d'un site distant dans votre propre
code HTML, même idée. Si le script contenait simplement un objet JSON, il n'aurait pas été du Javascript
valide et nous n'aurions pas pu y accéder.
En passant, ce type de vulnérabilité existe depuis un certain temps, connu sous le nom de
détournement JSON. L'exploitation de cela était également possible pour les objets Javascript
anonymes en remplaçant le Javascript Object.prototype.définirSetterméthode mais cela a été
corrigé dans Chrome 27, Firefox 21 et IE 10.
Pour revenir à l'exemple de Rodney, lorsque notre page malveillante est chargée, leen chargele gestionnaire d'événements
pour notre balise body à la ligne 25 exécutera la fonctionpasser en contrebandeà partir de la ligne 18. Ici,
7https://developers.google.com/chart/interactive/docs/dev/implementing_data_source#json-response-format
OAuth 170
nous obtenons l'élément textareacargaisondans notre formulaire ligne 27 et nous définissons le texte sur la réponse de
notre feuille de calcul. Nous soumettons le formulaire au site Web de Rodney et nous avons réussi à voler des données.
Fait intéressant, selon l'interaction de Rodney avec Google, changer cela n'était pas une solution simple et
nécessitait des modifications de l'API elle-même. En conséquence, bien qu'il ait rendu compte du 29 octobre
2015, ce problème n'a été résolu que le 15 septembre 2016.
Points à retenir
Il y a quelques points à retenir ici. Premièrement, les vulnérabilités OAuth ne concernent pas
toujours le vol de jetons. Gardez un œil sur les requêtes API protégées par OAuth qui n'envoient
ou ne valident pas le jeton (c'est-à-dire, essayez de supprimer l'en-tête du jeton OAuth s'il y a un
identifiant, comme l'ID de la feuille, dans l'URL). Deuxièmement, il est important de reconnaître et
de comprendre comment les navigateurs interprètent Javascript et JSON. Cette vulnérabilité était
en partie rendue possible puisque Google renvoyait un objet Javascript valide contenant du JSON
accessible via setResponse. S'il s'agissait d'un tableau Javascript anonyme, cela n'aurait pas été
possible. Enfin, même si c'est un thème commun dans le livre, lisez la documentation. La
documentation de Google sur les réponses a été essentielle au développement d'une preuve de
concept fonctionnelle qui envoyait les données d'une feuille de calcul à un serveur distant.
Résumé
OAuth peut être un processus compliqué à comprendre lorsque vous en découvrez pour la première fois,
ou du moins c'était pour moi et les pirates avec lesquels j'ai parlé et dont j'ai appris. Cependant, une fois
que vous l’avez compris, il existe de nombreuses vulnérabilités potentielles étant donné sa complexité.
Lorsque vous testez des choses, soyez à la recherche de solutions créatives, comme la reprise par
Philippe d'applications tierces et l'abus de suffixes de domaine comme Prakhar.
20. Vulnérabilités de la logique des applications
Description
Les vulnérabilités de la logique applicative sont différentes des autres types dont nous avons discuté jusqu’à présent.
Alors que l'injection HTML, la pollution des paramètres HTML, XSS, etc. impliquent tous la soumission d'un certain
type d'entrée potentiellement malveillante, les vulnérabilités de la logique des applications impliquent en réalité la
manipulation de scénarios et l'exploitation de bogues dans les décisions de codage et de développement de
l'application Web.
Un exemple notable de ce type d’attaque a été réalisé par Egor Homakov contre GitHub qui utilise Ruby
on Rails. Si vous n'êtes pas familier avec Rails, il s'agit d'un framework Web très populaire qui prend en
charge une grande partie du gros du travail lors du développement d'un site Web.
En mars 2012, Egor a signalé à la communauté Rails que, par défaut, Rails accepterait tous les paramètres qui lui
seraient soumis et utiliserait ces valeurs dans la mise à jour des enregistrements de la base de données (en fonction
de l'implémentation des développeurs). L'idée des principaux développeurs de Rails était que les développeurs Web
utilisant Rails devraient être responsables de combler cette faille de sécurité et de définir les valeurs pouvant être
soumises par un utilisateur pour mettre à jour les enregistrements. Ce comportement était déjà bien connu au sein
de la communauté mais le fil de discussion sur GitHub montre à quel point peu de personnes appréciaient le risque
que cela représentait.https://github.com/rails/rails/issues/52281.
Lorsque les principaux développeurs n'étaient pas d'accord avec lui, Egor a exploité une vulnérabilité
d'authentification sur GitHub en devinant et en soumettant des valeurs de paramètres incluant une date de
création (ce qui n'est pas trop difficile si vous avez travaillé avec Rails et savez que la plupart des
enregistrements incluent une colonne créée et mise à jour). dans la base de données). En conséquence, il a
créé un ticket sur GitHub avec la date des années dans le futur. Il a également réussi à mettre à jour les clés
d'accès SSH qui lui ont permis d'accéder au référentiel de code officiel GitHub.
Comme mentionné, le piratage a été rendu possible via le code back-end GitHub qui n'authentifiait pas
correctement ce que faisait Egor, c'est-à-dire qu'il n'aurait pas dû avoir l'autorisation de soumettre des valeurs
pour la date de création, qui ont ensuite été utilisées pour mettre à jour les enregistrements de la base de
données. Dans ce cas, Egor a découvert ce qu’on appelle une vulnérabilité d’affectation de masse.
Les vulnérabilités de la logique des applications sont un peu plus difficiles à trouver par rapport aux types d'attaques
précédents évoqués, car elles reposent sur une réflexion créative sur les décisions de codage et ne consistent pas
simplement à soumettre du code potentiellement malveillant auquel les développeurs n'échappent pas (sans essayer
de minimiser les autres types de vulnérabilités). ici, certaines attaques XSS sont plus que complexes !).
1https://github.com/rails/rails/issues/5228
Vulnérabilités de la logique des applications 172
Avec l'exemple de GitHub, Egor savait que le système était basé sur Rails et comment Rails gérait les entrées
des utilisateurs. Dans d'autres exemples, il peut s'agir d'effectuer des appels API directs par programme pour
tester un comportement qui complète un site Web, comme le montre le contournement des privilèges
d'administrateur de Shopify ci-dessous. Ou bien, il s'agit de réutiliser les valeurs renvoyées par des appels d'API
authentifiés pour effectuer des appels d'API ultérieurs, ce que vous ne devriez pas être autorisé à faire.
Exemples
1. Contournement des privilèges d'administrateur Shopify
Difficulté: Faible
URL: shop.myshopify.com/admin/mobile_devices.json
Lien de rapport:https://hackerone.com/reports/1009382
Date de déclaration: 22 novembre 2015
Prime payée: 500$
Description:
Shopify est une plate-forme énorme et robuste qui comprend à la fois une interface utilisateur Web et des API de
prise en charge. Dans cet exemple, l'API n'a pas validé certaines autorisations, contrairement à l'interface utilisateur
Web. En conséquence, les administrateurs de magasin, qui n'étaient pas autorisés à recevoir des notifications par
courrier électronique concernant les ventes, pouvaient contourner ce paramètre de sécurité en manipulant le point
de terminaison de l'API pour recevoir des notifications sur leurs appareils Apple.
Selon le rapport, le hacker aurait simplement à :
• Connectez-vous à l'application téléphonique Shopify avec un compte à accès complet.

• Intercepter la requête vers POST /admin/mobile_devices.json
• Supprimez toutes les autorisations de ce compte
• Supprimer la notification mobile ajoutée
• Rejouez la requête vers POST /admin/mobile_devices.json
Après cela, cet utilisateur recevrait des notifications mobiles pour toutes les commandes passées dans le
magasin, ignorant ainsi les paramètres de sécurité configurés par le magasin.
2https://hackerone.com/reports/100938
Points à retenir
Il y a deux points clés à retenir ici. Premièrement, tout ne consiste pas à injecter du code, du HTML, etc.
N'oubliez pas d'utiliser un proxy, de surveiller les informations transmises à un site et de jouer avec pour voir
ce qui se passe. Dans ce cas, il suffisait de supprimer les paramètres POST pour contourner les contrôles de
sécurité. Deuxièmement, encore une fois, toutes les attaques ne sont pas basées sur des pages Web HTML.
Les points de terminaison de l'API présentent toujours un domaine potentiel de vulnérabilité, alors assurez-
vous de prendre en compte et de tester les deux.
2. Manipulation du signal HackerOne
Difficulté: Faible
URL: hackerone.com/reports/XXXXX
Date de déclaration: 21 décembre 2015
Prime payée: 500$ Description:
Fin 2015, HackerOne a introduit une nouvelle fonctionnalité sur le site appelée Signal. Essentiellement,
cela permet d'identifier l'efficacité des précédents rapports de vulnérabilité d'un pirate informatique une
fois ces rapports fermés. Il est important de noter ici que les utilisateurs peuvent fermer leurs propres
rapports sur HackerOne, ce qui n'est censé entraîner aucun changement pour leur réputation et leur
signal�
Ainsi, comme vous pouvez probablement le deviner, en testant la fonctionnalité, un pirate informatique a découvert que la
fonctionnalité n'était pas correctement implémentée et a permis à un pirate informatique de créer un rapport pour
n'importe quelle équipe, de fermer automatiquement le rapport et de recevoir un boost de signal.
Et c’est tout ce qu’il y avait à faire�
Points à retenir
Bien qu'il s'agisse d'une brève description, les points à retenir ici ne peuvent pas être surestimés,soyez
à l'affût de nouvelles fonctionnalités !. Lorsqu'un site implémente une nouvelle fonctionnalité, c'est
de la viande fraîche. Les nouvelles fonctionnalités représentent l'opportunité de tester du nouveau
code et de rechercher des bugs. C'était la même chose pour les vulnérabilités Shopify Twitter CSRF et
Facebook XSS.
Pour en tirer le meilleur parti, c'est une bonne idée de vous familiariser avec les entreprises et de
vous abonner aux blogs d'entreprise, aux newsletters, etc. afin d'être averti lorsque quelque
chose est publié. Ensuite, testez.
3. Compartiments Shopify S3 ouverts
Difficulté: Moyen
URL: cdn.shopify.com/assets
Date de déclaration: 9 novembre 2015
Prime payée: 1000$
Description:
Amazon Simple Storage, S3, est un service qui permet aux clients de stocker et de servir des fichiers à partir des
serveurs cloud d'Amazon. Shopify et de nombreux sites utilisent S3 pour stocker et diffuser du contenu statique
comme des images.
L'ensemble de la suite d'Amazon Web Services, AWS, est très robuste et comprend un système de gestion des
autorisations permettant aux administrateurs de définir des autorisations, par service, S3 inclus. Les
autorisations incluent la possibilité de créer des compartiments S3 (un compartiment est comme un dossier de
stockage), de lire des compartiments et d'écrire dans des compartiments, entre autres.
Selon la divulgation, Shopify n'a pas configuré correctement les autorisations de ses compartiments S3 et a
autorisé par inadvertance tout utilisateur AWS authentifié à lire ou à écrire dans ses compartiments. Ceci est
évidemment problématique car vous ne voudriez pas que des chapeaux noirs malveillants utilisent au
minimum vos compartiments S3 pour stocker et servir des fichiers.
Malheureusement, les détails de ce ticket n'ont pas été divulgués, mais il est probable qu'il ait été
découvert grâce à l'AWS CLI, une boîte à outils qui vous permet d'interagir avec les services AWS à partir
de votre ligne de commande. Bien que vous ayez besoin d'un compte AWS pour ce faire, en créer un est
en réalité gratuit car vous n'avez besoin d'activer aucun service. En conséquence, avec la CLI, vous
pouvez vous authentifier auprès d'AWS, puis tester l'accès (c'est exactement ainsi que j'ai trouvé le
compartiment HackerOne répertorié ci-dessous).
Points à retenir
Lorsque vous identifiez une cible potentielle, veillez à noter tous les différents outils, y compris les
services Web, qu'elle semble utiliser. Chaque service, logiciel, système d'exploitation, etc. que vous
pouvez trouver révèle un nouveau vecteur d'attaque potentiel. De plus, c'est une bonne idée de vous
familiariser avec les outils Web populaires tels qu'AWS S3, Zendesk, Rails, etc. que de nombreux sites
utilisent.
4. Compartiments HackerOne S3 ouverts
Difficulté: Moyen
URL: [SUPPRIMÉ].s3.amazonaws.com
Date de déclaration: 3 avril 2016
Prime payée: 2 500 $
Description:
Nous allons faire quelque chose d'un peu différent ici. Il s'agit d'une vulnérabilité que j'ai réellement
découverte et elle est un peu différente du bug Shopify décrit ci-dessus, je vais donc tout partager en
détail sur la façon dont j'ai trouvé cela, en utilisant un script sympa et un peu d'ingéniosité.
Durant le week-end du 3 avril, je ne sais pas pourquoi mais j'ai décidé d'essayer de sortir des sentiers battus et
d'attaquer HackerOne. Je jouais avec leur site depuis le début et je n'arrêtais pas de me botter le cul à chaque
fois qu'une nouvelle vulnérabilité de divulgation d'informations était découverte, me demandant comment je
l'avais manquée. Je me demandais si leur compartiment S3 était vulnérable comme celui de Shopify. Je me
demandais également comment le pirate informatique avait accédé au compartiment Shopify. J'ai pensé qu'il
devait utiliser les outils de ligne de commande Amazon.
Maintenant, normalement, je me serais arrêté de penser qu'il n'y avait aucune chance que HackerOne soit
vulnérable après tout ce temps. Mais l’une des nombreuses choses qui m’ont marqué lors de mon entretien
avec Ben Sadeghipour (@Nahamsec) a été de ne pas douter de moi-même ni de la capacité d’une entreprise à
commettre des erreurs.
J'ai donc cherché quelques détails sur Google et suis tombé sur deux pages intéressantes :
Il y a un trou dans 1 951 compartiments Amazon S36
Recherche de compartiment S37
Le premier est un article intéressant de Rapid7, une société de sécurité, qui explique comment ils ont
découvert des compartiments S3 accessibles en écriture publique et l'ont fait en fuzzant ou en devinant le nom
du compartiment.
Le second est un outil sympa qui prendra une liste de mots et appellera S3 à la recherche de
compartiments. Cependant, il n’est pas accompagné de sa propre liste. Mais il y avait une ligne clé dans
l’article de Rapid7 : « Deviner les noms à travers quelques dictionnaires différents » Liste des noms de
sociétés Fortune 1000 avecpermutations sur .com, -backup, -media�
C'était intéressant. J'ai rapidement créé une liste de noms de buckets potentiels pour HackerOne comme
6https://community.rapid7.com/community/infosec/blog/2013/03/27/1951-open-s3-buckets
7https://digi.ninja/projects/bucket_finder.php
hackerone, hackerone.marketing, hackerone.attachments, hackerone.users, hackerone.files, etc.
Aucun de ceux-ci n'est le véritable seau - ils l'ont expurgé du rapport, donc je l'honore même si je
suis sûr que vous pourrez peut-être le trouver également. Je vais laisser cela pour un défi.
Maintenant, en utilisant le script Ruby, j'ai commencé à appeler les buckets. Tout de suite, les choses ne semblaient
pas bonnes. J'ai trouvé quelques seaux mais l'accès a été refusé. Pas de chance, alors je suis parti et j'ai regardé
NetFlix.
Mais cette idée me dérangeait. Alors avant de me coucher, j'ai décidé de relancer le script avec plus de
permutations. J'ai de nouveau trouvé un certain nombre de compartiments qui semblaient appartenir à
HackerOne, mais l'accès était tous refusé. J'ai réalisé que l'accès refusé m'a au moins dit que le
compartiment existait.
J'ai ouvert le script Ruby et j'ai réalisé qu'il appelait l'équivalent dulsfonction sur les
godets. En d’autres termes, il s’agissait de voir s’ils étaient lisibles – je voulais le savoir
ET s’ils étaient publics.ÉCRITABLE.
En passant, AWS fournit un outil de ligne de commande, aws-cli. Je le sais parce que je l'ai déjà
utilisé, donc un rapide sudo apt-get install aws-cli sur ma VM et j'avais les outils. Je les ai configurés
avec mon propre compte AWS et j'étais prêt à partir. Vous pouvez trouver des instructions à ce sujet
sur docs.aws.amazon.com/cli/latest/userguide/installing.html
Maintenant, la commandeaide AWS S3ouvrira l'aide S3 et détaillera les commandes disponibles, quelque
chose comme 6 au moment d'écrire ces lignes. L'un d'eux estmvsous la forme deaws s3 mv [FICHIER] [s3://
BUCKET]. Donc dans mon cas j'ai essayé :
toucher test.txt
aws s3 mv test.txt s3://hackerone.marketing
C'était le premier compartiment pour lequel j'ai reçu un accès refusé pour AND » échec du déplacement : ./
test.txt vers s3://hackerone.marketing/test.txt Une erreur client (AccessDenied) s'est produite lors de l'appel de
l'opération PutObject : Accès refusé. »
Alors j'ai essayé le suivantaws s3 mv test.txt s3://hackerone.filesET� SUCCÈS ! J'ai reçu le

message « déplacer : ./test.txt vers s3://hackerone.files/test.txt »
Incroyable! Maintenant, j'ai essayé de supprimer le fichier :aws s3 rm s3://hackerone.files/test.txtET encore

une fois, SUCCÈS !
Mais maintenant, le doute de soi. Je me suis rapidement connecté à HackerOne pour créer un rapport et, au fur et à mesure
que je tapais, j'ai réalisé que je ne pouvais pas réellement confirmer la propriété du compartiment. AWS S3 permet à
quiconque de créer n'importe quel compartiment dans un espace de noms global. Cela signifie que vous, le lecteur, auriez
pu posséder le seau que je piratais.
Je n'étais pas sûr de devoir signaler sans confirmer. J'ai cherché sur Google pour voir si je pouvais trouver
une référence au seau que j'ai trouvé – rien. Je me suis éloigné de l'ordinateur pour me vider la tête. Je
pensais que, pire encore, j'obtiendrais un autre rapport N/A et -5 répétitions. D'un autre côté, j'ai pensé
que cela valait au moins 500 $, peut-être 1 000 $ en fonction de la vulnérabilité de Shopify.
J'ai appuyé sur Soumettre et je me suis couché. Quand je me suis réveillé, HackerOne avait répondu en
félicitant la découverte, en disant qu'ils l'avaient déjà réparé et, ce faisant, ils avaient découvert quelques
autres compartiments vulnérables. Succès! Et c'est à leur honneur que lorsqu'ils ont attribué la prime, ils ont
pris en compte la gravité potentielle de la situation, y compris les autres seaux que je n'ai pas trouvés mais qui
étaient vulnérables.
Points à retenir
Il y a plusieurs points à retenir de ceci :
1. Ne sous-estimez pas votre ingéniosité et le potentiel d'erreurs des développeurs.

HackerOne est une formidable équipe de chercheurs en sécurité formidables.
Mais les gens font des erreurs. Remettez en question vos hypothèses.
2. N'abandonnez pas après la première tentative. Quand j'ai trouvé ceci, en parcourant chaque compartiment
n'était pas disponible et j'ai failli m'en aller. Mais ensuite j'ai essayé d'écrire un fichier et
ça a marché.
3. Tout est question de connaissances. Si vous savez quels types de vulnérabilités existent,
vous savez quoi rechercher et tester. L’achat de ce livre a été une première étape formidable.
4. Je l'ai déjà dit, je le répète, une surface d'attaque est bien plus qu'un site Web,
ce sont aussi les services que l'entreprise utilise. Sortez des sentiers battus.
5. Contourner l'authentification à deux facteurs de GitLab
Difficulté: Moyen
URL: n / A
Date de déclaration: 3 avril 2016
Prime payée: n / A
Description:
Le 3 avril, Jobert Abma (co-fondateur de HackerOne) a signalé à GitLab qu'avec

l'authentification à deux facteurs activée, un attaquant pouvait se connecter au compte d'une
victime sans réellement connaître son mot de passe.
Pour ceux qui ne sont pas familiers, l'authentification à deux facteurs est un processus de connexion en deux
étapes : généralement, un utilisateur saisit son nom d'utilisateur et son mot de passe, puis le site enverra un
code d'autorisation, généralement par e-mail ou SMS, que l'utilisateur doit saisir pour terminer la connexion.
processus.
Dans ce cas, Jobert a remarqué que lors du processus de connexion, une fois qu'un attaquant saisissait son
nom d'utilisateur et son mot de passe, un token était envoyé pour finaliser la connexion. Lors de la soumission
du jeton, l'appel POST ressemblait à :
POSTE/utilisateurs/connexion HTTP/1
.1 Hôte:159.xxx.xxx.xxx
...
- - - - - - - - - - 1881604860
Disposition du contenu:Données de formulaire;nom="utilisateur[otp_attempt]"
212421
- - - - - - - - - - 1881604860--
Si un attaquant l'a intercepté et a ajouté un nom d'utilisateur à l'appel, par exemple :
POSTE/utilisateurs/connexion HTTP/1
.1 Hôte:159.xxx.xxx.xxx
...
- - - - - - - - - - 1881604860
Disposition du contenu:Données de formulaire;nom="utilisateur[otp_attempt]"
212421
- - - - - - - - - - 1881604860
Disposition du contenu:Données de formulaire;nom="utilisateur[se connecter]"
John
- - - - - - - - - - 1881604860--
L'attaquant pourrait se connecter au compte de John si le jeton otp_attempt était valide pour John.
En d'autres termes, lors de l'authentification en deux étapes, si un attaquant ajoutait un Utilisateur
en ligne]paramètre, ils pouvaient changer le compte auquel ils étaient connectés.
Désormais, la seule mise en garde ici était que l’attaquant devait disposer d’un jeton OTP valide pour la
victime. Mais c’est là que le brutalforcement viendrait si. Si les administrateurs du site n'avaient pas mis
en œuvre de limitation de débit, Jobert aurait peut-être pu appeler à plusieurs reprises le serveur pour
deviner un jeton valide. La probabilité d'une attaque réussie dépendrait de la
le temps de transit qui envoie la requête au serveur et la durée de validité d'un jeton, mais peu
importe, la vulnérabilité ici est assez évidente.
Points à retenir
L'authentification à deux facteurs est un système difficile à mettre en œuvre. Lorsque vous remarquez qu'un
site l'utilise, vous souhaiterez tester entièrement toutes les fonctionnalités, y compris la durée de vie du jeton,
le nombre maximum de tentatives, la réutilisation des jetons expirés, la probabilité de deviner un jeton, etc.
6. Divulgation d'informations Yahoo PHP
Difficulté: Moyen
URL: http://nc10.n9323.mail.ne1.yahoo.com/phpinfo.php
Lien de rapport:https://blog.it-securityguard.com/bugbounty-yahoo-phpinfo-php-disclosure-2/9
Date de divulgation: 16 octobre 2014
Prime payée: n / A
Description:
Bien que cela n'ait pas été très payant comme certaines des autres vulnérabilités que j'ai incluses (il a en
fait payé 0 $, ce qui est surprenant !), c'est l'un de mes rapports préférés car il m'a aidé à comprendre
l'importance de l'analyse et de l'automatisation du réseau. .
En octobre 2014, Patrik Fehrenbach (dont vous devriez vous souvenir dans l'interview n°2 de Hacking Pro Tips -
un gars génial !) a trouvé un serveur Yahoo avec un fichier phpinfo() accessible. Si vous n'êtes pas familier avec
phpinfo(), c'est une commande sensible qui ne devrait jamais être accessible en production, et encore moins
publiquement disponible, car elle divulgue toutes sortes d'informations sur le serveur.
Maintenant, vous vous demandez peut-être comment Patrik a trouvé http://nc10.n9323.mail.ne1.yahoo.com

- Bien sûr. Il s'avère qu'il a envoyé une requête ping à Yahoo.com qui a renvoyé 98.138.253.109. Ensuite, il a
transmis cela à WHOIS et a découvert que Yahoo possédait réellement les éléments suivants :
9https://blog.it-securityguard.com/bugbounty-yahoo-phpinfo-php-disclosure-2/
PlageNet: 98.136.0.0 - 98.139.255.255

CIDR: 98.136.0.0/14
OriginAS:
Nom du réseau:UN-YAHOO-Poignée
réseau US9:FILET-98-136-0-0-1 Parent:
FILET-98-0-0-0-0 Type de réseau:Date
d'enregistrement de l'allocation directe:
2007-12-07
Mis à jour: 2012-03-02

Réf:http://qui est.arine.filet/repos/net/FILET-98-136-0-0-1
Remarquez la première ligne : Yahoo possède un bloc massif d'adresses IP, de 98.136.0.0 à
98.139.255.255, ou 98.136.0.0/14, soit 260 000 adresses IP uniques. Cela fait beaucoup de
cibles potentielles.
Patrik a ensuite écrit un simple script bash pour rechercher un fichier phpinfo disponible :
# !/bin/bash
pouripa dans98.13{6..9}.{0..255}.{0..255};faire
wget -t1-T5http://${ipa}/phpinfo.php;fait&
En exécutant cela, il a trouvé ce serveur Yahoo aléatoire.
Points à retenir
Lors d'un piratage, considérez l'ensemble de l'infrastructure d'une entreprise comme un jeu équitable, à
moins qu'elle ne vous dise qu'elle est hors de portée. Bien que ce rapport n'ait pas versé de prime, je sais que
Patrik a utilisé des techniques similaires pour trouver des paiements importants à quatre chiffres.
De plus, vous remarquerez qu'il y avait ici 260 000 adresses potentielles, qu'il
aurait été impossible d'analyser manuellement. Lors de l’exécution de ce type de
tests, l’automatisation est extrêmement importante et doit être utilisée.
7. Vote HackerOne Hacktivity
Difficulté: Moyen
URL: https://hackerone.com/hacktivity
Lien de rapport:https://hackereone.com/reports/137503dix
Date de déclaration: 10 mai 2016
dixhttps://hackerone.com/reports/137503
Prime payée: Guirlande
Description:
Bien que techniquement il ne s’agisse pas vraiment d’une faille de sécurité dans ce cas, ce rapport est un excellent
exemple de la manière de sortir des sentiers battus.
Fin avril/début mai 2016, HackerOne a développé une fonctionnalité permettant aux pirates
informatiques de voter sur les rapports via leur liste Hacktivity. Il existait un moyen simple et un moyen
difficile de savoir que la fonctionnalité était disponible. De manière simple, un appel GET à/utilisateur
actuelune fois connecté, il incluraithacktivity_voting_enabled : faux. La méthode dure est un peu plus
intéressante, où se situe la vulnérabilité et pourquoi j'inclus ce rapport.
Si vous visitez la hacktivity et consultez la source de la page, vous remarquerez qu'elle est assez clairsemée, juste
quelques divs et aucun contenu réel.
Source de la page HackerOne Hacktivity
Maintenant, si vous n'êtes pas familier avec leur plateforme et que vous n'avez pas de plugin comme wappalyzer
installé, il suffit de regarder la source de cette page pour vous dire que le contenu est
rendu par Javascript.
Donc, dans cet esprit, si vous ouvrez les outils de développement dans Chrome ou Firefox, vous pouvez
consulter le code source Javascript (dans Chrome, vous allez dans les sources et à gauche,haut-
> hackerone.com->actifs->frontend-XXX.js). Les outils de développement Chrome sont livrés avec un
joli{} joli bouton d'impression qui rendra lisible le Javascript minifié. Vous pouvez également utiliser Burp
et consulter la réponse renvoyant ce fichier Javascript.
C'est là que réside la raison de l'inclusion, si vous recherchez dans le JavascriptPOSTEvous pouvez trouver
un certain nombre de chemins utilisés par HackerOne qui peuvent ne pas être évidents en fonction de
vos autorisations et de ce qui vous est exposé en tant que contenu. Dont l'un est :
Application Hackerone Javascript Vote POST
Comme vous pouvez le constater, nous disposons de deux voies pour la fonctionnalité de vote. Au moment de la rédaction de ce
rapport, vous pouviez effectivement passer ces appels et voter sur les rapports.
Maintenant, c'est une façon de trouver la fonctionnalité - dans le rapport, le pirate informatique a utilisé une
autre méthode, en interceptant les réponses de HackerOne (vraisemblablement en utilisant un outil comme
Burp), ils ont remplacé l'attribut renvoyé comme faux par vrai. Cela exposait ensuite les éléments de vote qui,
une fois cliqués, effectuaient les appels POST et DELETE disponibles.
La raison pour laquelle je vous ai expliqué le Javascript est que l'interaction avec la réponse JSON peut ne pas
toujours exposer de nouveaux éléments HTML. En conséquence, la navigation en Javascript peut exposer des
points de terminaison autrement « cachés » avec lesquels interagir.
Points à retenir
Le code source Javascript vous fournit le code source réel d'une cible que vous pouvez
explorer. C'est génial car vos tests vont de la boîte noire, sans aucune idée de ce que fait le
back-end, à la boîte blanche (mais pas entièrement) où vous avez un aperçu de la façon
dont le code est exécuté. Cela ne signifie pas que vous devez parcourir chaque ligne, l'appel
POST dans ce cas a été trouvé sur la ligne 20570 avec une simple recherche dePOSTE.
8. Accéder à l'installation Memcache de PornHub
Difficulté: Moyen
URL: stage.pornhub.com
Date de déclaration: 1er mars 2016
Prime payée: 2500$
Description:
Avant son lancement public, PornHub gérait un programme privé de primes de bugs sur HackerOne avec une large
portée de primes de*.pornohub.comce qui, pour la plupart des pirates, signifie que tous les sous-domaines de
PornHub sont un jeu équitable. L’astuce consiste maintenant à les trouver.
Dans son article de blog, Andy Gill@ZephrFish12explique pourquoi c'est génial : en testant
l'existence de différents noms de sous-domaines à l'aide d'une liste de plus d'un million de noms
potentiels, il a découvert environ 90 cibles de piratage possibles.
Maintenant, visiter tous ces sites pour voir ce qui est disponible prendrait beaucoup de temps, il a
donc automatisé le processus à l'aide de l'outil Eyewitness (inclus dans le chapitre Outils) qui prend
des captures d'écran des URL avec des pages HTTP/HTTPS valides et fournit une belle
12http://www.twitter.com/ZephrFish
rapport des sites en écoute sur les ports 80, 443, 8080 et 8443 (ports HTTP et HTTPS communs).
Selon son article, Andy a légèrement changé de vitesse ici et a utilisé l'outil Nmap pour approfondir le
sous-domaine.stage.pornhub.com. Lorsque je lui ai demandé pourquoi, il a expliqué que, d'après son
expérience, les serveurs de test et de développement sont plus susceptibles d'avoir des autorisations de
sécurité mal configurées que les serveurs de production. Donc, pour commencer, il a obtenu l'IP du sous-
domaine en utilisant la commande nslookup :
Serveur nslookup
stage.pornhub.com : 8.8.8.8
Adresse : 8.8.8.8#53
Réponse ne faisant pas autorité :
Nom : stage.pornhub.com
Adresse : 31.192.117.70
J'ai aussi vu cela faire avec la commande,pinger, mais de toute façon, il avait maintenant
l'adresse IP du sous-domaine et en utilisant la commandesudo nmap -sSV -p- 31.192.117.70
- oA étape__ph -T4 &il a eu:
À partir de Nmap 6.47 ( http://nmap.org ) le 07/06/2016 à 14h09 CEST Rapport

d'analyse Nmap pour 31.192.117.70
L'hôte est opérationnel (latence de
0,017 s). Non affiché : 65 532 ports
fermés PORT STATE SERVICE VERSION
80/tcp ouvert http nginx
443/tcp ouvrir http nginx 60893/
tcp ouvrir le cache mémoire
Détection de service effectuée. Veuillez signaler tout résultat incorrect sur http://nmap.org/submit/ . Nmap
terminé : 1 adresse IP (1 hôte activé) analysée en 22,73 secondes
Décomposer la commande :
• le flag -sSV définit le type de paquet à envoyer au serveur et indique à Nmap d'essayer de
déterminer tout service sur les ports ouverts
• le -p- indique à Nmap de vérifier tous les 65 535 ports (par défaut, il ne vérifiera que les 1 000 les
plus populaires)
• 31.192.117.70 est l'adresse IP à analyser
• - oA stage__ph indique à Nmap d'afficher les résultats dans ses trois formats principaux à la fois en
utilisant le nom de fichier stage__ph
• - T4 définit le timing de la tâche (les options sont 0 à 5 et plus c'est plus rapide)
En ce qui concerne le résultat, l'élément clé à noter est que le port 60893 est ouvert et exécute ce que Nmap considère
comme du cache mémoire. Pour ceux qui ne sont pas familiers, memcache est un service de mise en cache qui utilise des
paires clé-valeur pour stocker des données arbitraires. Il est généralement utilisé pour accélérer le contenu d'un site Web en
fournissant un service plus rapide. Un service similaire est Redis.
Trouver cela n'est pas une vulnérabilité en soi, mais c'est un signal d'alarme définitif (bien que les guides
d'installation que j'ai lus recommandent de la rendre inaccessible publiquement par mesure de sécurité). En le
testant, il est surprenant que PornHub n'ait activé aucune sécurité, ce qui signifie qu'Andy pouvait se connecter
au service sans nom d'utilisateur ni mot de passe via netcat, un programme utilitaire utilisé pour lire et écrire
via une connexion réseau TCP ou UDP. Après la connexion, il a simplement exécuté des commandes pour
obtenir la version, les statistiques, etc. afin de confirmer la connexion et la vulnérabilité.
Cependant, un attaquant malveillant aurait pu utiliser cet accès pour :
• Provoquer un déni de service (DOS) en écrivant et en effaçant constamment le cache, gardant

ainsi le serveur occupé (cela dépend de la configuration du site)
• Provoquer un DOS en remplissant le service avec des données indésirables mises en cache, encore une fois, en fonction de la
configuration du service.
• Exécuter des scripts intersites en injectant une charge utile JS malveillante sous forme de données mises en cache
valides à servir aux utilisateurs.
• Et éventuellement, exécuter une injection SQL si les données memcache étaient stockées dans la base de
données
Points à retenir
Les sous-domaines et les configurations réseau plus larges représentent un grand potentiel de
piratage. Si vous remarquez qu'un programme inclut *.SITE.com dans son champ d'application, essayez
de trouver des sous-domaines qui peuvent être vulnérables plutôt que de vous attaquer aux fruits les
plus faciles à trouver sur le site principal que tout le monde recherche peut-être. Cela vaut également la
peine de vous familiariser avec des outils comme Nmap, eyewitness, knockpy, etc. qui vous aideront à
vous mettre à la place d'Andy.
9. Contourner les protections des comptes Twitter
Difficulté: Facile
URL: twitter.com
Lien de rapport: N / A
Date de déclaration: Prime attribuée en octobre 2016
Prime payée: 560$
Description:
En discutant avec Karan Saini, il a partagé avec moi la vulnérabilité Twitter suivante afin que je puisse
l'inclure et la partager ici. Bien que le rapport ne soit pas divulgué (au moment de la rédaction), Twitter
lui a donné la permission de partager les détails et il y a deux points à retenir intéressants de sa
découverte.
En testant les fonctionnalités de sécurité du compte Twitter, Karan a remarqué que lorsque vous tentiez
pour la première fois de vous connecter à Twitter à partir d'une adresse IP/navigateur non reconnu,
Twitter peut vous demander certaines informations de validation de compte telles qu'un e-mail ou un
numéro de téléphone associé à le compte. Ainsi, si un attaquant parvenait à compromettre votre nom
d'utilisateur et votre mot de passe, il serait potentiellement empêché de se connecter et de prendre le
contrôle de votre compte sur la base de ces informations supplémentaires requises.
Cependant, sans se laisser décourager, après que Karan ait créé un tout nouveau compte, utilisé un VPN et
testé les fonctionnalités du navigateur de son ordinateur portable, il a ensuite pensé à utiliser son téléphone, à
se connecter au même VPN et à se connecter au compte. Il s'avère que cette fois, il n'a pas été invité à saisir
des informations supplémentaires : il avait un accès direct au compte de la « victime ». De plus, il pouvait
accéder aux paramètres du compte et afficher l'adresse e-mail et le numéro de téléphone de l'utilisateur, lui
permettant ainsi d'accéder au bureau (si cela importait).
En réponse, Twitter a validé et résolu le problème, attribuant à Karan 560 $.
Points à retenir
J'ai inclus cet exemple car il démontre deux choses : premièrement, même si cela réduit
l'impact de la vulnérabilité, il arrive parfois que le signalement d'un bug qui suppose qu'un
attaquant connaît le nom d'utilisateur et le mot de passe d'une victime est acceptable à
condition que vous puissiez expliquer quelle est la vulnérabilité. et démontrer sa gravité.
Deuxièmement, lors des tests de vulnérabilités liées à la logique des applications, tenez compte des
différentes manières d'accéder à une application et de la cohérence des comportements liés à la
sécurité sur toutes les plates-formes. Dans ce cas, il s’agissait de navigateurs et d’applications mobiles,
mais cela pouvait également inclure des applications tierces ou des points de terminaison d’API.
Résumé
Les vulnérabilités basées sur la logique des applications n’impliquent pas nécessairement toujours du code. Au lieu
de cela, les exploiter nécessite souvent un œil attentif et davantage de réflexion hors des sentiers battus. Toujours
soyez à l’affût d’autres outils et services qu’un site peut utiliser, car ceux-ci représentent un nouveau vecteur
d’attaque. Cela peut inclure une bibliothèque Javascript que le site utilise pour afficher le contenu.
Le plus souvent, les trouver nécessitera un intercepteur proxy qui vous permettra de jouer avec les valeurs
avant de les envoyer au site que vous explorez. Essayez de modifier toutes les valeurs qui semblent liées à
l'identification de votre compte. Cela peut inclure la configuration de deux comptes différents afin que vous
disposiez de deux ensembles d'informations d'identification valides dont vous savez qu'ils fonctionneront.
Recherchez également les points de terminaison cachés/rares qui pourraient exposer des fonctionnalités
accessibles involontairement.
Assurez-vous également de prendre en compte la cohérence entre les différentes manières d'accéder au
service, par exemple via le bureau, des applications tierces, des applications mobiles ou des API. Les
protections offertes via une méthode peuvent ne pas être appliquées de manière cohérente à toutes les
autres, créant ainsi un problème de sécurité.
Enfin, soyez à l’affût des nouvelles fonctionnalités, elles représentent souvent de nouveaux domaines de tests !
Et si/quand cela est possible, automatisez vos tests pour mieux utiliser votre temps.
21. Pour commencer
Malheureusement, il n’existe pas de formule magique pour pirater et il y a trop de technologies en constante
évolution pour que je puisse expliquer chaque méthode permettant de détecter un bug. Bien que ce chapitre ne
fasse pas de vous une machine de piratage d'élite, vous pouvez apprendre les modèles suivis par les chasseurs de
bogues qui réussissent, qui conduisent généralement à plus de primes. Ce chapitre vous guidera à travers une
approche de base pour commencer à pirater n'importe quelle application. Il est basé sur mon expérience personnelle
en interviewant des pirates informatiques à succès, en lisant des blogs, en regardant des vidéos et en piratant.
Tout d’abord, vous devez redéfinir ce que vous considérez comme un succès. Vous pourriez considérer que votre
objectif est de trouver des bogues sur des programmes de haut niveau, de trouver autant de bogues que possible ou
simplement de gagner de l'argent. Si vous ciblez des programmes matures comme Uber, Shopify, Twitter, Google,
etc., la réussite financière risque d'arriver plus lentement. Des hackers très intelligents et accomplis testent ces
programmes quotidiennement et il est facile de se décourager lorsqu'on ne trouve pas de bugs. Pour cette raison, je
pense qu'il est important de définir le succès comme la connaissance et l'expérience acquises, plutôt que comme les
bugs découverts ou l'argent gagné. L’objectif devrait être de se concentrer sur l’apprentissage de quelque chose de
nouveau, de reconnaître des modèles et de tester de nouvelles technologies, du moins lorsque vous commencez.
Recadrer le succès de cette manière vous permet de rester positif quant à votre piratage pendant les périodes
de sécheresse. Les vulnérabilités viendront avec le temps. Tant que les gens écriront du code, ils feront des
erreurs. Une fois que vous avez réfléchi à ce à quoi ressemble le succès, il est temps d’employer une
méthodologie.
Reconnaissance
Commencez à aborder n’importe quel programme de bug bounty avec une certaine reconnaissance, ou reconnaissance, en en
apprenant davantage sur l’application. Comme vous l'avez appris dans les chapitres précédents, il y a beaucoup de choses à prendre
en compte lors du test d'une application. Commencez par poser des questions de base, telles que :
• Quelle est la portée du programme ? Est-ce *.example.com ou simplement www.example.com ?

• Combien de sous-domaines l'entreprise possède-t-elle ?
• Combien d'adresses IP l'entreprise possède-t-elle ?
• De quel type de site s'agit-il ? Un logiciel en tant que service ? Open source? Collaboratif ? Payant ou
gratuit ?
• Quelles technologies utilise-t-il ? Dans quel langage de programmation est-il codé ? Quelle base de
données ? Quels frameworks utilise-t-il ?
Commencer 189
Ce ne sont là que quelques-uns des éléments à prendre en compte au moment de démarrer. Pour les besoins de ce
chapitre, supposons que vous testez une application avec une portée ouverte telle que *.example.com. Commencez
par les outils que vous pouvez exécuter en arrière-plan afin de pouvoir effectuer d'autres reconnaissances en
attendant les résultats des outils. Vous pouvez exécuter ces outils depuis votre propre ordinateur, mais vous risquez
que des entreprises comme Akamai interdisent votre adresse IP. Étant donné qu'Akamai est un pare-feu
d'applications Web populaire, être banni par celui-ci signifie que vous ne pourrez peut-être pas visiter les sites
courants. Pour éviter une interdiction, je recommande de créer un serveur privé virtuel (VPS) auprès d'un fournisseur
d'hébergement cloud qui permet des tests de sécurité à partir de leurs systèmes. Vous devez rechercher votre
fournisseur de cloud, car certains n'autorisent pas ce type de tests (par exemple, au moment de la rédaction de ces
lignes, Amazon Web Services n'autorise pas les tests de sécurité sans autorisation explicite).
Énumération des sous-domaines
Puisque vous testez sur une portée ouverte, vous pouvez commencer votre reconnaissance en recherchant des
sous-domaines à l'aide de votre VPS. Plus vous trouvez de sous-domaines, plus vous disposerez de surface
d’attaque. Pour ce faire, je recommande d'utiliser l'outil Subfinder, qui est rapide et écrit dans le langage de
programmation Go. Subfinder extraira les enregistrements de sous-domaines d'un site en fonction de diverses
sources, notamment les enregistrements de certificats, les résultats des moteurs de recherche,
WaybackArchive et autres.
L'énumération par défaut de Subfinder peut ne pas trouver tous les sous-domaines. Les sous-domaines
associés à un certificat SSL spécifique sont faciles à trouver grâce aux journaux de certificat qui
enregistrent de manière transparente les certificats SSL enregistrés. Par exemple, si un site enregistre un
certificat pour test.example.com, il est probable que ce sous-domaine existera, au moins au moment de
l'enregistrement. Cependant, il est possible pour un site d'enregistrer un certificat pour un sous-domaine
générique (*.example.com). Si tel est le cas, vous ne pourrez peut-être trouver certains sous-domaines
que par approximation par force brute.
Idéalement, Subfinder peut également vous aider à créer des sous-domaines en utilisant une liste de
mots commune. La liste de sécurité du référentiel GitHub SecLists, référencée à l'annexe X, contient des
listes de sous-domaines communs. Jason Haddix a également publié une liste utile disponible sur https://
gist.github.com/jhaddix/86a06c5dc309d08580a018c66354a056.
Si vous ne souhaitez pas utiliser Subfinder et souhaitez simplement parcourir les certificats SSL, crt.sh est une
excellente référence pour vérifier si des certificats génériques ont été enregistrés. Si vous trouvez un certificat
générique, vous pouvez rechercher sur cesys.io le hachage du certificat. Il existe généralement même un lien direct
vers cesys.io sur crt.sh pour chaque certificat.
Une fois que vous avez fini d'énumérer les sous-domaines pour *.example.com, vous pouvez analyser le port et
capturer les sites que vous trouvez. Avant de continuer, vous devez également vous demander s'il est judicieux
d'énumérer les sous-domaines des sous-domaines. Par exemple, si vous constatez qu'un site enregistre un
certificat SSL pour *.corp.example.com, il est probable que vous puissiez trouver davantage de sous-domaines
en énumérant ce sous-domaine.
Commencer 190
Analyse des ports
Après avoir énuméré les sous-domaines, vous pouvez lancer l'analyse des ports pour identifier davantage de surfaces
d'attaque, y compris les services en cours d'exécution. Par exemple, en analysant les ports de Pornhub, Andy Gill a
trouvé un serveur Memcache exposé, gagnant 2 500 $, comme indiqué au chapitre 19.
Les résultats de l'analyse des ports peuvent également être révélateurs de la sécurité globale d'une entreprise. Par
exemple, une entreprise qui a fermé tous les ports sauf 80 et 443 (ports Web courants pour l'hébergement de sites
HTTP et HTTPS) est susceptible d'être soucieuse de la sécurité, tandis qu'une entreprise avec de nombreux ports
ouverts est probablement le contraire et peut avoir de meilleurs résultats. potentiel de primes.
Deux outils d'analyse de ports courants sont Nmap et Masscan. Nmap est un outil plus ancien et peut être lent
à moins que vous sachiez comment l'optimiser. Cependant, c'est génial car vous pouvez lui donner une liste
d'URL et il déterminera l'adresse IP à analyser. Il est également modulaire afin que vous puissiez inclure
d'autres contrôles dans votre analyse. Par exemple, l’utilisation du script intitulé httpenum effectuera un
bruteforcing de fichiers et de répertoires. En revanche, Masscan est extrêmement rapide et peut s’avérer
préférable lorsque vous disposez d’une liste d’adresses IP à analyser. J'utilise Masscan pour rechercher des
ports couramment ouverts tels que 80, 443, 8080 ou 8443, puis je combine les résultats avec une capture
d'écran (un sujet abordé dans la section suivante).
Une chose à noter lors de l'analyse des ports à partir d'une liste de sous-domaines est les adresses
IP vers lesquelles ces domaines sont résolus. Si vous constatez que tous les sous-domaines sauf un
sont résolus en une plage d'adresses IP commune (par exemple, les adresses IP appartenant à AWS
ou Google Cloud Compute), il peut être utile d'examiner la valeur aberrante. La différence d'adresse
IP peut indiquer qu'une application personnalisée ou tierce ne partage pas le même niveau de
sécurité que les applications principales de l'entreprise, qui résident sur la plage d'adresses IP
commune. Comme décrit au chapitre 15, Frans Rosen et Uranium238 ont exploité ce phénomène en
reprenant les services de Legal Robot et Uber.
Capture d'écran
Comme pour l'analyse des ports, une bonne étape à suivre une fois que vous avez une liste de sous-domaines
est de les capturer. Ceci est utile car cela vous donne un aperçu visuel de la portée du programme. Lorsque
vous parcourez des captures d’écran, vous devez rechercher une variété de choses. Tout d’abord, recherchez
les messages d’erreur courants provenant de services connus pour être associés aux reprises de sous-
domaines. Comme décrit au chapitre 14, une application qui s'appuie sur des services externes peut évoluer au
fil du temps et ses enregistrements DNS peuvent avoir été oubliés. Si un attaquant parvient à prendre le
contrôle du service, cela pourrait avoir un impact significatif sur l'application et ses utilisateurs.
Alternativement, vous constaterez peut-être que la capture d'écran ne révèle pas de message d'erreur, mais
vous remarquerez peut-être quand même que le sous-domaine s'appuie sur un service tiers.
Deuxièmement, vous pouvez rechercher du contenu sensible. Par exemple, si tous les sous-domaines
trouvés sur *.corp.example.com renvoient un accès refusé 403, à l'exception d'un sous-domaine qui a
une connexion à un site Web inhabituel, vous devez enquêter sur ce site inhabituel car il pourrait être
Commencer 191
implémenter un comportement personnalisé. De même, vous devez également faire attention aux pages de
connexion administrative, aux pages d'installation par défaut, etc.
Enfin, recherchez des applications intéressantes à tester. L'importance des applications trouvées sur les sous-
domaines peut être difficile à déterminer tant que vous ne vous êtes pas familiarisé avec elles, mais elles peuvent
conduire à de grandes récompenses, tout comme celle que Jasmin Landry a trouvée lorsqu'il a augmenté son accès
SSH pour une exécution de code à distance, comme décrit au chapitre 13. .
Il existe quelques outils qui peuvent vous aider à capturer des sites. Au moment de la rédaction, j'utilise
HTTPScreenShot et Gowitness. HTTPScreenShot est utile pour deux raisons : premièrement, vous pouvez
l'utiliser avec une liste d'adresses IP et il les capturera et énumérera les autres sous-domaines associés
aux certificats SSL qu'il analyse. Deuxièmement, il regroupera vos résultats en groupes selon que les
pages contiennent 403 messages, 500 messages, utilisent les mêmes systèmes de gestion de contenu,
etc. L'outil inclura également les en-têtes HTTP qu'il trouve, ce qui est également utile. Gowitness est une
alternative rapide et légère pour la capture d'écran. J'ai tendance à l'utiliser lorsque j'ai une liste d'URL au
lieu d'adresses IP. Il inclura également les en-têtes qu'il reçoit lors de la capture d'écran. Enfin, même si
je ne l'utilise pas, Acquatone est un autre outil qui mérite d'être mentionné. Au moment de la rédaction
de cet article, il a récemment été réécrit dans Go et inclut le clustering, une sortie facile des résultats
pour correspondre au format requis par d'autres outils et d'autres fonctionnalités.
Une fois que vous avez examiné vos sous-domaines et effectué une reconnaissance visuelle, l'étape suivante consiste à rechercher
du contenu intéressant.
Découverte de contenu
Il existe différentes manières d’aborder la découverte de contenu. Tout d’abord, vous pouvez tenter de
découvrir des fichiers et des répertoires en les forçant brutalement. Le succès dépend de la liste de mots que
vous utilisez ; comme mentionné, SecLists en fournit de bonnes, en particulier les listes de radeaux sont celles
que j'utilise. Au fil du temps, vous pouvez également compiler votre propre liste de fichiers fréquemment
trouvés si vous suivez les résultats de cette étape.
Une fois que vous avez une liste de fichiers et de noms de répertoires, vous avez le choix entre quelques
outils. J'ai tendance à utiliser Gobuster ou Burp Suite Pro. Gobuster est un outil de force brute
personnalisable et rapide écrit en Go. En lui donnant un domaine et une liste de mots, il testera
l'existence de répertoires et de fichiers et confirmera la réponse du serveur. De plus, l'outil de Meg,
développé par Tom Hudson et également écrit sous Go, vous permet de tester plusieurs chemins sur
plusieurs hôtes simultanément. C'est idéal lorsque vous avez trouvé de nombreux sous-domaines et que
vous souhaitez découvrir du contenu dans chacun d'eux simultanément.
Comme j'utilise Burp Suite Pro pour proxy mon trafic, j'utiliserai son outil de découverte de contenu intégré ou Intruder.
L'outil de découverte de contenu de Burp est configurable et vous permet d'utiliser une liste de mots personnalisée ou celle
intégrée, de rechercher des permutations d'extensions de fichiers, de définir le nombre de dossiers imbriqués à forcer
brutalement, et bien plus encore. Lorsque j'utilise Burp Intruder, j'enverrai une demande pour le
Commencer 192
domaine que je teste sur Intruder et définit la charge utile à la fin du chemin racine. Ensuite, j'ajouterai ma liste
comme charge utile et lancerai l'attaque. Je trierai généralement mes résultats en fonction de la longueur du
contenu ou de l'état de la réponse, en fonction de la réponse de l'application. Si je découvre un dossier
intéressant de cette façon, je peux réexécuter Intruder sur ce dossier pour découvrir les fichiers imbriqués.
Lorsque vous devez aller au-delà du bruteforcing de fichiers et de répertoires, Google Dorking, comme
décrit dans la vulnérabilité découverte par Brett Buerhaus au chapitre 10, peut également fournir une
découverte de contenu intéressante. Google Dorking peut vous faire gagner du temps, en particulier
lorsque vous trouvez des paramètres d'URL généralement associés à des vulnérabilités telles que url,
redirect_to, id, etc. Exploit DB gère une base de données de Google Dorks pour des cas d'utilisation
spécifiques, que vous pouvez trouver sur https://www.exploit-db.com/google-hacking-database/.
Une autre approche pour trouver du contenu intéressant consiste à consulter le GitHub de l'entreprise. Vous
pouvez trouver des référentiels open source de l'entreprise ou des informations utiles sur les technologies
qu'ils utilisent. C'est ainsi que Michiel Prins a découvert l'exécution de code à distance sur Algolia, comme
expliqué au chapitre 12. Vous pouvez utiliser l'outil GitRob pour explorer les référentiels GitHub à la recherche
de secrets d'application et d'autres informations sensibles. De plus, vous pouvez également consulter les
référentiels de code et rechercher des bibliothèques tierces sur lesquelles s'appuie une application. Si vous
parvenez à trouver un projet abandonné ou une vulnérabilité chez un tiers qui affecte le site, les deux
pourraient valoir une prime de bug. Les référentiels de code peuvent également vous donner un aperçu de la
manière dont une entreprise a géré les vulnérabilités précédentes, en particulier pour les entreprises open
source comme GitLab.
Bogues précédents
L'une des dernières étapes que je recommande en reconnaissance est de vous familiariser avec les bugs précédents.
Les articles de hackers, les rapports divulgués, les CVE, les exploits publiés, etc. sont utiles pour cela. Comme cela a
été répété tout au long de ce livre, ce n'est pas parce que le code est mis à jour que toutes les vulnérabilités sont
corrigées. Assurez-vous de tester les modifications. Lorsqu’un correctif est déployé, cela signifie également un
nouveau code, qui pourrait contenir des bugs.
Le bug de 15 250 $ @cache-money trouvé chez Shopify Partners était le résultat de la lecture d'un rapport de bug
précédemment divulgué et du nouveau test de la même fonctionnalité. Comme @cachemoney, lorsque des
vulnérabilités intéressantes ou nouvelles sont divulguées publiquement, vous devez lire le rapport et visiter
l'application. Dans le pire des cas, vous ne trouverez pas de vulnérabilité, mais vous développerez de nouvelles
compétences en testant cette fonctionnalité. Au mieux, vous pouvez contourner le correctif du développeur ou
trouver une nouvelle vulnérabilité.
Après avoir couvert tous les principaux domaines de reconnaissance, il est temps de passer aux tests de l'application.
Pendant que vous effectuez des tests, gardez à l’esprit que la reconnaissance fait partie intégrante de la recherche de
primes de bogues. C'est toujours une bonne idée de revenir puisque la surface d'attaque change et évolue
constamment.
Commencer 193
Tester l'application
Il n’existe pas d’approche unique pour tester une application. La méthodologie et les techniques que
vous utilisez dépendent du type d'application que vous testez, de la même manière que la portée du
programme peut définir votre reconnaissance. Pour les besoins de cette section, je donnerai un aperçu
général des considérations et des processus de réflexion à suivre lors de l'approche d'un nouveau site.
Cependant, quelle que soit l'application que vous testez, il n'y a pas de meilleur conseil que celui de
Matthias Karlsson (@avlidienbrunn) : « Ne pensez pas que « tout le monde a regardé, il ne reste plus rien
». Approchez-vous de chaque cible comme si personne n'y était allé auparavant. Vous ne trouvez rien ?
Choisissez-en un autre.
La pile technologique
L'une des premières choses que je fais lorsque je teste une nouvelle application est d'identifier les
technologies qu'elle utilise. Cela inclut, sans toutefois s'y limiter, les frameworks JavaScript frontaux, les
frameworks d'applications côté serveur, les services tiers, les fichiers hébergés localement, les fichiers
distants, etc. Je fais généralement cela en regardant l'historique de mon proxy Web et en notant les
fichiers servis, les domaines capturés dans l'historique, si les modèles HTML sont servis, tout contenu
JSON renvoyé, etc. Le plugin Firefox Wappalyzer est également très pratique pour les technologies de
prise d'empreintes rapides.
Pendant que je fais cela, j'ai tendance à laisser la configuration par défaut de Burp Suite activée et à
parcourir le site pour comprendre les fonctionnalités et noter les modèles de conception intéressants.
Cela me permet d'affiner les types de charges utiles que j'utiliserai dans mes tests, comme Orange l'a fait
lorsqu'il a trouvé le Flask RCE sur Uber au chapitre 13. Par exemple, si un site utilise AngularJS, testez
{{7*7}} pour voir si 49 est rendu quelque part. Si l'application est créée avec ASP.NET avec la protection
XSS activée, vous souhaiterez peut-être d'abord vous concentrer sur le test d'autres types de
vulnérabilités et vérifier XSS en dernier recours.
Si vous reconnaissez qu'un site est construit avec Rails, vous savez peut-être que les URL suivent
généralement un modèle /CONTENT_TYPE/RECORD_ID, où RECORD_ID est un entier auto-incrémenté. En
utilisant HackerOne comme exemple, les URL de rapport suivent le modèle www.hackerone.com/reports/
12345. Étant donné que les applications Rails utilisent généralement des ID entiers, cela signifie que vous
pouvez donner la priorité aux tests de vulnérabilités de référence d'objet direct non sécurisées, car le
type de vulnérabilité est facile à ignorer.
Si vous constatez qu'une API renvoie du JSON ou du XML, vous reconnaîtrez peut-être que ces appels d'API renvoient
involontairement des informations sensibles qui ne sont pas affichées sur la page. Ces appels pourraient constituer
une bonne surface de test et conduire à des vulnérabilités en matière de divulgation d’informations.
Parmi nos points à retenir, les éléments à garder à l’esprit à ce stade incluent :
• Formats de contenu qu'un site attend ou accepte. Par exemple, les fichiers XML se présentent sous différentes formes
Commencer 194
les formes, les tailles et l'analyse XML peuvent toujours être associées aux vulnérabilités XXE. Gardez un
œil sur les sites qui acceptent les fichiers .docx, xlsx, pptx ou d'autres types de fichiers XML.
• Outils ou services tiers facilement mal configurés. Chaque fois que vous lisez des rapports sur des
pirates informatiques exploitant de tels services, essayez de comprendre comment ces journalistes
ont découvert la vulnérabilité et appliquez cela à vos tests.
• Paramètres codés et manière dont une application les gère. Les bizarreries peuvent indiquer que
plusieurs services interagissent dans le backend, ce qui pourrait donner lieu à des abus.
• Mécanismes d'authentification personnalisés, tels que les flux OAuth. Des différences subtiles dans
la façon dont une application gère les URL de redirection, l'encodage et les paramètres d'état
peuvent conduire à des vulnérabilités importantes.
Cartographie des fonctionnalités
Une fois que j'ai compris les technologies d'un site, je passe à la cartographie des fonctionnalités. À ce stade, je suis encore
en train de naviguer, mais mes tests peuvent suivre l'une des méthodes suivantes : je peux rechercher des marqueurs de
vulnérabilités, définir un objectif spécifique pour mes tests ou suivre une liste de contrôle.
Lorsque je recherche des marqueurs de vulnérabilités, je recherche des comportements généralement

associés aux vulnérabilités. Par exemple, le site vous permet-il de créer des webhooks avec des URL ? Cela peut
conduire à des vulnérabilités SSRF. Un site permet-il l’usurpation d’identité ? Cela peut conduire à la divulgation
d’informations personnelles sensibles. Pouvez-vous télécharger des fichiers ? La manière et l'endroit où ces
fichiers sont rendus pourraient conduire à une vulnérabilité d'exécution de code à distance, XSS, etc. Lorsque je
trouve quelque chose d'intéressant, j'ai tendance à arrêter et à commencer les tests d'application, comme
décrit dans la section suivante, et à rechercher des indications sur une vulnérabilité existante. Il peut s'agir
d'un message inattendu renvoyé, d'un retard dans le temps de réponse, d'une entrée non vérifiée renvoyée ou
d'une vérification côté serveur contournée.
En revanche, lorsque je définis et travaille vers un objectif, je décide de ce que je vais faire avant de tester
l'application. L'objectif pourrait être de trouver une falsification de requête côté serveur, une inclusion de
fichier local, une exécution de code à distance ou une autre vulnérabilité. Jobert Abma, co-fondateur de
HackerOne, emploie et défend couramment cette approche, et Philippe Harewood a utilisé cette méthode
lorsqu'il a découvert le rachat de son application Facebook. Avec cette approche, vous ignorez toutes les autres
possibilités et vous concentrez entièrement sur votre objectif final. Vous ne vous arrêtez et ne commencez à
tester que si vous trouvez quelque chose qui mène à votre objectif. Par exemple, si vous recherchez une
vulnérabilité d’exécution de code à distance, un code HTML non nettoyé renvoyé dans un corps de réponse ne
vous intéresserait pas.
Enfin, vous pouvez suivre une liste de contrôle. L'OWASP et le Web Application Hacker's Handbook fournissent
tous deux des listes de contrôle de test complètes à utiliser lors de l'examen d'une application, il ne sert donc à
rien pour moi d'essayer de surpasser non plus. Je ne suis pas cette voie parce que je la trouve personnellement
trop monotone et qui rappelle le travail plutôt qu'un passe-temps agréable. Quoi qu'il en soit, suivre une liste
de contrôle peut vous aider à éviter de manquer des vulnérabilités en oubliant de tester des éléments
spécifiques ou en oubliant de suivre des méthodologies générales (comme l'examen des fichiers JavaScript).
Commencer 195
Trouver des vulnérabilités
Maintenant que vous comprenez le fonctionnement de l’application, il est temps de commencer les tests. Plutôt que
de fixer un objectif spécifique ou d’utiliser une liste de contrôle, je suggère de rechercher pour commencer un
comportement qui pourrait indiquer une vulnérabilité. À ce stade, vous pourriez supposer que vous devriez exécuter
des scanners automatisés comme le moteur d'analyse de Burp pour rechercher les vulnérabilités. Cependant, cela
n'est pas autorisé par la plupart des programmes que j'ai consultés, c'est inutilement bruyant et ne nécessite aucune
compétence ou connaissance. Au lieu de cela, vous devriez vous concentrer sur les tests manuels.
Si j'ai commencé les tests de mon application sans avoir rien trouvé d'intéressant à regarder lors de ma
cartographie des fonctionnalités, je commence à utiliser le site comme si j'étais un client. Je créerai du
contenu, des utilisateurs, des équipes ou tout ce que l'application propose. Ce faisant, je soumets
généralement des charges utiles partout où la saisie est acceptée et je recherche des anomalies et des
comportements inattendus sur le site. J'utilise généralement la charge utile <s>000'")};–//, qui inclut tous
les caractères spéciaux susceptibles de rompre le contexte dans lequel la charge utile est rendue, qu'il
s'agisse de HTML, de JavaScript ou d'une requête SQL backend. Ce type de charge utile est souvent
appelé polyglotte. La balise <s> est également innocente, facile à repérer lorsqu'elle est rendue non
nettoyée en HTML (vous verrez du texte barré lorsque cela se produit) et est souvent laissée inchangée
lorsqu'un site tente de nettoyer la sortie en modifiant l'entrée.
De plus, lorsqu'il y a une chance que le contenu que je crée puisse être affiché sur un panneau
d'administration, comme mon nom d'utilisateur, mon adresse, etc., j'utiliserai une charge utile différente
pour cibler le XSS aveugle de XSSHunter (un outil XSS discuté en annexe X). Enfin, si le site utilise un
moteur de template, j'ajouterai également les charges utiles associées au modèle. Pour Angular, cela
ressemblerait à {{88}}[[55]], et je chercherais 64 ou 25 à rendre. Bien que je n'aie jamais trouvé d'injection
de modèle côté serveur dans Rails, j'essaie quand même la charge utile <%=
ls%> au cas où un rendu en ligne apparaîtrait un jour.
Bien que cela couvre les vulnérabilités de type injection (telles que XSS, SQLi, SSTI, etc.), cela ne nécessite
pas non plus beaucoup de réflexion critique et peut rapidement devenir répétitif et ennuyeux. Ainsi, pour
éviter l'épuisement professionnel, il est important de garder un œil sur l'historique de votre proxy pour
découvrir des fonctionnalités intéressantes généralement associées aux vulnérabilités. Les vulnérabilités
courantes et les domaines à surveiller incluent, sans s'y limiter : - Les vulnérabilités CSRF - Les types de
requêtes HTTP qui modifient les données et si elles ont des jetons CSRF qui les valident - Les IDOR -
L'existence ou non de paramètres d'identification qui peut être manipulé
- Logique d'application - Possibilités de répéter les demandes sur deux comptes d'utilisateurs distincts
- XXE - Tout XML acceptant les requêtes HTTP - Divulgations d'informations - Tout contenu dont la
confidentialité doit être garantie - Redirections ouvertes - Toutes les URL ayant un paramètre lié à la redirection
- CRLF, XSS et certaines redirections ouvertes - Toute requête faisant écho aux paramètres d'URL dans la
réponse - SQLi - Que l'ajout d'un guillemet simple, d'un crochet ou d'un point-virgule à un paramètre modifie
une réponse - RCE - Tout type de téléchargement de fichier ou de manipulation d'image
- Conditions de concurrence - Traitement des données retardé ou comportements liés au moment de l'utilisation ou
au moment du contrôle - SSRF - Fonctionnalité qui accepte les URL, telles que les webhooks ou les intégrations
externes - Bogues de sécurité non corrigés - Informations sur le serveur divulguées telles que les versions
Commencer 196
de PHP, Apache, Nginx, etc. qui peuvent révéler une technologie obsolète
Malheureusement, cette liste est interminable et sans doute en constante évolution. Lorsque vous avez besoin
de plus d'inspiration pour savoir où rechercher les bogues, vous pouvez toujours jeter un œil aux sections à
retenir dans chaque chapitre de ce livre. Après avoir exploré les fonctionnalités et avoir besoin d'une pause
dans les requêtes HTTP, vous pouvez revenir au bruteforcing de vos fichiers et répertoires pour voir quels
fichiers ou répertoires intéressants, le cas échéant, ont été découverts. Vous souhaiterez examiner ces
résultats et visiter les pages et les fichiers. C'est également le moment idéal pour réévaluer ce que vous forcez
brutalement et déterminer s'il existe d'autres domaines sur lesquels vous concentrer. Par exemple, si vous
avez découvert un point de terminaison /api/, vous pouvez forcer de nouveaux chemins sur celui-ci. Cela peut
parfois conduire à tester des fonctionnalités cachées et non documentées. De même, si vous avez utilisé Burp
Suite pour proxy votre trafic HTTP, Burp peut avoir sélectionné des pages supplémentaires à vérifier en
fonction des liens analysés à partir des pages que vous avez déjà visitées. Ces pages non visitées, qui
pourraient vous conduire à des fonctionnalités non testées, sont de couleur grise dans Burp Suite pour les
différencier des liens déjà visités.
Comme mentionné précédemment, le piratage d’applications Web n’est pas magique. Être un chasseur
de bugs nécessite un tiers de connaissances, un tiers d’observation et un tiers de persévérance. Il est
essentiel d’approfondir l’application et de la tester minutieusement sans perdre de temps.
Malheureusement, reconnaître la différence demande de l’expérience.
Aller plus loin
Une fois que vous avez terminé toutes vos recherches et testé minutieusement toutes les fonctionnalités que vous pouvez
trouver, il est temps de trouver d'autres moyens de rendre votre recherche de bogues plus efficace. Bien que je ne puisse
pas vous dire exactement comment procéder dans toutes les situations, j'ai quelques suggestions.
Une façon de gagner du temps consiste à automatiser votre travail. Bien que nous ayons utilisé certains outils
automatisés dans ce chapitre, la plupart de nos piratages ont été manuels, ce qui signifie que nous sommes limités
dans le temps. Pour dépasser la barrière temporelle, vous avez besoin d’ordinateurs qui piratent à votre place. Rojan
Rijal (@uranium238) a révélé un bug Shopify qu'il a découvert cinq minutes après la mise en ligne du sous-domaine
sur lequel il a trouvé le bug. Cette découverte rapide est le résultat de l'automatisation de sa reconnaissance sur
Shopify. Comment automatiser votre piratage dépasse le cadre de ce livre et il est également tout à fait possible de
réussir avec un bug bounty sans cela, mais c'est un moyen pour les pirates d'augmenter leurs revenus. Vous pouvez
automatiser à partir de votre reconnaissance. Par exemple, vous pouvez automatiser plusieurs tâches telles que le
bruteforcing de sous-domaines, l'analyse des ports et la reconnaissance visuelle, pour n'en nommer que quelques-
unes.
Une autre opportunité de trouver plus de bogues consiste à examiner toutes les applications mobiles incluses
dans la portée du programme. Bien que ce livre se soit concentré sur le piratage Web, le piratage mobile offre
de nombreuses nouvelles opportunités pour trouver des bugs. D'après mon expérience, le piratage mobile
peut se faire de deux manières : tester directement le code de l'application ou tester les API avec lesquelles
l'application interagit. J'ai tendance à me concentrer sur ce dernier car cela s'apparente au piratage Web.
Commencer 197
et je peux me concentrer sur les types de vulnérabilités comme IDOR, SQLi, RCE, etc. Pour commencer à tester les API
d'applications mobiles, vous devrez proxy le trafic de votre téléphone lorsque vous utilisez l'application via Burp. C'est
une façon de voir les appels HTTP effectués afin de pouvoir les manipuler. Cependant, les applications utilisent
parfois l'épinglage SSL, ce qui signifie qu'elles ne reconnaîtront pas ou n'utiliseront pas le certificat SSL Burp et que
vous ne pourrez donc pas proxy le trafic de l'application. Contourner l'épinglage SSL, le proxy de votre téléphone et le
piratage mobile en général dépasse le cadre de ce livre, mais représente une excellente opportunité pour de
nouveaux apprentissages.
Le prochain domaine sur lequel se concentrer est l'identification de nouvelles fonctionnalités à mesure qu'elles
sont ajoutées à l'application que vous testez. Philippe Harewood est un exemple étonnant de quelqu'un qui
maîtrise cette compétence. Parmi les Hackers, si ce n'est les premiers, du programme Facebook, il partage
ouvertement les vulnérabilités qu'il découvre sur son site Internet (https://philippeharewood.com/). Ses articles
font régulièrement référence aux nouvelles fonctionnalités qu'il a découvertes et aux vulnérabilités qu'il a
découvertes avant d'autres grâce à son identification rapide. Frans Rosen a partagé une partie de sa méthodologie
pour y parvenir sur le blog Detectify (https://blog.detectify.com/). Pour suivre les nouvelles fonctionnalités des
sites Web que vous testez, vous pouvez lire les blogs d'ingénierie des sites que vous testez, surveiller leurs flux
Twitter d'ingénierie, vous inscrire à leurs newsletters, etc.
Vous pouvez également découvrir de nouvelles fonctionnalités du site en suivant les fichiers JavaScript. Se
concentrer sur les fichiers JavaScript est particulièrement efficace lorsqu'un site s'appuie sur des frameworks
JavaScript frontend pour restituer son contenu. L'application s'appuiera sur l'inclusion de la plupart des points
de terminaison HTTP qu'un site utilise dans ses fichiers JavaScript. Les modifications apportées aux fichiers
peuvent représenter des fonctionnalités nouvelles ou modifiées que vous pouvez tester. Jobert Abma, Brett
Beurhaus et Ben Sadeghipour ont tous discuté des approches pour y parvenir. Vous pouvez le trouver avec une
recherche rapide sur Google de leurs noms et une reconnaissance.
Même si cela peut sembler contre-intuitif lorsque vous essayez de gagner de l’argent grâce à des primes, vous
pouvez également payer pour accéder aux fonctionnalités. Frans Rosen et Ron Chan ont tous deux discuté de
leur succès en payant pour de nouvelles fonctionnalités, et j'ai également réussi à payer pour des produits, des
abonnements et des services qui augmentent ma portée potentielle de tests. D'autres ne voudront
probablement pas payer pour des fonctionnalités sur des sites qu'ils n'utilisent pas réellement, de sorte que les
fonctionnalités ont tendance à présenter davantage de vulnérabilités non découvertes. Par exemple, Ron Chan
a payé quelques milliers de dollars pour tester une application et a découvert un nombre important de
vulnérabilités qui ont valu la peine d'investir.
Enfin, examinez les technologies, les bibliothèques et les logiciels qu’une entreprise utilise et découvrez en
détail leur fonctionnement. Plus vous savez comment fonctionne une technologie, plus vous risquez de trouver
des bugs dans la façon dont elle est utilisée sur les applications que vous testez. Par exemple, les vulnérabilités
ImageMagick du chapitre 13 nécessitaient une compréhension du fonctionnement d'ImageMagick et de ses
types de fichiers définis. Vous pourrez peut-être trouver des vulnérabilités supplémentaires en examinant
d'autres technologies liées aux bibliothèques comme ImageMagick. Travis Ormandy l'a fait lorsqu'il a divulgué
des vulnérabilités supplémentaires dans GhostScript, pris en charge par ImageMagick. De même,
FileDescriptor explique dans ses articles de blog qu'il lit les RFC sur les fonctionnalités Web et se concentre sur
les considérations de sécurité pour comprendre comment
Commencer 198
quelque chose est censé fonctionner par rapport à la manière dont il est réellement mis en œuvre. Sa
connaissance approfondie d'OAuth est un excellent exemple de plongée approfondie dans une technologie
utilisée par un grand nombre de sites Web.
Résumé
Avec ce chapitre, j'ai essayé de faire la lumière sur ce à quoi pourrait ressembler une approche du
piratage en me basant sur ma propre expérience et des entretiens avec les meilleurs hackers de bug
bounty. À ce jour, j'ai trouvé le plus de succès après avoir exploré une cible, compris les fonctionnalités
qu'elle fournit et les avoir mappées aux types de vulnérabilités à des fins de test. Cependant, l'un des
domaines que je continue d'explorer, et que je vous encourage à examiner également, est
l'automatisation et la documentation de votre méthodologie. Il existe de nombreux outils de piratage
disponibles qui peuvent vous faciliter la vie ; Burp, ZAP, Nmap et Gowitness sont quelques-uns des rares
mentionnés ici. C'est une bonne idée de garder cela à l'esprit lorsque vous piratez pour mieux utiliser
votre temps. Enfin, une fois que vous avez épuisé les moyens typiques que vous utiliseriez pour trouver
des bogues, cherchez des moyens de rendre vos recherches de bogues plus efficaces en approfondissant
les applications mobiles et les nouvelles fonctionnalités développées sur les sites Web que vous testez.

AZERR

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AZERR

Transféré par

Droits d'auteur :

Formats disponibles

Traduit de Anglais vers Français - www.onlinedoctranslator.

1. Contournement des privilèges d'administrateur Shopify

Date de déclaration: 22 novembre 2015

Prime payée: 500$

Selon le rapport, le hacker aurait simplement à :

• Connectez-vous à l'application téléphonique Shopify avec un compte à accès complet.

2. Manipulation du signal HackerOne

Date de déclaration: 21 décembre 2015

Prime payée: 500$ Description:

Et c’est tout ce qu’il y avait à faire�

3. Compartiments Shopify S3 ouverts

Date de déclaration: 9 novembre 2015

Prime payée: 1000$

4. Compartiments HackerOne S3 ouverts

Date de déclaration: 3 avril 2016

Prime payée: 2 500 $

Il y a un trou dans 1 951 compartiments Amazon S36

Recherche de compartiment S37

hackerone, hackerone.marketing, hackerone.attachments, hackerone.users, hackerone.files, etc.

Alors j'ai essayé le suivantaws s3 mv test.txt s3://hackerone.filesET� SUCCÈS ! J'ai reçu le

Incroyable! Maintenant, j'ai essayé de supprimer le fichier :aws s3 rm s3://hackerone.files/test.txtET encore

Il y a plusieurs points à retenir de ceci :

1. Ne sous-estimez pas votre ingéniosité et le potentiel d'erreurs des développeurs.

5. Contourner l'authentification à deux facteurs de GitLab

Date de déclaration: 3 avril 2016

Le 3 avril, Jobert Abma (co-fondateur de HackerOne) a signalé à GitLab qu'avec

Disposition du contenu:Données de formulaire;nom="utilisateur[otp_attempt]"

Si un attaquant l'a intercepté et a ajouté un nom d'utilisateur à l'appel, par exemple :

Disposition du contenu:Données de formulaire;nom="utilisateur[otp_attempt]"

Disposition du contenu:Données de formulaire;nom="utilisateur[se connecter]"

6. Divulgation d'informations Yahoo PHP

Date de divulgation: 16 octobre 2014

Maintenant, vous vous demandez peut-être comment Patrik a trouvé http://nc10.n9323.mail.ne1.yahoo.com

PlageNet: 98.136.0.0 - 98.139.255.255

réseau US9:FILET-98-136-0-0-1 Parent:

FILET-98-0-0-0-0 Type de réseau:Date

d'enregistrement de l'allocation directe:

Mis à jour: 2012-03-02

En exécutant cela, il a trouvé ce serveur Yahoo aléatoire.

7. Vote HackerOne Hacktivity

Date de déclaration: 10 mai 2016

Prime payée: Guirlande

Source de la page HackerOne Hacktivity

Application Hackerone Javascript Vote POST

8. Accéder à l'installation Memcache de PornHub

Date de déclaration: 1er mars 2016

Prime payée: 2500$

À partir de Nmap 6.47 ( http://nmap.org ) le 07/06/2016 à 14h09 CEST Rapport

0,017 s). Non affiché : 65 532 ports

fermés PORT STATE SERVICE VERSION

80/tcp ouvert http nginx

443/tcp ouvrir http nginx 60893/

tcp ouvrir le cache mémoire

Cependant, un attaquant malveillant aurait pu utiliser cet accès pour :

• Provoquer un déni de service (DOS) en écrivant et en effaçant constamment le cache, gardant

9. Contourner les protections des comptes Twitter

Date de déclaration: Prime attribuée en octobre 2016

Prime payée: 560$

En réponse, Twitter a validé et résolu le problème, attribuant à Karan 560 $.

• Quelle est la portée du programme ? Est-ce *.example.com ou simplement www.example.com ?

Énumération des sous-domaines

Analyse des ports

Cartographie des fonctionnalités

Lorsque je recherche des marqueurs de vulnérabilités, je recherche des comportements généralement