IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

FBI : des pirates informatiques ont volé le code source d'agences gouvernementales américaines et d'entreprises privées,
à cause des outils de gestion de code source de SonarQube mal configurés

Le , par Stan Adkens

557PARTAGES

5  0 
Le Federal Bureau of Investigation (FBI) a envoyé en octobre dernier un avertissement aux services de sécurité des entreprises et des organisations gouvernementales. Le document divulgué la semaine dernière indique que les pirates informatiques inconnus ont profité d'une vulnérabilité de la plateforme pour vérification des erreurs dans le code de SonarQube pour accéder aux dépôts de code source. Cela conduit à des fuites de codes sources provenant d'organismes gouvernementaux et d'entreprises privées.

L'alerte du FBI a mis en garde les propriétaires de SonarQube, une application Web que les entreprises intègrent dans leurs chaînes de construction de logiciels pour tester le code source et découvrir les failles de sécurité avant de lancer le code et les applications dans les environnements de production. Les développeurs ont besoin de tester leur code source avant de les déployer.


Les acteurs exploitent des vulnérabilités de configuration connues, ce qui leur permet d'accéder à du code propriétaire, de l'exfiltrer et de publier les données. Le FBI a identifié de multiples intrusions informatiques potentielles qui sont en corrélation avec des fuites associées aux vulnérabilités de configuration de SonarQube.

Les applications SonarQube sont installées sur des serveurs Web et connectées à des systèmes d'hébergement de code source comme les comptes BitBucket, GitHub ou GitLab, ou les systèmes Azure DevOps. Selon le FBI, certaines entreprises ont laissé ces systèmes non protégés, fonctionnant avec leur configuration par défaut (sur le port 9000) et des identifiants d'administration par défaut (admin/admin). Les pirates informatiques abusent des applications SonarQube mal configurées depuis au moins avril 2020.

« Depuis avril 2020, des cyberacteurs non identifiés ont activement ciblé des instances vulnérables de SonarQube pour accéder aux dépôts de code source des agences gouvernementales américaines et les entreprises privées. Les acteurs exploitent des vulnérabilités de configuration connues, leur permettant d'accéder à du code propriétaire, l'exfiltrer et afficher les données publiquement. Le FBI a identifié de multiples intrusions informatiques potentielles en corrélation avec les fuites associées aux vulnérabilités de la configuration de SonarQube », lit-on dans le document du FBI.

Les responsables du FBI affirment que les acteurs de la menace ont abusé de ces mauvaises configurations pour accéder aux instances de SonarQube, pivoter vers les dépôts de code source connectés, puis accéder et voler des applications propriétaires ou privées/sensibles. Les fonctionnaires du FBI ont étayé leur alerte en fournissant deux exemples d'incidents passés qui ont eu lieu au cours des précédents mois :

« En août 2020, des acteurs de la menace inconnus ont divulgué des données internes de deux organisations par le biais d'un outil de dépôt public de cycle de vie. Les données volées provenaient d'instances SonarQube qui utilisaient des paramètres de port par défaut et des identifiants d'administration fonctionnant sur les réseaux des organisations concernées ».

« Cette activité est similaire à une précédente fuite de données en juillet 2020, dans laquelle un cyberacteur identifié a exfiltré le code source propriétaire d'entreprises par le biais d'instances SonarQube mal sécurisées et a publié le code source exfiltré sur un dépôt public autohébergé », lit-on.

Une faille dans les applications SonarQube déjà signalée auparavant

L'alerte du FBI touche à un problème peu connu des développeurs de logiciels et des chercheurs en sécurité. Alors que l'industrie de la cybersécurité a souvent mis en garde contre les dangers de laisser les bases de données MongoDB ou Elasticsearch exposées en ligne sans mot de passe, SonarQube a échappé à la vigilance. En effet, des instances MongoDB ou Elasticsearch ont souvent été trouvées en ligne par des chercheurs exposant des données sur des dizaines de millions de clients sans protection.

