Office voor Mac kan XLM-macro's niet goed uitschakelen
Een beveiligingsoptie in Office voor Mac die ervoor moet zorgen dat alle macro's worden geblokkeerd zorgt er juist voor dat een bepaald type macro zonder melding aan gebruikers automatisch wordt uitgevoerd, waardoor een aanvaller op afstand het systeem kan overnemen.
Daarvoor waarschuwt het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit. Tot en met Excel 4.0 was er binnen Office een macroformaat genaamd XLM beschikbaar. Dit type macro is vervangen door Visual Basic for Applications (VBA) macro's. XLM-macro's worden echter nog steeds door alle Microsoft Office-versies ondersteund en zijn bijvoorbeeld aan SYLK-bestanden toe te voegen. SYmbolic LinK (SYLK) is een uit de jaren 1980 stammend bestandsformaat van Microsoft dat met name wordt gebruikt om data tussen applicaties uit te wisselen, met name spreadsheets.
Macro's in het SYLK-formaat vormen een probleem, omdat de Protected View-sandbox van Microsoft Office niet op dit bestandsformaat van toepassing is. Protected View is juist bedoeld om Office-gebruikers tegen kwaadaardige code te beschermen, maar SYLK-bestanden worden niet in Protected View geopend. "Gebruikers zijn daardoor één klik verwijderd van het uitvoeren van willekeurige via een document dat van het internet afkomstig is", zegt Will Dormann van het CERT/CC.
Office 2011 voor Mac waarschuwt gebruikers niet bij het openen van SYLK-bestanden met XLM-macro's. Office 2016 en 2019 voor Mac waarschuwen wel voor het uitvoeren van XLM-macro's in SYLK-bestanden. Wanneer Office voor Mac echter is ingesteld met de optie "Disable all macros without notification", worden de XLM-macro's in SYLK bestanden automatisch uitgevoerd zonder gebruikers te waarschuwen. Dit is getest met volledig gepatchte versies van Office 2016 en 2019 voor Mac.
Wanneer een Mac-gebruiker een SYLK-bestand (.SLK) opent met Office 2016 of 2019 waar "Disable all macros without notification" staat ingeschakeld kan een aanvaller zodoende willekeurige code uitvoeren met de rechten van de ingelogde gebruiker. Op dit moment zijn er volgens het CERT/CC geen praktische oplossingen voorhanden. Organisaties krijgen het advies om SYLK-bestanden op mail- en webgateways te blokkeren.
Een andere optie is het inschakelen van de optie "Disable all macros with notification". Deze optie is volgens Dormann minder veilig dan de optie waarbij gebruikers geen melding ontvangen, maar is in dit geval voor Mac-gebruikers een betere optie zolang Microsoft geen beveiligingsupdate heeft uitgebracht.
Wat meer genuanceerd en bijkomende instellingen {url]https://outflank.nl/blog/2019/10/30/abusing-the-sylk-file-format/[/url]
Weinig met extensies van doen, ouderwets de header op het bestand bepaalt het type.
Probleem hier is dat de bestanden niet gemarkeerd worden naar waar ze vandaan komen. Onder Linux Apple BSD bestaat dat kenmerk niet bij bestanden. Onder NTFS bestaat het wel.
kun je dat inhoudelijk toelichten ? referenties geven ook? ik ben hier onbekend mee en ik heb het gevoel dat ik het niet begrepen heb.
kun je dat inhoudelijk toelichten ? referenties geven ook? ik ben hier onbekend mee en ik heb het gevoel dat ik het niet begrepen heb.
Het is iets complexer, er is een toegangsmodel in local machine, intranet, internet. Globaal de machine de eigen organisatie en de buitenwereld. Deze werkt door in de toegang van bestanden in je netwerkverbindingen. Met het bovenstaande kenmerk heb je een aanduiding wat er met het bestand aan de hand is zolang de extra datastream maar consistent blijft.
https://support.microsoft.com/nl-nl/help/303650/intranet-site-is-identified-as-an-internet-site-when-you-use-an-fqdn-o
Dat gedoe met verborgen datastreams zag ik voor het eerst met OS/2 1.2 waar de gecompileerde versie en de source als enkel geheel gebruikt werden. De source veranderen startte het compilatieproces en ware ze in sync dan gebeurde er niets.
Het verwarrende met de machine,intranet.internt is dat het voor alle bestanden geld. De programmatuur die je laad en bestanden als een excel welke je ophaalt.
Het is he vaak gewenste bij security mensen dat je moet weten in welke segmentering (hier globaal) het zit.
https://serverfault.com/questions/176874/why-is-my-file-server-in-the-internet-zone
Geef me iets vergelijksbaars wat functionaliteit is in de file systems met Linux. (nog nooit gezien).
Wat meer genuanceerd en bijkomende instellingen https://outflank.nl/blog/2019/10/30/abusing-the-sylk-file-format/
Weinig met extensies van doen, ouderwets de header op het bestand bepaalt het type.
There is one important reason why the SYLK format is appealing to attackers: the Protected View sandbox does not apply to this file format. This means that if a weaponized SYLK file is delivered via email or web and the Mark-of-the-Web flag is applied, the target user is not bothered with this warning message.
Maar dezelfde pagina legt uit hoe men het voor elkaar heeft gekregen om macro's in SYLK-bestanden te stoppen, iets wat kennelijk niet vanzelfsprekend is. Dat, in combinatie met de constatering dat Microsoft het niet nodig heeft gevonden om dit formaat niet met Protected View te beschermen, doet vermoeden dat men bij Microsoft zelf niet doorhad dat in SYLK macro's kunnen worden opgenomen.
De uitleg op textslashplain.com waar je naar linkte geeft een hele opsomming van manieren waarop de Mark-of-the-web kan falen. Het is vrij fragiel, alle betrokken software moet het juiste doen en er zijn verschillende manieren waarop de markering verloren kan gaan. Die fragiliteit kan een reden zijn waarom men in de Linux-wereld niet direct warm loopt voor dit soort oplossingen.
Voor gedownloade scripts en executables is er trouwens al een andere bescherming: de uitvoerbaarheid van een bestand wordt niet bepaald door de extensie maar door een executable-attribuut dat door geen enkele webbrowser of e-mailclient zal worden aangezet op een gedownload of bewaard bestand.
Verder was men zich in de open source-wereld over het algemeen al zeer bewust van de nadelen van allerlei autorun-achtige constructies toen de Windows-wereld nog helemaal in de denkwijze zat dat automatischer alleen maar beter kan zijn. Ik denk dat dat problemen daarmee op Linux daarom simpelweg nooit zo groot zijn geworden als op Windows, daar bleef men nog jaren in die modus doorgaan toen allang evident was dat er van alles mee mis aan het gaan was.
Ik denk dat deze factoren de noodzaak om op Linux een extra maatregel als Mark-of-the-web te nemen veel kleiner maken dan op Windows.
Ik denk dat deze factoren de noodzaak om op Linux een extra maatregel als Mark-of-the-web te nemen veel kleiner maken dan op Windows.
Die vraag is opgekomen vanuit hoe je informatie zou moeten beveiligen (attribuut based).
Het rare is dat men niet kijkt naar wat nodig is maar naar wat toevallig gebouwd is. Dan krijg je een gat met verwachtingen.
File transfers, het eigen machine idee maakt informatie beveiliging onmogelijk met Linux, Kijk maar eens naar alle datalekken waar dat met plakwerk geprobeerd is, maar niet blijkt te werken. De enige ultieme manier zal gekoppelde attributen zijn.
wordt off-topic, maar:
er bestaat zoiets als een SELinux context; niet alleen voor files, ook voor sockets en poorten etc. deze SELinux attributen 'verdwijnen' dan ook niet een twee drie als je van XFS naar ext2/3/4 ofzo een file copieerd.
wordt off-topic, maar:
er bestaat zoiets als een SELinux context; niet alleen voor files, ook voor sockets en poorten etc. deze SELinux attributen 'verdwijnen' dan ook niet een twee drie als je van XFS naar ext2/3/4 ofzo een file copieerd.
Het biedt niets als een process die informatie het bestand nodig heeft. Het is geen attribuut als ontstaan herkomst.
wordt off-topic, maar:
er bestaat zoiets als een SELinux context; niet alleen voor files, ook voor sockets en poorten etc. deze SELinux attributen 'verdwijnen' dan ook niet een twee drie als je van XFS naar ext2/3/4 ofzo een file copieerd.
Het biedt niets als een process die informatie het bestand nodig heeft. Het is geen attribuut als ontstaan herkomst.
and that is were you are wrong... en omdat je off-topic door gaat met onjuiste informatie, hier extra uitleg.
hoog over en misschien te abstract:
SELinux is een MAC (https://en.wikipedia.org/wiki/Mandatory_access_control) systeem.
in de praktijk dus:
een process dat alleen files van een type (context) mag lezen, zal middels SELinux ook enkel en alleen die files kunnen openen die de juiste context / tag hebben. zo maar een file van ze interwebs zal niet de juiste context hebben en door SELinux beschermde processen zullen die file dus NIET openen tenzij er een speciale policy is. MAC dus. Het is dus zelfs een breedere oplossing dan gedownloade files alleen een 'tag' in NTFS' only (er bestaat ook nog FAT onder windows op stickies etc) geven.
Niet mee eens?
Lees de gegeven MAC link eens goed door en zie dat MS wat later van de partij was (middels MIC) en precies gaat over wat je bedoelde.
Niet mee eens?
Lees de gegeven MAC link eens goed door en zie dat MS wat later van de partij was (middels MIC) en precies gaat over wat je bedoelde.
Je hebt het over statisch opgeslagen bestanden. Niet over bestanden die zich nar andere omgevingen verplaatsten.
De sheelshoch had geen groot effect als je selinux goed had staan. De grote paniek er omheen toont dat het niet goed zat.
Met api's en connecties naar andere machines en dat met standaard qachtwoorden als admin:admi zet de boel wahenwijd ipen.
De foute insteek is dat als je linux zou gebruiken alles wel goed is en niet hoeft te denken.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
