Les RSSI ne considèrent pas les dev comme méchant, ils considère tout être humain, sauf eux, comme méchant et voulant contourner les règles :)
Sinon, ce n'est pas vraiment un problème de compétences lié au développement sécurité, c'est un problème lié à un outil qui peut faire un reverse shell sur ta machine. Le problème aurait été identique si l'outil en question était LibreOffice Calc, et la conclusion aurait été la même, mais sur une population différente.
Ici, tu as deux problématique :
- le développeur qui va utiliser l'option de VSCode, sans connaitre les impacts
- un attaquant qui va utiliser cette option (soit via ton VSCode, soit un VScode qu'il va télécharger) pour avoir ce reverse shell. Or VSCode étant un binaire signé, connu et donc globalement considéré comme "de confiance", la plupart des outils d'analyse ne le verront pas, ce qui en fait tout l'intérêt par rapport à une backdoor développée sur mesure.
Du coup, l'approche serait plutôt sensibiliser les utilisateurs sur l'impact de télécharger tout et n'importe quoi, de les sensibiliser également sur cette option.
Et pour Linux, l'approche AppLocker peut être remplacée par un SeLinux ou AppArmor correctement configuré pour t'assurer que le seul VSCode autorisé est celui préconisé par l'IT/ta distrib et qu'en plus tu lui interdit de faire du reverse shell
[^] # Re: Et le blocage pour Linux ?
Posté par Toto . En réponse au lien Blocking Visual Studio Code embedded reverse shell before it's too late. Évalué à 5. Dernière modification le 24 septembre 2023 à 12:07.
Les RSSI ne considèrent pas les dev comme méchant, ils considère tout être humain, sauf eux, comme méchant et voulant contourner les règles :)
Sinon, ce n'est pas vraiment un problème de compétences lié au développement sécurité, c'est un problème lié à un outil qui peut faire un reverse shell sur ta machine. Le problème aurait été identique si l'outil en question était LibreOffice Calc, et la conclusion aurait été la même, mais sur une population différente.
Ici, tu as deux problématique :
- le développeur qui va utiliser l'option de VSCode, sans connaitre les impacts
- un attaquant qui va utiliser cette option (soit via ton VSCode, soit un VScode qu'il va télécharger) pour avoir ce reverse shell. Or VSCode étant un binaire signé, connu et donc globalement considéré comme "de confiance", la plupart des outils d'analyse ne le verront pas, ce qui en fait tout l'intérêt par rapport à une backdoor développée sur mesure.
Du coup, l'approche serait plutôt sensibiliser les utilisateurs sur l'impact de télécharger tout et n'importe quoi, de les sensibiliser également sur cette option.
Et pour Linux, l'approche AppLocker peut être remplacée par un SeLinux ou AppArmor correctement configuré pour t'assurer que le seul VSCode autorisé est celui préconisé par l'IT/ta distrib et qu'en plus tu lui interdit de faire du reverse shell