Par exemple en janvier 2019, une base de données Elasticsearch mal configurée en ligne a été découverte par Justin Paine, un chercheur en sécurité, exposant une importante quantité d’enregistrements client à la merci de toutes personnes malveillantes qui auraient découvert la vulnérabilité. Les informations sur plus de 108 millions de paris, y compris des détails des informations personnelles des utilisateurs, appartenaient aux clients d’un groupe de casinos en ligne.

Cependant, certains chercheurs en sécurité ont mis en garde depuis mai 2018 contre les mêmes dangers lorsque les entreprises laissent les applications SonarQube exposées en ligne avec des identifiants par défaut. À l'époque, le consultant en cybersécurité qui se concentre sur la recherche de brèches dans les données, Bob Diachenko, avait averti qu'environ 30 à 40 % des quelque 3000 instances de SonarQube disponibles en ligne à l'époque n'avaient pas de mot de passe ou de mécanisme d'authentification activé.

« Après que @zackwhittaker ait couvert la fuite d'EE, j'ai fait quelques recherches sur SonarQube. J'ai été choqué de voir plus de 3K+ instances disponibles, avec environ 30-40 % d'entre elles définies sans authentification, et presque la moitié de celles-ci contenant du code source avec des données de production. De grands noms sont impliqués, un autre domaine à couvrir », avait-il averti.


Un autre chercheur en sécurité nommé Till Kottmann a également soulevé, en août cette année, la même question des instances mal configurées des applications SonarQube. Tout au long de l'année, Kottmann a rassemblé sur un portail public le code source de dizaines d'entreprises technologiques, dont beaucoup provenaient d'applications SonarQube.

« La plupart des gens semblent ne modifier absolument aucun des paramètres, qui sont en fait correctement expliqués dans le guide de configuration de SonarQube », a dit Kottmann dans une déclaration. « Je ne connais pas le nombre actuel d'instances SonarQube exposées, mais je doute que cela ait beaucoup changé. Je pense qu'il y a encore plus de 1000 serveurs (indexés par Shodan) qui sont "vulnérables", soit parce qu'ils ne nécessitent pas d'authentification, soit parce qu'ils laissent des créneaux par défaut », a-t-il ajouté.


Après que Kottmann ait accédé aux codes de diverses entreprises, et après vérification, SonarSource, éditeur de SonarQube, a confirmé dans un billet de blog qu’ « il était possible d'accéder au code source en raison de la manière dont ces instances spécifiques de SonarQube étaient configurées, et non en raison d'une vulnérabilité du produit SonarQube lui-même ».

« SonarQube est un produit sur site qui permet d'analyser la qualité et la sécurité du code. En tant que tel, il est conçu pour s'installer derrière le pare-feu, dans l'environnement privé des entreprises. Les entreprises peuvent bien sûr décider de l'exposer à l'extérieur de leur pare-feu, auquel cas il nécessite une configuration spécifique », a écrit SonarSource. L’entreprise a jouté que les instances de SonarQube auxquelles Kottmann a pu accéder « sont celles qui sont accessibles sur le Web et qui n'ont pas fait l'objet d'une configuration supplémentaire pour empêcher un accès non authentifié ».

Pour éviter de telles fuites, l'alerte du FBI énumère une également série de mesures que les entreprises peuvent prendre pour protéger leurs serveurs SonarQube :

  • Modifier les paramètres par défaut de SonarQube, notamment en changeant le nom d'utilisateur de l'administrateur par défaut, le mot de passe et le port (9000).
  • Placez les instances de SonarQube derrière un écran de connexion, et vérifiez si des utilisateurs non autorisés ont accédé à l'instance.
  • Révoquer l'accès à toute clé d'interface de programmation d'application ou à tout autre justificatif d'identité qui a été exposé dans une instance SonarQube, si possible.
  • Configurez les instances SonarQube pour qu'elles se placent derrière le pare-feu de votre organisation et d'autres défenses de périmètre afin d'empêcher tout accès non authentifié.

