Des pirates arrivent à infecter des PC via Word sans utiliser des macros, Réactions à la publication du 13/11/2017

[Lionel]

Pendant des années, les macros de Microsoft Office ont été un moyen courant utilisé par des pirates pour infecter des ordinateurs. Il suffisait d'envoyer un fichier contenant ces macros par e-mail et de laisser l'utilisateur le lancer.
Depuis, les avertissements avant l'exécution d'une macro sont clairs et sur PC, les logiciels antivirus scrutent ces fichiers pour y détecter du code malveillant.

Des pirates (ce serait le même groupe qui aurait infiltré le parti démocrate américain pendant les dernières élections présidentielles) ont toutefois réussi à infecter à distance des PC sans utiliser de macro. Ils ont pour cela utilisé une fonction d'Office appelée Dynamic Data Exchange. Cette fonction DDE permet de mettre à jour un fichier de manière croisée avec un autre. On sait depuis longtemps que cela pose de potentiels problèmes de sécurité, maintenant c'est fait.

Les pirates envoient par e-mail un fichier qui passe les contrôles de sécurité, mais ensuite propose de se mettre jour à partir d'un autre fichier.
C'est ce second fichier, laissé sur un serveur distant, qui contient le code malveillant et l'exécute SI ET SEULEMENT SI, l'utilisateur accepte de le faire en acceptant de valider deux alertes.

Dans ce cas, un code distant va s'exécuter et permettre l'accès à la machine.

Certes, une fois encore on se retrouve dans un cas où l'utilisateur est en partie fautif de ce qui lui arrive, mais cela fonctionnera sans problème sur les personnes peu impliquées dans la sécurité informatique et qui font une confiance aveugle aux logiciels destinés à les protéger.

Lien vers le billet original

[Ze Clubbeur]

Certes, une fois encore on se retrouve dans un cas où l'utilisateur est en partie fautif de ce qui lui arrive, mais cela fonctionnera sans problème sur les personnes peu impliquées dans la sécurité informatique et qui font une confiance aveugle aux logiciels destinés à les protéger.

Lien vers le billet original

Je ne connais pas trop les macros ni les documents croisés, mais dans le cas où le fichier est distant, cela implique d'ouvrir une connexion en utilisant une ip et un port non ?
Si le SI est correctement conçu, le pare-feu devrait rejeter ce genre de requête non ?

Ce message a été modifié par Ze Clubbeur - 13 Nov 2017, 00:11.

[zero]

J'imagine que c'est le même port qui est utilisé. De toute façon, il y a très très peu de personnes qui configurent le firewall pour bloquer toutes les requêtes entrantes et le firewall par défaut ne peut pas bloquer les requêtes sortantes.

Ce message a été modifié par zero - 13 Nov 2017, 00:55.

[castor74]

C'est triste et même désolant de constater que c'est encore l'utilisateur que l'on considère comme fautif, du moins en partie... En gros, c'est comme si des petits malins mettaient des clous sur certaines routes pour crever les pneus et qu'on dise ensuite «c'est un peu la faute du conducteur, il a pris la mauvaise route...».

[BdeHOGUES]

C'est connu : Les Macros... ça puent !

[malhomme]

J'imagine que c'est le même port qui est utilisé. De toute façon, il y a très très peu de personnes qui configurent le firewall pour bloquer toutes les requêtes entrantes et le firewall par défaut ne peut pas bloquer les requêtes sortantes.

Dans une entreprise, de toute façon ce n'est pas du ressort de l'utilisateur.
Là où je travaille, les fichiers mis à jours à plusieurs dans des espace collaboratifs sont nécessaires (et légion). Et possiblement un risque.

[marc_os]

Certes, une fois encore on se retrouve dans un cas où l'utilisateur est en partie fautif de ce qui lui arrive, mais cela fonctionnera sans problème sur les personnes peu impliquées dans la sécurité informatique et qui font une confiance aveugle aux logiciels destinés à les protéger.

Lien vers le billet original

Je ne connais pas trop les macros ni les documents croisés, mais dans le cas où le fichier est distant, cela implique d'ouvrir une connexion en utilisant une ip et un port non ?
Si le SI est correctement conçu, le pare-feu devrait rejeter ce genre de requête non ?

Le lien se fait via la "vielle" techno DDE qui permet de lier des documents.
Ça permet par exemple d'insérer un document Excel dans un document Word.
Si Excel est ouvert, alors Word pourra demander à Excel d'actualiser le cas échéant les données Excel qu'il "embarque".
Et le lien vers le fichier externe peut être une URL, qui peut être bloquée, par exemple en bloquant le serveur via son fichier host.

Notez que ça "marche" aussi avec Word pour Mac. Pour l'instant ça craint pas pour nous, car dans le cas qui nous intéresse, ça tente in fine d'exécuter des trucs compilés pour Windows...

