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 , , 107 reacties

Volgens McAfee is de foutieve virusupdate van woensdag, die veel problemen heeft veroorzaakt, het gevolg van een 'wijziging' in het testprotocol. Een uitgelekt document wijst erop dat de update niet op Windows XP met SP3 is getest.

Afgelopen woensdag werd bekend dat McAfee een foutieve virusupdate heeft verspreid. Deze had tot gevolg dat het Windows-systeembestand svchost.exe als virus werd aangemerkt. De 'false positive' zorgde voor veel problemen; getroffen computers kregen BSOD's of bleven eindeloos herstarten. Vooral veel bedrijven zouden hinder hebben ondervonden.

In een blogposting biedt het antivirusbedrijf zijn excuses aan. Ook legt het bedrijf uit hoe de foutieve virusupdate zou zijn verspreid. Door een 'wijziging' in de testprocedure zou de update door de kwaliteitsbewaking zijn gekomen. McAfee licht niet toe wat deze wijziging inhoudt, maar volgens ZDNet, dat zich op een uitgelekt document baseert, was de test simpelweg niet compleet. Zo zou de update niet zijn getest voor systemen met Windows XP, Service Pack 3 en versie 8.7 van McAfee's zakelijke virusscanner.

Dit strookt met een faq op de site van McAfee, die meldt dat alleen systemen met Windows XP SP3 en bepaalde versies van het systeembestand last van het probleem hadden. McAfee heeft aangegeven de testprotocollen te verbeteren en een whitelist met essentiële systeembestanden op te zetten om false positives in de toekomst te voorkomen. Gebruikers met problemen kunnen al sinds woensdag voor een oplossing terecht op de site van McAfee.

Moderatie-faq Wijzig weergave

Reacties (107)

Whitelisten van deze bestanden is niet handig omdat dat juist er voor zorgt dat deze bestanden bijzonder interessant worden om te infecteren.
Is het niet zo, dat de whitelists ook de hashes van bestanden bevatten, zodat een gewijzigd windowsbestand er zo uitgehaald kan worden? ...
Technisch gezien is het mogelijk om een 2e bestand te maken dat dezelfde hash krijgt als het eerste bestand. Dit is afhankelijk van de gebruikte hashmethode wel vrij lastig, maar zeker niet ondenkbaar.
Maar om een bestand te produceren dat dezelfde hash heeft, uitvoerbaar is, en ook nog eens doet wat jij wil, is (bijna) onmogelijk.
Je kunt bij executables naar mijn weten gewoon extra data achter het bestand aanplakken. Misschien ingewikkeld en tijdrovend, maar als je virus/ trojan daardoor ongezien blijft, zeker de moeite waard lijkt me.
Misschien weet je niet precies wat een hash is, maar als er gebruikt wordt van hashes om bestanden te identificeren op basis van hun authenticiteit, is dit niet mogelijk.

Een hash van een bestand is een korte string die door een algoritme gemaakt is, gebaseerd op de inhoud van het bestand. Deze hash is onomkeerbaar (als jij een hash hebt kun je nooit terug naar het bestand), en nagenoeg uniek voor elk bestand. Er bestaan wel dezelfde hashes voor verschillende inputstrings (botsingen), maar deze zijn te verwaarlozen.

Als bestand 1 hash 5ter80f8349pdfj90hdf heeft, en jij zet er *HAX CODE VIRUS* achter, zal het bestand een andere hash waarde krijgen. Vervolgens weer MCAffee dat er met het bestand gerotzooid is, en dat het niet meer te vertrouwens is :)

Hopelijk begrijp je het nu (beter) :)
Hij bedoeld dat wanneer je bepaalde data achterin het virusbestand toevoegt de hash hetzelfde kan zijn. Met een goed hash algoritme kan een bestand met een willekeurige inhoud met toevoegingen elke mogelijke hash genereren. Let wel: het is technisch mogelijk maar praktisch ondoenbaar natuurlijk.
Extra data er achteraan plakken kan toch wel met een checksum?

Hash werkt idd via algoritme, dat word al een stuk lastiger.. :P
Als er niet gekeken wordt naar de grootte van het bestand, maar puur naar de hash, dan is het bij bijv. md5 niet zo moeilijk om een bestand te maken dat precies dezelfde hash heeft.

