Letzte Änderung am 24. Juni 2022 by Christoph Jüngling
Makroviren sind schon seit längerem ein Problem, und zwar sowohl für Entwickler als auch für Anwender von Microsoft Office. Die naheliegende Empfehlung an Anwender, alle Makros zu deaktivieren, ist zwar hilfreich, aber nicht immer realistisch. Denn manche Anwendungen basieren auf einem der Office-Programme, und VBA ist ja gerade dafür gedacht, besondere Wünsche der Anwender per einfach zu schreibendem Code zu erfüllen. Es wäre ziemlich sinnlos, wenn man nun auf dies alles wieder verzichten sollte. Gottseidank gibt es aber eine Lösung, die ich in diesem Beitrag beschreiben möchte.
In diesem Artikel
Was ist das Ziel?
Ziel der Aktion ist, dem Anwender unsere eigenen Makros zur Verfügung stellen zu können, aber zugleich fremde und potentiell bösartige Makros rauszuhalten. Gerade im Unternehmensumfeld sollte dieses Verfahren generell angewendet werden, denn man kann sich leider nicht immer auf die Anwender verlassen. Insbesondere Emotet ist sehr kreativ darin, den Anwender davon zu überzeugen, die Makroausführung zuzulassen. Da ist es besser, wenn der Administrator per Windows-Policy (in der deutschen Übersetzung “Gruppenrichtlinien”) entsprechende Einstellungen vorschreibt und gegen Veränderung sperrt. Doch wie unterscheiden wir gute und böse Makros voneinander?
Das Problem mit MS Access
Vorab sei noch darauf hingewiesen, dass das hier gesagte so ziemlich für alle Programme aus dem Umfeld von “Microsoft Office” gelten sollte. Zumindest habe ich in Word, Excel, Powerpoint und Visio stets das gleiche Verhalten festgestellt. Leider gibt es aktuell mindestens eine Ausnahme: In Access ist das beschriebene Verhalten in einer .accdb-Datenbank leider nicht mehr möglich. Ich kann zwar noch den alten Dialog “Extras –> Digitale Signatur” aufrufen, dort das Zertifikat auswählen und dann auf “OK” klicken, doch dann kommt diese Meldung:
Da die verwendete Datenbank weder unter Quellcodeverwaltung steht (jedenfalls nicht nach dem Verfahren, das Microsoft verstehen würde) und auch nicht schreibgeschützt ist, bleibt nur der dritte genannte Grund: In einer .accdb-Datei geht das nicht.
In einer .mdb-Datenbank konnte ich zwar eine Signatur erstellen, aber beim Schließen von Access wird mir immer mitgeteilt, dass diese wieder verworfen wurde. Die Meldung ist zwar eine andere, doch das Ergebnis ist das selbe: Das Zertifikat ist weg.
Es bleibt also nur der Weg, den Verpackungs- und Weitergabeassistent oder einen anderen Installer zu verwenden. Beide können digital signiert werden, aber diese Signatur bezieht sich nur auf das Setup selbst. Nach der Installation ist die Datenbank weiterhin ungeschützt. Das ist aus meiner Sicht deshalb besonders fatal, da Access-Datenbanken oft auch für die Zwischenspeicherung von Datenbankobjekten verwendet werden, also entweder von programmseitig vorgesehenen temporären Tabellen oder (seitens Access automatisch) betreffs dynamischer Abfragen. Aus diesem Grund installiere ich Access-Datenbankapplikationen oft in den Benutzerbereich (C:\Users\USERNAME\AppData\Local\Programs). Dort hat der Benutzer Schreibrechte, was obiges Verhalten unterstützt, leider aber auch die Infektion durch andere. Bei dem von mir gern verwendeten InnoSetup geht das übrigens sehr einfach über die Zeile DefaultDirName={userpf}\{#MyAppName}
in der [Setup]-Gruppe.
Fazit für Access: So geht es leider nicht.
Nun aber zum eigentlichen Thema. Ich gehe davon aus, dass wir in einer der genannten Applikationen VBA-Code hinzugefügt haben. Betrachten wir das Projekt zunächst aus Entwicklersicht.
Entwickler
Der Entwickler wird sich zunächst natürlich um seine Software kümmern. Sie soll funktionieren, möglichst keine Fehler mehr enthalten und vor allem den Anforderungen des Kunden gerecht werden. Damit ist er hoffentlich irgendwann fertig, nun geht es daran, das Programm beim Kunden/Anwender zu installieren. Wie auch immer dies passiert – manuell vor Ort, per Fernwartung oder durch ein Setup – danach liegt der VBA-Code in dem Dokument auf der Festplatte des Anwenders. Je nachdem was vereinbart wurde, ist der Code entweder passwortgeschützt oder nicht.
Gehen wir ferner davon aus, dass der Kunde nicht mutwillig im Code herumpfuscht, denn das dürfte oft für Probleme sorgen. Das Dumme ist nur: Unser VBA-Code zum Beispiel in einer Word-Vorlage ist erwünscht, VBA-Code in einer beliebigen anderen Word-Datei jedoch oft nicht. Für Word ist das nicht unterscheidbar. Je nach Einstellung führt Word den Code entweder aus oder nicht.
Hier kommt die digitale Signatur in’s Spiel. Der Entwickler hat sich von irgend einem Anbieter ein Zertifikat besorgt, mit dem er Code signieren kann (meins stammt z.B. von Comodo). Mit diesem Zertifikat kann der Entwickler seinen VBA-Code signieren. Das geschieht einfach im VB-Editor unter dem Menüpunkt “Extras –> Digitale Signatur”. Danach muss das Dokument gespeichert werden.
Falls nun noch Änderungen am VBA-Code notwendig sind, kann dies ohne Probleme gemacht werden. Solange dies auf dem Rechner und unter dem Account geschieht, wo der private Schlüssel des Zertifikats verfügbar ist, wird die Signatur automatisch aktualisiert. Wenn dies jedoch später auf dem Rechner des Anwender geschehen sollte, dann wird die Signatur verworfen.
Anwender oder Administrator
Der Anwender sollte auf seinem Rechner zunächst in die Einstellungen des betreffenden Programms gehen. Unter “Datei –> Optionen –> Trust Center” befindet sich eine Schaltfläche “Einstellungen für das Trust Center”. Dort wählen wir “Einstellungen für Makros” und finden dann diese Optionen vor:
Dabei sollten wir die Option “Alle Makros außer digital signierten deaktivieren” auswählen. Danach alles mit OK bestätigen und das Programm beenden. Nun kann die fragliche Datei geöffnet werden.
Allerdings zeigt zumindest Excel 2016 zunächst an, dass die Inhalte der Datei deaktiviert worden seien. Das Zertifikat allein scheint also nicht auszureichen. Doch immerhin bewirkt die obige Einstellung, dass bei einer Testdatei mit Makros ohne Zertifikat gar nichts passiert. Gut, aber noch nicht gut genug. Im Grunde ist das aber auch logisch: Nur weil eine Excel-Arbeitsmappe digital signiert ist, ist sie noch lange nicht vertrauenswürdig! Denn so ein Zertifikat könnte sich der Programmierer des Makrosvirus’ ja ebenfalls besorgen, und damit wäre nichts gewonnen.
Der richtige Zertifikatsspeicher
Also müssen wir noch einen weiteren Schritt gehen: Das öffentliche Zertifikat des Entwicklers muss noch in den Speicher der vertrauenswürdigen Herausgeber gelegt werden.
Und schon klappt’s: Die digital signierten Makros des vertrauenswürdigen Entwicklers werden ausgeführt, alle anderen Makros (egal ob die Signatur nicht vertrauenswürdig oder gar nicht vorhanden ist) werden stillschweigend ignoriert.
Vertrauenssache
Jetzt stellt sich nur noch die Frage, woher ich denn das öffentliche Zertifikat des Entwicklers bekomme. Im Grunde ist das ganz einfach, denn sobald der Anwender eine Datei mit einem digitalen Zertifikat des Entwicklers bekommen hat, hat er auch schon dessen Zertifikat. Die Datei muss also geöffnet werden, und während z.B. Excel die bekannte Sicherheitsmeldung anzeigt, öffnet der Anwender das Datei-Menü und klickt dort auf den Button “Inhalt aktivieren”. Aus dem ausklappenden Menü wird “Erweiterte Optionen ausgewählt, darin “Allen Dokumenten von diesem Herausgeber vertrauen” aktiviert und mit OK bestätigt.
Das muss natürlich nur einmal gemacht werden. Danach weiß Windows in Bezug auf den angemeldeten User, dass der Entwickler des Makros vertrauenswürdig ist. Dies gilt dann automatisch auch in Zukunft für alle weiteren VBA-Makros des Entwicklers, wenn sie mit dem selben Zertifikat signiert sind.
TL;DR
- Digitale Signatur bei Access 2016 nur für den Installer verfügbar, VBA-Code bleibt ungeschützt
- Digitale Signatur bei Excel (mindestens ab 2010) und anderen Office-Programmen für VBA möglich
- Makroeinstellung im Trustcenter auf “alle außer digital signierten deaktivieren” setzen
- Datei -> Inhalte aktivieren -> Erweiterte Einstellungen -> Allen Dokumenten von diesem Herausgeber vertrauen -> OK
2 Kommentare
Hallo, Herr Jüngling,
wenn ich Ihren Blog-Artikel richtig interpretiere, gibt es also speziell für Access keine adäquate Möglichkeit, VBA-Code bzw. Makros zu signieren?
Was empfehlen Sie, wenn meine Firma jedoch die Codesignierung von Access-Datenbanken zur Vorgabe macht?
Gruß, Daniel Schunk
Autor
Hallo Herr Schunk,
ja, das ist auch mein Wissensstand. Makros konnten in Access sowieso noch nie signiert werden, das VBA-Projekt hingegen schon (jedenfalls früher mal). Einzig der Installer kann eine Signatur bekommen, egal ob der Weitergabe-Assistent (“Verpacken und Signieren”) oder ein externes Programm wie z.B. InnoSetup verwendet wird. Das deckt sich z.B. mit dem, was mein Kollege Phil Stiefel herausgefunden hat (https://codekabinett.com/rdumps.php?Lang=2&targetDoc=signing-vba-code-access-accdb).
Eine Idee wäre, per signiertem Setup-Programm die Frontend-Datenbank mit Admin-Rechten in einen Bereich zu installieren, wo der User keinen schreibenden Zugriff hat. Bei Frontend-Backend-Trennung ist die Datenbearbeitung ja weiterhin möglich, Codeänderungen jedoch nicht. Dies müsste allerdings mit der aktuellen Applikation getestet werden, da ich nicht weiß, wie Access dann mit der Unmöglichkeit umgeht, temporäre Datenbankobjekte anzulegen und z.B. den Execution Plan der Abfragen zu aktualisieren.
Ich hoffe das hilft Ihnen weiter. Wenn Sie eine Lösung finden, wäre ich für einen Hinweis dankbar.
Grüße aus Kassel
Christoph Jüngling