Comment Meta et l’industrie de la sécurité collaborent pour sécuriser Internet

La chasse aux bogues est difficile et peut parfois passer inaperçue dans notre industrie. La création de méthodes de détection de bogues évolutives sur de grandes bases de code et des bibliothèques open source est un effort sous-estimé mais critique auquel toute société d’ingénierie doit s’atteler. Parce que le résultat idéal est que les bugs sont trouvés et corrigés avant qu’ils ne soient exploités, certains des meilleurs travaux de notre industrie sont souvent inconnus.

Cependant, le partage d’informations sur les découvertes de bugs entre nos ingénieurs, ou entre les chercheurs de bug bounty, a généré de nouvelles idées et conduit à de nouvelles façons d’améliorer la sécurité de notre plateforme. Nous pensons que le partage plus régulier de nos principaux apprentissages avec l’extérieur est un pas en avant important pour la transparence et l’avancement dans notre industrie.

Aujourd’hui, nous sommes ravis de publier le premier d’une série de bulletins de bogues réguliers, dans lesquels nous partageons les détails de certaines des découvertes notables identifiées dans notre propre code et dans celui de tiers. Utilisez ces bulletins pour partager des aperçus et parfois des analyses approfondies de bogues spécifiques, ainsi que des mises à jour sur les programmes de sécurité pertinents.

Comment nous chassons les bogues chez Meta

Avant de nous plonger dans les apprentissages récents, voici un peu de contexte sur la façon dont nous recherchons les bogues de sécurité chez Meta : La recherche et la correction des bogues est une partie essentielle de notre stratégie de sécurité de défense en profondeur. Cette approche signifie que nous avons mis en place des couches de protection sur notre plateforme. Si une vulnérabilité dans notre code dépasse une ligne de défense, nous disposons de couches de support supplémentaires pour prévenir et résoudre les bogues le plus rapidement possible.

Comme il est pratiquement impossible d’écrire du code sans faille, il n’est pas rare que les logiciels internes et open source aient des bogues. Comme nos pairs, notre stratégie est double : tout en travaillant constamment à l’amélioration de la qualité de notre code avant qu’il ne soit mis en production, nous intégrons également des couches de protection pour prévenir et détecter les bogues dans le code existant le plus rapidement possible. Nous comptons sur une combinaison de outillage automatisérevues de sécurité, équipe rougeet notre Programme Bug Bounty pour aider à garder notre communauté en sécurité. Ce travail ne se fait pas dans le vide ou au sein d’une seule équipe. Et souvent, les bogues découverts dans un domaine de produit peuvent éclairer la façon dont nous abordons notre travail dans une partie entièrement différente de la base de code.

Dans ce premier article de la série, partagez bien les bogues notables que nous avons trouvés et corrigés dans notre propre logiciel et signalés à des développeurs tiers, et mettez bien en évidence certaines des découvertes de nos chercheurs de primes de bogues.

Travail d’analyse statique

Notre automatisé outils d’analyse statique aidez-nous à examiner de grandes quantités de code à grande échelle, ce qui libère du temps pour que nos ingénieurs analysent des scénarios plus complexes. Au cours des cinq dernières années, nous avons construit et continuellement amélioré nos outils maison, ils nous aident maintenant à trouver environ 70 % des vulnérabilités de sécurité que nous découvrons. Par exemple, notre travail sur Zoncolanqui passe en revue le code de piratage, nous a aidés à trouver plus de 1 300 bogues cette année.

Zoncolan a récemment identifié un bogue dans la production back-end de Messengers qui aurait pu permettre à un mauvais acteur d’injecter Vous avez célébré un amiversaire avec un ami dans un fil de discussion entre deux peple. Cela aurait pu être exploité par un acteur malveillant pour créer un faux sentiment de connexion authentique à long terme à exploiter pour les escroqueries. Le message serait apparu dans la liste de discussion de quelqu’un s’il était déjà connecté ou dans son dossier de demande de message s’il ne l’était pas. Zoncolan a trouvé ce bogue en observant que nos systèmes acceptaient les entrées des utilisateurs et en créaient un contexte de visualisation. Ces terminaux vulnérables n’avaient aucune intégration frontale et n’étaient présents nulle part dans nos applications en production. Notre équipe a rapidement examiné le rapport de Zoncolan, n’a trouvé aucune preuve d’abus et a atténué les points de terminaison touchés pour résoudre le problème.

