Archives de catégorie : APT

APT, backdoor, Communiqué de presse, Cyber-attaque, Cybersécurité, Leak, Mise à jour, Piratage, Securite informatique

Infy : Prince of Persia persiste et signe

En février 2017, l’Unit42, unité de recherches de Palo Alto Networks a observé une évolution du malware “Infy” que nous avons appelée « Foudre ». Les acteurs concernés semblent avoir tiré les enseignements suite à notre démantèlement et notre sinkholing (redirection vers un serveur que nous contrôlons) de leur infrastructure de commande et de contrôle (C2). En effet, Foudre intègre désormais de nouvelles techniques anti-démantèlement censées éviter que ses domaines C2 ne soient détournés vers un site sinkhole comme nous l’avions fait en 2016.

L’Unit42 a documenté ses travaux de recherche originels sur cette campagne vieille de dix ans en utilisant le malware Infy en mai 2016. Un mois après la publication de ces travaux, l’Unit42 a donné une description détaillée de notre démantèlement et de notre sinkholing des serveurs C2 de l’acteur. En juillet 2016, au congrès Blackhat U.S.A, Claudio Guarnieri et Collin Anderson ont présenté des preuves montrant qu’un sous-ensemble des domaines C2 redirigés vers notre sinkhole avaient été bloqués par falsification DNS et filtrage HTTP par la Telecommunication Company of Iran (AS12880), empêchant l’accès depuis le territoire national iranien à notre sinkhole.

Voici les modifications apportées au malware dans ce blog post dédié, quelques informations et précisions ci-dessous. L’Unit42 en profite également pour mettre en avant certaines erreurs courantes, et explique comment elle les a exploitées pour en savoir plus sur cette campagne.
Cartographie des victimes

L’Unit42 avait prévu l’un des noms de domaine DGA et l’avait enregistré avant que l’adversaire ne puisse le faire.

Les victimes ont tenté de se connecter à un C2 dans ce domaine, mais, ne possédant pas la clé privée RSA, l’Unit42 n’a pas pu vérifier son domaine auprès d’elles. Cependant, elle a pu établir une cartographie géolocalisant les victimes à l’aide de GeoIP (voir pièce jointe).

On remarque la prépondérance des victimes sur le territoire national iranien, ce qui rappelle fortement les campagnes d’Infy. Les attaques menées contre les États-Unis et l’Irak sont aussi familières. Ici encore, le très petit nombre de cibles fait penser à une motivation non financière.

L’une des victimes en Irak utilise une adresse IP dans le même réseau de classe C que l’une des victimes Infy déjà observées, ce qui laisse à penser que l’adversaire cible la même organisation, voire le même ordinateur.

Même si, en l’absence de la clé privée RSA, l’Unit42 n’a pas réussi à établir la communication avec les victimes, elle a découvert qu’en envoyant un fichier de signature non valide à la victime, du fait de l’absence de validation en entrée du contenu/de la taille de ce fichier, elle arrive à faire échouer le processus rundll32 qui exécute la DLL malveillante de Foudre. Cela permet de désactiver l’infection jusqu’à ce que la victime réinitialise sa machine.
Conclusion

Dans son post, blog Prince of Persia, l’Unit42 avait indiqué que cette campagne durait depuis au moins une dizaine d’années. Ainsi, elle a poursuivi le sujet avec son blog Prince of Persia: Game Over, qui documente son démantèlement et son sinkholing de l’infrastructure C2 de l’adversaire.

En ce qui concerne les actions de la Telecommunication Company of Iran en vue d’empêcher les C2 d’être redirigés vers notre sinkhole, Guarnieri et Anderson font observer que « la politique de filtrage indique que les autorités iraniennes sont intervenues spécialement pour bloquer l’accès aux domaines de commande et de contrôle d’une campagne d’intrusion visant l’État, au niveau national. »

L’Unit42 s’attend à voir Infy faire son retour : dans les grandes lignes, ce sera toujours le même malware, ciblant les mêmes victimes.

Les acteurs ont compris qu’ils avaient besoin d’une infrastructure C2 plus robuste pour empêcher l’infiltration et le démantèlement. L’algorithme DGA apporte une dose de résilience, mais n’est pas invulnérable à un démantèlement.

