Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 123 reacties
Submitter: luuj

Hackers blijken erin geslaagd te zijn om in te breken op de website van Linux Mint. Eenmaal binnen hebben zij via de website aangepaste iso-bestanden van de Linux-distro verspreid; hierin was een backdoor verstopt. De geÔnfecteerde iso betrof versie 17.3 Cinnamon van Linux Mint.

De beheerders van Linux Mint ontdekten de hack zelf en lichtten het publiek in via hun blog. Daarbij is de website van de Linux-distro offline gehaald. Hoe de hackers binnen zijn gekomen wordt niet vermeld, maar wel is duidelijk dat zij via de website besmette iso-bestanden hebben verspreid van Linux Mint versie 17.3 Cinnamon die op zaterdag kortstondig online stond. Volgens de beheerders van de distro was er een backdoor in verstopt, maar veel meer informatie werd er over de infectie niet gegeven.

Uit de verwijzingen blijkt dat de vermoedelijke daders waarschijnlijk uit Sofia komen en dat de backdoorsoftware die verstopt zit in de iso verbinding legt via absentvodka.com. Linux Mint vraagt gebruikers die recent software hebben gedownload om de md5-code van de iso te bepalen; op het blog is een lijst met valide codes gezet, zodat gebruikers kunnen bepalen of zij een geïnfecteerde versie hebben gedownload.

Naast het verspreiden van besmette iso-bestanden lijken de hackers ook de forumdatabase van Linux Mint in handen te hebben gekregen. Hoeveel gegevens er precies zijn gestolen is niet bekend, maar de database wordt al wel op het 'dark web' verhandeld.

Moderatie-faq Wijzig weergave

Reacties (123)

Wat extra info:
  • als je tijdens het draaien van dit OS een bestand genaamd ' /var/lib/man.cy' hebt dan ben je besmet
  • het gaat alleen om Linux Mint 17.3 Cinnamon edition.
  • het gaat alleen om downloads op 20 februari
  • het gaat alleen om gebruikers die de ISO via http gedownload hebbben van af de website van Mint zelf (andere links zijn wel ok).
Checksums:
  • 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
Het is heel ernstig dat dit gebeurd is. Mint is met name populair bij beginnende gebruikers die niet in staat zijn om met zo'n besmetting om te gaan. Beginners controleren typisch ook geen checksums.
Trouwens, vandaag de dag mag je wel iets beters gebruiken dan MD5, zeker in een situatie waarin de veiligheid serieus in het geding is.

Laat het een les zijn voor iedereen: wees extra voorzichtig als je een OS download, dat is het makkelijkste moment om je te besmetten. Download bij voorkeur van HTTPs-links, controleer de link en controleer de checksum.

Het enige goede nieuws in dit hele verhaal is dat de prijs van de gestolen database vrij laag is. Blijkbaar zit er weinig interessante informatie in.

Ergens is het wel opvallend dat het nu net Mint moet zijn die dit overkomt. De meeste Linux-distributies hameren nogal hard op beveiliging. Mint koos juist voor gebruikersvriendelijkheid en is daarom erg populair. Ik vrees dat hun ruime houding ze fataal is geworden.

update
Ik heb de md5-checksum van een besmette ISO gevonden: 7d590864618866c225ede058f1ba61f0
Waarschijnlijk is dat de checksum van de 64-bit ISO maar dat weet ik niet zeker. Hoe dan ook, als je bovenstaande md5-checksum krijgt dan ben je besmet.

[Reactie gewijzigd door CAPSLOCK2000 op 21 februari 2016 12:32]

Je verhaal over MD5 gaat in dit geval niet echt op. Het gaat niet zozeer om een versleuteling veiligheid, maar in dit geval wordt MD5 gebruikt als bestandsintegriteitsmiddel. Dat staat geheel los van de kwetsbaarheid van MD5 voor wachtwoordversleuteling tegenwoordig.
MD5 heeft niets te maken met versleuteling. Het is alleen maar een hash functie.

Daarnaast is MD5 zo kwetsbaar als wat. Een ISO maken met dezelfde hash waarde als de originele ISO kan tegenwoordig op iedere huis tuin en keuken computer.

Zie ook: http://www.mathstat.dal.ca/~selinger/md5collision/

[Reactie gewijzigd door keesdewit op 21 februari 2016 14:09]

Waarbij de inhoud ook nagenoeg hetzelfde is? Want daar gaat het om. Leuk dat je een bepaald bestand kan genereren met dezelfde hashwaarde, maar een bestand dat voor 99% overeenkomt, maar toch wat backdoors bevat? Die op dezelfde hashwaarde uitkomt. Veel succes daarmee!
MD5 is maar 128 bits lang (16 byte) dus je hoeft maar een regio in je ISO te hebben van zeg 1kB waarin je willekeurig bits kan varieren (bv een plaatje dat best corrupt mag zijn) en je kunt al veeeel meer dan 2128 variaties maken.
Is heel goed mogelijk. Zal hooguit een kilobyte afwijken qua grootte, meer niet.

Edit: Reactie van Jaaap is juist.

[Reactie gewijzigd door keesdewit op 21 februari 2016 17:06]