C'est connu : Les Macros... ça puent !

Le truc justement c'est que ça ne passe pas par des macros !
Un document Word sans macro associée peut donc être désormais "infecté" lui aussi.
Désormais, plus aucun document Word ne peut être considéré comme fiable.

Ce message a été modifié par marc_os - 13 Nov 2017, 12:59.

[iAPX]

C'est connu : Les Macros... ça puent !

Le truc justement c'est que ça ne passe pas par des macros !
Un document Word sans macro associée peut donc être désormais "infecté" lui aussi.
Désormais, plus aucun document Word ne peut être considéré comme fiable.

+1 oui.

Mais fondamentalement c'est une erreur du contrôleur de clavier (celui basé sur du carbone, pas celui en silicium!)

[Ze Clubbeur]

Certes, une fois encore on se retrouve dans un cas où l'utilisateur est en partie fautif de ce qui lui arrive, mais cela fonctionnera sans problème sur les personnes peu impliquées dans la sécurité informatique et qui font une confiance aveugle aux logiciels destinés à les protéger.

Lien vers le billet original

Je ne connais pas trop les macros ni les documents croisés, mais dans le cas où le fichier est distant, cela implique d'ouvrir une connexion en utilisant une ip et un port non ?
Si le SI est correctement conçu, le pare-feu devrait rejeter ce genre de requête non ?

Le lien se fait via la "vielle" techno DDE qui permet de lier des documents.
Ça permet par exemple d'insérer un document Excel dans un document Word.
Si Excel est ouvert, alors Word pourra demander à Excel d'actualiser le cas échéant les données Excel qu'il "embarque".
Et le lien vers le fichier externe peut être une URL, qui peut être bloquée, par exemple en bloquant le serveur via son fichier host.

Oui, j'avais compris que c'était avec DDE. Mais cette techno est au minimum basée sur une ip (et un port) pour fonctionner, je pense. Dans mon souvenir, sur un réseau local, pour utiliser les documents croisés, il fallait utiliser le nom de la machine si on devait travailler sur des fichiers présents sur un réseau local (enfin, on naviguait vers le dossier partagé et on sélectionnait le fichier). Et qui dit nom de la machine dit IP et port (pour le protocole utilisé).

Je parlais de firewall dans le cas de machines dans un SI. Le pare-feu sur le routeur ou le proxy, si il est correctement configuré, devrait pouvoir bloquer ces requêtes si elles ne sont pas utiles. De fait, même si l'utilisateur clique sur le lien et que le port est bloqué, ça ne passera pas. Si le lien est une URL, comme tu le dis, ça peut être bloqué facilement en rejetant l'adresse.

Après, pour ce qui est des ordinateurs personnels, c'est quand même bien plus rare d'avoir à utiliser des documents croisés juste pour le plaisir.

[iAPX]

...
Je parlais de firewall dans le cas de machines dans un SI. Le pare-feu sur le routeur ou le proxy, si il est correctement configuré, devrait pouvoir bloquer ces requêtes si elles ne sont pas utiles. De fait, même si l'utilisateur clique sur le lien et que le port est bloqué, ça ne passera pas. Si le lien est une URL, comme tu le dis, ça peut être bloqué facilement en rejetant l'adresse.

Après, pour ce qui est des ordinateurs personnels, c'est quand même bien plus rare d'avoir à utiliser des documents croisés juste pour le plaisir.

Tu peux me donner une liste exhaustive des IP et noms d domaines à filtrer svp?

[malhomme]

Mais fondamentalement c'est une erreur du contrôleur de clavier (celui basé sur du carbone, pas celui en silicium!)

Outre que cette tarte à la crème finit par exaspérer, encore une fois, dans un espace collaboratif, je ne vois pas bien en quoi ce serait le cas.