Toutefois, l’utilisation de la signature numérique constitue un dispositif de défense contre un C2. Sans accès aux clés privées, il n’est pas possible d’usurper l’identité d’un C2 même si un domaine DGA est enregistré par un chercheur. Il se peut que les clés privées résident localement sur le serveur C2, mais sans accès au C2, nous ne pouvons pas confirmer cette vulnérabilité potentielle de leur infrastructure.

Décidément, Prince of Persia persiste et signe.

APT, Base de données, BYOD, Chiffrement, Cloud, Cybersécurité, Entreprise, Mise à jour, Securite informatique

Les risques, les vulnérabilités, les licences des logiciels open source

Les risques concernant la sécurité et la conformité des composants tiers atteignent des proportions incontrôlables, et menacent l’intégrité même de la chaîne d’approvisionnement de logiciels.  Il suffit de voir l’impact de la faille Heartbleed pour s’en convaincre !

Aujourd’hui, les entreprises incluent davantage de code open source que d’éléments conçus en interne ou propriétaires dans leurs produits.  Malheureusement, en profitant de ces logiciels open source (OSS) pour accélérer le développement de leurs produits, la plupart d’entre elles ne respectent pas les licences open source associées à ces composants.  Bien que les OSS soient gratuits, leurs utilisateurs ne sont pas pour autant libres de toute obligation les concernant.  Celles-ci peuvent aller de la reproduction de déclarations de droits d’auteur ou d’une copie d’un document de licence à la divulgation de l’intégralité du code source de leurs produits.  Des enquêtes récentes ont montré que la plupart des entreprises ne connaissent qu’un faible pourcentage des composants open source sur lesquels elles s’appuient, et ne sont donc pas en mesure de respecter les obligations indiquées dans les licences de ces éléments.  En outre, ces logiciels peuvent comporter des bugs ou des vulnérabilités susceptibles d’affecter votre produit.  Sans un suivi adéquat, ce dernier peut passer à côté de mises à jour ou de patches corrigeant des vulnérabilités connues. Mais malgré cela l’open source offre de précieux avantages.

Découverte, gestion et conformité en cinq étapes

Face aux problématiques de conformité ou de gestion des vulnérabilités des OSS, la première question est généralement : « Comment savoir quels composants open source nous utilisons ? » Il est possible de mieux comprendre ce que l’on fait et de mettre en place un processus pour découvrir, gérer et s’assurer de la conformité avec ces OSS en cinq étapes.

Étape 1 :  comprendre comment les OSS sont introduits dans votre entreprise

Les OSS peuvent s’introduire de différentes façons.  Cas classique : un développeur décide d’utiliser un composant open source, télécharge le code source, et l’intègre au produit.  Ce cas est encore très fréquent, mais il existe bien d’autres scénarios.  Très souvent, les développeurs utilisent ce qu’on appelle des gestionnaires de référentiels (repository manager).  Ces outils leur permettent d’indiquer les composants qu’ils veulent utiliser, puis s’occupent eux-mêmes d’en télécharger le code source ou des fichiers binaires compilés. Ces gestionnaires stockent généralement les composants open source dans un référentiel distinct, hors du système classique de gestion des codes source.  On peut notamment citer parmi eux Maven, Nuget ou npm.

Des éléments open source peuvent également être introduits dans une organisation en tant que sous-composant d’un composant open source plus important ou commercial.  Les composants de premier niveau ont très souvent plusieurs sous-composants ou dépendances open source, qui sont rarement divulgués ou gérés.

En outre, ces éléments serviront de pièces d’une infrastructure runtime, comme des serveurs Web, des systèmes d’exploitation ou des bases de données et peuvent permettre de contrer les risques.

Étape 2 :  chercher les OSS

Une fois que vous savez comment vos composants open source sont sélectionnés et utilisés, vous pouvez évaluer les risques et ceux dont vous avez besoin, et comment ils sont utilisés ou répartis.  On appelle ça dresser une nomenclature (Bill of Materials), ou une liste de divulgation.  Cette liste sert à suivre les obligations, à modifier les politiques vis-à-vis des OSS, et à réagir aux vulnérabilités rendues publiques.  Souvent, des paquets open source comporteront des termes de licence que votre organisation ne pourra pas respecter, ce qui pose automatiquement un problème de conformité.  Dans de tels cas, le composant en question devra être supprimé et la fonctionnalité remplacée, soit par un autre composant OSS, ou en écrivant une fonctionnalité équivalente.