Die backdoor hoeft maar een simpele referentie naar een C&C server te hebben. De rest van de data zodanig manipuleren zodat de hash overeen komt en je bent binnen?
Je verhaal over MD5 gaat in dit geval niet echt op. Het gaat niet zozeer om een versleuteling veiligheid, maar in dit geval wordt MD5 gebruikt als bestandsintegriteitsmiddel. Dat staat geheel los van de kwetsbaarheid van MD5 voor wachtwoordversleuteling tegenwoordig.
Je hebt waarschijnlijk gelijk, in dit geval is MD5 zeer waarschijnlijk genoeg. Ik neem aan dat ze gecontroleerd hebben dat de MD5s van de aanvaller anders zijn dan de echte.

Maar in het algemeen durf ik dat niet meer te zeggen. Collission-attacks op MD5 zijn realistisch mogelijk. Voor een bescheiden prijs huur je een rekencluster die ze on-demand maakt.

Er is geen enkele goede reden om MD5 wel nog te blijven gebruiken. We hebben al jaren een opvolger. Sterker nog, zelfs de opvolger van MD5 (namelijk SHA1) is al op z'n retour. SHA256 is universeel beschikbaar, er is geen enkele reden om dat niet te gebruiken.
Wie er nu nog voor kiest* om minder te gebruiken neemt het in mijn ogen niet serieus.

* in legacy situaties ligt het anders, maar voor nieuwe toepassingen moet je minsten sha256 nemen.
Het probleem van de MD5 checksum (en welke andere checksum dan ook) is dat aanvallers die toegang hebben tot de website om er een verkeerde ISO op te zetten, waarschijnlijk ook makkelijk de checksum kunnen veranderen.
De oplossing is om de checksums te beveiligen met een digitale handtekening die via een ander kanaal dan de website is te controleren. De standaard hiervoor is PGP.

Kijk bijvoorbeeld hoe Debian het doet: https://www.debian.org/CD/verify
Debian maakt verschillende checksums van alles (MD5, SHA1, SHA256, SHA512) en ondertekent die vervolgens met een PGP-handtekening. Als je al Debian gebruikt dan heb je de bijhorende sleutel voorgeinstalleerd staan op je systeem. Als dat niet het geval is dan kun je het zogenaamde "Web of Trust" gebruiken om te controleren dat de gegeven PGP-sleutel echt bij Debian hoort.

Het gaat te ver om precies uit te leggen hoe het werkt, maar de belangrijkste is dat de benodigde digitale sleutels op verschillende plekken worden gepubliceerd en dat er verschillende manieren zijn om de echtheid er van te controleren.

Alles wat op een gehackte website staat is niet meer te vertrouwen. Daarom is het van belang om van te voren te zorgen voor een betrouwbare en onafhankelijke manier om de integriteit te controleren.
het probleem met pgp is alleen dat het zo ver.....de gebruiks-onvriendelijk is, en dat er ook niet echt een betrouwbare partij overheid of bank is die een keysharings-service draait, ik had gedacht en gehoopt (toen jaren terug de digi-id werdt aangekondigd) dat er iets van deze strekking zou komen, en dat men pgp daarin zou verwerken, zodat mijn digi bijv als een soort masterkey gebruikt kon worden, helaas is daar niets van terecht gekomen en heb ik derhalve niets aan pgp noch aan digid
Dat is niet het probleem, ISO van zowel http als p2p moet dezelfde zijn en de p2p die kan niet aangepast worden.

MD5 collision is best mogelijk, zeker als dat je target is, maar hier is het dus niet het geval.
Het is nog steeds een probleem want wie gaat er nu zijn http-versie nog vergeijken met een p2p versie. Diegene vergelijkt zijn http-versie ( van de besmette iso) met de bijbehorende hash (van die besmette iso) en denkt dat alles goed is terwijl dat niet het geval is. Geen reden om nog naar p2p-versies te gaan kijken en onderling hashes te gaan vergelijken.
Na dit bericht zal men eerder geneigd zijn dat te doen maar enkel degenen die wat meer IT-kennis hebben en ook van deze hack weten.
Laten nu veel nieuwe Mint gebruikers niet tot beide groepen behoren.
Mint gebruikers zijn niet per definitie newbies hoor.

De http versie en p2p hebben dezelfde hash, als de hash is veranderd zullen p2p gebruikers het snel opmerken, veranderd het niet dan zullen http gebruikers het verschil opmerken, zoals nu gebeurt is. Binnen de dag is de ISO eraf gehaald, dat is voor een open source project toch best snel.
Los van de MD5 of beter discussie: stel he je hebt een collision op een MD5 hash. Dat is niet leuk, maar in hoeverre is het waarschijnlijk dat dit een werkende ISO oplevert?
Collisions berekenen op basis van MD5 is doenbaar, maar niet triviaal, maar is dit dan nog een werkend systeem? Dat vraag ik me af. Een garbled manpage ofzo is niet zo erg, maar de kans is best aanwezig dat het relevante binaries (of gewone bestanden) zijn die stuk gaan. Dat kan (gelukkig) best opvallen.

Dat gezegd hebbende, sha256 heeft wel de voorkeur.
Dat is niet leuk, maar in hoeverre is het waarschijnlijk dat dit een werkende ISO oplevert?
Ik denk niet dat het al haalbaar is, maar ik zou m'n leven er niet aan toe vertrouwen. Het punt dat het wel haalbaar is lijkt in ieder geval in zicht. De techniek is al jaren goed genoeg om gericht SSL-certificaten te vervalsen en dit is daadwerkelijk in de praktijk gebruikt. SSL met MD5 is daarom echt niet meer acceptabel.