Travail de l’équipe rouge X

En plus de chasser les bugs dans notre propre code, notre Équipe rouge X travaille à repérer les vulnérabilités de sécurité dans le matériel et les logiciels externes et à assurer la sécurité d’Internet au sens large. Dans le cadre de notre politique de divulgation responsable, nous signalons régulièrement les bogues dans le code tiers aux entreprises et travaillons directement avec elles pour tester et confirmer leurs atténuations. Voici quelques exemples récents de collaborations intéressantes que nous avons eues dans l’industrie.

Notre équipe travaille avec Schneider Electric, une entreprise qui se spécialise dans l’automatisation numérique et la gestion de l’énergiepour corriger un ensemble de vulnérabilités dans deux modules Ethernet qui apportent des capacités de mise en réseau modernes à la gamme d’automates M580 (contrôleurs logiques programmables). Les API ou PAC (contrôleurs d’automatisation programmables) permettent à l’équipement d’agir sur des instructions complexes et sont utilisés dans les systèmes de contrôle industriels pour les machines dans de nombreuses industries. Lorsqu’elles sont enchaînées, les vulnérabilités identifiées pourraient permettre à un attaquant authentifié de contourner plusieurs étapes de vérification du micrologiciel et le processus de démarrage sécurisé des modules, en écrasant à distance le micrologiciel des modules. Cela pourrait conduire à un blocage permanent ou à une porte dérobée de l’appareil. Pour exploiter ces vulnérabilités, un attaquant aurait besoin d’un accès au réseau et d’informations d’identification valides pour le compte d’installation privilégié. Schneider Electric effectue une analyse complète pour identifier et fournir des correctifs pour tous les produits concernés par ces découvertes. Ces vulnérabilités ont été attribuées CVE-2022-34759, CVE-2022-34760, CVE-2022-34761, CVE-2022-34762, CVE-2022-34763, CVE-2022-34764et CVE-2022-34765.

Nous avons également travaillé avec Airspan, une société qui fournit du matériel et des logiciels pour les réseaux 4G et 5G, pour renforcer une gamme d’eNodeB, les points d’accès sans fil qui fournissent un service cellulaire aux téléphones et autres appareils LTE et leur permettent de se connecter au réseau. Nous avons signalé des problèmes et vérifié des correctifs pour les vulnérabilités qui auraient pu permettre à des adversaires locaux et en réseau d’obtenir l’exécution de commandes root. En contrôlant le dernier saut de l’infrastructure LTE, un attaquant aurait pu affecter la disponibilité en désactivant le service cellulaire. Notre enquête a révélé que même si un attaquant aurait pu accéder au trafic utilisateur chiffré, il n’aurait pas été en mesure de le déchiffrer. Un acteur malveillant aurait pu utiliser leur accès pour pivoter davantage dans l’infrastructure cellulaire afin d’impacter davantage les réseaux d’entreprise où ces eNodeB sont déployés, ou même pour se connecter aux principaux opérateurs de réseau qui acheminent et gèrent les données et les appels LTE. Ces problèmes ont été attribués CVE-2022-36306, CVE-2022-36307, CVE-2022-36308, CVE-2022-36309, CVE-2022-36310CVE-2022-36311 et CVE-2022-36312.

Notre Red Team X a récemment signalé une vulnérabilité dans le système d’exploitation Apples Big Sur qui permet l’exécution de code noyau dans les noyaux Darwin. Cela aurait pu être exploité en forkant des processus et en tirant parti de l’API host_request_notification. Nous avons trouvé ce bogue grâce à un audit manuel de Darwin Kernel et à des expérimentations. Apple a divulgué la vulnérabilité et publié des correctifs logiciels dans la mise à jour de sécurité 2021-005 Catalina ; iOS 14.8 et iPadOS 14.8 ; tvOS 15; iOS 15 et iPadOS 15 ; watchOS 8; et macOS Big Sur 11.6. Ce constat a été attribué CVE-2021-30857.

