Je kan op je vingers natellen dat ongezien code uitvoeren "van elders" geen goed idee is. Het betekent dat je de bron ongezien vertrouwt en "elders" blijkt toch best een grote plaats.

Eerste wat iedereen riep toen microsoft met "VBA"-macros kwam. En ja hoor, binnen twee dagen was er ook het eerste macrovirus. Dat is nu al wat jaartjes terug. Genoeg jaartjes dat er toen kinderen nog niet geboren waren die nu aan de alcohol mogen.

En toch blijven we macros in documenten stoppen en die dan in het wilde weg rondsturen. Binnen het bedrijf. Buiten het bedrijf. Onderling prive. Noem maar op. Bijna net zo graag als javascript in webpaginas, liefst in webpaginas die het helemaal niet nodig hebben. Tjsa.

We weten dit. Maar pas als er grootschalig misbruik van gemaakt wordt staat er een of ander clubje op dat zegt "kom, laten we het maar even niet doen." Volgende week is deze golf over en we gaan over tot de orde van de dag. Over twee weken... etc. *zucht*

'Elders' is in dit geval een bekende van je die jou een mail stuurt waar een stuk tekst van jezelf gequote is.

Dat verlaagt de alertheid toch een flink stuk. Niet iedereen denkt eraan dat het mailaccount van iemand die hij vertrouwd, gehacked kan zijn. Alle checks qua spoofing kloppen ook omdat de mail echt van dat account komt.

Ik denk niet dat dit advies veel opgevolgd gaat worden. Zoals Briolet hierboven ook schrijft, Emotet verspreidt zich vanaf gecompromitteerde accounts van mensen die door ontvangers van hun e-mails worden vertrouwd, o.a. omdat zij eerder succesvol informatie met hen hebben uitgewisseld. Omdat het hierbij ook om een collega in hetzelfde gebouw kan gaan, zul je macro's helemaal moeten verbieden en kun je dus die functionaliteit beter meteen helemaal uit office applicaties verwijderen.

Nb. het gaat niet alleen om e-mails met "gewone" office-document-bijlagen (die door een mailserver-uitbreiding op het bevatten van macro's gecontroleerd en desgewenst geblokkeerd kunnen worden), maar ook om versleutelde of anders gemanipuleerde bijlagen om detectie te vermijden. Ook kan het zijn dat, door tranport via non-NTFS-formatted USB geheugendragers, of als gevolg van het gebruik van bepaalde decompressiesoftware, tags zoals Microsoft's MotW (Mark of the Web) verloren gaan - waardoor het besturingssysteem geen verschil ziet met een zelf geschreven document (en meestal alle waarschuwingen weglaat). Ten slotte kan het om een e-mail met een link naar een bestand op bijv. een (mogelijk eerder gezamenlijk gebruikte) bestandsuitwisselingsite gaan (Dropbox, WeShare, SharePoint, *Drive etc.), waarbij je -door het gebruik maken van https verbindingen- meestal volledig afhankelijk bent van detectiefunctionaliteit op het eindstation van de gebruiker. Waarbij cybercriminelen er ook in die situatie alles aan zullen doen om detectie te voorkomen.

Een alternatief is dat de makers van office software (ook non-Microsoft!) macro's in twee verschillende soorten opsplitsen:
1) Macro's met uitsluitend effect binnen het "document" (ook spreadsheets, presentaties etc.) zelf, voor velen onmisbare functionaliteit;
2) Macro's die met effect buiten het document, zoals het starten van externe programma's of externe scripts.

Die tweede categorie is namelijk net zo gevaarlijk als executable files, en daarvan is zelden toegestaan dat die, simpel, door eindgebruikers kunnen worden uitgewisseld. Daarom is het van de zotte dat we hiermee door blijven gaan bij office documenten. Balken met "click here to enable macro's" blijken onvoldoende effecief; immers de verzender wordt vertrouwd en ontvangers doen braaf wat jarenlang tegen ze geroepen is: open geen e-mails/bijlagen van onbekende afzenders!

De eis voor alle bestanden die commando's voor extern uitvoerbare code kunnen bevatten, zou moeten zijn dat deze, in een veilige en vertrouwde omgeving (offline of anders met voldoende scheiding van potentieel gecompromitteerde systemen), eerst grondig worden geïnspecteerd, en indien zij slechts goedaardige (evt. whitelisted) macro's e.d. bevatten, digitaal worden gesigneerd en voorzien van een timestamp (die eveneens digitaal gesigneerd is, bij voorkeur door een trusted third party).

Los van het bovenstaande is het m.i. noodzakelijk dat we (of onze verzekeraars) verzenders van -al dan niet gesigneerde- malware aansprakelijk gaan stellen voor alle door onszelf geleden schade (exclusief de gevolgschade als wijzelf, doordat wij onze beveiliging onvoldoende op orde hadden/hebben, zelf malware versturen). Niet meer "vervelend voor je, het kan ook mij overkomen" (want dat zou nou juist niet eenvoudig moeten kunnen, door het nemen van maatregelen om de verspreiding van malware vanuit jouw organisatie te voorkomen), maar de vervuiler betaalt. Want ook in dit geval maken zachte heelmeesters stinkende wonden - en worden softwareleveranciers onvoldoende onder druk gezet om veiliger, en toch redelijk bruikbare, producten te maken, en blijven we er zelf teveel van uitgaan dat het ons niet zal overkomen dat wij malware gaan verzenden. Assume compromise!

