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 !

Des adresses IP russes accèderaient aux données du gouvernement américain via le DOGE de Musk
Un lanceur d'alerte révèle une intrusion de haut niveau à l'aide d'un identifiant et d'un mot de passe approuvés

Le , par Stéphane le calme

28PARTAGES

18  0 
Une récente révélation d'un lanceur d'alerte a mis en lumière une faille de cybersécurité majeure au sein du gouvernement américain, impliquant le Département de l'Efficacité Gouvernementale (DOGE), dirigé par Elon Musk. Selon Daniel Berulis, architecte DevSecOps au Conseil National des Relations de Travail (NLRB), des techniciens de DOGE auraient obtenu un accès excessif aux systèmes du NLRB, permettant l'exfiltration de données sensibles.

Berulis affirme que des protocoles de journalisation ont été altérés et qu'environ 10 Go de données, incluant des informations sur des activités syndicales et des affidavits privés, ont été extraits des serveurs du NLRB. Il rapporte également des tentatives de connexion depuis une adresse IP russe utilisant des identifiants valides, bloquées grâce à des politiques de sécurité basées sur la localisation.


Contexte

Ces allégations soulèvent des préoccupations quant à la sécurité des infrastructures critiques américaines, notamment en ce qui concerne l'utilisation de Starlink, le service Internet par satellite de SpaceX. Berulis suggère que l'infrastructure de DOGE, connectée à Starlink, pourrait servir de canal direct vers des réseaux étrangers, facilitant potentiellement l'accès à des données sensibles par des acteurs russes.

En réponse à ces révélations, plusieurs poursuites judiciaires ont été engagées pour contester l'accès de DOGE aux données gouvernementales. Des groupes de défense de la vie privée, tels que l'Electronic Privacy Information Center (EPIC), ont intenté des actions en justice, qualifiant cette situation de « plus grande violation de données de l'histoire des États-Unis ».

Un accès avec des IP russes

Un lanceur d'alerte du National Labor Relations Board (NLRB) a expliqué comment le vol de données du DOGE a été immédiatement suivi d'une tentative d'accès à partir d'adresses IP russes, ce qui soulève de graves questions quant à la pénétration des systèmes les plus sensibles des États-Unis par des services de renseignement étrangers.

Daniel Berulis, informaticien au NLRB, a fourni des preuves montrant que, quelques minutes après que les ingénieurs du DOGE ont obtenu un accès de niveau « Dieu » aux systèmes sensibles du travail, quelqu'un opérant depuis la Russie a tenté de se connecter en utilisant des identifiants du DOGE nouvellement créés. Il ne s'agissait pas d'une simple supposition au hasard : cette personne avait le bon nom d'utilisateur et le bon mot de passe.

Il ne s'agissait pas d'une simple tentative de piratage. Selon la déclaration officielle de Berulis au Congrès : "Ces tentatives étaient “presque en temps réel”... La personne qui tentait de se connecter utilisait l'un des comptes DOGE nouvellement créés - et elle avait le bon nom d'utilisateur et le bon mot de passe".

Bien que ces tentatives de connexion russes aient été bloquées, elles révèlent la vulnérabilité immédiate créée par les activités de la DOGE. Le moment choisi suggère soit une négligence choquante, soit quelque chose de bien plus sinistre - une coordination avec des services de renseignement étrangers.


Les experts en cybersécurité qui ont examiné les preuves fournies par M. Berulis ont constaté l'existence de techniques correspondant à des opérations sophistiquées des services de renseignement russes. Russ Handorf, ancien cyberfonctionnaire du FBI, a noté que ces actions correspondent à ce que nous avons vu de la part d'acteurs russes ciblant les systèmes du gouvernement américain dans le passé. La principale différence ? "On leur a donné les clés de la porte d'entrée.

Cette connexion russe est particulièrement alarmante étant donné les liens bien documentés d'Elon Musk avec Poutine et les oligarques russes. Ses entreprises ont reçu d'importants investissements russes, y compris de la part de milliardaires sanctionnés. L'avocat du dénonciateur a spécifiquement noté la dimension du renseignement étranger, en déclarant : « Cette affaire est particulièrement délicate car elle implique la possibilité que des services de renseignement étrangers sophistiqués accèdent à des systèmes gouvernementaux sensibles. »

