Bonjour,
Petit journal pour alerter ceux éventuellement concernés, suite à un sujet sur le blog officiel de Linux Mint : leur Wordpress a été la cible de plusieurs attaques à partir du 20 février (il est hors-ligne à l'heure où je publie), et le lien vers l'Iso de Linux Mint 17.3 Cinnamon a été changé, pointant sur un site tiers délivrant une version modifiée de celle-ci avec backdoor.
Source : http://blog.linuxmint.com/?p=2994
Apparemment, c'est la seule version concernée : les autres éditions, les downloads antérieurs ou via torrent ne sont pas compromis.
Pour vérifier, si vous estimez être dans cette situation, les signatures valides sont :
6e7f7e03500747c6c3bfece2c9c8394f linuxmint-17.3-cinnamon-32bit.iso
e71a2aad8b58605e906dbea444dc4983 linuxmint-17.3-cinnamon-64bit.iso
30fef1aa1134c5f3778c77c4417f7238 linuxmint-17.3-cinnamon-nocodecs-32bit.iso
3406350a87c201cdca0927b1bc7c2ccd linuxmint-17.3-cinnamon-nocodecs-64bit.iso
df38af96e99726bb0a1ef3e5cd47563d linuxmint-17.3-cinnamon-oem-64bit.iso
Autre façon de savoir si vous avez installé l'Iso infectée, lancer une session Live sans Internet, si un fichier dans "/var/lib/man.cy" est présent, il faut sauvegarder les données et immédiatement tout réinstaller…
L'Iso modifiée était hébergée sur 5 . 104 . 175 . 212 et la porte dérobée tentait une connexion vers absentvodka . com (Bulgarie).
L'équipe de Linux Mint - qui a eu la transparence de prévenir publiquement dès le problème connu - indique que des investigations sont menées afin d'en savoir plus et surtout, des travaux pour sécuriser leur site et garantir l'intégrité des futurs téléchargements.
# MD5
Posté par claudex . Évalué à 5.
Il faut peut-être éviter de donner des hash en MD5 pot une ISO si a été corrompue mais passer sur un algo sûr comme SHA256.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MD5
Posté par fcartegnie . Évalué à 5. Dernière modification le 21 février 2016 à 15:25.
(supprimé, en fait on disait la même chose)
Par contre, pas de SHA256. Faut signer le contenu, pas fournir un hash.
[^] # Re: MD5
Posté par claudex . Évalué à 4.
On peut faire les deux. Vérifier un hash, c'est plus facile et ça permet déjà de voir que si ça pose problème là, pas la peine de se fatiguer pour vérifier la signature. Le problème de la signature, c'est qu'il faut récupérer la clef publique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MD5
Posté par fcartegnie . Évalué à 9.
Le hash n'apporte strictement rien dans le cas présent, parce que sur le même serveur.
Si l'iso est compromis le hash le sera aussi, si les hackeurs ont un peu de jugeotte.
Certains proposent de servir les hash en SSL et cela montre qu'ils n'ont rien compris.
[^] # Re: MD5
Posté par claudex . Évalué à 10.
C'est le même raisonnement avec une clef publique si publiée sur le même serveur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: MD5
Posté par Harry . Évalué à 2.
La clé utilisée par le projet Linux Mint pour signer les hashs des ISO (sha256sum.txt.gpg) est celle du développeur principal. Il est malheureux de constater que c'est une clé DSA 1024 (que le NIST considère actuellement comme non-sûre).
[^] # Re: MD5
Posté par X345 . Évalué à 6.
Oui, enfin, apparemment, gcc se paye aussi le luxe de signer ses releases avec des clés de DSA 1024 bits.
# [:roflol]
Posté par sirrus . Évalué à -10.
ah elle est belle l'image du logiciel libre
ça n'arriverait pas avec microsoft ou apple
[^] # Re: [:roflol]
Posté par Ytterbium . Évalué à 5.
Ah bon ? Il n'y avait pas une version de Xcode vérolée quie se promenait dans la nature en Chine ? Et qui injectait des malwares dans les binaires compilés ?
[^] # Re: [:roflol]
Posté par groumly . Évalué à 7.
Sisi, mais elle etait pas fournie par apple, et dispo uniquement en chine.
Les debits en chines sont tellement pourris que certains dev allaient chercher xcode sur des sites douteux mais chinois, donc bien plus rapide que sur le store apple.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: [:roflol]
Posté par GG (site web personnel) . Évalué à 4.
Non, ce n'est pas vraiment ça.
Les débits en Chine sont très mauvais dès qu'il s'agit de sortir de Chine (ou d'entrer).
Mais il n'y a pas que ça. Les DNS mentent. Avoir son propre résolveur limite une partie des dégats.
Enfin, sans VPN, les mises à jour des dépôts vont vous renvoyer vers une flopée de sites chinois et russes, dont les signatures des clefs ne correspondent pas. Et ce n'est pas qu'un problème de DNS.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: [:roflol]
Posté par Maclag . Évalué à 10.
Effectivement ce qui est beau avec le logiciel libre, ou ici Mint, pour être précis, c'est qu'ils sont transparents et corrigent au plus vite.
Avec Apple ou MS tu as peut-être les backdoors par défaut et peu de chance de le savoir.
[^] # Re: [:roflol]
Posté par groumly . Évalué à -7.
Vu le bordel que le fbi fait a apple en ce moment, non seulement t'es a peu pres sur qu'il n'ya pas de backdoors, mais en plus tu le saura s'ils en ajoutent une, vu que ca passe au tribunal.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: [:roflol]
Posté par Nairwolf . Évalué à 5.
Ah, parce que tu crois qu'ils vont l'annoncer à tout le monde s'ils doivent mettre réellement une backdoor ? Dans quel but, faire effondrer leur part de marché ?
[^] # Re: [:roflol]
Posté par groumly . Évalué à -2.
le juge l'annoncera pour eux, et vu comment l'affaire est mediatisee, tous les journaux du monde se feront un plaisir de relayer l'info.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: [:roflol]
Posté par Nairwolf . Évalué à 5.
J'ai du mal à y croire étant donné que l'affaire PRISM a déjà été largement relayé médiatiquement, mais que peu de monde ont bougé. En fait, c'est bien le problème principal avec des logiciels non open-source, il est difficile de savoir ce qui est vrai et ce qui est faux.
[^] # Re: [:roflol]
Posté par groumly . Évalué à -3.
T'as du mal a croire que l'affaire est jugee publiquement devant un tribunal federal?
Ben je sais pas quoi te dire alors.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: [:roflol]
Posté par MTux . Évalué à 4.
Clem a joué la transparence a fond et sans langue de bois.
Un piratage ça peut arriver à n'importe qui, maintenant l'important c'est de voir comment on gère la crise.
En plus ce n'est pas Mint qui a failli, c'est Wordpress.
# Précisions
Posté par Xavier G. . Évalué à 8.
D'après ce post, le trojan injecté dans l'Iso modifiée serait "tsunami", dont l'une des fonctions est de faire rejoindre un botnet, et pourrait servir à récupérer des données ou mots de passe.
La base du forum LM aurait également été piratée et circulerait sur le darknet. Des serveurs miroirs auraient également diffusé la mauvaise Iso.
Après effectivement, MD5 + Wordpress non patché, pour les mainteneurs d'une distro se voulant diffusée auprès du plus grand nombre, ça fait mal…
[^] # Re: Précisions
Posté par patrick_g (site web personnel) . Évalué à 7.
Ce qui fait surtout mal c'est l'amateurisme absolu des gens derrière Linux Mint :
http://blog.linuxmint.com/?p=2994#comment-124881
https://lwn.net/Articles/676662/
Ils n'ont pas isolé la machine après la première attaque ? Ils se font trouer une seconde fois sur la même machine ?
[^] # Re: Précisions
Posté par FredBezies (site web personnel) . Évalué à 1.
Ça donne une mauvaise image de la distribution en effet. Mais est-ce que cela aura un impact sur le plus long terme ? À voir.
Un libriste qui en a sa claque des puristes.
[^] # Re: Précisions
Posté par Jiel (site web personnel) . Évalué à 4.
Tu as raison, mais après probablement, c'est un projet bénévole, donc avec du temps de contribution limité, peut-être que les experts sécurité de la troupe sont débordés/en vacances/injoignables etc. Loi de Murphy oblige, ce genre d'attaque arrive toujours au plus mauvais moment.
[^] # Re: Précisions
Posté par patrick_g (site web personnel) . Évalué à 6.
Qui a reçu plus de 16 000 dollars de dons rien que pour le mois de décembre 2015 : http://blog.linuxmint.com/?p=2985
Ils viennent d'annoncer que le forum a également été complètement troué. Ils demandent à tous leurs utilisateurs de changer leur passwords d'urgence : http://blog.linuxmint.com/?p=3001
[^] # Re: Précisions
Posté par Liorel . Évalué à 2.
Oui enfin, bénévole ou pas, quand on fait une distro qui se veut accessible par des utilisateurs incompétents (c'est quand même le but des ubuntu-like), on bétonne derrière, parce que si on se fait trouer, il y aura 0 filet de sécurité.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Précisions
Posté par xcomcmdr . Évalué à 3.
Voilà bien pourquoi je préfère l'original (Ubuntu) à la copie (Linux Mint)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Précisions
Posté par GnunuX (site web personnel) . Évalué à 2.
Ouais enfin sans parler d'isolement, ils pourraient mettre des droits unix corrects.
www-data ne devrait pas pouvoir modifier des ISOs.
[^] # Re: Précisions
Posté par Brunus . Évalué à 4.
D'après ce qui est indiqué dans les commentaires (liens postés par Patrick_g)
C'est la page contenant les liens vers les .iso qui a été édité. Et non les .iso stockés sur les serveurs.
L'iso qui a été vérolé a été créé, et était hébergé, en dehors du site Linux Mint.
Le lien legit de la page de download a été dirigé par l'IP externe qui héberge l'iso vérolé.
Enfin c'est ce que j'ai compris.
Pour la méthode de pénétration :
Le truc classique: on exploite une faille du CMS qui permet d'uploader un shell script, soit on le pose direct avec l'extension .php soit on le déguise en .gif pour qu'il passe le filtre puis on le renomme pour l'utiliser.
Généralement soit on peut tout faire grâce à une faille dans un truc genre éditeur HTML WYSIWYG intégré au CMS, soit on passe par une faille dans l'ACL pour obtenir les privilèges nécessaires à partir d'un compte user classique.
Quand on utilise ce genre d'application, patchée ou non, monitorer l'arborescence du site pour y détecter tout mouvements de fichier .php est une bonne idée…y'a plein de libs et de scripts pour ça.
Un de mes scripts peut être réglé pour détruire tout nouveau fichier .php créé dans l'arbo en dehors de répertoires qu'on veut exclure (genre cache).
Ok il faut penser à le désactiver si on souhaite faire une mise à jour ou installer une extension, mais on y pense facilement après avoir fait la connerie d'oublier une première fois.
[^] # Re: Précisions
Posté par GnunuX (site web personnel) . Évalué à 1.
Ok, ce n'est peut être pas les ISO, mais cela ne change rien. www-data ne devrait pas pouvoir éditer/uploader des fichiers php (en tout cas dans un répertoire non prévu a cet effet).
[^] # Re: Précisions
Posté par Brunus . Évalué à 2.
Oui on peut sans doute être plus safe et interdir à www-data l'écriture dans des répertoires sensibles, on se casse le système interne de mise à jour mais c'est pas grave car on peut faire les mises à jour sur un local isolé puis les pousser sur le prod' niveau système sans utiliser les fonctions du backoffice.
Ce qui laisse, généralement, le répertoire du cache dans lequel on a besoin d'écrire du PHP.
Par contre l'édition de pages ça se fait en générale dans la base et c'est du HTML, ça ne passe pas par la corruption ou l'upload d'un fichier PHP. Et là ça peut se faire en exploitant une faille dans l'ACL du CMS.
J'ai vu des failles, dans des templates de CMS, qui permettaient de voir le contenu de n'importe quel fichier du système, y compris en dehors de l'arbo du site ciblé…y compris dans /etc par exemple, et ça sans déposer de PHP.
Si il y a, comme dans certains CMS (Joomla, Magento…Wordpress je sais pas), un password de user de la database en clair dans un fichier, le récupérer suffit à aller modifier tout ce qu'on veut dans la base.
En tous cas ils se sont fait troué parce que leur truc n'était pas patché à priori.
Donc là il y a eu faute c'est clair.
Mais, des failles de sécu inconnues et pour lesquelles il n'y a pas de patch à un moment donné (0day) ça existe aussi.
Mieux vaut en tous cas sortir l'artillerie lourde pour couvrir au maximum tous les classiques modes d'attaque au niveau du site et du système : Nginx + Naxsi WAF (ou une extension dédiée au CMS) pour empêcher l'injection, et en mode parano ajouter à ça le monitoring de l'arbo du site.
Ceinture + bretelles + parachute et gilet de sauvetage…le seul truc impossible à éliminer c'est la connerie humaine et en tapant ces lignes, j'ai conscience d'en faire aussi des conneries, d'être parfois feignant, etc…
[^] # Re: Précisions
Posté par Misc (site web personnel) . Évalué à 5.
Ouais, enfin on parle de Mint. Ils ont pas vraiment de listes pour annoncer les mises à jour de sécurité, n'ont pas d'email pour envoyer les failles et réagissent pas sur ce qu'on leur rapportent.
La sécurité de Linuxmint dépend uniquement du travail fait par Ubuntu/debian, et donc les paquets fait maison sont pas géré.
Exemple (et au risque de ressembler à un disque rayé):
https://bugs.launchpad.net/linuxmint/+bug/1008501
Bientöt 3 ans que personne regarde vraiment ce CVE. Je reconnais que c'est mineur, mais la correction est pas non plus compliqué.
Donc ouais, ça m'étonne pas non plus que leur wordpress se soit fait pourrir. L'upstream d'owncloud pointe d'ailleurs:
https://statuscode.ch/2016/02/distribution-packages-considered-insecure/
[^] # Re:Précisions
Posté par Juke (site web personnel) . Évalué à 3.
le quoi ?
[^] # Re:Précisions
Posté par vv222 (site web personnel) . Évalué à 1.
Le darknet, le jumeau maléfique et gothique d’Internet :
# Le hash doit être régulièrement vérifié !
Posté par Space_e_man (site web personnel) . Évalué à 5.
Concernant la publication du hash (md5 en l'occurrence) à côté du téléchargement d'un iso.
Cela permet de vérifier que le téléchargement s'est bien déroulé.
Cela permet également de vérifier que le support live à correctement été écrit (typiquement via dd)
J'écarte "bien évidemment" le défi qui consisterait à modifier l'image iso de sorte à obtenir, malgré la modification malveillante insérée, le même hash et ± la même taille de fichier. Il n'est pas question de ce genre de prouesse ici. Même si c'est théoriquement possible, ce n'est pas du tout simple à faire. Car l'image devrait toujours être fonctionnel et la modification passer inaperçue.
Donc, je continue à penser que le hash (ici MD5) à côté du fichier à télécharger reste une bonne solution, mais doit être régulièrement vérifié. Cela peut-être automatisé ou fait de manière collective.
[^] # Re: Le hash doit être régulièrement vérifié !
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
La commande ne vérifie pas d'éventuels octets rajoutés à la fin du cdrom. Il reste quand même possible d'ajouter des choses et de ne pas être alerté par la commande.
[^] # Re: Le hash doit être régulièrement vérifié !
Posté par Space_e_man (site web personnel) . Évalué à 2.
Sauf que cette commande est sensé suivre la commande du genre
Donc $(stat -c "%s" gnulinux-live-image.iso) est bien le nombre d'octets écrits, non ?
Le support numérique, clé usb, est généralement plus grand, donc si tu souhaites être sûr des octets qui se trouvent ensuite, il faudra remplir de zero par exemple avec dd.
[^] # Re: Le hash doit être régulièrement vérifié !
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
En effet, mais alors pourquoi ne pas juste faire le md5sum sur /dev/sdc ? Voire même une comparaison octet par octet (cmp) ?
[^] # Re: Le hash doit être régulièrement vérifié !
Posté par Space_e_man (site web personnel) . Évalué à 2.
md5sum sur /dev/sdc considérera l'ensemble des octets disponibles sur le support. Imaginons qu'il s'agisse d'une clé USB de 4 Go sur laquelle nous aurions placé l'image iso de 1,2 Go, alors md5sum sur dev/sdc calculera la somme MD5 des 4 Go.
Je connais mais n'ai pas encore utilisé la commande cmp. Il y aurait a priori le même soucis et nous utiliserions probablement l'option -n, --bytes=LIMIT
md5sum utilisera moins d' io mais plus de cpu
cmp plus d' io et moins de cpu
Théoriquement, cmp sera plus fiable dans la mesure ou serait écarté de malheureuse coïncidences dont la très faible probabilité est connue (concernant les collisions MD5).
Par contre, je préfère md5sum pour en revenir toujours à cette même somme que je connais pour devoir correspondre (écartant la prouesse malveillante ou une mauvaise source d'information).
[^] # Re: Le hash doit être régulièrement vérifié !
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
Effectivement, vu comme ça je comprend. Merci pour l'explication ^
# man.cy
Posté par Bisaloo . Évalué à 4.
https://gist.github.com/Oweoqi/31239851e5b84dbba894
Le code du fichier douteux man.cy
# Forum
Posté par NumOpen . Évalué à 4.
Une partie de la liste des comptes piratés sur le forum a été ajoutée sur https://haveibeenpwned.com.
Si votre adresse de courriel y est, changez tous les identifiants/mots de passe identiques utilisés ailleurs.
[^] # Re: Forum
Posté par zurvan . Évalué à 2.
merci. Mon adresse est dedans… ainsi que sur un pastebin de décembre 2015. Est-ce lié au même compte du forum de linuxmint ? Peut-être pas. Dommage que pastebin ait effacé ce fichier, on aurait pu en savoir plus…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Forum
Posté par Piervit . Évalué à 0.
Je ne sais pas si ma remarque est pertinente mais pourquoi ferais je confiance à un site comme https://haveibeenpwned.com/? Il consiste à faire entrer son adresse email aux utilisateurs, quel garantie ai je qu'il ne les stocke pas et ne les revend pas?
Il montre qu'il est capable de stocker les mots de passes de millions d'utilisateurs victimes de failles sur les dernires années.Le site dit fonctionner en utilisant https://twitter.com/dumpmon, un robot qui récupere les patterns semblant contenir des adresses emails sur des pad publics temporaire.
Rigoureusement, c'est limite de conserver des emails d'utilisateurs qui ont mis peut leur email en clair par erreur sur un pad et qui se sont fait scanné.
En vrai, c'est parce que vous estimez que c'est quelqu'un qui est suffisamment connu et respecté dans le milieu des chapeaux blancs?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.