Depuis trois semaines, une partie de la France est en télétravail. Si certains sont déjà habitués, pour d’autres, le télétravail forcé a dû être improvisé avec les moyens du bord. Beaucoup de commentateurs nous alertent sur la sécurité du système d’information en situation de télétravail. Nous allons ici en discuter quelques aspects, liés à la maîtrise de la surface exposée.

 

La maîtrise de la menace exposée, de quoi s’agit-il ?
Pour permettre aux salariés distants, clients, fournisseurs, de se connecter au SI de l’entreprise, il est nécessaire de « publier » des services sur internet. Tout comme un site web est visible de la planète entière, des services, bien que de nature différente du web, peuvent être publiés sur internet. Certains sont spécifiquement en rapport avec le télétravail : le bureau à distance, le partage de fichiers Windows.

Et il se trouve que chez Adista, nous avons pu constater une augmentation du nombre de ces services exposés, dont certains peuvent poser problème.

 

Des services plus ou moins présentables
En effet, tous les « services » ne sont pas faits pour être publiés sur l’« internet sauvage ». Selon les cas d’usage pris en compte à la conception, le niveau de robustesse du logiciel est plus ou moins abouti.

Le bureau à distance Windows, par exemple, le fameux « protocole RDP », a encore été l’objet de multiples vulnérabilités « 0-day » à l’été dernier. Ce qui signifie qu’un pirate, découvrant un tel service disponible sur internet, peut tenter de le compromettre pour s’introduire dans le système.

Le service de partage de fichier de Windows, le « protocole SMB », est connu pour avoir donné les vulnérabilités 0-day les plus médiatiques. La dernière en date est toute récente d’ailleurs.

Ces services ne doivent pas être considérés comme suffisamment robustes pour être exposés directement à Internet. Evidemment, ce n’est pas l’éditeur qui vous le dira franchement. Mais pourtant, c’est une réalité à prendre en compte, et parfois à défendre devant les décideurs.

Il arrive même que ces vulnérabilités touchent des équipements, dits « de sécurité », qui sont justement eux-mêmes conçus pour faire la passerelle avec l’internet. Là encore, pas besoin d’aller chercher bien loin dans le passé. C’est gênant, pour se prémunir de cela, il faut appliquer les principes de la défense en profondeur (mais c’est un autre sujet…).

Des interfaces d’administration du SI, comme le FTP pour mettre à jour le site web, ou un SSH, qu’elles soient vulnérables ou pas, ne devraient pas non plus être exposées à tout internet. C’est le principe de minimisation. En effet, à partir du moment où les mises à jour du site web ne se font que depuis les bureaux de l’entreprise, ou de son prestataire web, pourquoi dévoiler l’existence même du système d’administration à 4 milliards d’adresses IP* ?

 

La continuité de la sécurité en situation perturbée : le pragmatisme
Du coup, comment concilier les besoins d’ouverture du SI, parfois en urgence, et la limitation de la prise de risque ?

La très grande majorité des entreprises disposent évidemment d’un firewall ou pare-feu, qui permet de filtrer les flux autorisés aux moyens de règles simplement définies par des adresses IP source, destination, et type de service. Pourquoi ne pas autoriser les services nouvellement exposés uniquement aux adresses IP des collaborateurs chez eux ? Oui, si ces adresses IP peuvent être identifiées, c’est déjà une très bonne mesure. Mais si l’adresse IP change ? Il est alors possible d’ouvrir les larges blocs d’adresses IP du fournisseur d’accès (en consultant par exemple la base du RIPE). C’est moins précis bien sûr, mais il n’empêche qu’on ouvre ainsi à une petite fraction de l’internet seulement, et la prise de risque s’en trouve atténuée. Oui, cela peut être pénible à gérer s’il y a beaucoup de collaborateurs. Si le pare-feu le permet, pourquoi ne pas présenter le service uniquement aux adresses IP françaises ? C’est encore moins précis, mais c’est mieux que d’ouvrir à tout internet.

Parfois, souvent, les pare-feux ont une fonctionnalité de « règle authentifiée », qui permet de n’autoriser un flux que si le poste accédant a d’abord pris le soin de se signaler, en général sur un petit portail web. Déployer une telle fonctionnalité permet également d’atténuer le risque. Et même avec un compte générique commun à toute l’entreprise, dans l’urgence, ce sera toujours mieux que rien.

Si, en tant que responsable informatique, vous avez du mal à convaincre votre patron, montrez lui donc qu’il existe des sites spécialisés pour inventorier les services exposés. Normalement, voyant une capture d’écran listant les dernières personnes connectées au serveur RDP d’une entreprise imprudente, il devrait être convaincu…

La plupart des attaques font intervenir, à un moment ou à un autre, l’utilisation d’un mot de passe compromis. Imaginons une PME qui fait intervenir un prestataire spécialisé pour l’installation d’un fax connecté. Celui-ci s’aperçoit, le jour de l’installation, qu’il a besoin d’un compte dans l’annuaire Active Directory. Le besoin n’ayant pas été anticipé, le DAF faisant fonction d’informaticien prête une console au prestataire, qui créé lui-même le compte « fax », mot de passe « fax », et stipule bien au DAF qu’il faudra changer le mot de passe conformément à la politique de sécurité de l’entreprise, mais plus tard. Car sur le clavier du fax, style texto, un bon mot de passe serait bien plus long à saisir…

Vient ensuite la crise sanitaire que nous connaissons, qui oblige à activer en vitesse le bureau à distance sur le serveur de fichiers, et à le publier sur internet. Voilà, le décor est planté pour une attaque réussie ! Le pirate pensera-t-il à essayer le login « fax » ? Bien sûr que oui.

