La VULNÉRABILITÉ qui peut RAPPORTER GROS ? | WEB CACHE POISONING f/t Nishacid

[@QuentinLAPAIRE]

J'aime beaucoup la vidéo. J'aimerais bien bosser avec toi 😂 et j'aime trop le bob. Continue !

[@Fransosiche]

Merci !

[@gurvanseveno3498]

Style le petit bob, mais encore une bonne vidéo 😉

[@Fransosiche]

Merci monsieur le miniaturiste

[@franck34]

Bravo. Ca tape dans le cache coeur

[@franck34]

t'as eu droit a un post linkedin du coup

[@hugojousselin9325]

Video super intéressante, j'avais une question concernant la vuln : comment on sait que notre requête va bien passer en cache ? Parce que si on fait une requête dont la réponse est déjà en cache on obtient la réponse du cache et donc comment ça se fait que notre requête empoisonnée devient celle enregistrée dans le cache et remplace la precedente ?

[@Fransosiche]

Thx, alors pour que la requête empoisonnée soit mise en cache, elle doit répondre aux critères de mise en cache du serveur ou du système de cache intermédiaire. Cela inclut souvent des aspects comme le code de statut HTTP, les en-têtes de cache (Cache-Control, Expires), et si la réponse semble être dynamique ou statique + il y a aussi l'aspect de timing c'est-à-dire que si une requête empoisonnée est envoyée et que le système la considère comme apte à être mise en cache, elle doit arriver au moment opportun pour remplacer ou influencer une entrée de cache existante. Si le cache n'a pas encore de réponse stockée pour cette requête spécifique, ou si la réponse en cache est proche de son expiration, la requête malveillante a plus de chances de remplacer l'ancienne réponse.

[@hugojousselin9325]

@@Fransosiche OK merci beaucoup pour cette explication. C'est bien ce qu'il me semblait ça à pas l'air si simple de juste passer sa requête dans le cache même sans l'avoir empoisonnée. Merci

[@Mass1010]

vraiment top tes vidéos, j'aime bien .. un pétit conseille pour moi stp, sur une certif que tu me recommanderais sur le pentest web, je suis novice dans le domaine

[@Fransosiche]

Merci ! Pour un débutant, je recommanderais de commencer avec l'eWPT pour une introduction pratique et bien structurée au pentest web, puis éventuellement progresser vers des certifications comme l'OSCP ou la GWAPT selon tes intérêts et tes besoins professionnels. Assure-toi également de compléter ton apprentissage par beaucoup de pratique, peut-être en utilisant des plateformes comme Hack The Box ou OWASP WebGoat, où tu peux tester et améliorer tes compétences dans un environnement sécurisé. Bonne chance dans ton parcours de pentesteur web !

[@Mass1010]

@@Fransosiche vraiment, un grand merci .. je tâcherai d'appiliquer; merci bcp

[@user-nt8ok]

Merci pour la vidéo top comme toujours ! Je t'ai posé une question sur ta vidéo concernant le kerberoasting mais j'ai pas eu de réponse.. tu pourrais check ? Merci d'avance ;)

[@Fransosiche]

Thx, yep j'y réponds de ce pas !

[@Fransosiche]

Update, je ne vois pas ton commentaire sur la vidéo Kerberoasting chef :/

[@user-nt8ok]

Voici ce que j'ai/j'avais mis car je le vois : Merci pour la vidéo ! J'ai deux petites questions : 1) Sur BloudHound (dans la section Kerberostable) il y a des users(en tout cas c'est le logo USER sous BH) qui ont cette syntaxe : HOSTNAME$@DOMAIN. A quoi fait référence le '$' ? 2) De plus, lors de divers rooms en faisant du kerberoasting j'ai pu récupérer des TGS mais etype 18 (normalement on a du etype 23) et via hashcat je n'ai réussi à les craquer. Tu as une idée ? Tu as déjà eu des etype 18 ? Merci beaucoup et à la prochaine ;)

[@Fransosiche]

@@user-nt8ok Okay bizarre, voilà pour les réponses : En gros, dans l'environnement Windows, le symbole $ à la fin d'un nom d'utilisateur, comme dans HOSTNAME$@DOMAIN, désigne un compte d'ordinateur plutôt qu'un compte d'utilisateur. Ce type de compte est utilisé pour authentifier un ordinateur dans le réseau. Chaque ordinateur membre d'un domaine possède un compte associé qui est géré automatiquement par le domaine. Concernant le kerberoasting et les types de chiffrement (etype) des tickets, l'etype 18 correspond à AES 256-bit, tandis que l'etype 23 est pour RC4. AES est plus sécurisé et beaucoup moins susceptible d'être cassé par force brute par rapport à RC4. C'est probablement pour cela que tu as des difficultés à craquer les hashes de type etype 18 avec hashcat. Pour attaquer ces types de tickets, il te faudra soit une technique plus avancée, soit un accès à des ressources de calcul plus importantes. Assure-toi aussi que ta version de hashcat supporte le mode correspondant à AES 256-bit (etype 18), qui est le mode 19700.

[@user-nt8ok]

@@Fransosiche Merci pour tes réponses !

[@hadzah_fr]

roh ce bob !

[@Fransosiche]

Eh oué

[@CodingBill]

Hack the bob

[@Mass1010]

je trouve vraiment le domaine du web très fascinant, et t'es vraiment connaisseur sur le point, j'avoue que tes mots me casse la tête par fois 🙃.. tu pourrai me passer ton insta si possible stp ?

[@Fransosiche]

Go sur mon discord ce sera mieux, check mon serveur en description

[@Mass1010]

@@Fransosiche d'accprd pas de soucis, ça marche