Il ne s'agissait pas d'une simple tentative de piratage. Selon la déclaration officielle de Berulis au Congrès : « Ces tentatives étaient “presque en temps réel”... La personne qui tentait de se connecter utilisait l'un des comptes DOGE nouvellement créés - et elle avait le bon nom d'utilisateur et le bon mot de passe ».

Bien que ces tentatives de connexion russes aient été bloquées, elles révèlent la vulnérabilité immédiate créée par les activités de la DOGE. Le moment choisi suggère soit une négligence choquante, soit quelque chose de bien plus sinistre (une coordination avec des services de renseignement étrangers).

Les experts en cybersécurité qui ont examiné les preuves fournies par Berulis ont constaté l'existence de techniques correspondant à des opérations sophistiquées des services de renseignement russes. Russ Handorf, ancien cyberfonctionnaire du FBI, a noté que ces actions correspondent à ce que nous avons vu de la part d'acteurs russes ciblant les systèmes du gouvernement américain dans le passé. La principale différence ?« On leur a donné les clés de la porte d'entrée ».

Cette connexion russe est particulièrement alarmante étant donné les liens bien documentés d'Elon Musk avec Poutine et les oligarques russes. Ses entreprises ont reçu d'importants investissements russes, y compris de la part de milliardaires sanctionnés. L'avocat du dénonciateur a spécifiquement noté la dimension du renseignement étranger, en déclarant : « Cette affaire est particulièrement délicate car elle implique la possibilité que des services de renseignement étrangers sophistiqués accèdent à des systèmes gouvernementaux sensibles. »

Daniel Berulis : la violation des données américaines par les Russes via le DOGE a été réalisée via Starlink « directement vers la Russie »

Suite à ses révélations surprenantes sur la façon dont les ingénieurs du DOGE ont accédé aux bases de données du MLRB sans autorisation, et que des adresses IP russes ont été utilisées avec des identifiants et des mots de passe récemment créés pour y accéder, Daniel Berulis (s'exprimant par l'intermédiaire de son avocat) a fait suivre cette révélation d'une nouvelle bombe selon laquelle les systèmes du DOGE « étaient également connectés à Starlink ».

Bakaj affirme que le ministère de la défense a cessé d'utiliser Starlink parce qu'il est considéré comme un « pipeline direct » vers la Russie. Starlink est le service Internet par satellite d'Elon Musk, qui appartient à SpaceX.

Berulis a partagé un graphique qui, selon lui, montre des « indications de compromission ».

Une cour d'appel a permis au DOGE du milliardaire Elon Musk d'accéder à nouveau aux données personnelles privées de trois agences fédérales

La décision de la cour d'appel marque un revirement par rapport aux jugements précédents. En février 2025, un juge fédéral a bloqué l'accès du DOGE aux informations sensibles du ministère de l'Éducation et de l'Office of Personnel Management (bureau de gestion du personnel). L'ordonnance a indiqué que le gouvernement américain avait [URL="https://droit.developpez.com/actu/369451/-Le-gouvernement-americain-a-viole-la-loi-sur-la-protection-de-la-vie-privee-en-divulguant-des-donnees-personnelles-au-DOGE-d-Elon-Musk-selon-un-juge-qui-estime-que-cela-constitue-un-prejudice-irreparable/"...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 01/05/2025 à 19:57
TRÈS TRISTE TOUT ÇA
2  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 02/05/2025 à 13:41
Citation Envoyé par Artemus24 Voir le message
Remplacer les gros ordinateur IBM VM/CMS JCL TSO ISP qui sont très performants, par des mini ordinateurs en migrant le COBOL vers du 'C/C++', risque d'être problématique du point de vue sécurité mais aussi en performance. C'est selon moi, peu réaliste.
Je te rassure, nous sommes entièrement d'accord. Les "quelques programmes" que je cite ne sont pas représentatifs d'un ERP, et la majeure partie du code COBOL est transformé vers un autre langage qui va te donner de bonnes raisons d'être horripilé; Du Python.

Citation Envoyé par Artemus24 Voir le message
Ce problème existe aussi dans les banques où l'on ne sait plus trop comment fonctionner des pans entiers de codes COBOL car il n'y a pas ou plus de documentations pour expliquer ce que ça fait réellement. Sans compter, le nombre considérable d'intervenant qui ont modifié le code, pas toujours d'une bonne manière. Bonjour pour faire une retroingérierie qui sera extrêment complexe, sans rien apporter de bénéfique au final.
Citation Envoyé par Prox_13
-Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.
Citation Envoyé par Artemus24 Voir le message
Entièrement d'accord. Donc pourquoi changer quelque chose qui fonctionne parfaitement ?
Les deux problèmes se recoupent;