Concrètement : qu'est-ce qui te permet de savoir si les 28 feuilles excel que tu consultes dans un powerpoint ne sont pas concernées ?
(si j'ai bien compris).

[Ze Clubbeur]

...
Je parlais de firewall dans le cas de machines dans un SI. Le pare-feu sur le routeur ou le proxy, si il est correctement configuré, devrait pouvoir bloquer ces requêtes si elles ne sont pas utiles. De fait, même si l'utilisateur clique sur le lien et que le port est bloqué, ça ne passera pas. Si le lien est une URL, comme tu le dis, ça peut être bloqué facilement en rejetant l'adresse.

Après, pour ce qui est des ordinateurs personnels, c'est quand même bien plus rare d'avoir à utiliser des documents croisés juste pour le plaisir.

Tu peux me donner une liste exhaustive des IP et noms d domaines à filtrer svp?

Tu n'es pas idiot, tu sais très bien qu'on peut mettre en place un filtrage efficace. Toi qui est censé être capable d'utiliser plusieurs serveurs pour crypter un trafic, mettre en place un filtrage extrêmement restrictif où seulement ce qui est nécessaire soit accessible est quand même loin d'être difficile à faire...

[Ze Clubbeur]

Mais fondamentalement c'est une erreur du contrôleur de clavier (celui basé sur du carbone, pas celui en silicium!)

Outre que cette tarte à la crème finit par exaspérer, encore une fois, dans un espace collaboratif, je ne vois pas bien en quoi ce serait le cas.

Concrètement : qu'est-ce qui te permet de savoir si les 28 feuilles excel que tu consultes dans un powerpoint ne sont pas concernées ?
(si j'ai bien compris).

Tout à fait. Dans "contrôleur", il y a "con" et bien souvent, ça résume très bien l'utilisateur de base qui est devant son clavier, dont on aura beau lui dire de faire attention à ce qu'il télécharge, à ses pièces jointes et autres mises à jours flash, n'aura de cesse de faire la gaffe qui plantera au mieux seulement son ordi.
Dans un SI, on ne peut pas demander à l'utilisateur lambda de faire le boulot du responsable de la sécurité info. C'est au système d'information à s'adapter et prendre en compte la totalité des problèmes de sécurité qu'il pourrait rencontrer (même si, comme chacun sait, à moins de débrancher le câble réseau...).
Le responsable du SI doit :
- Mettre en place les moyens nécessaires pour sécuriser au maximum son système informatique.
- Mettre en place toute la documentation nécessaire à la sensibilisation aux risques informatiques (formations, plaquettes...).
- Doit avertir sa hiérarchie des risques encourus si les corrections ne sont pas effectuées et prendre les mesures nécessaires pour se prémunir en cas d'attaque car, si la société subit des préjudices, c'est lui qui trinquera.
Ce sont les règles de base (pour ne pas dire les seules) que doit suivre le DSI en matière de sécurité informatique.

[Guest_dtb06_*]

DDE existait dans Office 95, je crois même dans Word6/Excel5. Ca servait à faire communiquer les différents logiciels d'Office entre eux. Après c'est sûr que s'il reste des fragments de code pour communiquer avec IE, ça risque de poser problème au vu de la maintenance de IE.

[iAPX]

...
Je parlais de firewall dans le cas de machines dans un SI. Le pare-feu sur le routeur ou le proxy, si il est correctement configuré, devrait pouvoir bloquer ces requêtes si elles ne sont pas utiles. De fait, même si l'utilisateur clique sur le lien et que le port est bloqué, ça ne passera pas. Si le lien est une URL, comme tu le dis, ça peut être bloqué facilement en rejetant l'adresse.

Après, pour ce qui est des ordinateurs personnels, c'est quand même bien plus rare d'avoir à utiliser des documents croisés juste pour le plaisir.

Tu peux me donner une liste exhaustive des IP et noms d domaines à filtrer svp?

Tu n'es pas idiot, tu sais très bien qu'on peut mettre en place un filtrage efficace. Toi qui est censé être capable d'utiliser plusieurs serveurs pour crypter un trafic, mettre en place un filtrage extrêmement restrictif où seulement ce qui est nécessaire soit accessible est quand même loin d'être difficile à faire...

Ben justement, je sais que c'est totalement impossible en pratique, surtout avec la joyeuse habitude qu'ont des hackers de prendre position sur des sites connus et reconnus pour y mettre leur malware.

Dernier cas ce mois-ci avec la découverte qu'on pouvait stocker ce qu'on voulait sur le site web de la FCC aux USA, via le système de commentaire avec upload de fichier, et réaliser un lien vers celui-ci.
Va prévoir, à l'avance, de filtrer un site gouvernemental, qui plus est en https avec un certificat en béton?

Il est totalement impossible de filtrer efficacement. Oublie l'idée!

PS: ils ont encore des problèmes de sécurité, pour moi, car ils n'ont visiblement pas de pro pour les aider: on ne signe pas servicedev.fcc.gov avec le même certificat, ça veut dire que les certificats se baladent partout et qu'en cas d'erreur humaine, de bug ou d'attaque sur leur "servicedev", c'est exploitable plus facilement.
La bonne procédure consiste, pour une organisation de cette taille à avoir son propre certificat racine, à l'intégrer dans les posts clients, et à générer ses propres certificats pour les sites "internes", mais à ne surtout pas mettre le certificat du site public partout.

Ils ont d'autres failles, inacceptable à ce niveau de jeu, c'est presque une invitation, et j'ai juste utilisé Chrome sans aucune extension...

En bonus ça simplifie le travail des hackers d'avoir la liste des sites à essayer dans le certificat

Ce message a été modifié par iAPX - 14 Nov 2017, 19:44.