Le phénomène n’est pas nouveau, mais il semble toujours faire des ravages: des utilisateurs de github – une plateforme utilisée notamment pour partager du code logiciel – y publient malencontreusement des données confidentielles (mots de passe, clés d’authentification) en partageant leurs développements. Et certaines de ces données sont particulièrement recherchées, notamment les clés d’authentification sur les plateformes de services telles Amazon EC2 (ou Microsoft Azure).
Amazon EC2 est un service (proposé par Amazon Web Services – ce qui nous rappelle qu’Amazon n’est pas qu’une société de commerce électronique) qui permet notamment de disposer très rapidement de multiples instances de serveurs notamment pour disposer d’une puissance de calcul flexible au moment où l’utilisateur en a besoin.
Le dernier exemple en date – qui a été publié par sa victime pour aider à sensibiliser contre ce risque – s’est déroulé de cette façon:
- Pendant les vacances de Noël, la victime a voulu tester Ruby on Rails, une plateforme de développement d’applications pour le Web, en l’occurrence pour essayer de développer rapidement un site sur le même modèle que Yelp (un réseau social de recommandation de restaurants et autres commerces) – et il utilise pour ses tests différents services d’informatique en nuage auxquels il semble habitué ;
- Il se sert notamment de heroku pour stocker son application (elle est en ligne ici d’ailleurs), mais a besoin d’espace pour stocker ses images, il rajoute donc dans sa configuration un espace de stockage sur un compte Amazon à l’essai (en l’occurrence la branche Amazon S3) ;
- En même temps, il pousse son code sur son compte github, mais se rend compte très rapidement que les clés de l’API d’Amazon, qui servent à identifier de façon unique son compte auprès de leurs services, ont aussi été poussées sur les serveurs de github. Il procède à un nettoyage rapide, s’estimant protégé par le fait qu’il n’avait pas spécialement diffusé l’adresse de son dépôt github pour cette application… (normalement ces fichiers de configuration auraient dû se trouver listés dans le fichier .gitignore pour empêcher une telle bévue)
- Au réveil le lendemain matin, 4 courriers électroniques d’Amazon l’attendent sur sa boîte mail et un appel en absence. Au bilan, ce sont près de 2400$ qui ont été dépensés à son insu !
Il semblerait en effet que des individus fassent tourner des routines qui cherchent automatiquement et en permanence les mots de passe et clés d’API Amazon ou autres informations confidentielles. Github dispose en effet d’un moteur de recherche qui facilite ce type de découvertes (article d’ITNews qui expliquant ceci au mois de mars 2014). Ces ressources sont ensuite apparemment utilisées pour miner des crypto-monnaies (des Litecoin ou des YaCoin apparemment, d’autant plus profitables si on ne paie pas les ressources utilisées pour les calculs cryptographiques, mais les plus chevronnés chercheront sûrement les crypto-monnaies les plus rentables du moment).
Notre victime de Noël 2014 n’est pas la seule à avoir rendu publique sa mésaventure (on note qu’Amazon est conscient du problème et rembourse les victimes qui se font avoir une première fois) :
- en janvier 2013, la sonnette d’alarme était déjà tirée suite à l’ouverture des fonctions de recherche avancée sur Github
- $3500 en décembre 2013
- Securosis témoigne de $500 perdus en trois jours en janvier 2014
- $8000 en avril 2014
- $6000 dépensés en une nuit en septembre 2014, avec plus de 600 instances de serveur Amazon lancés par les délinquants (dans ce cas, les données confidentielles étaient stockées dans une copie du fichier de configuration, qui avait donc un nom différent du fichier habituel et n’était pas correctement listé dans le .gitignore)
Amazon donne ici des conseils utiles pour se protéger et des bonnes pratiques ici. Et de façon générale, si vous êtes un développeur et souhaitez faire profiter les autres de vos développements (sur Github ou d’autres plateformes de partage), faites attention à ne pas publier de données confidentielles dans ces espaces de partage (par exemple, regroupez toute la configuration dans un seul fichier que vous ferez systématiquement attention de ne pas partager et avant de partager, faites une recherche dans votre code). Si vous avez d’autres conseils ou d’autres ressources, n’hésitez pas à les partager en commentaires.
Le fait que deux ans après l’alerte sur ce type de risque ait été lancée, on ait toujours autant de cas montre qu’il faut faire circuler l’information, donc n’hésitez pas à partager l’article !
Petit complément: en mai 2014, un autre événement intéressant a été signalé: des données confidentielles de NBC ont été accidentellement partagées avec un autre utilisateur de Github parce que son pseudonyme ressemblait certainement à celui de la personne normalement concernée. Cela peut vous arriver dans n’importe quelle plateforme de partage (par exemple sur le Drive de Google ou Office.com de Microsoft).