Grâce à l’examen manuel du code, Red Team X a également trouvé une série de bogues dans EternalTerminal, un service de terminal distant open source tiers qui peut se reconnecter automatiquement après des événements tels que des pannes de réseau et l’itinérance IP sans interrompre la session. Plus particulièrement, ils ont signalé un bogue qui pourrait permettre à l’attaquant de modifier les autorisations de propriété sur des fichiers arbitraires et par la suite.tu gagnes privilèges root sur la machine hôte. Ces bogues ont été corrigés par les responsables d’EternalTerminal et attribués CVE-2022-24949, CVE-2022-24950, CVE-2022-24951et CVE-2022-24952.

Travail de prime de bogue

L’un des avantages d’avoir un contrat de plus de 10 ans Programme Bug Bounty est que certains de nos chercheurs ont consacré des années à la chasse sur notre plateforme et sont devenus extrêmement familiers avec nos produits et services. Ces chercheurs sont capables de creuser au-delà des problèmes superficiels et de nous aider à identifier les bogues percutants mais de niche que la communauté au sens large ne saurait nécessairement rechercher.

Par exemple, l’un de nos chercheurs de longue date, Youssef Sammouda, a passé sept mois à rechercher des bugs sur notre API Facebook, connue sous le nom de Canvas App. Il y a plus de dix ans, nous avons créé l’application Canvas pour aider les développeurs à intégrer leurs jeux et applications sur notre plateforme de jeux en ligne. Sammouda a audité le code côté client à l’intérieur applications.facebook.com et trouvé un certain nombre de bogues très graves dans notre implémentation OAuth qui auraient pu conduire à un scénario de prise de contrôle de compte. Il s’agissait de scénarios complexes où, pour tenter d’exploiter les bogues, un attaquant devait inciter sa cible à cliquer sur un lien, par exemple. Nous avons enquêté sur ces signalements, résolu les problèmes et n’avons trouvé aucune preuve d’abus. Au total, Sammouda a soumis six rapports de bugs à nous, totalisant 187 250 $ en bounty récompenses. À ce jour, il s’agit de la plus grande série de paiements que nous ayons accordée à un chercheur pour une seule mise en œuvre. Nous avons travaillé avec lui pour confirmer nos atténuations, et nous apprécions son partenariat continu pour tester nos défenses. Sammouda a partagé des informations et des conseils supplémentaires pour les chercheurs en sécurité dans son blog.

Un autre de nos chercheurs de longue date, Philippe Harewood, a récemment identifié une vulnérabilité de terminal qui aurait pu permettre à un acteur malveillant de récupérer un jeton d’accès à une application Instagram. Le grand avantage de travailler sur ces rapports avec nos chercheurs est que même lorsque nous avons des protections en place pour empêcher les scénarios d’exploitation les plus percutants comme dans ce cas, la collaboration nous amène souvent à apporter des modifications pour éviter des problèmes similaires à l’avenir dans notre base de code, et nous récompensons les chercheurs en fonction de l’impact maximal potentiel que nous constatons à la suite de nos propres recherches sur la sécurité interne. Nous avons résolu ce problème de point de terminaison, n’avons vu aucun indicateur d’abus et avons attribué à Harewood une prime de 30 000 $. Harewood a partagé des informations supplémentaires sur son blog.

Nous sommes reconnaissants à la communauté de la sécurité d’avoir contribué à l’excellente recherche de notre programme. Continuons à faire notre part pour élargir le bassin de chercheurs pour rejoindre la communauté des primes de bogues. Nous avons récemment organisé notre première Conférence BountyConEDU à Madrid, où nous avons invité des étudiants universitaires et de jeunes diplômés de toute l’Europe à découvrir comment nous enquêtons sur les signalements et à participer à un événement de piratage en direct. En trois jours, nous avons reçu 26 rapports valides et versé plus de 35 000 $ en primes. Cet événement pilote a largement dépassé nos attentes et nous sommes ravis d’utiliser nos apprentissages pour créer des opportunités similaires dans le monde entier.

Alors que nous continuons à façonner le format de ces Bulletin de bogue mises à jour, nous accueillons tous les commentaires de nos partenaires de l’industrie et de nos pairs et espérons qu’ils nous feront savoir ce qu’ils trouveraient le plus utile de lire ensuite le blog Engineering at Meta.