Er wordt een hoop over geschreven over aanvallen op MD5, ik quote even wat van Wikipedia:
https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities
MD5 uses the Merkle–DamgŚrd construction, so if two prefixes with the same hash can be constructed, a common suffix can be added to both to make the collision more likely to be accepted as valid data by the application using it. Furthermore, current collision-finding techniques allow to specify an arbitrary prefix: an attacker can create two colliding files that both begin with the same content. All the attacker needs to generate two colliding files is a template file with a 128-byte block of data, aligned on a 64-byte boundary that can be changed freely by the collision-finding algorithm.
<knip>
A new variant of parallelized collision searching using MPI was proposed by Anton Kuznetsov in 2014 which allowed to find a collision in 11 hours on a computing cluster.
Een ISO is geen bijzonder bestand, het is feitelijk niets meer/minder dan een sector-by-sector kopie van een optical disc als een CD of DVD. Lijkt me dus niet erg moeilijk om aanpassingen te doen aan een ISO zonder dat deze stuk gaat. Ik kan me zelfs voorstellen dat een ISO zelfs (deels) werkt wanneer je bijvoorbeeld maar de helft hebt. Wat ik me afvraag is of er ook loze ruimte zit op een ISO door niet volledig gebruikte sectoren. If so, dan kun je die ruimte misbruiken om je ISO aan te passen, en vervolgens niet te laten groeien in grootte.
Dat gaat echt over het wachtwoordsgebeuren. Iets met klok en klepel. Een collision op een ISO die voor 99,99% hetzelfde data bevat? Ik wens je daar heel veel succes mee :).
Dat gaat echt over het wachtwoordsgebeuren. Iets met klok en klepel. Een collision op een ISO die voor 99,99% hetzelfde data bevat? Ik wens je daar heel veel succes mee :).
Het begint wel heel dicht bij te komen hoor. Ik vertrouw niet meer op MD5 als het er echt toe doet. md5 is prima voor vertrouwde data maar niet als beveiliging een rol speelt.
Op dit moment is het nog te moeilijk maar we zitten akelig dichtbij en gaat in de komende jaren waarschijnlijk wel bereikt worden. Het zou me niet verbazen dat NSA-achtige clubs het al kunnen. Hoe dan ook, het komt dicht bij en MD5 moet vervangen worden. We kunnen wachten tot het te laat is en dan in paniek alle software patchen of we kunnen zorgen dat we het vervangen voor er een probleem ontstaat.
Collisions zijn inderdaad niet moeilijk te maken, maar dan heb je wel een bestand wat erg afwijkt van het origineel. En om het werkend te houden zal het veelal factoren groter zijn dan het origineel.

Of je moet er echt een 100% maatwerk iets van maken wat niet meer simpel een md5-collision maakt door garbage aan het einde toe te voegen, maar wat bijv de bestanden in de iso gaat herverplaatsen, maar dat is echt 100% maatwerk wat afaik nooit toegepast is buiten echt 100% getargete applicaties (en waar je in het publiek niets over hoort)

En je hoeft al die moeite helemaal niet te doen, want de meeste mensen (net zoals jij) gaan uit van de md5, maar die staat op dezelfde website als dat de hackers net gehackt hebben, oftewel die is ook zo aan te passen.
Ik vind het op zich wel een interesante discussie, ook al is het hier een beetje OT, maar zo'n discussie geeft al aan dat er een probleem is, er zijn situaties waarin je MD5 beter niet kan gebruiken. Dat is voor mij een rode vlag: gebruik het niet want het kŠn fout gaan.

Neem het voorbeeld van een gerichte aanval. Die zal je inderdaad niet via de gebruikelijke kanalen kunnen detecteren. Je zal het zelf waarschijnlijk nooit weten. Met MD5 is het misschien onwaarschijnlijk maar niet onrealistisch. Met SHA256 is het voorlopig wel nog onrealstisch.

Met sha256 hoef ik voorlopig nergens over na te denken, op sha256 durf ik blind te vertrouwen. Waarom het risico nemen dat je een verkeerde inschatting maakt en MD5 gebruikt waar dat niet kan? Het is nergens voor nodig. Het is algemeen beschikbaar en computers zijn snel genoeg voor vrijwel alle toepassingen.

Het is misschien geen ramp om nog MD5 te gebruiken maar het geeft het verkeerde signaal af.
Dat het mogelijk is om een alternatieve string van hooguit tientallen tekens te vinden voor een identieke md5-hash wil niet zeggen dat het ook mogelijk is deze truc toe te passen voor een paar honderd megabyte aan broncode.

MD5 gebruik je tegenwoordig niet meer als hash voor wachtwoorden, omdat het relatief makkelijk is om een string te vinden waarmee je dezelfde hash kunt genereren. MD5 is verder prima bruikbaar om te kijken of twee stukken gecompileerde broncode identiek zijn. Het is namelijk een behoorlijke kunst om een string van een paar honderd megabyte te vinden die dezelfde hash als uitkomst geeft ťn die ook nog eens vloeiend als besturingssysteem draait als je het in je pc stopt (en niet van het origineel te onderscheiden is).

