L'injection de prompts dans les outils de traitement de code machine (MCP), illustrée par une vulnérabilité GitHub, peut entraîner l'exfiltration de données de référentiels privés. Le problème fondamental est que les outils MCP fonctionnent souvent avec des jetons d'accès trop larges, dépourvus de limites d'exécution, ce qui les rend vulnérables aux prompts malveillants ou aux serveurs compromis. Les méthodes d'authentification existantes sont insuffisantes car les jetons nécessitent généralement un accès complet au référentiel, même pour des tâches simples. Bien que OAuth 2.1 RAR puisse offrir une portée granulaire, il manque d'adoption, et les fournisseurs d'API n'ont aucune incitation à mettre en œuvre de telles fonctionnalités. Pour remédier à cela, MCP Snitch, un proxy de sécurité open source, agit comme une couche de médiation. Il applique un contrôle d'accès basé sur une liste blanche, par défaut de refus et autorisant explicitement les opérations. MCP Snitch gère également les demandes d'autorisation d'exécution avec une visibilité de l'interface utilisateur et détecte/bloque l'utilisation abusive des clés API, fournissant une journalisation complète. Cependant, il ne résout pas les attaques de la chaîne d'approvisionnement, les mécanismes de persistance ou les opérations réseau hors bande. L'évolution de la sécurité MCP reflète le parcours du navigateur vers le sandboxing et les autorisations granulaires. Jusqu'à ce que les IDE fournissent un sandboxing approprié et que MCP acquière une sécurité au niveau du protocole, la sécurité basée sur un proxy est la défense pratique actuelle.

Un service boîte noire avec un SDK mal documenté et obscurci a motivé la création de grpc-scan. L'outil automatise l'énumération des services gRPC en exploitant les variations des messages d'erreur causées par des requêtes invalides, car les méthodes de découverte standard ne sont pas disponibles. La nature binaire de gRPC et ses exigences sensibles à la casse rendent l'énumération manuelle difficile, nécessitant les noms exacts des services et des méthodes, ainsi que des messages correctement sérialisés. L'outil identifie le protocole gRPC et génère des combinaisons probables de noms de services et de méthodes basées sur des modèles observés. Il identifie les différences subtiles dans les codes d'erreur renvoyés par différentes implémentations gRPC. L'outil multiplexe les requêtes pour améliorer la vitesse de balayage en établissant plusieurs connexions avec les services. Les pentests révèlent souvent une prolifération de services due aux migrations, une prolifération de méthodes avec une authentification incohérente et une exposition inattendue de services internes. Les anciens services manquent souvent des contrôles de sécurité présents dans les implémentations plus récentes, ce qui entraîne des vulnérabilités. L'historique organisationnel est également révélé via la découverte d'espaces de noms de packages, exposant des hypothèses de sécurité variables. Les limitations incluent l'incapacité de créer automatiquement des structures protobuf spécifiques pour les services, et une focalisation actuelle sur les appels unitaires.

Les modules natifs sont des fichiers Node.js compilés qui permettent aux applications Node.js d'interagir avec du code natif écrit dans des langages tels que C, C++ ou Objective-C. Ces fichiers sont des binaires compilés qui peuvent contenir du code machine et s'exécuter avec les mêmes privilèges que le processus Node.js qui les charge. Contrairement aux fichiers JavaScript, les fichiers .node ne sont pas lisibles et peuvent appeler directement des API système et effectuer des opérations que le code JavaScript pur ne peut pas. Ces extensions peuvent utiliser Objective-C++ pour exploiter les API natives de macOS directement depuis Node.js, permettant une exécution de code arbitraire en dehors de la sandbox normale. Les applications Electron utilisent souvent le format de fichier ASAR pour empaqueter le code source de l'application, mais la vérification de l'intégrité ASAR est désactivée par défaut. Lorsqu'elle est activée, la vérification de l'intégrité ASAR vérifie le hachage de l'en-tête de l'archive ASAR à l'exécution et empêche la falsification des fichiers dans l'archive. Cependant, de nombreuses applications s'exécutent en dehors de l'archive vérifiée, sous app.asar.unpacked, car les fichiers .node compilés ne peuvent pas être exécutés directement depuis une archive ASAR. Cela permet à un attaquant local de modifier ou de remplacer les fichiers .node dans le répertoire décompressé, similaire au détournement de DLL sous Windows. Pour résoudre ce problème, deux outils ont été développés : Electron ASAR Scanner, qui évalue si les applications Electron implémentent la protection de l'intégrité ASAR, et NodeLoader, un simple compilateur d'extensions Node.js natif. Les outils Electron ASAR Scanner et NodeLoader peuvent aider à identifier et à atténuer les vulnérabilités de sécurité potentielles dans les applications Electron qui utilisent des modules natifs.

Nous venons de publier une étude de cas sur un cabinet d'avocats australien qui a remarqué que deux employés accédaient à un grand nombre de fichiers sensibles. Le comportement a été signalé à l'aide de l'UEBA, qui a déclenché des alertes basées sur des écarts par rapport aux modèles d'accès normaux. Le cabinet a enquêté et a trouvé des signes de mouvements latéraux et de tentatives d'escalade de privilèges. Ils ont pu sécuriser les choses avant que tout chiffrement ou exfiltration de données ne se produise. Pas de charge utile, pas de violation. C'est un excellent exemple de la façon dont l'analyse comportementale et l'application du moindre privilège peuvent réellement fonctionner en pratique. Curieux de savoir ce qui fonctionne pour les autres dans leurs environnements hybrides ? soumis par /u/Varonis-Dan