De fix daarop is dan ook om de grootte van het bestand ook te controlen.
Of je houdt zowel een MD5, als een SHA1 checksum van de bestanden bij.

De kans dat beide checksums op dezelfde values bij dezelfde input dezelfde collisions hebben is nihil.
@brama
Ok, succes, zonder dat ik je de grootte van het bronbestand vertel, want daar word niet naar gekeken in jou theorie, kan jij dit ontcijferen:

eb69786bce860c78e182d7b8fd270986

Tis een MD5 hash, dus succes, jij vind het kennelijk niet zo moeilijk.
Het gaat ten slotte om de exacte gegevens die tot die hash gekomen zijn, NIET de hash zelf. Maar zo werkt het simpelweg niet.

Het doel van de MD5 hash is om te kijken of er geknoeid is met een bestand.
Als je dat wilt neppen zodat je virusje dezelfde hash heeft, dan moet je HEEL VEEL willekeurige combinaties van nutteloze data er in stoppen om ooit tot diezelfde hash te komen.

Als jij het niet zo moeilijk vind, vertel me dan maar eens met welke text jij deze hash zelf hebt nagemaakt:

"eb69786bce860c78e182d7b8fd270986"


On-Topic:
Wat een goede tip is voor macafee:
Die whitelist uitrusten met een download progje die de system32 bestanden kan downloaden wanneer ze WEL geinfecteerd zijn.

[Reactie gewijzigd door Yezpahr op 24 april 2010 10:38]

@Yezpahr:

http://www.mscs.dal.ca/~selinger/md5collision/

Hier doen ze precies wat jij vraagt, compleet met een voorbeeld van zo'n 'geforceerde' MD5 collision.

Ze maken zelfs twee executables met dezelfde MD5 hash, maar met duidelijk andere functionaliteit.

[Reactie gewijzigd door tofus op 24 april 2010 14:45]

@ Foxl: Je kan daar natuurlijk makkelijk op controleren door hash+bestandsgrote te controleren zoals bij mijn weten ook altijd gedaan wordt, en die combinatie is dus onmogelijk te foppen.
Yeah, totdat MS een update uitbrengt voor je OS en je virus scanner nog niet is geupdate, worden de betreffende bestanden nog gezien als virus en heb je als nog een niet werkende computer.
Yeah, totdat MS een update uitbrengt voor je OS en je virus scanner nog niet is geupdate, worden de betreffende bestanden nog gezien als virus en heb je als nog een niet werkende computer.
Het is niet zo dat bestanden die niet op de whitelist staan automatisch als virus worden gezien. Het is een extra beveiliging om problemen zoals nu spelen te voorkomen.

De mogelijkheid dat er een fout in de virusdefinities zit, dat deze fout ervoor zorgt dat een systeembestand wordt verwijdert en dat dit systeembestand door een update nog niet op de lijst stond lijkt me tamelijk klein.

[Reactie gewijzigd door doeternietoe op 23 april 2010 19:00]

Dat kan eenvoudig maar dan is de hash weer anders zoals compufreak88 (nmi duidelijk) aangeeft
Maar kun je ook:
- jouw virus-code toevoegen,
- de hash hetzelfde houden (dit kost meestal veel ruimte!)
- en de grootte van het bestand hetzelfde houden?
Als je hash+size checkt dan wordt het extreem moeilijk om nog met dat bestand te rotzooien.
Bestaande code eruit slopen, om jezelf wat "werkruimte" te geven, is immers geen optie: een paar kleine functies eruit slopen betekent dat je alle interne verwijzingen (pointers en entry points en dergelijke) aan moet passen; verre van triviaal. En ik waag te betwijlfen of je een groot, aaneengesloten blok kunt vinden dat weggooid kan worden (denk eraan dat we het over een essentieel systeembestand hebben) zonder dat het geheel zo onbruikbaar wordt dat de machine niet eens meer kan booten.
Bovendien is het volgens mij niet zo triviaal om gegeven een bestand en bijbehorende hash een tweede bestand te maken met diezelfde hash.