Dat iets voor A niet geschikt is, wil niet zeggen dat het dan ook niet voor B geschikt is. Dat heeft dezelfde logica als: laten we maar geen papier meer gebruiken om op te schrijven, want als je er een brug van bouwt kan het instorten.
Waarom zou je MD5 gebruiken als je ook SHA256 kan gebruiken?
We weten dat MD5 aan het afbrokkelen is, het is een kwestie van tijd voor het echt mis gaat.

Voor mij klinkt het als asbest: "Ach, zolang je er maar niet in zaagt is er niet zo veel aan de hand". Dat is misschien een reden om het niet uit bestaande huizen te halen maar het mag geen argument zijn om nog nieuwe huizen te bouwen met asbest, ook als je niet van bent om er in te gaan zagen.
Er is geen reden om nu MD5 te gebruiken, echter, als het er al is is er ook geen reden om het aan te passen, want SHA256 voegt in dit geval niets toe. Immers, met MD5 is de kans op vervalsing nog steeds 0.

[edit2]Met je voorbeeld met asbest kun je twee kanten op:

1) Het is inderdaad misschien niet zo zinvol om asbest te verwijderen als het al in een huis zit (net als een systeem aanpassen als je al MD5 gebruikt in deze functie). Voor een nieuw systeem zou ik ook geen MD5 meer gebruiken, net als dat je geen asbest gebruikt in een nieuw huis.

2) Daarnaast, bij asbest is er wel degelijk een vergroting van risico (ook als het al in je huis zit, bv. vrijkomen bij brand of instorting). Dat kan een reden zijn om je huis alsnog aan te passen. Dit geldt voor MD5 in deze specifieke functie van broncodes checken niet.

[Reactie gewijzigd door Het_Eendje op 21 februari 2016 14:41]

Hoezo kans 0? Er is toch bewezen dat dit niet 0 is?
Totale onzin. Binnen een paar minuten kun je op iedere huis en tuin computer een ISO bestand maken die dezelfde hashwaarde geeft. Dat gaat je met sha2 niet lukken.
Maar in dit geval is al bekend dat de gehackte versie een andere MD5 hash heeft, dus controle geeft in elk geval uitsluitsel dat het niet die specifieke gehackte versie is. Dat je misschien ook een gehackte versie kan maken met een MD5 hash die wel klopt kan misschien zijn maar dat zou een andere hack zijn dan waar het hier over gaat.

Overigens moet een gehackte ISO niet alleen de juiste MD5 hash houden maar ook nog volledig functioneel blijven. En dat is best lastig want al die pakketten op de ISO hebben weer hun eigen CRC. Dus je moet je hack invoegen, dan de ISO manipuleren zodat het dezelfde hash heeft zonder de overige bestanden zelf zo te beschadigen dat ze dezelfde CRC houden en ook nog correct werken.

Maar zoals gezegd is de MD5 hash van de gehackte ISO's anders en is een MD5 check genoeg om vast te stellen of je die ISO hebt of niet. Ik denk dat zelfs een CRC32 genoeg zou zijn voor dat doel.
Ik vind het op zich wel een interesante discussie, ook al is het hier een beetje OT, maar zo'n discussie geeft al aan dat er een probleem is, er zijn situaties waarin je MD5 beter niet kan gebruiken. Dat is voor mij een rode vlag: gebruik het niet want het kŠn fout gaan.
Er zijn gewoon situaties waarbij je beter geen hashes kan gebruiken, de gebruikte hash-methode is dan irrelevant.

SHA4096 is in deze situatie niet beter of slechter dan MD5, want het probleem zit hem buiten de hashing, namelijk in de methode waarop de hash getoond die niet los staat van het downloaden.

De specifieke collision flaw bij MD5 is supersimpel op te lossen(voor dit geval), zet er een filesize naast. Er is afaik nog geen collision op significant grote bestanden gevonden die niet de filesize aanpaste.

Alleen dat is allemaal irrelevant als de hackers ook de hash op de website kunnen aanpassen, dan kan jij blindelings geloven in een SHA256 en die kan 100% overeenkomen met die op de website, maar het zegt alleen maar dat die gelijk zijn, niet dat het het juiste bestand is. Want de website was gehacked.
Er zijn gewoon situaties waarbij je beter geen hashes kan gebruiken, de gebruikte hash-methode is dan irrelevant.
<knip>
Alleen dat is allemaal irrelevant als de hackers ook de hash op de website kunnen aanpassen, dan kan jij blindelings geloven in een SHA256 en die kan 100% overeenkomen met die op de website, maar het zegt alleen maar dat die gelijk zijn, niet dat het het juiste bestand is. Want de website was gehacked.
Dat is helemaal waar, ik ben bang dat ik mijn punt een beetje te ver heb opgeblazen. Ik wil niet beweren dat MD5 hier schade heeft gedaan, mijn opmerking was in het algemeen bedoeld. SHA256 is in vrijwel alle gevallen de betere keuze en er is geen reden om nog bij MD5 te blijven. Er zijn volgens mij geen gevallen waarin SHA256 een slechte keuze is en MD5 een goede. Gebruik dus maar gewoon SHA256.

