TL;DR
La formation AWAE fournie dans le package OSWE est une formation que je recommande à tous ceux qui s’intéressent de près ou de loin à la sécurité des applications web, et particulièrement sur l’audit de code (ou boite blanche). Des prérequis en développement d’application web sont fortement conseillés. L’environnement de lab propose un nombre limité d’applications complexes permettant d’aborder différentes techniques en profondeur. L’assurance de réussir l’examen dépendra principalement de la qualité de la méthodologie d’audit construite par l’élève.
Introduction
Cet article expliquera l’approche que j’ai pu avoir afin de me préparer à cette certification. La création d’un journal de bord détaillé ne m’a pas semblé pertinente, je vous proposerai néanmoins certains repaires temporaires. Je précise également que l’article ne contient pas d’information confidentielle concernant le lab ou l’examen de l’OSWE. Enfin, cet article est purement subjectif. Il représente mon point de vue personnel et s’inscrit dans un cadre temporel précis (les certifications évoluent rapidement). C’est pourquoi je vous conseille également de consulter d’autres retours d’expérience.
Cet article intervient en complément de ma présentation faite à Hack2G2, disponible ci-dessous:
Les slides sont également disponibles ici.
Pourquoi une certification ?
Pourquoi passer une certification ?
Ayant terminé mon école d’ingénieur en cybersécurité, je souhaitais valoriser mon expérience personnelle et particulièrement dans le domaine de la sécurité des applications web. Ayant tout juste passé l’OSCP, une certification comme l’OSWE était pour moi une satisfaction personnelle que je souhaitais ajouter à mon CV.
Pourquoi en passer une “maintenant” ?
Nous sommes en mars 2020. La fin de mes études et la baisse d’activité de mon équipe de CTF Aperi’Kube m’ont permis de libérer du temps afin de passer la certification OSCP. Le confinement mis en place contre la pandémie mondiale de COVID-19 est encore d’actualité, et la fin de l’OSCP m’a laissé un grand vide. J’ai donc décidé de me lancer dans les révisions techniques peu de temps après la fin de ma certification OSCP afin de capitaliser sur les connaissances acquises.
Quelle certification choisir ?
Le choix d’une certification technique dépend généralement de plusieurs facteurs :
- Le contenu de la formation associée
- Sa réputation
- Sa difficulté
- Son prix
- Autres (besoin de l’entreprise, besoin client …)
Certaines certifications propriétaires ne possèdent pas d’alternative, dans ce cas la question du choix ne se pose pas. En ce qui concerne la cybersécurité (et surtout le pentest), il existe une multitude de certifications avec des caractéristiques différentes.
Afin de répertorier ces différentes certifications, des projets communautaires comme Security Certification Roadmap ont vu le jour :
Je ne vais pas aborder l’ensemble des certifications sur cet article, une présentation de certains organismes a déjà été faite dans mon précédent article.
En ce qui me concerne, le choix de l’OSWE s’est fait principalement dans la continuité de la certification OSCP proposé par le même organisme. L’approche “boite blanche” est par ailleurs peu répandue et m’a conforté dans ce choix.
Note : Depuis peu, Offensive Security propose une formation au niveau “web-200 OSWA” plus accessible techniquement. Je ne connais pas le contenu de cette formation, mais si le choix devait se faire, j’irais tout de même vers l’OSWE pour des raisons économiques, techniques et pour son intêret dans le bundle “OSCE3”.
Présentation rapide de l’OSWE
Offensive Security
Offensive Security est une entreprise américaine de pentest et forensics crées en 2007. L’entreprise maintient notamment la distribution de pentest Kali Linux (anciennement BackTrack), mais également le site ExploitDB, Google Hacking Database, ou encore l’outil de pentest Metasploit.
L’entreprise propose un ensemble de formation en pentest, dont l’OSCP qui correspond à leur certification d’entrée de gamme. Cette certification est à mon sens la certification la plus connue dans le milieu du pentest. Le passage de l’ensemble des certifications d’Offensive Security se fait sur des exercices pratiques, contrairement à certains organismes optant pour des QCM.
Cours AWAE
La certification vient accompagnée d’une formation “AWAE” (Advanced Web Attacks & Exploitation) constituée d’un PDF de plus de 410 pages, ainsi que de plus de 10 heures de vidéos explicatives, le tout en anglais. Tout comme l’OSCP, l’accès à ces ressources est privé et illimité. Le contenu de la formation est quantitativement inférieur à celui de l’OSCP, cependant son contenu est technique et pertinent.
La formation se présente par ailleurs comme ceci: “Advanced Web Attacks and Exploitation (WEB-300) is an advanced web application security review course. We teach the skills needed to conduct white box web app penetration tests.” En français: AWAE est une formation d’audit de code. Nous enseignons les compétences nécessaires pour conduire un pentest en audit boite blanche sur des applications web.
Lab AWAE
À cette formation s’ajoute un environnement virtuel, également appelé “Lab”. Cet environnement est constitué de 11 machines. Ces dernières sont directement accessibles, sans cloisonnement ni système de pivotage comme pour le lab PWK. Les machines proposent par ailleurss un accès SSH ou RDP dont les identifiants sont fournis avec le package de formation. L’accès au lab se fait via un profile openvpn.
Prix
Les prix initialement proposés par Offensive Security sont en dollars américains. Les prix en euros ne prennent pas en compte les potentiels frais de votre banque. En ce qui me concerne, j’ai opté pour le package Cours + 60 jours à 1101 € et n’ai pas eu de frais supplémentaires. Concernant la durée du lab, je conseille un accès de 60 jours au minimum (je reviendrais sur cette durée dans l’article).
L’ajout de contenu récent a modifié les prix de la formation depuis mon passage de l’OSWE. Je vous met ici les prix qui m’étaient proposés. Notez par ailleurss qu’Offensive Security change progressivement de modèle d’offre, avec des prix significativement plus chers pour les dernières formations.
| Package | Prix ($) | Prix (€) |
|---|---|---|
| Cours + 60 jours d’accès au lab + un examen OSWE | $1299 | 1101 € |
| Cours + 90 jours d’accès au lab + un examen OSWE | $1499 | 1270 € |
| Rattrapage | Prix ($) | Prix (€) |
| Frais de rattrapage d’examen OSWE | $249 | 211 € |
| Extension de Lab | Prix ($) | Prix (€) |
| Extension de Lab de 30 jours | $359 | 304 € |
| Extension de Lab de 60 jours | $599 | 508 € |
| Extension de Lab de 90 jours | $799 | 677 € |
Contenu de la formation
Le Syllabus du cours AWAE est disponible librement sur le site d’Offensive Security. On y retrouve notamment les différents sujets traités par la formation (liste non exhaustive) :
- Cross-Origin Resource Sharing (CORS) avec CSRF et RCE. Le début du cours aborde les attaques coté client et force le développement d’exploits complexes type CSRF/XSS.
- JavaScript Prototype Pollution. Une ou deux application NodeJS proposent une vulnérabilité de type Prototype Pollution.
- Advanced Server Side Request Forgery.
- Web security tools and methodologies. Les outils de type proxy burp et génération de payload type ysoserial sont abordés pendant le cours. Les outils orientés boite noire comme ffuf ne sont pas abordés. La méthodologie proposée aborde la configuration de l’environnement de debug.
- Source code analysis. Il s’agit d’une notion abordée tout au long de la formation.
- Persistent cross-site scripting. Au même titre que les reflected XSS
- Session hijacking. Ce type d’attaque repose sur des bugs logiques intéressants à aborder en boite blanche.
- .NET deserialization. Le cours propose la conception de payload “from scratch” puis avec l’aide d’outils.
- Remote code exécution. Des bypass de blacklist sont également proposés pour une application NodeJS.
- Blind SQL injections. Les outils comme SQLmap sont interdits pendant l’examen.
- Data exfiltration. Je pense qu’il s’agit des résultats des vulnérabilités type XSS et SQLi.
- Bypassing file upload restrictions and file extension filters. Valable pour PHP essentiellement.
- PHP type juggling with loose comparisons. Vulnérabilité intéressante et parfois difficile à remonter en boite blanche.
- PostgreSQL Extension and User Defined Functions. Il s’agit de techniques d’exploitation d’injections SQL particulières et avancées apportant des primitives du type écriture de fichier et exécution de code.
- Bypassing REGEX restrictions. Apprendre à reconnaitre les bypass possibles, notamment pour les vulnérabilités de type path traversal
- Magic hashes. Vulnérabilité technique particulière mais intéressante dans un contexte boite blanche. La vulnérabilité est généralement liée à une réduction d’entropie rendant l’exploitation possible.
- Bypassing character restrictions.
- UDF reverse shells. Directement lié aux injections PostgreSQL
- PostgreSQL large objects. Directement lié aux injections PostgreSQL
- DOM-based cross site scripting (black box). Très légèrement abordé pendant la formation
- Server side template injection. L’approche de cette vulnérabilité est plutôt abordée d’un point de vue boite noire.
- Weak random token generation. Il s’agit ici de reconnaitre des réductions d’entropies ou l’utilisation de suites cryptographiques obsolètes.
- XML external entity injection. Vulnérabilité liée aux parseurs XML, parfois utilisés pour les fichiers excels.
- RCE via database functions. On y apprend notamment à récupérer la fonction xp_cmdshell depuis une dll externe.
- OS command injection via WebSockets (black box). L’approche des websocket est combinée à d’autres vulnérabilités. L’interaction avec ces dernières avec un langage scripté constitue un bon exercice.
- …
D’une manière générale, j’ai trouvé le contenu de la formation très spécifique, sur des vulnérabilités très particulières. La formation est cependant très incomplète pour un pentester souhaitant progresser sur du pentest en boite noire. Une partie “remote debugging” et instrumentalisation du code et des bases de données pour le debuggage est également proposé par la formation. Bien que ces points ne fassent pas partie du syllabus, ces derniers furent très intéressants et pertinents pour ma méthodologie d’audit.
Le lab constitue un support direct du cours. En effet chaque notion est explicitement abordée au travers d’une des machines du lab. Des exercices complémentaires permettent ensuite d’approfondir par sois-même la notion sur l’environnement testé. En effet chaque machine propose généralement plusieurs vulnérabilités, ou bien des méthodes alternatives d’exploitations.
Mon niveau initial
Comme indiqué dans le paragraphe sur mes motivations, je suis un jeune pentester passionné, sortant d’école d’ingénieur et tout juste certifié de l’OSCP. À ce moment précis j’ai 23 ans et j’ai déjà réalisé plusieurs pentests, essentiellement sur des environnements web. J’avais également participé à de nombreux CTF (une trentaine), principalement avec mon équipe Aperi’Kube, et même organisé quelques-uns. Concernant les plateformes de challenges, j’étais relativement actif sur Root-Me, et je sortais tout juste d’un entrainement intensif sur HackTheBox. Enfin, j’avais déjà une aisance particulière en scripting et développement (python3, PHP, Java), qui m’a été utile pendant mes révisions. Avant de m’engager dans cette certification, je n’avais pas identifié de “grosses” lacunes hormis l’environnement .NET qui m’était moins familier.
En raison du nombre limité de retours des personnes certifiées OSWE, j’appréhendais cette certification. J’ai profité de la situation sanitaire et de mon entrainement intensif de l’OSCP pour m’engager.
Important : Mon expérience personnelle ne constitue en aucun cas un prérequis pour passer l’OSWE. Les compétences nécessaires à l’obtention de la certification sont abordées dans le cours. Une expérience préalable en pentest web (ou CTF) et/ou développement est fortement conseillée mais ne vous dispensera pas des révisions.
Ma préparation avant le cours AWAE
Hack The Box
Ma décision de passer la certification ne s’est pas traduite directement par l’achat du package OSWE, mais par un entrainement sur le lab du site Hack The Box. J’ai pour cela souscrit à l’offre VIP à 10 £/mois (~12 €/mois). L’accès à l’offre VIP permet de disposer des anciennes box (machines vulnérables), d’un environnement de révisions plus calme, des machines plus stables et moins de risque de spoil par les autres membres inscrits. Le nombre de machine proposant de l’audit boite blanche est cependant limité comparé aux environnements utilisés lors de mon OSCP.
Les box proposées sur HackTheBox sont généralement plus “limitées” en superficie de code, et parfois plus compliquées que celles du lab AWAE. Ces box sont malheureusement les seuls environnements “dédiés” à l’audit de code que j’ai pu trouver. Il existe plusieurs listes communautaires énumérant les box pertinentes pour les révisions OSWE :
Tout comme le lab AWAE, les box proposées sur HTB nécessitent généralement le développement de “script” d’exploitation. Par ailleurs, j’ai pris l’habitude de développer des exploits pour chaque machine, afin de me conforter aux exigences de l’examen. Généralement, plusieurs actions sont attendues tel que la compromission d’un compte applicatif puis le gain d’une exécution de code. L’élévation de privilèges linux/windows n’est cependant pas attendue.
Du mois de mars 2021 à mai 2021, j’ai rooté 4 machines HTB retirées, soit une box toutes les deux semaines pendant 2 mois par ordre croissant de difficulté. J’ai réalisé ces révisions en dehors de mes horaires le travail dans un rythme moins soutenu que mes révisions OSCP. La validation de ces box s’est faite sans l’aide de Write-Ups (corrections). Étant donné le côté chronophage de l’exercice, j’ai passé la dernière semaine à lire des Write-Ups de box orienté audit de code. Ce compromis entre le temps passé à chercher et la notion enseignée est un paramètre qui peut être difficile à appréhender. Aussi, je recommande aux personnes n’ayant pas pratiqué de challenges type “CTF” de ne pas utiliser ces write-ups pour commencer, quitte à passer plusieurs jours sur une box.
Je n’ai pas abordé ici les VM “Vuln-Hub” ni l’audit de code de projets open source, qui auraient pu constituer des bons candidats comme environnement d’entrainement pré-OSWE. Ce dernier à le mérite de se rapprocher au plus proche d’un environnement réel. J’ai jugé Hack The Box plus pertinent, car j’avais déjà pu auditer certains projets open source.
Prise de notes
Lors de la réalisation de ces box, j’ai tenu à jour un wiki personnel afin d’y renseigner mes commandes et techniques de manière organisées. J’ai opté pour un repository GIT avec des fichiers au format MarkDown, mais également des scripts. Voici un extrait de l’architecture :
├── Database
│ ├── PostgreSQL
│ │ ├── awae
│ │ │ └── awae.sln
│ │ ├── awae.c
│ │ ├── awae.dll
│ │ ├── revshell.c
│ │ ├── revshell.dll
│ │ └── so2sql.py
│ └── PostgreSQL.md
├── exploit_skeletton.py
├── Java
│ └── Java.md
├── JavaScript
│ ├── ClientSide
│ │ └── Javascript.md
│ └── NodeJS
│ └── NodeJS.md
├── Logging
│ ├── Databases.md
│ └── PHP.md
├── Microsoft.NET
│ └── Microsoft.NET.md
├── PHP
│ └── Functions.md
├── Scripting.md
├── TypeJuggling
│ ├── loose_comparison.png
│ ├── PHPMagicTricks-TypeJuggling.pdf
│ └── PHP.md
└── Unserialize
├── Microsoft.NET.md
├── NodeJS.md
└── PHP.md
Afin de pouvoir naviguer et effectuer des recherches dans ces notes, j’ai utilisé l’IDE VSCode :
Cette prise de note personnelle est à mon sens essentiel pour progresser et obtenir la certification. Certains pentesters opteront pour des outils différents, comme CherryTree. L’accès à votre wiki ainsi qu’aux wikis publics est autorisé à tout moment, y compris pendant l’examen.
Parmi la liste des ressources présente dans mes marque-pages, j’aimerais vous partager les suivantes que j’ai jugé utiles pour le passage de cette certification :
- PayloadAllTheThings : Base de données de payloads, de bypass et de méthodologies
- HackTricks : Wiki complet décrivant des méthodologies par protocoles ou environnement
- PHP.net : Documentation PHP
Formations préalables ?
Afin de réduire les couts de formation, il peut être utile de se former au préalable dans l’idée de réduire au maximum votre temps de lab (et limiter le nombre de repassages d’examen). La formation AWAE et le lab AWAE sont fournis en même temps. Il n’est donc pas possible de lire la formation avant de commencer le décompte du temps lab. Malheureusement, je n’ai pas de formation particulière à vous recommander (autre que AWAE !), en revanche voici des articles couvrant une partie de cette formation et méritant d’être abordés en amont :
- Ressources liées aux injections PostgreSQL
- Ressources liées à la désérialisation
- INSOMNIA - PHP Magic Tricks: Type Juggling : Spécificités liées au “Type Juggling”.
D’une manière générale, je vous recommande l’ensemble des dossier “web” du repository PayloadsAllTheThings.
Cours et Lab
Après avoir rooté 4 box et lu un ensemble conséquent de corrections, je me suis inscrit pour le package OSWEE avec un accès lab de 60 jours. Offensive Security propose différentes dates de début de formation (afin de ne pas surcharger le lab partagé). J’ai pu obtenir une date le 30 mai 2021, soit quelques jours après l’achat de mon package. Tout comme pour mes révisions OSCP, j’ai réparti mon travail sur des horaires allant de 18 h à 00 h en semaine, et toute la journée le week-end. La formation a été très chronophage, et j’ai passé 90 % de mes week-ends à réviser. Heureusement, le confinement m’a conforté dans l’idée de ne pas pouvoir sortir.
Cours
J’ai pu lire les vidéos fournies dans leur entièreté. Le contenu du cours en PDF n’est qu’un complément du cours vidéo. Je connaissais déjà une bonne partie du contenu de la formation, c’est pourquoi je regrette de ne pas avoir passé l’OSWE plus tôt. J’ai tout de même appris des choses, notamment sur l’environnement de débuggage distant, ou encore sur l’environnement .NET. La lecture du cours s’est faite de manière progressive en même temps que le lab. En effet, la lecture du cours sans support technique n’a quasiment aucun interêt puisqu’il ne permet pas de s’entrainer ni de vérifier les comportements abordés.
Lab
La progression dans le lab est particulièrement lente. En effet, ce dernier ne possède qu’une dizaine de machines particulièrement longues à exploiter. Je ne peux pas vous fournir un schéma de révision détaillé, celui-ci s’établit entre 1 à 2 box par semaine environ, dans l’ordre abordé par le cours. Chaque machine dispose de multiples chemins de compromissions, et le cours est construit de manière à pouvoir réutiliser les compétences acquises dans les environnements suivants. Le cours suggère des exercices complémentaires (“Extra miles”), que j’ai fait et que je recommande de faire.
Contrairement au lab PWK - OSCP, le lab AWAE - OSWE est entièrement dédié à l’élève, aucune machine n’est partagée et l’environnement est complètement dédié pour chaque utilisateur. En revanche les machines sont éteintes par défaut et disposent d’un mécanisme d’extinction automatiques lorsqu’il n’y a plus de trafic. Je n’ai pas expérimenté de déconnexion intempestive pendant mes révisions (sur une pause déjeuner par exemple). Les accès aux box sont explicitement fournis dans un wiki interactif, avec généralement un accès SSH et/ou RDP.
Je vous conseille également de prendre l’habitude d’utiliser les outils abordés par le cours, notamment sur l’environnement RDP. En effet, lors de l’examen, il ne sera pas possible de rapatrier les applications en local.
Préparation à l’examen
Mon lab se finissait en juillet. Un mois avant la fin de ce lab, j’ai pu prévoir une date de passage d’examen pour le 07 juillet. Les créneaux de passage le WE sont rares, je vous conseille donc de prévoir votre date d’examen dès que possible (il est possible de décaler cette date plusieurs fois).
Avant l’examen, j’ai préparé un modèle de rapport en me basant sur celui fourni par Offensive Security, mais également celui proposé par Noraj sur son repository GitHub. La création d’un tel modèle est un gain de temps précieux que vous devez prendre en compte. J’ai également relu l’ensemble des règles relatives à l’examen (durée de l’examen de 47 h 45, restrictions relatives aux scanners, à SQLmap, outils professionnels interdits, exploitation automatique interdite, preuves obligatoires sur le rapport…). J’ai également mis en place des solutions de secours en cas de problèmes : vérifier son crédit téléphonique en cas de coupure internet, configurer un PC de secours si possible, vérifier si l’on dispose d’une seconde webcam, etc. Enfin, vérifiez votre stock de boissons énergisantes et/ou café, et reposez-vous la veille de votre examen.
Déroulement de l’examen
L’examen de l’OSWE dure 47 h 45, auxquelles s’ajoute 24 h dédiées à la rédaction du rapport. Vous êtes bien entendu autorisé à prendre autant de pauses que vous le souhaitez.
Proctoring
L’examen est depuis peu “proctoré” : vous devez partager l’intégralité de vos écrans ainsi que votre webcam tout le long de l’examen (hors rédaction). Ce partage s’effectue facilement grâce au plug-in Janus WebRTC Screensharing. Lorsque l’examen démarre, le surveillant vous demandera alors de présenter votre carte d’identité, ainsi que de faire le tour de la pièce avec votre webcam. Une fois le processus de vérification terminé, le surveillant vous enverra les modalités d’examen. Il sera ensuite amené à vous contacter en cas de perte de la caméra ou d’un écran. À l’inverse, vous serez invité à prévenir le surveillant lors de vos pauses.
Il est intéressant d’ajouter une restriction majeure : Il est interdit de rapatrier l’application en local sur sa machine. L’analyse boite blanche doit donc être faite en accès RDP. Cette restriction était particulièrement contraignante, il est donc primordial de s’habituer aux outils proposés par la formation.
OS
L’OS utilisé pour passer l’examen est libre du moment que vous pouvez satisfaire la connexion OpenVPN ainsi que le proctoring. Ayant révisé essentiellement sur ArchLinux, j’ai opté pour un host ArchLinux + une VM Kali et Windows pour l’examen. Je vous conseille de garder le même environnement entre vos révisions et votre examen, et d’éviter de faire des mises à jour la veille de l’examen. Contrairement à l’OSCP, l’utilisation de l’OS Windows me paraît plus pertinent qu’un OS linux.
Notation
Pour valider l’examen de l’OSWE, un score de 85 points au minimum est demandé. Ces points sont attribués en fonction du taux de compromission des différentes box d’examen. Par ailleurs, un script d’exploitation complet est demandé pour chaque box. Auncune interaction (autre que l’URL à fournir) ne doit avoir lieu avec le script. Cela signifie par exemple que le script doit être en mesure de générer des objets sérialisés dans n’importe quelle technologie avant de l’envoyer dans une requête. L’utilisation de bibliothèques externes (requests, ysoserial.jar, etc.) est autorisée, mais le script doit lui être dans un seul fichier. En cas d’environnement d’exécution particulier (par exemple, script écrit en ruby avec une gemme externe), il est demandé de préciser les méthodes de déploiement de l’environnement d’exécution.
Jusqu’à aujourd’hui, le seul modèle d’examen que j’ai pu rencontrer sur les différents retours d’expérience pour l’OSWE était le suivant :
| Tache | Description |
|---|---|
| “Authentication bypass” (35 points) | Récupération d’un compte applicatif privilégié (par exemple, à l’aide d’une injection SQL, XSS, …) |
| “Remote code exécution” (15 points) | Gain d’une exécution de code sur le serveur |
| “Authentication bypass” (35 points) | Récupération d’un compte applicatif privilégié (par exemple, à l’aide d’une injection SQL, XSS, …) |
| “Remote code exécution” (15 points) | Gain d’une exécution de code sur le serveur |
Vous l’aurez donc compris, la découverte des 2 bypass d’authentification et d’une exécution de code est nécessaire à l’obtention de la certification. La découverte des 2 RCE et d’un bypass n’est pas suffisante pour satisfaire les conditions de la certification.
Tous comme pour le lab, l’ensemble des box est truffé de “rabbit holes”. Une bonne méthodologie, en adéquation avec l’examen, permettra d’éviter de passer trop de temps sur des fausses pistes. L’examen de l’OSWE est particulier puisque les applications à auditer sont particulièrement larges et il est possible d’y passer des semaines entières.
Je vais donc vous partager la méthodologie “dédiée à l’examen” que j’ai pu préparer en amont. J’ai commencé par classer les vulnérabilités par catégories en vérifiant tout d’abord “Quelles vulnérabilités permettent le bypass d’authentification, sans l’exécution de code ?”. Voici une liste non exhaustive de réponses:
- Les mécanismes de session (cookies de sessions custom ?)
- Les mécanismes de mot de passe oubliés (token de reset de mdp)
- Des mécanismes d’administrations sans contrôle d’accès (création de compte administrateur, modification de mdp …)
- Les XSS/CSRF (nécessite un client derrière)
- Les SQLi si le SGBD ne gère pas les stacked queries
- La désérialisation (dans le cas d’application ou les seuls gadget existants permettent le takeover mais pas la RCE)
- Autres
La seconde question est donc : “Quelles vulnérabilités permettent la RCE ?”. Encore une fois, voici une liste non exhaustive:
- L’évaluation de code / de commandes
- L’upload de fichiers
- La désérialisation (dans certains cas)
- Les SQLi (dans certains cas)
- Autres
Concernant les technologies, celles-ci sont variées, lors de mon examen j’ai été confronté à un framework PHP ainsi qu’une application Java (le nombre de machine d’examen à ce jour étant très limité, je ne donnerai pas plus d’informations).
Enfin, le nombre de points n’est pas directement représentatif de la difficulté de la tache.
Mon passage
Pour rappel, mon examen commençait le 08/07/2021 à 7 h. Voici un récapitulatif détaillé de ma journée :
- 7 h 45 : Découverte du premier bypass.
- 8 h 30 [35 pts]: Script d’exploit du premier bypass 🙂.
- 8 h 40 : Découverte de la première exécution de code.
- 9 h [50 pts] : Script complet avec RCE sur la Box n°1.
- 12 h : Découverte du deuxième bypass.
- 15 h [85 pts] : Script d’exploit du deuxième bypass. La certification est normalement assurée à ce stade 🙂.
- 17 h 40 : Découverte de la deuxième RCE. C’est la vulnérabilité qui m’a semblé la plus longue à identifier.
- 18 h 30 [100 pts] : Script d’exploit avec RCE sur la Box n°2.
J’ai pu profiter de la journée suivante pour vérifier l’ensemble de mes preuves et captures d’écran. J’ai également commencé la rédaction du rapport. Vous noterez que le temps de rédaction de scripts n’est pas négligeable, même pour un développeur averti.
J’ai terminé l’examen en moins d’une journée, mais j’estime avoir eu beaucoup de chance sur l’identification des vulnérabilités. La durée de 48 h me semble nécessaire.
Résultats
Quelques jours après avoir soumis mon rapport, je recevais la certification OSWE avec succès 🙂.
Et après ?
La fin du lab et le passage de l’examen ont de nouveau laissé place à un vide mais non sans une certaine fatigue. Mes soirées n’étaient plus rythmées par mes révisions et la crise mondiale de COVID-19, bien que toujours présente, a laissé place à un allègement des différents confinements. Suite à cela, j’ai changé d’entreprise, progressé sur les environnements Windows, et entamé des légères révisions portant sur la certification “OSEP” (évasion d’anti-virus et attaques avancées sur environnement Windows), sans pour autant avoir pour projet de la passer dans les mois qui suivent.
Remerciements
Je remercie ma famille, mes amis et collègues qui ont participé de près ou de loin à l’obtention de cette certification, et plus particulièrement :