L’examen du code base, les risques, la tenue d’entretiens et l’utilisation d’outils d’analyse de code peuvent être utiles dans le cadre de ce processus.

Étape 3 : questionner l’équipe de développement

Les projets devenant sans cesse plus vastes, complexes et distribués, il est de plus en plus difficile de découvrir l’ensemble des éléments utilisés.  Il est donc important d’avoir des échanges réguliers avec les développeurs, équipes DevOps, ainsi que l’ensemble du personnel informatique impliqué dans la création, le déploiement et la mise en œuvre du projet en question.  Posez-leur des questions ciblées, comme « Quelle base de données utilisons-nous ? », ou « Quelle bibliothèque de chiffrement utilisons-nous ? ».  Cela peut être utile pour découvrir d’autres modules potentiellement passés inaperçus la première fois.

Demander simplement « Quel code open source utilisons-nous » permet rarement de créer une liste complète pour un certain nombre de raisons, notamment à cause d’oublis ou de l’absence de registres adéquats.

Étape 4 : comprendre comment les OSS entrants sont gérés

La gestion des composants tiers et les risques doivent faire l’objet d’un processus cohérent et correctement appliqué.  Votre organisation pourra ainsi respecter ses obligations des licences open source, mais aussi faire face à de nouvelles vulnérabilités.  Il est fréquent de voir ce processus atteindre différentes étapes et niveaux de conformité.  Certaines organisations se contentent encore de suivre les composants « sollicités » par les développeurs.  Celles-ci n’ont souvent connaissance que des éléments les plus importants, ou découvrent que certains développeurs sont plus assidus que d’autres dans le cadre du respect du processus.

D’autres entreprises utilisent des outils d’analyse pour découvrir et suivre leurs OSS.  Leurs résultats varieront en fonction des solutions utilisées ou du niveau d’analyse.  Certains outils ne découvrent que les textes de licence, pas les composants open source. D’autres ne peuvent retrouver que les composants gérés par des gestionnaires de paquets.  Il est donc important de savoir quel niveau d’analyse est adopté et ce que l’on peut espérer repérer…

Étape 5 :  cherchez des preuves de conformité des OSS

Une fois toutes ces étapes franchies, il est important de confirmer la visibilité de cette conformité.  Les déclarations et autres avis légaux (droits d’auteurs) nécessaires sont-ils présents dans les produits ou leur documentation ?  Les textes des licences sont-ils visibles comme il se doit ?  Existe-t-il une offre écrite relative au code source ou ses distributions, et ciblant du contenu rendu libre que vous utilisez ?  Tous ces éléments seront les témoins visibles de l’efficacité de votre processus de gestion des composants open source.

En suivant ces cinq étapes, en sensibilisant votre personnel à l’utilisation adaptée des OSS, et en encourageant les membres de votre écosystème à en faire de même, vous pourrez créer des applications modernes et puissantes, tout en respectant les licences open source.

En outre, plus vous en savez sur les ingrédients, les éléments tiers et les vulnérabilités de votre produit, mieux ce dernier pourra être sécurisé et pris en charge ! (Par Christian Hindre – Directeur Commercial Europe de Flexera Software)

APT, Communiqué de presse, Cybersécurité, Entreprise, Fuite de données, Mise à jour, Social engineering

Le cyberespionnage via les APT devient le pire cauchemar des entreprises

En France, plus de deux tiers (71 %) des DSI estiment que leur entreprise pourrait « certainement » être la cible de campagnes de cyberespionnage utilisant des menaces persistantes avancées (Advanced Persistent Threats – APT) selon une récente étude.

Les APT, des cyber-outils complexes conçus sur mesure pour attaquer des grandes entreprises ou organismes d’état, et collecter discrètement des données sensibles sur de longues périodes. 27 % des personnes interrogées considèrent que leur infrastructure informatique pourrait « éventuellement » être la cible d’actions de cyberespionnage de haut niveau visant à exfiltrer des informations de manière systématique.

Seule une petite minorité n’est pas préoccupée par les APT