Ik maakte die opmerking wel ook om te laten zien dat ik niet zo'n hoge pet op heb van de security van Mint. Alleen MD5 geeft mij niet het gevoel dat hier een team achter zit dat veiligheid heel serieus neemt.
Nagenoeg elke website heeft hun downloads nog in MD5-checksum, dat heeft niks met veiligheid te maken. Bij andere hashingmethodieken is ook de mogelijkheid op dezelfde hash niet uitgesloten. SHA256 ook niet. Alleen ga je nagenoeg nooit een exact hetzelfde werkend product, met iets gewijzigd of er bij in gestopt (in dit geval de backdoor) krijgen en dan toch dezelfde hash. Dus die collisions zijn voor dit geval echt een papieren onveiligheid.
Hoezo een papieren onveiligheid? MD5-collissions zijn tegenwoordig zeer gemakkelijk te creŽren: met behulp van de juiste tools en een gehuurde Amazon-cluster kun je voor zo'n 50 cent in ongeveer een dag tijd een botsing produceren. Zie http://natmchugh.blogspot...r-own-md5-collisions.html

Het feit dat het om een bestand van een paar GB gaat maakt niet uit: de lengte van de string die je wilt vervalsen is namelijk irrelevant: wat wel belangrijk is is dat je aan het einde van het bestand een arbitraire bitstring van een constante lengte kunt toevoegen, die gevarieerd blijft worden totdat het in combinatie met de prefix (die je zelf kan kiezen, zo lang mag zijn als je wilt, en maar ťťn keer gehasht hoeft te worden) de gewenste hash oplevert.

Je kunt gemakkelijk een geldige ISO-image maken waarbij de waarde van de laatste bytes niet uit maakt: een image van een ISO 9660-bestandssysteem eindigt bijvoorbeeld met een " Volume Descriptor Set Terminator", die eindigt met zo'n 2MB aan arbitraire data.

De hackers in kwestie hadden in principe dus best een vervalste ISO kunnen creŽren met dezelfde MD5 hash; dat was echter niet de moeite waard geweest: gezien ze de website hadden gecompromitteerd hadden ze waarschijnlijk ook de hashes (die op dezelfde site stonden) kunnen aanpassen.
Waarom veel groter? MD5 is maar 128bit, met iedere 128bit zou je, lijkt mij, iedere MD5 moeten kunnen genereren. ISO's lijken mij te groot om te beveiligen middels MD5. Een bestandje van een paar kb's ja, maar een bestand van meerdere GB's??
Volgens mij kan een simpel laptoppie tegenwoordig md5 al kraken

Maar het punt hier is dat het doel hier niet is je wachtwoorden te versleutelen.
Het verhaal over MD5 gaat wel degelijk op. MD5 als bestandintegriteitscontrolemiddel (scrabbel?) is niet meer veilig, en het is aan te tonen dat je [twee verschillende executables](http://www.mathstat.dal.ca/~selinger/md5collision/) kan maken die dezelfde hash opleveren. Daarnaast staat het gebruik als bestandintegriteitscontrolemiddel en wachtwoordhashing (niet versleuteling) zeker niet los van elkaar. Als het algoritme gebroken is, is het in beide gevallen niet meer bruikbaar.
Trouwens, vandaag de dag mag je wel iets beters gebruiken dan MD5, zeker in een situatie waarin de veiligheid serieus in het geding is.
Ik behoor ook tot de noobs waar jij het over hebt (overweeg Linux). Dus als je iets beters kun gebruiken voor de checksum-check, dan is het handig die concreet vermelden }:O
SHA256 is momenteel de standaard maar iemand zal de checksums moeten uitrekenen voor je ze kan controleren. Als jij de ISO nog hebt dan zou je jouw checksum hier kunnen publiceren zodat andere kunnen controleren of ze dezelfde checksum hebben.

Dat doe je met het 'sha256sum' commando:
$ sha256sum /tmp/linuxmint-17.3-cinnamon-64bit.iso
854d0cfaa9139a898c2a22aa505b919ddde34f93b04a831b3f030ffe4e25a8e3 /tmp/linuxmint-17.3-cinnamon-64bit.iso
Even voor de duidelijkheid voor de echte noobs, dit is het commando:
sha256sum /tmp/linuxmint-17.3-cinnamon-64bit.iso
De $ ervoor is een symbool van de command line, en de tekst na het commando is het resultaat van het commando.

[Reactie gewijzigd door Crazy Harry op 21 februari 2016 12:39]

Wat voor zin heeft het om een MD5 hash nog te controleren als de besmette versies dezelfde MD5 hash levert die op de gecompromitteerde website staat? (ik ga er even vanuit dat dit ook met de website van Mint is gebeurd, anders neem ik mijn woorden terug).
Wat voor zin heeft het om een MD5 hash nog te controleren als de besmette versies dezelfde MD5 hash levert die op de gecompromitteerde website staat? (ik ga er even vanuit dat dit ook met de website van Mint is gebeurd, anders neem ik mijn woorden terug).
Daarom is het verstandig om de ISO te downloaden van een andere locatie dan waar je de checksums opzoekt. Maar zelfs als je dat niet doet dan kan het nog helpen tegen ongelukjes tijdens het downloaden (opzettelijk of niet).
Als de checksum van de besmette versie dezelfde is als de officiŽle versie dan hang je alsnog. En ja, dat is gewoon mogelijk.
Gisteren dus toevallig even geprobeerd... Maar ik zie dus dat ik de 17.2 ISO had. Maar wat kun je doen met die "backdoor", aangepaste grub laten installeren die een keyboard logger laad ofzo?