Transcoder des règles de gestion déjà inutiles en COBOL vers un langage peu efficace comme le Python est d'un part chronophage et inefficient en performance (si la procédure est utilisée).
Engager des développeurs COBOL en 2025 est couteux; Continuer de maintenir le systeme dans ce langage c'est l'assurance de tomber en pénurie de budget ou de main d’œuvre.

En tout cas, j'essaie de me mettre dans les bottes des personnes en charge de la migration du système pour y voir ces points, ca ne veut pas dire que je tombe d'accord avec la solution retenue.

Citation Envoyé par Artemus24 Voir le message
J'ai réagit sur le fait que le COBOL n'est pas apparu avant guerre mais en 1959.
J'ai connu la fin des perforatrice et des cartes perforées pour écrire un programme. Le seul point positif est qu'à l'époque, on savait programmer car la place manquait et il fallait jongler dans des techniques qui ont totalement disparu aujourd'hui pour gérer la mémoire. C'est comparable entre la règle à calcule et les approximations que l'on faisaient à l'époque et l'avènement aujourd'hui des calculatrices et des ordinateurs qui nous ont simplifié grandement la tâche. Mais croire que la tâche sera plus simple de remplacer le COBOL est selon moi une erreur.
Je me doutais que tu avais une chose intéressante a dire sous cette remarque. Et encore une fois, nous tombons d'accord sur le fait que le COBOL sera difficilement remplaçable, de surcroit par une couche de Python.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 02/05/2025 à 14:04
J'ai fait mon activité professionnel dans les banques et un peu dans les assurances, au travers des SSII (ESN aujourd'hui). Le principale langage que j'ai utilisé est bien le COBOL que je trouve adapté pour de la gestion.

Citation Envoyé par Prox_13
et la majeure partie du code COBOL est transformé vers un autre langage qui va te donner de bonnes raisons d'être horripilé; Du Python.
Cela va dépendre de ce que l'on fait avec. Une grosse partie du développement en gestion est destiné à faire de la présentation de résultats, comme des états.
Par contre, c'est d'une stupidité si c'est le cœur même du métier car la performance n'est pas au rendez-vous, sans parler de la précision dans les calculs.

Citation Envoyé par Prox_13
Engager des développeurs COBOL en 2025 est couteux; Continuer de maintenir le système dans ce langage c'est l'assurance de tomber en pénurie de budget ou de main d’œuvre.
Je veux bien, mais tout réécrire couterait encore plus cher. Un des aspects que l'on maitrise le moins est justement la maintenance, que ce soit aujourd'hui, ou dans dix ans. Qui dit que le python sera encore d'actualité ? Et par quoi va-t-on le remplacer ? On va se retrouver avec un système totalement hétérogène ou plus personne n'osera mettre son nez dedans de peur de tout casser.
2  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 02/05/2025 à 16:31
Je ne préfère pas réveler le coeur de métier du système, par sécurité, ce serait possible de retrouver qui je suis ou pire, l'entreprise dans laquelle je travaille

Citation Envoyé par Artemus24 Voir le message
Cela va dépendre de ce que l'on fait avec. Une grosse partie du développement en gestion est destiné à faire de la présentation de résultats, comme des états.
Par contre, c'est d'une stupidité si c'est le cœur même du métier car la performance n'est pas au rendez-vous, sans parler de la précision dans les calculs.
Je suis peut-être a côté de la plaque par rapport à mes supérieurs hiérarchiques qui prennent ces décisions sur les technologies a adopter, mais le but est clair comme du cristal de roche :
Il faut remplacer tout code COBOL par du Python, par principe de facilité de maintenance. (Y compris les programmes-clés qui gèrent la majeure partie de la production.)

Personnellement, je serais plus d'avis de garder un cœur COBOL et un interfaçage en Python, ce qui permettrait de profiter des performances de COBOL, et comme tu le soulignes, la souplesse du Python. (Et sa modernité, car faire communiquer du COBOL avec des -nouvelles- technologies web est parfois complexe)

