[English]Microsoft setzt seine Pläne, Makros in Office 365 standardmäßig zu deaktivieren, erneut fort. Denn Macros in Office stellen ein Einfallstor für Malware wie Dridex, Emotet, Trickbot, Qbot etc. dar. Ist zwar eine on-off-Geschichte, die Microsoft die letzten Wochen da gefahren hat – aber jetzt heißt es erneut „mit Volldampf voraus“.
Sie wollen, sie wollen nicht …
Microsoft hatte in einer Ankündigung vom 8. Februar 2022 mitgeteilt, dass man aus Sicherheitsgründen das Verhalten von Microsoft Office zum Blockieren von Macros aus Dateien, die per Internet geladen wurden, ändern möchte. Das Ganze wird näher im Techcommunity-Beitrag Helping users stay safe: Blocking internet macros by default in Office ausgeführt.
Dort hieß es im Februar 2022:
We’re introducing a default change for five Office apps that run macros:
VBA macros obtained from the internet will now be blocked by default
For macros in files obtained from the internet, users will no longer be able to enable content with a click of a button. A message bar will appear for users notifying them with a button to learn more. The default is more secure and is expected to keep more users safe including home users and information workers in managed organizations.
Diese Änderung sollte nur Office auf Geräten mit Windows und nur die folgenden Anwendungen betreffen: Access, Excel, PowerPoint, Visio und Word. Die Änderung sollte mit der Version 2203 für die genannten Anwendungen, beginnend mit dem Current Channel (Preview) Anfang April 2022, eingeführt werden. Später war diese Änderung auch in den anderen Update-Kanälen wie dem Current Channel, dem Monthly Enterprise Channel und dem Semi-Annual Enterprise Channel geplant und man wollte das sogar auf Office LTSC, Office 2021, Office 2019, Office 2016 und Office 2013 ausrollen. So weit so gut.
Zum 8. Juli 2022 gab es dann die Meldung, dass Microsoft einen Rückzieher mache und die standardmäßig Deaktiverung der VBA-Makros in Office aussetze. Ich hatte im Blog-Beitrag Microsoft will standardmäßig nun doch keine Makros in Office blockieren darüber berichtet. So richtig erklärt hatte Microsoft sich nicht, sondern nur auf „Feedback der Nutzer“ verwiesen. Hochgespült wurde dies wohl am 6. Juli 2022 von einem Nutzer, der auf Techcommunity im Ursprungsartikel nachfragte, ob das Feature zurückgerollt worden sei.
Oh, sorry, war nicht so gemeint
Nachdem die obige Geschichte einigen Wirbel verursachte, ruderte das Unternehmen zurück. Im Blog-Beitrag Office Makro-Blockade: Aussetzung ist nur temporär hatte ich den Hinweis aufgegriffen, dass die „Aussetzung der Makro-Deaktivierung“ durch Microsoft nur temporär sei. Ein Auszug aus der Ergänzung im Techcommunity-Beitrag besagte:
This is a temporary change, and we are fully committed to making the default change for all users. We will provide additional details on timeline in the upcoming weeks.
Was der Grund für die Rolle rückwärts von der Rolle rückwärts ist, blieb zwar im Dunkeln, aber es war klar, dass sich irgendwann wieder was ändert.
Jetzt wird wieder deaktiviert
Zum 20. Juli 2022 hat Microsoft dann ein Update im Techcommunity-Beitrag eingefügt, welches das Rollout der Änderungen im Current Channel für Office 365 ankündigt.
We’re resuming the rollout of this change in Current Channel. Based on our review of customer feedback, we’ve made updates to both our end user and our IT admin documentation to make clearer what options you have for different scenarios. For example, what to do if you have files on SharePoint or files on a network share. Please refer to the following documentation:
- For end users, A potentially dangerous macro has been blocked
If you ever enabled or disabled the Block macros from running in Office files from the Internet policy, your organization will not be affected by this change.
Damit sind wir nun da, wo wir vor einigen Wochen schon mal standen. Mal schauen, wie das weiter geht – jedenfalls wisst ihr jetzt Bescheid. (via)
Sofern es wen interessiert, ich habe das in einem Problemsystem mal nachvollzogen und von ausserhalb geht es. Also für Fälle wo man die Anwendung fersteuern will.
VBA geht nicht, VB6 von aussen geht, C# COM Interop geht auch.
Als alter COM Spezie erahnt man ein InProc Server Problem.
Und Tatsache hat Microsoft hier rumgespielt so wie ich das sehe.
Vereinfacht gesagt der Registry Key HKEY-CURRENT sollte immer den aktuellen Benutzer wiederspiegeln, das macht er gerade nicht mehr bei den InProc32 Keys, die Umstände kenne ich auch noch nicht.
Wenn Du mehr herausfindest, lasse es mich ggf. wissen – gerne auch per Mail. Vielleicht lässt sich da mal ein Inside-Artikel drüber machen.
Zum Registrierungszweig: Ich nehme an, dass HKey_Current_User gemeint ist. Da ist das Problem, dass bei administrativen Sachen die Einträge in HKCU des Administrator-Kontos manipuliert werden, statt des aktuell angemeldeten Benutzers – weil die UAC dafür sorgt, dass die Prozesse unter diesem Kontext ausgeführt werden. Ob das bei COM-Aufrufen so geregelt wird, weiß ich nicht.
Warum ist es so schwierig, den englischen Text korrekt wiederzugeben und keine Click-Bait-Überschrift zu verwenden?
Makros sind schon seit Urzeiten in Microsoft Office deaktiviert, erst recht bei heruntergeladenen. Es wird jetzt nur schwerer gemacht, sie bei aus dem Internet heruntergeladenen (oder per Mail von anderen Konzern-Mitarbeitern erhaltenen…) durch einen einzigen Klick auf die gelbe eindringliche Warnmeldung trotzdem zu aktivieren!
Außerdem sind Makros auch selbst bei eigenen lokalen Dateien deaktiviert außer vielleicht bei digital signierten (so wie hier bei uns zumindest eingestellt) und zusätzlich nur, wenn die Dateien an als vertrauenswürdig eingestuften Orten gespeichert sind. Viel besser kann man es als Microsoft kaum machen, um maximale Sicherheit trotz extremer Leistungsfähigkeit einer Office-Plattform zu ermöglichen. Wem natürlich der Funktionsumfang von notepad und Konsorten auskommt, hat eher andere Probleme oder weiß es nicht besser.
Wir nutzen auch die Option per GPO nur signierte Makros zu erlauben. Das hat den Charme, dass Makros in Dateien ohne Signatur von Office komplett totgelegt werden. Es gibt schlicht keine Option mehr diese zu aktivieren. Selbst wenn sich jemand in die Sicherheitseinstellungen für VBA-Makros verirrt, so sind andere Optionen dort inaktiv. Der Anwender kann also keine Modifikationen an den Einstellungen vornehmen und die Sicherheit herabsetzen.
Des Weiteren sind die Mailserver so eingestellt, dass Dateien mit Makros, Dateien mit Makros in Archiven wie zip, 7z, cab, iso, rar und Archive mit Passwort (verschlüsselt) nicht zum Anwender gelangen.
Einen Nachteil sollte man aber auch nennen. Die Zertifikate zum signieren des VBA-Codes haben bei uns eine Gültigkeit von zwei Jahren und werden von der internen PKI bereitgestellt. Hat man viele Dateien mit Makros, so sollte man sich vorab Gedanken über den Wechsel der Zertifikate machen.
Bei uns gibt es Dateien mit VBA, welche quasi nur als Vorlage dienen, vom Anwender aber am Ende als normale Excel-Datei gespeichert werden. Daher bleibt es noch überschaubar. Würden die Makros in den Dateien verbleiben, so würden sich diese schnell verteilen (Speicherorte) und dann ggf. alle mit Ablauf des Zertifikats nicht mehr funktionieren. Es kann schnell lästig werden zum Stichtag viele Dateien überarbeiten zu müssen.
Oder man signiert gleich mit Zeitstempel, dann ist es nur wichtig, dass die Unterschrift zu einem Zeitpunkt erfolgte an welchem das Zertifikat gültig war. Wir machen das nicht, da man den Zeitpunkt der Unterschrift zu leicht manipulieren kann.
Gruß Singlethreaded
Auf die Gefahr, dass die Frage dumm ist: Wie manipuliert man denn den Zeitpunkt der Unterschrift? Dazu bräuchte man doch einen Zeitstempeldienstleister, der gleichzeitig vertrauenswürdig und korrupt ist?
Ich arbeite viel mit Datenbanken. Meine Frontends sind Access und Excel. Bei den Systemeinstellungen kenne ich nur das Nötigste. Bei dutzenden von Kunden habe ich natürlich auch keine Kenntnisse und keinen Einfluss auf deren IT. Die Updates werden per Internet angeboten. Es gibt Anwendungen mit mehreren zehntausend Programmzeilen. (Allein der Gedanke, hier von „Makros“ zu reden ist irgendwie schräg.)
Kurz, es ist für mich nur schwer vorstellbar, dass das alles sicherheitshalber deaktiviert wird.
Das schreibt Microsoft ja auch gar nicht, nur so manches Blog, vor allem gerne in Überschriften…
Was Microsoft vorhat – und das ist durchaus sinnvoll, steht in deren Veröffentlichung und auf Deutsch in einem Satz auch in meinem obigen Beitrag.
Ich weiß nicht wo ich so richtig meine Frage loswerden kann. Besitze ein Zertifikat zum Signieren von vba-Makros. Ist es möglich, das in Excel-Dateien ohne vba-Code, das Zertifikat gar nicht erhalten bleibt?