Wat is het potentiŽle gevaar?

7-zip kan ook SHA-256 checksums genereren via context-menu (of in het programma zelf), mocht je de ISO hebben en in Windows zitten

[Reactie gewijzigd door SkyStreaker op 21 februari 2016 12:46]

Wat is het potentiŽle gevaar?
In potentie? Alles.

We weten het niet maar als het gedaait heeft kan het alles met je computer doen dat ieder ander virus kan: bestanden wissen, data lekken, cryptolocker, wachtwoorden jatten, naaktfoto's posten, de webcam afluisteren etc....
Wat niet in de oorspronkelijke aanval zit kan altijd nog via die backdoor worden binnengehaald.

Ik zeg niet dat al deze aanvallen ook gebeuren, we weten het gewoon nog niet, maar eigenlijk is het ook niet interessant omdat het op ieder moment kan veranderen als de aanvaller een nieuwe versie upload via de backdoor.

[Reactie gewijzigd door CAPSLOCK2000 op 21 februari 2016 14:02]

Download bij voorkeur van HTTPs-links, controleer de link en controleer de checksum.
Mmm maar AL deze dingen waren hier gecompromitteerd. Naar verluidt waren de checksums ook veranderd (en als de download file kan vervangen mag het aanpassen van een html textje ook geen probleem zijn).

Ik denk dat je vooral vertrouwen moet hebben helaas. Ik probeer altijd de files te downloaden een paar dagen voor ik ze nodig heb. In dit geval had dat me gered.
Mmm maar AL deze dingen waren hier gecompromitteerd. Naar verluidt waren de checksums ook veranderd (en als de download file kan vervangen mag het aanpassen van een html textje ook geen probleem zijn).

Ik denk dat je vooral vertrouwen moet hebben helaas. Ik probeer altijd de files te downloaden een paar dagen voor ik ze nodig heb. In dit geval had dat me gered.
Ik adviseer om de ISO van een andere site te downloaden dan waar je de checksums opzoekt. Dat is ook niet feilloos maar weer iets beter. Perfecte veiligheid bestaat niet, er is altijd wel een probleem te vinden, maar met relatief eenvoudige maatregelen is al heel veel te bereiken.

Overigens is het controleren van checksums ook los van de veiligheid een goed idee. Tijdens het installeren van een OS wil je geen last krijgen van een mislukte download of een rotte USB-key. Dat geeft maar vervelende problemen die moeilijk te achterhalen zijn. Even de checksum controleren voorkomt een hoop gehannes.
MD5 controleren klinkt leuk, zeker in dit geval waar de .iso is vervangen door een malafide versie. Maar wat ik niet kan vinden, en wat me aannemelijk lijkt, is dat de checksum (die op de website wordt getoond) ook vervangen is door degene die bij het malafide bestand hoort.

Eigenlijk zouden de checksums van een andere partij moeten komen, een soort CA.
Een goede manier om dit te doen is om de checksums te ondertekenen met welbekende PGP-sleutel. In de open-source wereld is er een hoop ervaring met dit soort systemen. Een probleem is dat je het wel van te voren moet regelen, nadat je gehackt bent is het heel moeilijk om nog het juiste vertrouwen op te bouwen.

Een ander groot probleem is de praktische uitvoering voor gewone mensen. Je kan niet in met ťťn klik en in ťťn oogopslag zien of het in orde is. Er zit een nogal technische procedure aan vast. Voor de meeste mensen is dat veel te ingewikkeld. Wat dat betreft is het maar goed dat de meeste mensen hun computer voorgeinstalleerd kopen en niet zelf een OS te hoeven downloaden.
Lastig is dat dit mogelijk vaker voorgekomen is, echter niet ontdenkt wordt/is.
Ik zou eerlijk gezegd nog liever een signature met PGP/GPG zien waar de master key door verschillende partijen is ondertekend om de authenticiteit te waarborgen. Hashes zijn handig als je de afkomst van de hash kan vertrouwen maar zonder dat dat kan iemand dit net zo makkelijk vervalsen (denk aan man in the middle attack voor de website met de hashes. mirrors zijn vaak niet beveiligt met HTTPS of alleen self-signed)!
en, als extra veiligheidsmarge, een paar dagen wachten na downloaden voor je de iso gebruikt... :)
als je tijdens het draaien van dit OS een bestand genaamd ' /var/lib/man.cy' hebt dan ben je besmet
Even kleine aanvulling hierop :
als je een DVD gedownload hebt, en je draait de live-sessie, en DAN zie zie je het bestand 'var/lib/man.cy' heb je een besmette installatie-CD!

Van de website:
If you still have the burnt DVD or USB stick, boot a computer or a virtual machine offline (turn off your router if in doubt) with it and let it load the live session.

Once in the live session, if there is a file in /var/lib/man.cy, then this is an infected ISO.