Twee bestanden maken met dezelfde hash is, bijvoorbeeld in het geval van md5, wel mogelijk tegenwoordig, maar dan heb je dus controle over beide bestanden, niet over slechts ťťn van de twee.

Of heb ik ergens iets gemist/verkeerd begrepen en is ook de weak-collision-resistance van MD5 al om zeep geholpen?

Daarnaast lijkt het me niet dat McAffee zo dom zou zijn om voor zo'n toepassing een hash algoritme te gebruiken waarvan bekend is dat het niet betrouwbaar is.

[Reactie gewijzigd door Orion84 op 23 april 2010 16:31]

Je kan altijd meerdere hashes per file opslaan om het zo NOG moeilijker te maken.
bvb: md5 + SHA-256 + grootte van het bestand.

Maar anderzijds: die 'whitelisted' system files van windows worden vaak geupdate -> hash veranderd -> wordt gezien als virus?
Dan is de extra beschermingslaag tegen het verwijderen van essentiŽle systeembestanden even niet in werking. Effectief ben je in de tijd tussen de update van een systeembestand van de kant van Microsoft en de update van de whitelist door McAfee terug in de situatie van nu. De kans dat in die tussentijd er een fout als de bovenstaande de virusdefinities insluipt lijkt me klein.
Zowel SHA1 als MD5 bijhouden, collision op meerdere hashes wordt wel bijzonder moeilijk.
Het kan inderdaad wel, maar als er wat betere hashing algoritmes dan MD5 of SHA-0 worden gebruikt, dan is het niet mogelijk. Als SHA-1 of SHA-2 worden gekraakt, dan zitten alle websites die gebruik maken van TLS of SSL in grote problemen (en SSH en IPsec). SHA-1 wordt op het moment op veel plekken uitgefaseerd, SHA-2 wordt nog steeds als compleet veilig beschouwd.

[Reactie gewijzigd door the_shadow op 23 april 2010 17:03]

whitelisten met hash lijkt ok, tenzij je niet test met alle mogelijke updates, nu wordt sp3 voor xp natuurlijk niet of nauwelijks gebruikt (daar hoef je niet een op te testen zo weinig) maar stel dat er opeens een veelgebruikte update tussendoor komt dan kun je zomaar een heleboel bestanden als false positive aanmerken.

[Reactie gewijzigd door bitflusher op 24 april 2010 08:05]

je kan dagelijks een andere hashkey/methode gebruiken, waardoor je maximaal een zero-day exploit/virus kan hebben
Misschien met een signatuur van zo'n bestand? Dus niet enkel met de bestandsnaam zelf, maar ook met de exacte bytecode (of een hash daarvan)? Een virus dat zo'n bestand infecteert verandert sowieso de bytecode van dit bestand, en op deze manier zouden dus geÔnfecteerde van niet-geÔnfecteerde whitelistbestanden onderscheiden kunnen worden.

[Reactie gewijzigd door Dooievriend op 23 april 2010 15:49]

Een besturingssysteem dat niet meer opstart, dat is handig. Ze kunnen natuurlijk wel waarschuwen dat er een gevaar is, maar verwijderen is zo ongeveer het domste dat je kunt doen.
Ik denk dat ze bedoelen dat de whitelist bestanden zal bevatten die niet per definitie in quarantaine mogen worden gezet - niet dat ze niet gescand zullen worden. Je krijgt dan alsnog de melding dat er een infectie gevonden is, maar het geÔnfecteerde bestand blijft in ieder geval wel staan, tenminste zo lees ik het.
weer lekker slordig van MCAfee,
aangezien dit niet de eerste keer is dat zoiets gebeurd verwacht ik ook dat ze misschien klanten gaan verliesen.

Heb zelf ook MCAfee maar draai hem op Windows 7 en geen problemen.

Toch erg jammer.
En toch heeft McAfee de minste false positives volgens Gartner, IDC en Forrester en dit al meerdere jaren na elkaar. Ze zijn ook absolute marktleider in beveiliging van endpoints en netwerken.

Dit toont dat geen enkel product 100% werkt en nooit problemen zal geven.