Oui, dans cette situation exceptionnelle, c’est peut-être le moment de se souvenir de ces « comptes de service » aux mots de passe pas toujours très robustes. S’il n’y a pas d’interférences gênantes entre les modalités techniques du télétravail d’une part, et de changement de mot de passe utilisateur d’autre part, alors c’est peut-être même le moment d’imposer des règles de complexité, longueur, renouvellement aux utilisateurs.

Et dans le cas particulier de la crise actuelle, il est essentiel également de bien sensibiliser tous les collaborateurs à l’avalanche de messages malveillants en rapport avec le COVID. Si on vous propose un traitement efficace sur internet alors que vous n’avez rien demandé, c’est une tentative d’attaque. Et oui, nos utilisateurs ne sont pas exposés via des adresses IP, mais ils sont cependant exposés, et même très bien exposés. Donc il est important de bien stimuler leurs défenses pendant cette crise.

 

Le télétravail sécurisé : oui, mais comment ?
Pendant la crise, ce n’est pas le moment de définir l’architecture du SI ni de mettre en place les outils de télétravail et de sécurité. C’est pourquoi il est essentiel de se préparer à l’avance. Quel retour d’expérience avoir après cette crise, pour préparer la prochaine ?

-Connaitre la surface exposée et utiliser des passerelles de sécurité. Par exemple, plutôt que d’exposer un RDP directement sur internet, utiliser une « passerelle RDS ». Ce qui n’est pas du tout évident à l’heure ou le cloud public érode les pare-feux qui délimitent les réseaux « intérieurs » de l’internet « extérieur ».

-Maintenir à jour ses logiciels, pour éviter les vulnérabilités « 0-day ». Sur tout le système d’information bien sûr, mais plus encore sur les systèmes publiés en externe, et sur les postes utilisateurs (qui sont eux exposés aux utilisateurs, justement).

-Si possible, déployer des mécanismes d’authentification à deux facteurs. Ce n’est pas toujours évident, car ces mécanismes sont encore très dépendant des éditeurs et fabricants (au contraire du vieux mot de passe qui est universel). Et là encore, selon le positionnement « on premise » (dans les locaux de l’entreprise) ou « dans le cloud » d’un système, le déploiement sera différent.

-Déployer un contrôle de sécurité du poste accédant. Que se passe-t-il si du jour au lendemain, on envoie les salariés en télétravail avec l’ordinateur familial ? Ce poste est peut-être déjà membre d’un « botnet », ou déjà espionné par un « RAT » ou un « keylogger ». Et donc il pourrait ouvrir une brèche vers le SI de l’entreprise. Des solutions logicielles existent, qui permettent de s’assurer que le poste est à jour, son antivirus également, et autres bonnes pratiques de sécurités.

-La surveillance des événements anormaux est également une mesure de sécurité généraliste qui permet de détecter des attaques, venant de l’intérieur ou de l’extérieur. Mais déployer tout un système de « gestion des évènements et informations de sécurité » (SIEM) est un projet très engageant, à la fois pour le planning, le budget et les ressources humaines. Il faudra donc souvent se limiter à inspecter les journaux de la passerelle d’accès distant.

Un petit renforcement un peu technique, mais cependant assez simple, atténuant un large spectre d’attaques : pour éviter que les problèmes ne rentrent, bloquer les connexions qui sortent. Pourquoi ? Dans une attaque qui tirerait parti d’une vulnérabilité logicielle sur un service exposé à Internet, l’attaquant injecte du « code », du programme, en utilisant une faiblesse créée par une erreur de programmation. Par exemple, le programmeur peut avoir oublié de rejeter des patronymes utilisant des caractères binaires non affichables. Le malveillant va donc pouvoir exécuter un bout de programme, mais dans la très grande majorité des cas, ce programme doit être très court. Si par exemple, le programmeur a pensé à limiter la longueur de la case « nom » à 80 caractères, le programmeur malveillant va devoir être concis.  Et donc en général, ce bout de programme injecté, qu’on nomme un « shellcode », va lui-même servir à télécharger, à l’extérieur, le vrai code d’un malware, plus grand. Le shellcode ne sert que de lanceur, et il a besoin d’une connexion sortante. Si on applique la règle qui veut qu’un serveur n’ai pas accès à internet (en dehors des destinations strictement nécessaire à son travail), la connexion sortante initiée par le shellcode sera bloquée. Le malveillant ne recevra jamais la réponse du bout de code injecté, et l’attaque est contrée. Même si le service est touché par une vulnérabilité 0-day, on est protégé. C’est déjà de la défense en profondeur. Donc à retenir : contrôler les connexions sortantes, et pour les serveurs, les limiter vraiment au strict nécessaire.

 

Pour conclure, même si l’accès distant au système d’information ne conçoit pas en un jour, il est important de mettre en place des mesures d’atténuation proportionnées et de bien connaître les points noirs, pour déterminer quelles concessions sont acceptables ou pas dans le contexte d’urgence. Ces mesures permettent de limiter la probabilité d’une intrusion, mais ne peuvent pas constituer une politique de sécurité.

Il faudra être particulièrement vigilant après la sortie de crise COVID-19, car nous pouvons malheureusement craindre que des pirates auront profité de ces faiblesses pour prendre position dans des SI, discrètement, et déclencheront des attaques décalées, d’ici quelques mois. A cette étape, le sujet ne sera plus celui de la sécurité du télétravail, mais bien celui de la sécurité globale du SI.

 

*4 milliards est environ la quantité d’adresses IP sur internet.