Comment fonctionne BeEF et comment peut-il être persistant?
BeEF - le cadre d'exploitation du navigateur. Je pense (pensais) que j'avais une compréhension de base de son fonctionnement. Récemment, cependant, je regardais, cette conversation DEFCON , où un pirate a utilisé une attaque d'homme au milieu pour injecter un crochet BeEF dans de nombreux navigateurs. Bien. Cependant, il a affirmé que son accrochage persistait même après que la victime se soit déconnectée de son proxy ou accédait à une autre page car "le JavaScript s'exécutait dans le cache". Seul l'effacement du cache pourrait libérer le navigateur accroché. Comment est-ce possible?
Ma compréhension était que les exploits BeEF (et le hook) étaient basés sur JS et fonctionnaient comme une attaque XSS, plutôt que d'exploiter une vulnérabilité dans l'exécutable du navigateur lui-même. Je sais qu'il est possible de stocker des informations dans le stockage local ou les cookies, mais comment est-il possible d'exécuter du javascript dans les onglets/sessions? Ma compréhension de BeEF est-elle mauvaise? ou JavaScript? J'ai cherché le fichier payload.js réel pour voir ce qu'il fait vraiment, mais je ne le trouve nulle part. Merci quatre votre aide
BeEF est mieux exécuté à partir de l'outil MITMf - les deux sont disponibles dans la plupart des versions (particulièrement récentes) de Kali Linux. MITMf a une extension de BeEF introuvable dans d'autres endroits appelée BeEFAutorun . BeEFAutorun et BeEF Autorun Rule Engine (ARE) fonctionnent de manière similaire à XSSF et au fichier beef_injection_framework de Trustwave SpiderLabs, mais le ARE intégré est supérieur et fonctionne prêt à l'emploi. MITMf est un concurrent d'Ettercap (ancien) et de bettercap (plus récent et inclut un beefbox module proxy ). Vidéos de TheBeefProject ici .
Cela dit, BeEF et XSSF - quelle que soit la manière dont ils sont livrés ou automatisés - ont tous deux leurs avantages et leurs inconvénients. Aucun des deux n'a une capacité intégrée de persistance du cache. Cette technique de cache peut ne s'appliquer qu'aux navigateurs prenant en charge le stockage hors ligne HTML5, bien que la plupart le fassent aujourd'hui. La technique originale a été découverte par Lavakumar Kuppan et discutée sur son site Web, andlabs (site d'outil en panne, mais article de blog est toujours en place), ainsi que dans le livre HTML5 Security dans la section sur le cache d'application. Une balise manifeste html peut spécifier un fichier cache.manifest dans lequel le stockage a lieu. Une condition d'homme au milieu, le contrôle d'un serveur proxy, un hook de navigateur (par exemple, BeEF), etc., sont nécessaires pour lancer l'attaque. Le code pour effectuer l'attaque a été légèrement modernisé par rapport au code d'origine et disponible sur GitHub sous la forme squid-imposter .
comment est-il possible d'exécuter du javascript sur des onglets/sessions?
Cette fonctionnalité est déjà disponible dans le BeEF Modules qui fournit persistance . En particulier, un attaquant BeEF devrait envisager d'utiliser à la fois les modules man_in_the_browser et iframe_above sauf s'ils souhaitent une injection temporaire. Si tout ce dont vous avez besoin est une injection temporaire (par exemple via votre propre site hébergé, malveillant, via un XSS ou un autre mécanisme rapide), alors j'utiliserais le module invisible_iframe pour fournir un lien vers un - metasploit-framework écouteur browser_autopwn. Cette technique est fournie dans le livre, Gray Hat Hacking The Ethical Hacker's Handbook, 4th Edition. Je pense que ce livre a la couverture la plus approfondie de l'intégration de BeEF et MetaSploit, mais Mastering Kali Linux for Advanced Penetration Testing, Intermediate Security Testing de Daniel Dieterle et The Browser Hacker's Handbook mentionnent également bon nombre de ces techniques.
Il est intéressant de comparer le code de BeEF à XSSF. Par exemple, la conservation de la persistance entre les onglets dans XSSF est effectuée par les modules ghostify et iframeize . Une chose que j'aime avec XSSF est l'intégration directe à l'interface de ligne de commande msfconsole. BeEF fournit également une Console . Un livre en cours appelé Holistic InfoSec for Web Developers a un excellente section sur la configuration de BeEF qui comprend l'intégration du framework metasploit et la configuration de la console BeEF. L'auteur a également un chaîne YouTube où BeEF est largement couvert dans les démos 1 et 3. La console XSSF est incroyablement flexible lorsqu'elle est pressée par le temps, mettant en œuvre des commandes telles que xssf_add_auto_attack detect_properties, qui peut être très utile dans les scénarios en direct et les cyber-exercices. La configuration et le démontage des tunnels XSSF sont excellents. BeEF a plus de modules et est plus facile à dépanner si vous avez besoin d'une console supplémentaire (BeEF a des consoles Web et en ligne de commande, ainsi que cette version en ligne de commande contribuée par un tiers nommée beefconsole.rb ) et de débogage (par exemple, boeuf options cli ) capacités. Le module de détection MS Office et une attaque d'ingénierie sociale livrée par Meterpreter et compatible avec Internet Explorer avec hta_powershell sont particulièrement impressionnants. Enfin, BeEF prend en charge les canaux sur WebRTC , ce qui en fait l'un des outils les plus cool du bloc.
Je ne sais pas si c'est sa méthode, mais vous pouvez associer un événement window.open à une action de clic et appeler window.focus qui vous donne effectivement une fenêtre pop-under. Cela peut être utile pour garder votre crochet pendant qu'ils vontquer à leurs occupations dans une fenêtre différente. Le fait d'avoir un fichier javascript empoisonné dans le cache peut vous permettre de connecter le système lorsque les pages Web correspondantes sont chargées et que la ressource est exécutée. Chaque fois qu'ils visitent le site-x qui utilise le fichier javascript empoisonné comme ressource, vous les avez. Recherchez le métasploit pour ce faire. Il faudrait en effet que l'utilisateur vide son cache.