L’année dernière, des entreprises de  grande envergure ont été confrontées à un nombre croissant d’incidents et de violations de sécurité, avec une augmentation significative des APT et des attaques ciblées visant aussi bien les entreprises que les entités gouvernementales (telles que APT-28 et, plus récemment, Netrepser). En fait, moins de 2% des DSI considèrent que les APT ne sont pas une menace réelle pour leur environnement de travail. Les inquiétudes sur la sécurité vont en se multipliant, et la question est de plus en plus souvent traitée par les conseils d’administration des entreprises. Les hauts responsables de services informatiques, tout comme les membres des conseils d’administration s’en préoccupent de plus en plus, non seulement parce qu’une violation de la sécurité peut leur coûter cher, mais aussi parce que le futur des entreprises est en jeu quand des données sensibles sont dérobées par des pirates informatiques.

Les risques ne sont pas toujours visibles, mais ils sont bien présents

Étonnamment, si 42% des DSI ont déclaré qu’il leur faudrait entre quelques semaines et un mois pour repérer une APT, 23% d’entre eux pensent qu’il leur faudrait entre deux mois et plus d’un an pour détecter les menaces modernes les plus sophistiquées. Preuve que de nombreux professionnels interrogés sont au courant et craignent ces menaces, mais qu’ils pensent ne pas être suffisamment bien protégés pour les détecter et les bloquer.

Selon Liviu Arsene, Analyste des e-menaces chez Bitdefender, « les cyberattaques peuvent passer inaperçues pendant des mois et, dans la plupart des cas, les violations proviennent de failles Zero-day ou de malwares s’attaquant au noyau du système. Ce sont précisément ces vulnérabilités que ciblent les APT, car elles leur évitent d’être détectées. Les exploits au niveau du noyau et les rootkits peuvent échapper aux solutions de sécurité traditionnelles pour endpoints et prendre le contrôle total du système d’exploitation. »

Les menaces persistantes les plus avancées ne se limitent pas aux attaques soutenues par des États : les entreprises peuvent également devenir les victimes de cybercriminels qui exploitent des vulnérabilités Zero-day pour diffuser des malwares extrêmement ciblés conçus pour les espionner et voler des éléments de propriété intellectuelle. L’enquête de Bitdefender confirme que les RSSI considèrent leurs concurrents comme les plus susceptibles d’attaquer leurs entreprises, dans le cadre d’un espionnage professionnel (66%), suivis des hackers (57%).Les cybercriminels soutenus par des Etats, les agences gouvernementales et les personnes en interne arrivent respectivement en 3ème, 4ème et 5ème position (51, 41 et 30%).

Les risques sont réels, et les entreprises doivent les limiter

76 % des responsables de services informatiques français estiment que la pire conséquence à craindre d’une attaque par une APT est d’ordre financier. En deuxième position on retrouve l’atteinte à la réputation (66%), suivie de la faillite (51%). Parmi les risques les plus sinistres, citons également la guerre ou les cyber-conflits (24%) ; et même un décès par suicide ou attaque cardiaque (14%).

Les entreprises ont surtout peur de perdre des informations relatives à leurs clients (52%), suivies des informations financières (47%), des recherches sur de nouveaux produits (37%), des informations sur certains employés (35%), des informations et de caractéristiques de produits (34%), leur propriété intellectuelle (34%) et leurs recherches sur la concurrence (20%).

Ainsi, 94 % des conseils d’administration estiment que la cybersécurité est un sujet critique dans la gestion des risques de l’entreprise, avec des conséquences sévères sur leur situation financière et leur réputation si elle est négligée. Seuls 4% ne lui accordent pas encore une telle importance. La plupart des entreprises (58%) ont un plan de réponse aux incidents et un plan de reprise après sinistre dans le cas d’une attaque par APT ou d’une violation de sécurité massive, et 40% reconnaissent qu’elles sont en train d’élaborer une stratégie en la matière. Moins de 2% n’ont adopté aucune procédure de ce type à ce jour, et n’’envisagent pas de le faire dans le futur.

Une sécurité multi-couches est la meilleure solution

64% des responsables informatiques français interrogés perçoivent la défense multi-couches, associant plusieurs politiques de sécurité et outils conçus pour combattre les menaces et intrusions modernes, comme étant la meilleure défense contre les menaces persistantes avancées. Les audits de sécurité, les solutions de nouvelle génération, la sécurité traditionnelle et la surveillance des journaux ont également été mentionnés par plus d’un tiers des sondés. (Bitdefender)