Dit neemt niet weg dat dit erg slordig was natuurlijk.
En toch heeft McAfee de minste false positives volgens Gartner, IDC en Forrester en dit al meerdere jaren na elkaar. Ze zijn ook absolute marktleider in beveiliging van endpoints en netwerken.
Een false positive op een onschuldig bestand heeft natuurlijk een ander resultaat dan bij een systeembestand zoals in dit geval, waarbij de volledige installatie onbruikbaar is (tot de fix).
Laatste keer dat dit bij McAfee gebeurde is volgens mij meer dan 6 jaar geleden.
Dat het recenter bij een aantal andere is gebeurd lijkt me geen aanleiding dat specifiek McAfee klanten verliest.
leuk detail op NU.nl
een half procent van alle klanten.. yeah right... |:(

"Het bedrijf heeft inmiddels zijn excuses aangeboden voor de foutieve update. In een officiŽle verklaring laat McAfee weten dat “minder dan een half procent van alle klanten last heeft gehad van de update.”



in het officiele artikel staat er ook niets over.
http://siblog.mcafee.com/...lse-positive-remediation/

[Reactie gewijzigd door carpcatcher op 23 april 2010 15:59]

Dit klopt wel want de helft van de mensen die weten hoe alles moet hebben het zo ingesteld dat:
1. mcafee vraag op update
2. op een afgesproken datum.

En als ze er net buiten vallen, dan hebben ze net genoeg

[Reactie gewijzigd door Stefanto op 23 april 2010 15:57]

Dat is maar de vraag. Op mijn werk zijn de desktops buiten schot gebleven (Epolicy draait bij ons met 1 dag vertraging, dat is veiliger dan klakkeloos uitrollen en als een virus erg serieus is kunnen we altijd daar nog een mouw aan passen), maar de laptops wilden allemaal niet booten. Dit omdat de laptops dus thuis gebruikt kunnen worden, en daar wel gewoon netjes automatisch de nieuwste updates binnentrekken zodra er internetverbinding aan hangt.
"Gebruikers met problemen kunnen al sinds woensdag voor een oplossing terecht op de site van McAfee."
Dat is leuk bedacht maar geen echte hulp wanneer je computer niet opstarten wil. 8-)
Daarom is het ook handig om niet afhankelijk te zijn van een enkele PC, of in ieder geval niet een enkele Windows install. Dit soort geintjes komen vaker voor.
dan zijn we blij dat we ergens een linux boot disk hebben liggen ;)

overal waar ik (als amateur) een PC installeer laat ik een ubuntu cdtje achter. Kan je via VPN al een hoop oplossen.
Al die uren?

Zoveel werk was het niet.
Hoeveel systemen waren het? Ziehier een voordeel om niet en masse naar nieuwe OS'sen of op oude OS'sen te blijven.

In dit geval bleef een groot deel buiten schot bij ons :)

Overigens wel vrij vlotte reactie van McAfee hoor.

[Reactie gewijzigd door basset op 23 april 2010 15:47]

Ziehier een voordeel om niet en masse naar nieuwe OS'sen of op oude OS'sen te blijven
Ja hallo, Vista werd door iedereen afgeraden, XP SP3 is nog steeds het meest gebruikt en Windows 7 komt net op de hoek kijken: omdat bedrijven zoals McAfee hun zaken niet op orde hebben moeten we dus maar klakkeloos upgraden, ookal heeft het geen enkele toegevoegde waarde? Mah.
Bij ons in de firma heeft men geluk gehad dat de IT dienst onze systemen nog op SP2 houd op dit moment, anders hadden we hier over duizenden defecte systemen gesproken.
"Foutieve McAfee-update gevolg van gebrekkige testprocedure"

Thank you for pointing out the obvious!!

Daar had ik nou geen uitgelekt document voor nodig om daar achter to komen.
en het is inderdaad nogal knudde dat het in eens niet meer gedaan wordt, gezien zo veel bedrijven nog steeds XP gebruiken.

voortaan doen we lekker zelf wel het testen van de DAT files voordat het uitgerold wordt.
geen 2de keer dit grapje.
En ga jij ALLE situaties kunnen testen in een testomgeving? Dat kan je niet. Bij 1 van de vorige keren dat dit bij een concurent gebeurde bleek het probleem beperkt tot bepaalde talen van het OS. Moet je dan duizenden systemen gaan opzetten waarbij je imens veel combinaties gaat testen?