Wat mij betreft moet de tweede categorie niet meer opgevat worden als een document dat een macro bevat maar als een programma dat een document bevat. Het moet een eigen extensie en magic number krijgen en als een soort executable worden opgevat (zoals geïnterpreteerde talen ook uitvoerbaar zijn). Het normale office-programma bavat niet eens de mogelijkheden om de macro-acties met externe effecten uit te voeren, die mogelijkheid is ondergebracht in de interpreter waarmee dit type bestand wordt uitgevoerd, die op zijn beurt de office-executable aanroept, of de office-library gebruikt, die de normale document- en macrofuncties bevat.

De gevaarlijke functies zijn daardoor alleen uitvoerbaar en zelfs alleen aanwezig in de runtime als het bestandstype herkenbaar gevaarlijk is.

Naar het effect van de gevolgen van een probleem kijken lost het probleem niet op.
Doorvragen -> waarom zijn al de macro's en scripting nodig? Wat mankeert er aan de standaard ICT dat deze uitweg gezocht wordt. Als je de vragen stelt dan kan je aan het echte probleem gaan werken. Ik ben bang dat het wijzen naar ICT is.

Een andere vraag is waarom een macro in een document zoveel schade kan aanrichten. Dat betekent dat het met de inrichting voor gebruik niet gekeken is naar wat veilig is maar wat makkelijk is in het gebruik.
Binnen Windows worden bestanden gemarkeerd (NTFS) waar ze vandaan komen lokaal machine, intranet , internet. Dar zou een goede beheerder wat mee moeten kunnen doen naast het email en document store gebeuren.

Laten we het geheel ontleden: Microsoft, Office, VBA. Natuurlijk is Microsoft de grote crimineel in deze, in heel veel oppervlakken. En ik dacht dat W10 zo goed als onkraakbaar was. Toch niet helemaal kennelijk. Dan hebben we Office. Dat is net zoals alle MS producten een gigant, geproduceerd onder hoge tijdsdruk. Een foutje is dan zo gemaakt, toch? En dan hebben we nog VBA, het prachtmodel van MS. Dat inderdaad alweer zo oud is als Metusalem.

Tja, er zijn alternatieven die zelfs hartstikke goed werken.

Criminelen maken natuurlijk gebruik van de mogelijkheden, ook als ze daar niet voor bedoeld zijn. Om dan MS crimineel te noemen gaat mij te ver. Ook zijn met andere Office pakketten zoals LibreOffice, die dezelfde functionaliteiten biedt, soortgelijke problemen. Omdat LibreOffice minder populair is, dus minder aantrekkelijk voor criminelen, zie je hier malware niet zo snel terug.

Maar wat is nu de oplossing ? Office documenten als bijlage verbieden ? Alleen PDF versturen ? Macro's altijd uitschakelen ?

1 - Windows platform wordt het meest gebruikt.
2 - MS Office wordt het meest gebruikt.
3 - Linux zou fijn zijn maar is voor velen of niet bruikbaar genoeg, veel software pakketten alleen voor windows.

In mijn geval is macro whitelisting bijna niet te doen. En het koppelen van documenten om rapporten te maken wordt meer gebruikt dan je denkt. Eigenlijk is het zo vertakt in de organisatie en communicatie dat je kunt stellen, welke strategie je ook wilt volgen er geen sjieke oplossing is.

Alleen dan, nee. Maar als je "ze hadden beter moeten weten" en "ze zijn ruimschoots gewaarschuwd" en "er zit al twintig jaar tussen" erbijoptelt, dan kom je uiteindelijk wel tot grof en daarmee crimineel nalatig.

"De" oplossing, ach. We kunnen eens beginnen met werken aan een oplossing. Iets van een bestandsformaat waar niet allerlei rommel bijin past?

Terzijde: "normale" PDF heeft adobe in hun wijsheid uitgebreid met javascript, xml, en zelfs flash, dus dan moet je alweer opletten dat je echt alleen "PDF/A" genereert en accepteert.

Nou, dan heb je net jezelf veroordeeld tot geen andere mogelijkheid hebben dan microsoft zover krijgen dat ze hun eigen rotzooi nou eens een keertje opruimen. Dat heb ik ze nog nooit zien doen, maar als je het voorelkaar krijgt, petje af hoor.

Dit blijkt vooral tussen de oren te zitten. En oh ja, een hele hoop politiek.

Mischien moet je dan iets fundamenteels veranderen aan je workflow.

Ik zie je alleen maar naar "kan niet anders" toeredeneren. En zolang je dat blijft doen, is er ook echt geen andere oplossing. Dus zul je ellende blijven houden. Maar zeg niet dat je het niet wist, kon weten, of er niets aan kon doen. Dat kan best, maar pas nadat je in je eigen hoofd hebt toegegeven dat het ook echt kan.

Hoort allemaal! zo zit het dus:
@donderslag je hebt helemaal gelijk!...

Niet de malware klootzakken zijn de oorzaak van de www en email ellende die zij veroorzaken maar de (os) software.

Even een vergelijking waar je het helemaal mee eens zult zijn:
Een petjespuistkop die in de V10 Audi R-8 van zijn poepie-stinkend rijke pa door een woonwijk met spelende kleuters jaagt en er een schept is niet de crimineel... neu... dat is de auto fabrikant.