Les comptes de jonction de domaine sont fréquemment exposés lors des processus de construction, et même en suivant les recommandations actuelles de Microsoft, ils héritent d'ACLs surprivilégiés (propriété, lecture complète, restrictions de compte) qui permettent la divulgation de LAPS, RBCD et d'autres abus à fort impact. Le renforcement nécessite la superposition de contrôles tels que l'interdiction aux utilisateurs à faibles privilèges de créer des comptes de machine et de s'assurer que les administrateurs de domaine sont propriétaires des objets ordinateur joints. De plus, ajoutez des ACE de refus pour LAPS (ms-Mcs-AdmPwd) et RBCD (msDS-AllowedToActOnBehalfOfOtherIdentity) tout en limitant les droits de création/suppression à des unités d'organisation spécifiques. Même avec ces atténuations, les droits de réinitialisation de mot de passe peuvent être militarisés via le retard de réplication plus AD CS pour récupérer le secret de la machine avant la réinitialisation. Plongez-vous dans ce post pour voir les procédures pas à pas du laboratoire, les pointeurs de détection et les scripts qui étayent ces affirmations. Soumis par /u/ivxrehc

https://maxwelldulin.com/BlogPost/Why-I-Fired-My-AI-Security-Assistant soumis par /u/mdulin2

Salut à tous, j'ai trouvé une campagne de phishing qui utilise le flux de partage de documents de Zoom comme vecteur de confiance initial. Elle force les victimes à passer par une fausse porte de "protection de bot", puis affiche une connexion de type Gmail. Lorsque quelqu'un tape ses identifiants, ils sont envoyés à l'attaquant via WebSocket et le backend les valide. Soumis par /u/unknownhad.

BsidesNoVA est une conférence sur la sécurité gérée par la communauté et organisée par des bénévoles, qui aura lieu du 10 au 11 octobre à GMU Mason Square à Arlington, VA. Plusieurs présentations et ateliers seront très techniques, s'adressant aux praticiens et aux chercheurs de la région du DMV. Les sujets abordés comprennent l'ingénierie de détection avec Sigma et KQL, la criminalistique réseau dans les environnements hybrides et la criminalistique de la mémoire sous Linux/macOS. Des chasses basées sur l'intelligence des menaces et un laboratoire de simulation de brèches seront également présentés. La conférence couvrira la recherche sur les adversaires, y compris la rupture de la détection de phishing basée sur l'IA et les techniques de pivotement OSINT pour le suivi des acteurs. Des scénarios de brèches en direct feront partie du Breach Village. Parmi les autres points forts, citons un concours Capture-the-Flag avec des prix de valeur pour des défis du monde réel. Il y aura des villages dédiés à la collaboration DFIR, IA et CTI, favorisant l'apprentissage et le réseautage en personne. Le programme est piloté par les pairs, garantissant l'absence de présentations de fournisseurs ou de contenu commercial. L'ordre du jour et les archives du CFP sont disponibles sur bsidesnova.org.

TLDR : Les LLM sont généralement plus performants que les outils SAST existants lorsque vous avez besoin de répondre à une question subjective qui nécessite du contexte (c'est-à-dire de nombreuses façons de définir une chose), mais seulement aussi bien (ou moins bien) lorsque vous recherchez une sortie objective et déterministe. L'IA fait beaucoup parler d'elle commercialement, mais en même temps, elle suscite un sentiment assez négatif de la part des praticiens (du moins d'après mon expérience). Il est vrai qu'il y a de nombreuses raisons de NE PAS utiliser l'IA, mais j'ai écrit un article de blog qui tente de résumer ce pour quoi l'IA est réellement douée en matière de revue de code. soumis par /u/prestonprice

Les vulnérabilités AMI BMC figurent désormais dans le catalogue CISA des vulnérabilités connues et exploitées. Je pense que c'est la première vulnérabilité BMC à figurer dans le KEV. Voici quelques modèles Nuclei pour détecter cette vulnérabilité dans vos BMC. soumis par /u/TechDeepDive

Ce subreddit est un forum de discussion, de questions et de partage d'outils directement liés à la sécurité des réseaux. Les participants sont tenus de maintenir un discours civil et d'éviter le contenu NSFW, qui doit être marqué s'il est utilisé. Les liens vers du contenu classifié doivent également être clairement indiqués, et les mèmes sont interdits au profit de la communication verbale. Aucune demande ou offre de support technique n'est autorisée sur cette plateforme.

Dans la version 3.0 de PacketSmith, que nous avons expédiée lundi, nous avons ajouté un fragmentateur IPv4/IPv6. Aujourd'hui, nous publions un article décrivant certains des détails d'implémentation qui le sous-tendent. soumis par /u/MFMokbel

J'ai créé PhishCan parce que j'étais frustré par le manque de ressources gratuites et accessibles sur les cybermenaces au Canada. Priorité au Canada : données de phishing qui reflètent réellement les cibles locales (banques, services publics, gouvernement, alertes aux investisseurs). Ouvert et transparent : tout est gratuit, avec une API publique et des données brutes sur GitHub. Pipeline continu : les domaines, les acteurs et les infrastructures sont surveillés en temps quasi réel et enrichis de contexte, toutes les 12 heures. Données sur Github : https://github.com/Phishcan/phishcan-data soumis par /u/Additional_Swan_9280