Citation Envoyé par Artemus24 Voir le message
Je veux bien, mais tout réécrire couterait encore plus cher. Un des aspects que l'on maitrise le moins est justement la maintenance, que ce soit aujourd'hui, ou dans dix ans. Qui dit que le python sera encore d'actualité ? Et par quoi va-t-on le remplacer ? On va se retrouver avec un système totalement hétérogène ou plus personne n'osera mettre son nez dedans de peur de tout casser.
Pour les 5 ans qui viennent, nous avons encore la chance d'avoir les anciens druides COBOL pour guider la migration. Après ça, c'est un saut de l'ange sur les questions que tu viens d'aborder.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 02/05/2025 à 19:22
Il ne faut pas croire qu'il y a un consensus au niveau des entreprises pour le choix des langages. Chacun fait comme il lui plait, d'où une hétérogénéité en France dans une même corps de métier (bancaire, assurance).

Comme je l'ai dit, l'avantage du COBOL repose sur le "COMP-3" que l'on nomme le format "packed decimal" où l'on utilise la représentation DCB (décimal codé binaire). Je ne suis plus très au courant de ce qui se fait dans les langages d'aujourd'hui. Ce n'est plus trop mon centre d'intérêt. Mais avons encore nous ce type de format dans Python ? La précision doit être absolue dans le domaine bancaire, et non faire des arrondis.

Citation Envoyé par Prox_13
Il faut remplacer tout code COBOL par du Python, par principe de facilité de maintenance. (Y compris les programmes-clés qui gèrent la majeure partie de la production.)
Remplacer le COBOL, cela se comprend aisément puisqu'il y a de moins en moins de compétences en ce domaine sur le marché du travail. Ce langage n'est plus enseigné à l'école. Donc, comment résoudre ce problème ? La solution la plus basique est de migrer vers un nouveau langage qui répond aux attentes de coûts de la maintenance. Oui, mais, où trouver la compétence du corps de métier du client ? Cela ne va pas se faire aussi facilement qu'on veut le croire. Il y a surtout le problème de la sécurité, qui est cruciale, mais aussi celui des performances. Je me rappelle que faire tourner sur des mini ordinateurs prenait pour valider une journée, un peu plus de 24 heures. C'était à l'époque dans une phase de mise au point, et les performances n'étaient pas du tout au rendez-vous. C'était il y a un peu plus de vingt-cinq ans.

Il ne faut pas s'engouffrer dans un langage parce qu'on le connait et qu'il existe partout de la compétence. En premier lieu, je trouve idiot d'utiliser un langage interprété au lieu d'un langage compilé. Ensuite, y-a-t-il un quelconque format "packed decimal" dans le langage choisit ? Quelles sont les performances et surtout quelle machine va-t-on faire les traitements de production ? Et la sécurité dans tout ça ?

Je ne parle ici que du cœur du métier, pas de ce qui est à la périphérie, ce qui complexifie le système d'information. On peut aussi se demander si les gros systèmes comme IBM sont encore fait pour ce type de traitement.

Je ne suis plus trop dans le coup, et je ne sais pas ce qui se fait de mieux en ce domaine.
2  0 
Avatar de Guesset
Expert confirmé https://www.developpez.com
Le 02/05/2025 à 22:52
Bonjour,

Les langages interprétés sont très biens pour développer rapidement la glue des appels de fonctions de bibliothèques écrites dans un langage compilé (en général C ou C++). Les utiliser intégralement pour des projets de grandes tailles n'est pas très pertinent car ils sont aussi peu performants qu'ils sont faciles à mettre en œuvre. Ce n'est pas un problème intrinsèque au langage mais au type d'outil qui le transforme en exécutable.

Jadis on utilisait le DCB non pas pour la seule précision mais parce que les processeurs savaient les traiter en natif et que les valeurs restaient lisibles humainement ce qui n'est pas le cas des codes binaires.
Aujourd'hui on utiliserait des types à virgules fixes qui sont en fait des entiers sur lesquels on plaque une virgule à une position donnée. Ce n'est pas lisible humainement mais ce n'est plus un problème. Et la taille est plus économique que le DCB qui utilise 4 bits par décades donc 36 bits pour 1 milliard contre 30 bits en binaire. De plus les temps de calcul sont très rapides ce qui ne serait pas le cas s'il fallait émuler le DCB.

Salutations
2  0 
Avatar de Heaven_4u
Futur Membre du Club https://www.developpez.com
Le 07/05/2025 à 12:10
Est-ce que nous avons la mémoire courte?

On a juste à penser au travail énorme de réécriture de code fait pour le fameux bug de l'an 2000.

Je fairais un cours de refresher dans cette techno main frame et Cobol pour finir ma carriere comme consultant Cobol. Ca serait payant j'en suis sur
1  0