Le FBI encourage, en outre, les destinataires de l’alerte à communiquer les informations concernant des activités suspectes ou criminelles à leur bureau local du FBI. Selon un commentateur, le problème des bases de données laissées avec les paramètres par défaut peut aussi être réglé au niveau des États, à l’image des mesures prises par la Californie dans une loi concernant la sécurité des objets connectés (IdO).

En général, les dispositifs IdO doivent être dotés d'un dispositif de sécurité raisonnable, et cette loi considère un dispositif de sécurité comme raisonnable si l'une des exigences suivantes est remplie : « (1) Le mot de passe préprogrammé est unique à chaque dispositif fabriqué ; » ou « (2) Le dispositif contient un dispositif de sécurité qui nécessite une utilisation pour générer un nouveau moyen d'authentification avant que l'accès ne soit accordé au dispositif pour la première fois ». Et vous, qu’en pensez-vous ?

Sources : FBI, Tweet, SonarSource

Et vous ?

Qu’en pensez-vous ?
Selon vous, pourquoi les entreprises continuent de laisser les bases de données en ligne avec les paramètres par défaut malgré les mises en garde ?
Pensez-vous que des législations à l’échelle des pays similaires à celle de la Californie (concernant l’IdO) pourrait résoudre le problème ?

Voir aussi :

108 millions de paris de clients de casinos en ligne exposés via une instance Elasticsearch mal configurée, y compris les détails des utilisateurs
MongoDB : 202 millions de CV privés exposés sur internet, à cause d'une base de données non protégée
90 millions d'enregistrements de données personnelles divulgués sur Internet par la Chine, via un serveur ElasticSearch non sécurisé
Le Congrès US étudie un projet de loi sur la sécurisation de l'internet des objets, dont la faiblesse constitue l'une des « plus importantes menaces »

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Fagus
Membre expert https://www.developpez.com
Le 09/11/2020 à 13:42
Selon vous, pourquoi les entreprises continuent de laisser les bases de données en ligne avec les paramètres par défaut malgré les mises en garde ?
Parce que c'est possible.

Si le logiciel n'interdit pas à l'admin autre chose qu'un test en local avec un login par défaut, c'est qu'il n'est pas conçu pour la sécurité.
Il y a même des logiciels amateurs qui interdisent d'utiliser une authentification faible...
0  0 
Avatar de tanaka59
Inactif https://www.developpez.com
Le 10/11/2020 à 13:43
Bonjour,

FBI : des pirates informatiques ont volé le code source d'agences gouvernementales américaines et d'entreprises privées, à cause des outils de gestion de code source de SonarQube mal configurés.

Qu’en pensez-vous ?
Personne n'est invulnérable , pas même les administrations publiques. Surtout dans ce secteur ou la culture "IT" a plusieurs année de retard. Parfois c'est par manque de temps et de personnel que des app sont laissées en plan avec des défauts lors de l'installation.

Selon vous, pourquoi les entreprises continuent de laisser les bases de données en ligne avec les paramètres par défaut malgré les mises en garde ?
> un prestataire s'occupe de l'alimentation, le canal n'étant pas un canal interne l'entreprise pense bien souvent que c'est de la responsabilité du presta tant que c'est pas sa chaîne de valeur traitement.
> une méconnaissance de logiciel/app utilisé et des fonctions mal maitrisées.
> un cas de test qui est passé entre les mailles du filets car non identifié ou auquel on a pas pensé lors de la defi

Pensez-vous que des législations à l’échelle des pays similaires à celle de la Californie (concernant l’IdO) pourrait résoudre le problème ?
Prendre des lois et réglements pour sanctionner les personnes et entreprises negligeantes c'est bien. Pouvoir faire appliquer par une autorité juridique qui n'est pas dépassé techniquement et n'a pas une simple approche bureaucratique c'est mieux ...
0  0