Op een gegeven moment bereik je een punt waarbij de kosten niet meer opwegen tegen de baten. Het is in een bedrijfsomgeving zowiezo aan te raden om updates nog eens zelf te testen omdat in een bedrijfsomgeving de meeste systemen een gelijkaardige softwarecombinatie draaien.
Lekker betrouwbaar bedrijf. Als het nou zo makkelijk is om een bestand te verwijderen dan gaan we wat beleven in de toekomst. 27 processen in 1 keer plat. Dat is wel een idee. Gelukkig meer Panda verkocht dan McAfee. De paar McAfee pcs zijn alweer in orde maar het is wel weer gezeur met een antiviruspakket. Ik vind wel dat nog steeds virussen makkelijk door antiviruspakketen komt maar dat is even een ander verhaal.
En wat als het volgende week Panda overkomt? Ga je dan nog gelukkig zijn dat je meer Panda verkoopt?

En de virusdetectie van de grote namen is redelijk goed te noemen, 100% detectie kan gewoon niet.
Gelukkig gebruiken we hier geen McAfee, maar is het niet heel erg om te zeggen dat iedereen nu schadeclaim moet indienen bij hun, omdat ze een fout hebben gemaakt?

Je bent systeembeheerder en je moet dan toch werken. Dit soort problemen oplossen hoort in principe bij je (dagelijkse) taken?
We gaan er steeds meer en meer naartoe dat er IEMAND de schuld moet hebben van bepaalde zaken om er geld uit te halen. Het kan niet zo zijn dat er iets gebeurd zonder dat er een schuldige is dus claimen en aanklagen die boel.

Natuurlijk is dit een fout van mcAfee, maar om nou gelijk uurtje --> factuurtje te doen richting hun vind ik wat ver gezocht.
Wat dacht je van systeembeheerders die 's nachts uit hun bed gebeld worden omdat verscheidene laptops niet meer werken (laten laptops namelijk nu net niet via Epolicy Orchestrator lopen maar gelijk updaten vanaf internet)? Die beheerders maken dure overuren. Gezien er best wat geld betaald wordt aan McAfee om dit soort situaties te voorkomen kan ik me voorstellen dat er over schadevergoedingen worden gepraat (alhoewel ik dat op mijn werk niet teruggehoord heb overigens, en het me persoonlijk niet zo veel uitmaakt).
Op woensdag kwam het mailtje al binnen van Medusoft, update tegengehouden in de epolicy orchestrator. Een paar systeempjes bleken toch problemen te krijgen, maar de volgende patch kwam snel genoeg. Langs de pc's gerend met svchost.exe en de laatste dat files. Geen probleem. Mcafee kwam erg snel en adequaat met een oplossing, je moet als sysadmin alleen wel wakker blijven met zulke grappen.
Ook hier de instructies van Medusoft gevolgd (DAT 5958 uit ePO gehaald en autoupdate tijdelijk uitgezet en EXTRA.DAT erin gezet) en eindresultaat was dat er in het hele bedrijf maar 2 pc's met problemen waren (op zo'n 400 man personeel). Er zijn wel mensen geweest die de update hebben gekregen (voornamelijk laptops buiten de deur), maar toch maar 2 probleemgevallen. En wij gebruiken ook hoofdzakelijk Windows XP met SP3 en in een enkel geval nog Windows XP met SP2.

Ik weet niet precies onder welke condities het fout ging, maar ik heb zelf ook DAT 5958 erop gehad en geen problemen ondervonden (Windows XP met SP3, Engelstalige versie met zowel VSE8.5 patch8 en VSE8.7 patch3 met AntiSpyWare module). Dit was buiten de ePO managed omgeving.
zouden heel veel bedrijven hiervoor nou geen schade claim indienen? kost hun weer geld om hun systeembeheerders al die computers weer te laten repareren.
vind het belachelijk dat dit er doorheen is gekomen, vooral als groot antivirus bedrijf mag jezelf toch niet zo'n fout als deze permiteren. ongeacht testprocedure. gehele ziekenhuizen lagen plat. zo zie je maar weer hoe digitaal we worden.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 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