Dus: als je een DVD gebrand hebt (of deze op USB hebt gezet), even de PC uitzetten, opnieuw opstarten met deze DVD (of USB stick) en controleren of /var/lib/man.cy bestaat.

[Reactie gewijzigd door Pietervs op 21 februari 2016 15:17]

Mint gebruikers zijn niet per definitie newbies hoor.
Amen to that. Wat mij betreft is Mint 17.3 tot nu toe gewoon de beste windowsvervanger die ik ben tegengekomen. Probeer al heel wat jaartjes distro's uit, en deze is zů goed en stabiel dat het nu mijn standaard laptop OS is.
Ergens is het wel opvallend dat het nu net Mint moet zijn die dit overkomt. De meeste Linux-distributies hameren nogal hard op beveiliging. Mint koos juist voor gebruikersvriendelijkheid en is daarom erg populair. Ik vrees dat hun ruime houding ze fataal is geworden.
Lijkt me onzin. Dit heeft niks met de beveiliging van de distributie te maken maar met beveiliging van de website(s) . En ja, daar valt kennelijk wat op af te dingen. Maar dat zegt dus niks over mint als distro an sich.
Lijkt me onzin. Dit heeft niks met de beveiliging van de distributie te maken maar met beveiliging van de website(s) . En ja, daar valt kennelijk wat op af te dingen. Maar dat zegt dus niks over mint als distro an sich.
In theorie is er weinig relatie tussen de beveiliging van de website en de rest van de distro maar in praktijk zal het grotendeels over dezelfde mensen gaan. Hoe er met dit incident wordt omgegaan laat ook weer zien dat Mint niet overloopt van de beveiligingsspecialisten. Je hebt gelijk, het zegt niks over Mint, maar het is wel opvallend.


Trouwens, zoals we hebben gezien is het beveiligen van je distro zinloos als je website niet veilig is want dan wordt er gewoon een besmette ISO gepubliceerd.
Ik heb een machine op Linux Mint 17.3 Cinnamon draaien. Geen idee welke ISO ik gebruikt heb. Iemand enig idee hoe ik kan controleren of mijn installatie legit is of die backdoor bevat?
Van de top post:
Wat extra info:
- als je tijdens het draaien van dit OS een bestand genaamd ' /var/lib/man.cy' hebt dan ben je besmet
Je kan de MD5 signature van je installatie ISO checken, als die niet klopt heb je de foute versie binnengehengeld.
Ik weet dus niet zeker welke ISO dat was, heb er een paar op mijn harde schijf staan maar kan ook de live usb stick van een kameraad gebruikt hebben.

Zie echter wel dat de iso maar een dag verkeerd online stond, die installatie is al een paar weken oud dus ik zal niet getroffen zijn.
Ik weet dus niet zeker welke ISO dat was, heb er een paar op mijn harde schijf staan maar kan ook de live usb stick van een kameraad gebruikt hebben.
Je kan voor de zekerheid de checksums van alle ISO's uitrekenen en vergelijken met het lijstje van de website van Mint.
is van nu zaterdag .. gisteren dus ;)
Iig absentvodka.com in je host file laten resolven naar localhost?
Is inmiddels voldoende over te vinden.
Heb je de machine gisteren geÔnstalleerd? Want het was enkel in ISOs van 20 februari.
Niet helemaal antwoord op je vraag, maar als je die ISO niet de 20/21e gedownload hebt dan ben je waarschijnlijk niet getroffen door hetgeen waar dit artikel over gaat
Als je de iso nog op een Windows machine hebt staan, dan kan je met bijvoorbeeld dit tooltje http://www.winmd5.com/ heel eenvoudig je checksum zien en controleren.

Als ik de blog lees, gaat het hier om alleen de iso editie van 20 februari j.l en niet eerder, dus lijkt de impact veel kleiner dan in het artikel wordt gesuggereerd ?

Does this affect you?

As far as we know, the only compromised edition was Linux Mint 17.3 Cinnamon edition.

If you downloaded another release or another edition, this does not affect you. If you downloaded via torrents or via a direct HTTP link, this doesn’t affect you either.

Finally, the situation happened today, so it should only impact people who downloaded this edition on February 20th.
Welke checksum is goed en/of welke moet je niet hebben dan :) ?

Ah, de vraag is hieronder al beantwoord.

[Reactie gewijzigd door Feanathiel op 21 februari 2016 12:06]

Als je even de moeite neemt om het linkje http://blog.linuxmint.com/?p=2994 in het artikel te openen:

