Sans être un paranoïaque de la sécurité, je fais plutôt partie des gens qui
entretiennent un hygiène informatique sérieuse. Et c'est bienvenu car c'est
quand même mon métier.
En plus de 20 ans de pratique quotidienne je n'ai jamais découvert de
compromission sur mes machines. Ça ne veut pas dire que je n'ai jamais fait de
bourde : un mot de passe tapé « par réflexe » mais dans la mauvaise fenêtre, une
petite fuite d'info dans des moteurs de recherches, etc.
Ceci étant, comme on le verra, ça n'empêche pas d'accumuler certaines mauvaises
pratiques, en partie parce que la façon « moderne » de faire l'impose pour être
efficace au quotidien.
Mais la compromission de sa station de travail, routinière pour les usagers de
Windows, a un caractère exceptionnel pour un utilisateur de GNU/Linux de longue
date comme moi. Et comme on va le voir, ça ressemble aussi à une mise à nu.
Note: Je partage mon expérience y compris dans le but d'améliorer ma réaction.
N'hésitez pas à me contacter si je donne l'impression de passer à coté d'un gros
truc.
Si ya un doute, ya pas de doute
Au détour d'un travail sur un projet de
l'April je vois un subliminal mais
inquiétant:
[1]+ Fini /home/francois/April/drupal2spip_lal/venv/bin/python3 /home/francois/.uds/_err.log > /dev/null 2>&1 (wd : ~)
(maintenant, wd : ~/April/spamotron)
J'ouvre ce fichier et très vite le doute s'installe :
import base64,lzma;exec(lzma.decompress(base64.b85decode("{Wp48S^xk9=GL@E0stWa761SMbT8$j;4$nE7F_@lh
[...]
Je remplace le exec par un print et j'obtiens un source python assez bien
écrit (surtout après le passage de
black), qui ressemble à un service de
télécommande.
Un ps fauxww me montre que le script s'exécute encore dans un shell. Par
curiosité je regarde la liste des fichiers ouverts. Celle-ci se limite quasiment
au minimum vital pour un script python. Mais une connexion est ouverte :
$ lsof -p 3755
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
[...]
python3 3755 francois 4u IPv4 7991113 0t0 TCP renard:38026->199.247.5.158.vultr.com:3500 (ESTABLISHED)
Bon, ok. Il apparait via le ~/.bashrc. Je le nettoie et vérifie qu'il ne
revient pas. J'en profite pour vérifier mes crontab et files at.
Il ne revient pas.
Pas de panique
« sur sa couverture on peut lire en larges lettres amicales la mention : PAS
DE PANIQUE »
— Douglas Adams, The Hitchhiker's Guide to the Galaxy
Ok. Pas de panique. Pas d'urgence, on respire un coup et un prend un café.
Première chose : rapidement cerner l'origine dans le temps de la chose. En
fouillant les backups je déduis le 3 août comme première valeur.
Deuxième chose : en parcourant le code je comprends que c'est un botnet. Le code
ne comprend rien d'autre qu'une télécommande, mais le maitre du botnet a pu
avoir accès à toute ma machine.
Troisième chose : convaincu que le bot a eu potentiellement accès à tous mes
fichiers perso, je commence sans tarder à demander la révocation de mes accès :
- à mes collègues de travail ;
- à mes collègues associatifs.
Je fais retirer mes accès à pas moins de quatre parcs de machines complètement
disjoints, chacun contenant des dizaines de serveurs, de kvm et de conteneurs.
Mes machines perso attendront, elles ne sont plus à ça près.
Comprendre
Le chemin de l'exécutable python désigne clairement un venv pour un projet que
j'ai mené pour l'April en juillet/août. Je recherche sans succès les traces
de l'origine du trojan.
J'examine le code à la recherche d'éléments spécifiques à chercher dans Google.
Rien d'évident. Je recherche « pip .uds _err.log ». Je tombe sur une page dans
un dialecte asiatique datée du 6 aout :
https://guanjia.qq.com/news/n1/2583.html
Je la fait traduire par Google. Malgré le résultat très approximatif de la
traduction, ça raconte assez bien la chose. Je remarque les mêmes serveurs
impliqués, je retrouve certains des extraits de code montrés.
Leur explication ? Une opération de phishing impliquant PyPI au 31 juillet et
ciblant le paquet request.
Request. Là mon cerveau fait tilt.
Mais putain quel con !
La semaine dernière j'ai finalisé drupal2spip_lal et testé sa mise en prod sur
une Debian nue. J'ai été amené à corriger des
dépendances,
notamment requests. Comme un con pendant le dev j'avais fait une fôte
(écrivant
request)
et c'était passé inaperçu. Je ne l'avais remarqué qu'au déploiement à cause
d'une erreur de pip.
En fait ce qui s'était passé est qu'un développeur attentionné et conscient que
parfois les gens se trompent a publié un paquet nommé request dont le principe
est le suivant :
import sys,requests
#Some people might mistake this module for the popular python requests module
#So let's add an alias of that
sys.modules[__name__] = sys.modules['requests']
C'est gentil, inoffensif mais peu productif : je fais partie de ceux qui
préfèrent avoir des erreurs et les corriger très tôt plutôt que des bricolages
d'adaptation.
Par contre ce qui n'est pas du tout inoffensif a été le script d'installation.
Je n'ai pas la copie sous la main mais visiblement il s'est chargé a minima de
modifier mon ~/.bashrc et d'installer la première charge dans
~/.uds/_err.log.
Tout ça pour une bête typo suivie d'un make update dans un contexte de
pratiques discutables.
Résultat
Ma station de travail -- c'est-à-dire la machine avec laquelle je passe plus de
temps qu'avec n'importe qui d'autre sur terre -- est compromise. J'ai hébergé un
trojan à mon insu pendant 22 jours. C'est un cataclysme assez élevé sur
l'échelle des drames.
Il n'y a pas à mégoter sur l'étendue de la situation : j'ai offert un shell
python à un inconnu qui en avait envie. Il a eu accès à potentiellement tout sur
ma machine. Il va falloir réinstaller et révoquer tout ce qui est possible.
Heureusement l'essentiel de mes secrets sont protégés :
- fichiers importants chiffrés GPG ;
- clés GPG et SSH toutes protégées par une passphrase ;
- trousseau de mot de passe Firefox protégé par une passphrase.
Mais tout n'est pas rose :
- des scans administratifs en clair ;
- les mots de passe courriels en presque clairs : mon
MUA sait gérer une passphrase dans les versions
modernes, mais j'avais raté l'info donc je ne l'ai mis en œuvre que ce jour ;
- j'utilise des agents SSH et GPG qui donnent un potentiel accès total sans
passer par mes passphrases. Idem pour l'accès root à ma machine. Je suppose
même possible d'exfiltrer la totale en examinant la carte mémoire des agents.
Bon, voilà pour la théorie. En pratique je ne suis même pas sûr qu'il y ait eu
fuite de données. Les seuls codes d'exfiltration que j'ai lu sont conçus
uniquement pour Windows et n'ont aucun effet sur ma machine (cf la charge « C2 »
présentée par guanjia.qq.com). Il est possible et probable que la machine n'ai
servi à rien d'autre que relais d'exécution à un botnet.
Le rôle de pip
J'ai parlé de mauvaises pratiques ou de pratiques discutables. J'en vois
essentiellement une : le recours excessif à pip à la place du gestionnaire de
paquet de l'OS. Pendant longtemps j'ai été réfractaire et râleur à ce sujet (et
là je fais une dédicace à mon ami Christian qui lui y est toujours
réfractaire...).
Mais depuis 6 ans que je fais du développement web et du « devops », pip est
devenu incontournable. Même des gens plutôt précautionneux m'ont poussé à en
faire. De plus, c'est quasiment impossible de faire du django (mon
environnement de prédilection) sans pip, tout comme c'est quasiment impossible
de faire du front sans npm (auquel je fais beaucoup beaucoup beaucoup moins
confiance que à pypi/pip).
Notons que dans ce cas précis ça n'a aucun intérêt précis d'installer
requests via pip : ce paquet est tellement populaire que disponible
partout dans une version convenable. C'est par un pédantisme mal placé que je
l'ai introduit (avec typo) dans mes requirements pour être exhaustif. En
l'occurence i) je n'en avais pas besoin en local car requests était déjà
présent sur ma machine et ii) ce projet ne sera jamais installé que par moi et
sur une seule machine. Mais en bout de chaîne ce paquet s'est installé par la
suite par un effet de bord attendu.
Le rôle de pypi
Les mainteneurs de pypi ont visiblement détecté le problème et supprimé le
paquet. C'est pour ça que j'ai vu l'erreur au déploiement. Ceci étant :
- Je n'ai trouvé nulle part de trace de ça. Il serait intéressant que les
mainteneurs de pypi aient un registre qui liste ce genre de menace.
- D'ailleurs ça m'étonne tellement que je suis sûr que ça existe mais je le n'ai
pas trouvé. Google non plus.
- Je n'ai pas été averti du problème alors qui a été connu des mainteneurs. On
pourrait imaginer que les mainteneurs, à la place de supprimer le paquet,
forgent un paquet « virtuel » en version ultime, qui lors d'un upgrade informe
la personne de la situation avec de gros messages en gras rouge.
Je vais dorénavant utiliser plus assidûment des outils comme
safety. Mais ce n'est pas évident que ça
m'aurait protégé d'une charge à l'installation comme celle qu'il y a eu là.
D'ailleurs il n'y a pas eu de CVE et ce problème est ignoré de safety.
Conclusion
Comme disait Frédéric, « ce
qui ne me tue pas me rend plus fort ». Mais comme répond echarp, « ou te laisse
blessé ! ».
Bien sûr on n'est jamais sûr de rien car j'ignore la nature de la charge
potentiellement téléchargée et exécutée pendant ces 22 jours.
Une fois passé la bourde, j'ai de bonnes raisons de penser qu'il n'y a pas à
paniquer. Mes secrets importants sont protégés par un secret qui n'est que dans
mon esprit. Dans la durée ça ne vaut rien mais dans l'instant ça protège.
Les backups c'est le bien. Ça m'a permis de remonter le temps et de comprendre
l'origine et la nature des soucis. Car bien évidemment l'état de mon dépôt git
ne conserve pas les détails historiques (je ré-écrit souvent l'historique). Idem
pour le venv qui est régulièrement changé (ça sert à ça).
Notons que sans Google je ne trouve ni analyse, ni traduction de l'analyse. Je
n'aime pas les GAFAMs et passe beaucoup
de temps à lutter contre eux, mais force est de
constater que Google rend des services encore difficiles à remplacer.
J'en vois une autre de mauvaise pratique : le recourt permanent aux agents. Je
n'utilise pas le transfert d'agent car en cas de compromission c'est un
cataclysme. Voir par exemple cette
analyse pour un cas
concret. En revanche j'utilise l'agent SSH et l'agent GPG fourni par Debian avec
la configuration fournie par Gnome. Ils sont raisonnablement utiles (peut on
vraiment faire de l'orchestration sans agent SSH ?) et raisonnablement limités,
mais puisque je les utilise quotidiennement, ils ont donc des fenêtres
d'ouverture pendant lesquelles je ne peux que supposer qu'ils exposent mes
accès.
Mieux limiter mon recours à pip et aux agents sera un réflexion à mener. A
minima un agent PGP ne me sert pas à grand-chose et devrait disparaître.
Notons également que j'ai tendance à ne pas restreindre ni tracer les accès
réseaux vers la sortie, mais en l'occurrence ça aurait pu m'aider à y voir clair
post mortem. Ceci étant, c'est une telle reponsabilité à maintenir correctement
que je pense ne pas commencer. Idem pour les systèmes types IDS (OSSEC, Wazuh,
Samhain) : les restrictions et les alertes me semblent exploitables sur des
systèmes stables de production, mais sur une station de travail dédiée au
développement mais une autre paire de manche à mettre en œuvre efficacement.
À défaut de mieux je vais m'employer à mieux ségréger mes développements (coucou
docker).
Notons que le chiffrement de mon disque dur n'est dans ce cas d'aucun secours.