The valid signatures are below:

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
En nu maar hopen dat de hackers niet ook die checksums weer aanpassen.
Zal op genoemde pagina nu wel goed zitten maar ik zie zo vaak MD5 hashes vermeld staan die moeten duiden op betrouwbaarheid van het bestand maar het zegt natuurlijk niets als je hash ook niet goed is en is aangepast op de aanpassingen in iso's en exe's.
Het is een leuke indicatie maar je kan er niet blind op varen dat wanneer de hash klopt het dan allemaal wel ok is.
En mocht je nou geen zin hebben om een programma te installeren voor het checken van de MD5-hash, dan kan je er ook achter komen met behulp van het volgende Powershell commando: powershell get-filehash -algorithm md5 <bestandsnaam>.
Wel een goede reden om voortaan iso's via bittorrent binnen te halen.
Misschien zou het wel goed zijn om ook via de update-manager een waarschuwing uit te sturen als mensen toch geÔnfecteerd zijn geraakt en de backdoor op hun systeem zit?
Er kan vast iemand tussen zijn die dit nieuws niet meekrijgt of begrijpt en nu een backdoor heeft.
Wel een goede reden om voortaan iso's via bittorrent binnen te halen.
In dit geval had het niet geholpen, de hacker had net zo makkelijk een valse torrent kunnen publiceren. Op zich is de ingebouwde checksum wel handig maar je zal het wel zelf moeten controleren. (Simpele manier is om de magnet op verschillende sites te vergelijken of om de .torrent/.magnet vanaf verschillende sites te openen. Als je torrentclient ze allemaal samenvoegd dan zit je goed, als je echter meerdere aparte downloads krijgt dan is er iets mis.
Misschien zou het wel goed zijn om ook via de update-manager een waarschuwing uit te sturen als mensen toch geÔnfecteerd zijn geraakt en de backdoor op hun systeem zit?
Dat valt te proberen maar het risico is dat de hackers (die controle hebben over de besmette systemen) zo'n waarschuwing weer uit zetten.
Er kan vast iemand tussen zijn die dit nieuws niet meekrijgt of begrijpt en nu een backdoor heeft.
De keerzijde is dat er mensen kunnen denken dat ze niks hoeven te doen omdat ze geen pop-up hebben gehad.
In dit geval had het niet geholpen, de hacker had net zo makkelijk een valse torrent kunnen publiceren.
Persoonlijk verwacht ik ook wel dat de besmette ISO's nog wel enige tijd in roulatie zullen blijven als gevolg van de BT distributie. Het is niet geheel ondenkbaar dat mensen de direct download hebben gepakt en vervolgens die als Torrent hebben aangeboden, al dan niet met de beste bedoelingen (om bandbreedte te sparen voor de Linux Mint servers).
Is er een manier om te controleren of je te maken hebt met de besmette versie wanneer je de ISO al hebt geinstalleerd? De ISO gooi ik vaak weg vanwege ruimte en gezien je die normaal gesproken opnieuw kan downloaden. Ze gaan er hier vanuit dat je de ISO nog hebt.
Voor gister geinstalleerd? Dan ben je veilig. Alleen gister was het probleem aanwezig.
Hier veilige downloads en checksums voor Linux Mint 17.3: http://ftp.heanet.ie/pub/linuxmint.com/stable/17.3/
Wie zegt dat die veilig zijn? De checksums op diezelfde site?
Ergens is het wel opvallend dat het nu net Mint moet zijn die dit overkomt. De meeste Linux-distributies hameren nogal hard op beveiliging. Mint koos juist voor gebruikersvriendelijkheid en is daarom erg populair. Ik vrees dat hun ruime houding ze fataal is geworden.
Dit heeft zonder meer te maken met hun ruime houding, een jaartje terug overkwam het Manjaro, de beginners versie van Arch linux. Het is 2016, wen er maar aan, tasjes rovers zijn ouderwets.

Ik had jaren terug nog wel eens een servertje draaien voor ontwikkel doeleinden, iemand had met een virus geÔnfecteerde laptop gewerkt op dat netwerk, mijn netwerk informatie is het web over gegaan en een dag later kon ik live aanschouwen hoe een Poolse hacker (althans het IP adres) zeer systematisch allerlei gevoelige gegevens probeerde te ontvreemden.

Dit soort gegevens (user content) zijn gewoon big business zowel op de legale markt (Google) als de zwarte.
Ik snap dan ook niet hoe mensen zich veilig wanen in DE cloud... Voor sommige dingen toch echt alleen pen en papier!

[Reactie gewijzigd door Azbest op 21 februari 2016 12:55]

Gewoon goed je bestanden beveiligen en nee dan bedoel ik geen bitlocker en nee ook geen windows gebruiken daarvoor.
Wat adviseer je dan wel? Roepen je bestanden te beveiligen en daarbij enkel zeggen wat niet te doen helpt natuurlijk niemand.
Tsja, maar vertrouw je Windows niet en draai je Linux Mint, ben je alsnog de sjaak.
Misschien handig om te vertellen:
We were exposed to an intrusion today. It was brief and it shouldn’t impact many people, but if it impacts you, it’s very important you read the information below.
Today is inmiddels gister, maar als je dus vrijdag of eerder een iso opgehaald hebt ben je dus veilig.
En de meeste linux iso downloads gaan via torrwnt, standaard download optie is ook torrent. Voor directe download moet je bewust verder klikken
Ze mogen die beveiliging wel eens opvoeren daar dan. Denk je een Linux ISO te downloaden, download je gewoon een dik virus. Tegenwoordig is bijna niks meer te vertrouwen en moet je met alles de hash gaan checken? :')

[Reactie gewijzigd door AnonymousWP op 21 februari 2016 14:41]

Ik denk dat ze dat hopelijk nu door hebben. best is het controleren op voorhand en anders weet je nu met dat lek dat ze maar 1 dag toegang hadden tot de site en het veranderen van de iso's. Dus de schade zal wel meevallen, maar toch nog spijtige zaak voor zo een populaire linux distro.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Microsoft Xbox One S FIFA 17 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True