Freigeben über

Test der Windows-Sicherheitsfeatures

  • Artikel

Testet die App, um sicherzustellen, dass sie die Windows-Sicherheitsfeatures und starken Zugriffssteuerungslisten (ACLs) verwendet.

Hintergrund

Durch Ändern der standardmäßigen Windows-Sicherheitsvorkehrungen können Kunden einem erhöhten Risiko ausgesetzt werden.

Testdetails

Testet die Sicherheit der App, indem der BinScope Binary Analyzer und der Attack Surface Analyzer ausgeführt werden.

Maßnahmen

Behandeln und beheben Sie das in den Tests identifizierte Problem. Erstellen Sie die App neu, und wiederholen Sie den Test.

BinScope Binary Analyzer-Tests

Die BinScope Binary Analyzer-Tests untersuchen die Binärdateien der App auf Code- und Erstellungsmerkmale, die die App weniger anfällig für Angriffe oder für die Verwendung als Angriffsmittel machen.

Die BinScope Binary Analyzer-Tests prüfen, ob die sicherheitsrelevanten Features korrekt verwendet werden:

  • AllowPartiallyTrustedCallersAttribute
  • /SafeSEH-Ausnahmebehandlungsschutz
  • Datenausführungsverhinderung
  • Zufallsgestaltung des Adressraumlayouts
  • Lesen/Schreiben des freigegebenen PE-Abschnitts
  • AppContainerCheck
  • ExecutableImportsCheck
  • WXCheck

AllowPartiallyTrustedCallersAttribute

Fehlermeldung des Windows-Zertifizierungskits für Apps: APTCACheck Test failed (Fehler beim APTCACheck-Test.)

Das AllowPartiallyTrustedCallersAttribute-Attribut (kurz: APTCA-Attribut) ermöglicht den Zugriff auf vollständig vertrauenswürdigen Code aus teilweise vertrauenswürdigem Code in signierten Assemblys. Wenn Sie das APTCA-Attribut auf eine Assembly anwenden, können teilweise vertrauenswürdige Aufrufer diese Assembly aufrufen, solange die Assembly besteht. Dies kann ein Sicherheitsrisiko darstellen.

Was ist zu tun, wenn die App den Test nicht besteht?

Verwenden Sie das APTCA-Attribut nur dann für Assemblys mit starkem Namen, falls dies für das Projekt erforderlich ist und die Risiken bekannt sind. Falls das Attribut erforderlich ist, stellen Sie sicher, dass alle APIs durch geeignete Sicherheitsanforderungen für den Codezugriff geschützt sind. APTCA hat keine Auswirkung, wenn die Assembly Teil einer Windows Store-App ist.

Anmerkungen

Dieser Test wird nur für verwalteten Code (C#, .NET usw.) ausgeführt.

/SafeSEH-Ausnahmebehandlungsschutz

Fehlermeldung des Windows-Zertifizierungskits für Apps: SafeSEHCheck Test failed (Fehler beim SafeSEHCheck -Test.)

Ein Ausnahmehandler wird ausgeführt, wenn in der App eine Ausnahmebedingung auftritt – beispielsweise bei einem Fehler aufgrund einer Division durch Null. Da die Adresse des Ausnahmehandlers beim Aufrufen einer Funktion im Stapel gespeichert wird, besteht das Risiko eines Pufferüberlaufangriffs, sollte Schadsoftware den Stapel überschreiben.

Was ist zu tun, wenn die App den Test nicht besteht?

Aktivieren Sie beim Erstellen der App die Option "/SAFESEH" im Linker-Befehl. Diese Option ist in den Veröffentlichungskonfigurationen von Visual Studio standardmäßig aktiviert. Vergewissern Sie sich, dass diese Option in den Erstellungsanweisungen für alle alle ausführbaren Module Ihrer App aktiviert ist.

Anmerkungen

Für 64-Bit-Binärdateien oder für Binärdateien für den ARM-Chipsatz wird dieser Test nicht ausgeführt, da hier keine Ausnahmehandleradressen im Stapel gespeichert werden.

Datenausführungsverhinderung

Fehlermeldung des Windows-Zertifizierungskits für Apps: NXCheck Test failed (Fehler beim NXCheck-Test.)

Dieser Test stellt sicher, dass die App keinen Code ausführt, der in einem Datensegment gespeichert ist.

Was ist zu tun, wenn die App den Test nicht besteht?

Aktivieren Sie beim Erstellen der App die Option "/NXCOMPAT" im Linker-Befehl. Diese Option ist in Linker-Versionen mit Unterstützung der Datenausführungsverhinderung (Data Execution Prevention, DEP) standardmäßig aktiviert.

Anmerkungen

Wir empfehlen, Apps auf einer DEP-fähigen CPU zu testen und alle DEP-bedingten Fehler zu beheben.

Zufallsgestaltung des Adressraumlayouts

Fehlermeldung des Windows-Zertifizierungskits für Apps: DBCheck Test failed (Fehler beim DBCheck-Test.)

Die Zufallsgestaltung des Adressraumlayouts (Address Space Layout Randomization, ASLR) lädt ausführbare Bilder in unvorhersehbare Speicherbereiche. Dadurch wird eine größere Hürde für Schadsoftware geschaffen, die erwartet, dass ein Programm an einer bestimmten virtuellen Adresse geladen wird. Ihre App und alle von der App verwendeten Komponenten müssen über ASLR-Unterstützung verfügen.

Was ist zu tun, wenn die App den Test nicht besteht?

Aktivieren Sie beim Erstellen der App die Option "/DYNAMICBASE" im Linker-Befehl. Vergewissern Sie sich, dass auch alle von der App verwendeten Module diese Linker-Option verwenden.

Anmerkungen

ASLR hat in der Regel keine Auswirkungen auf die Leistung. In einigen Szenarios ist auf 32-Bit-Systemen aber eine geringfügige Leistungsverbesserung zu beobachten. Es ist möglich, dass sich die Leistung bei einem stark belasteten System verschlechtert, bei dem viele Bilder an vielen unterschiedlichen Speicherbereichen geladen sind.

Dieser Test wird nur für Apps ausgeführt, die in nicht verwaltetem Code geschrieben wurden, z. B. mit C# oder .NET Framework.

Lesen/Schreiben des freigegebenen PE-Abschnitts

Fehlermeldung des Zertifizierungskits für Windows-Apps: Fehler beim SharedSectionsCheck-Test.

Binärdateien mit beschreibbaren Abschnitten, die als freigegeben gekennzeichnet sind, stellen eine Sicherheitsbedrohung dar. Erstellen Sie keine Apps mit freigegebenen beschreibbaren Abschnitten, wenn dies nicht notwendig ist. Verwenden Sie CreateFileMapping oder MapViewOfFile, um ein freigegebenes Speicherobjekt zu erstellen, das ordnungsgemäß gesichert ist.

Was ist zu tun, wenn die App den Test nicht besteht?

Entfernen Sie sämtliche freigegebene Abschnitte aus der App, und erstellen Sie freigegebene Speicherobjekte, indem Sie CreateFileMapping oder MapViewOfFile mit den passenden Sicherheitsattributen aufrufen und die App dann neu erstellen.

Anmerkungen

Dieser Test wird nur für Apps ausgeführt, die in nicht verwalteten Sprachen geschrieben wurden, z. B. mit C oder C++.

AppContainerCheck

Fehlermeldung des Zertifizierungskits für Windows-Apps: Fehler beim AppContainerCheck-Test.

Der AppContainerCheck-Test prüft, ob das appcontainer-Bit im PE-Header einer ausführbaren Binärdatei gesetzt ist. Für Windows Store-Apps muss das appcontainer-Bit für alle EXE-Dateien und nicht verwalteten DLLs gesetzt sein, damit diese korrekt ausgeführt werden.

Was ist zu tun, wenn die App den Test nicht besteht?

Wenn der Test für eine systemeigene ausführbare Datei nicht erfolgreich ist, stellen Sie sicher, dass Sie zum Erstellen der Datei den aktuellen Compiler und Linker und für den Linker das Kennzeichen /appcontainer verwenden.

Wenn der Test für eine verwaltete ausführbare Datei nicht erfolgreich ist, stellen Sie sicher, dass Sie zum Erstellen der Windows Store-App den aktuellen Compiler und Linker wie beispielsweise Microsoft Visual Studio verwenden.

Anmerkungen

Dieser Test wird für alle EXE-Dateien und nicht verwalteten DLLs ausgeführt.

ExecutableImportsCheck

Fehlermeldung des Zertifizierungskits für Windows-Apps: Fehler beim ExecutableImportsCheck-Test.

Ein portierbares ausführbares Image (Portable Executable, PE) besteht diesen Test nicht, wenn es in einen Abschnitt mit ausführbaren Code eingefügt wurde. Dies kann auftreten, wenn Sie das Zusammenführen des Abschnitts ".rdata" ermöglicht haben, indem Sie das Kennzeichen /merge des Visual C++-Linkers auf /merge:.rdata=.text festgelegt haben.

Was ist zu tun, wenn die App den Test nicht besteht?

Führen Sie die Importtabelle nicht in einem Abschnitt mit ausführbarem Code zusammen. Stellen Sie sicher, dass das /merge-Kennzeichen des Visual C++-Linkers nicht so eingestellt ist, dass der Abschnitt ".rdata" in einem Codeabschnitt zusammengeführt wird.

Anmerkungen

Dieser Test wird für den gesamten Binärcode ausgeführt, außer für ausschließlich verwaltete Assemblys.

WXCheck

Fehlermeldung des Windows-Zertifizierungskits für Apps: Fehler beim WXCheck-Test.

Mit dieser Überprüfung können Sie sicherstellen, dass eine Binärdatei keine Seiten enthält, die als schreibbar und ausführbar gekennzeichnet sind. Dies kann vorkommen, wenn die Binärdatei schreibbar und ausführbar oder wenn ihr SectionAlignment kleiner als PAGE_SIZE ist.

Was ist zu tun, wenn die App den Test nicht besteht?

Stellen Sie sicher, dass die Binärdatei keinen schreibbaren oder ausführbaren Abschnitt enthält und dass der SectionAlignment-Wert der Binärdatei mindestens seiner PAGE_SIZE entspricht.

Anmerkungen

Dieser Test wird für alle EXE-Dateien und systemeigenen, nicht verwalteten DLLs ausgeführt.

Eine ausführbare Datei kann einen schreibbaren und ausführbaren Abschnitt enthalten, wenn bei ihrer Erstellung "Bearbeiten und Fortfahren" aktiviert wurden (/ZI). Bei Deaktivierung von "Bearbeiten und Fortfahren" ist der ungültige Abschnitt nicht mehr enthalten.

PAGE_SIZE ist der Standardwert von SectionAlignment für ausführbare Dateien.

Im Windows Store unzulässige Dateien

Fehlermeldung des Windows-Zertifizierungskits für Apps: Banned File Check test failed (Fehler beim Test auf unzulässige Dateien).

In Windows Store-Apps dürfen bestimmte Dateien nicht enthalten sein. Für diese Dateien sind neuere Dateien verfügbar, die wichtige Verbesserungen in Bezug auf die Sicherheit, Zuverlässigkeit oder andere Bereiche umfassen. Microsoft blockiert diese Dateien im Windows-Zertifizierungskit für Apps, um sicherzustellen, dass von allen Entwicklern aktuelle Versionen verwendet werden.

Beim Test auf unzulässige Dateien im Windows-Zertifizierungskit für Apps wird derzeit eine Überprüfung auf folgende Dateien durchgeführt:

  • Bing.Maps.JavaScript\js\veapicore.js

    Für diese Überprüfung tritt normalerweise ein Fehler auf, wenn von einer App anstelle der aktuellen offiziellen Version eine Release Preview-Version der Datei verwendet wird. Verwenden Sie zum Beheben dieses Fehlers die aktuelle Version des Bing Maps SDK für Windows Store-Apps.

Attack Surface Analyzer

Die Attack Surface Analyzer-Tests untersuchen Änderungen am Systemstatus, Laufzeitparametern und sicherungsfähigen Objekten, die nach dem Installieren und Ausführen einer App auftreten, um spezielle Sicherheitsschwachstellen aufzuspüren. Das Korrigieren dieser Schwachstellen hat keine Leistungseinbußen zur Folge. Wenn Ihre App eine dieser Sicherheitsschwachstellen aufweist, können wir sie nicht für den Windows Store qualifizieren.

Die Attack Surface Analyzer-Tests gelten für alle Programmiersprachen und halten nach den folgenden Sicherheitsschwachstellen in einer App Ausschau.

  • Sichere ausführbare Dateien, die schwache ACLs haben
  • Sichere Verzeichnisse, die Objekte enthalten und schwache ACLs haben
  • Sichere Registrierungsschlüssel mit schwachen ACLs
  • Dienste, die Benutzerkonten ohne Administratorrechte Zugriff gewähren und anfällig für Manipulationen sind
  • Dienste mit schnellen Neustarts oder Dienste, die innerhalb von 24 Stunden mehr als zweimal neu gestartet werden

Sichere ausführbare Dateien, die schwache ACLs haben

Dieser Test sucht nach sicheren ausführbaren Dateien, die schwache Zugriffssteuerungslisten (ACLs) haben. Hierzu werden die ACLs für jede neue oder geänderte ausführbare Datei geprüft, die ein Administrator besitzt. Die ACLs für diese Dateien müssen verhindern, dass die Dateien von Benutzern ohne Administratorrechte geändert werden. Attack Surface Analyzer testet ausführbare Dateien (EXE-Dateien) sowie Dateien, die ausführbaren Inhalt enthalten können, z. B. Skripts und Hilfedateien.

Was ist zu tun, wenn die App den Test nicht besteht?

Wenn diese Schwachstelle in Ihrer App erkannt wird, prüfen Sie die folgenden Rechte für alle Konten von Nichtadministratoren, und entfernen Sie sie: GENERIC_ALL, GENERIC_WRITE, WRITE_OWNER, WRITE_DAC, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA oder FILE_WRITE_DATA, DELETE

Anmerkungen

Bei schwachen ACLs können Nichtadministratoren eine ausführbare Datei ändern. Wenn eine ausführbare Datei geändert wurde, funktioniert sie ggf. nicht wie erwartet. Sind die Zugriffsrechte nicht korrekt konfiguriert, könnte ein Angreifer den Inhalt der Datei ersetzen oder ändern und in böswillig Schaden anrichten.

Sichere Verzeichnisse, die Objekte enthalten und schwache ACLs haben

Dieser Test sucht nach sicheren Verzeichnissen, die Objekte enthalten und schwache ACLs haben, indem die ACLs für neue oder geänderte Ordnerhierarchien geprüft werden. Hierarchische ACLs (oder vererbte ACLs) steuern den Zugriff auf alle Dateien und Ordner in einem Ordner. Die ACLs für diese Ordner müssen verhindern, dass die Ordner oder ihre Inhalte von Benutzern ohne Administratorrechte geändert werden.

Anstatt jede ausführbare Datei und jeden Unterordner zu kennzeichnen, der nicht ordnungsgemäß gesichert ist, identifiziert dieser Test den höchsten Ordner in einer Hierarchie, der schwache ACLs aufweist.

Was ist zu tun, wenn die App den Test nicht besteht?

Wenn diese Schwachstelle in Ihrer App erkannt wird, prüfen Sie für das vom Test identifizierte Verzeichnis die folgenden Rechte für alle Konten von Nichtadministratoren, und entfernen Sie sie: GENERIC_ALL, GENERIC_WRITE, WRITE_OWNER, WRITE_DAC, FILE_ADD_FILE, FILE_ADD_SUBDIRECTORY, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, FILE_WRITE_DATA, FILE_DELETE_CHILD und DELETE. Dies kann das Ändern des Inherited-Kennzeichens für die ACL des Stammverzeichnisses umfassen.

Nachdem Sie die Rechte für das Stammverzeichnis korrigiert haben, müssen Sie die Rechte vielleicht auch für einzelne ausführbare Dateien korrigieren, so wie unter Sichere ausführbare Dateien, die schwache ACLs haben beschrieben.

Anmerkungen

Dieser Test identifiziert eine Hierarchie von Verzeichnissen und dazugehörigen Dateien, die alle schwache ACLs haben und dadurch Nichtadministratoren unangemessene Rechte gewähren. Diese Hierarchie kann durch falsch vererbte Rechte entstanden sein. Sehen sie sich also zuerst die vererbten Rechte an, bevor Sie die Rechte in den untergeordneten Verzeichnissen und Dateien ändern.

Sichere Registrierungsschlüssel mit schwachen ACLs

Dieser Test sucht nach sicheren Registrierungsschlüsseln, die schwache Zugriffssteuerungslisten (ACLs) haben. Hierzu werden die ACLs für neue oder geänderte Registrierungsschlüssel in der Registrierungsstruktur Lokaler Computer (HKLM) geprüft. Nur Administratoren sollten Schreibzugriff auf die Registrierungsstruktur "Lokale Computer" haben.

Was ist zu tun, wenn die App den Test nicht besteht?

Entfernen Sie die folgenden Rechte für das im Test identifizierte Objekt für alle Benutzerkonten ohne Administratorrechte: GENERIC_ALL, GENERIC_WRITE, WRITE_OWNER, WRITE_DAC, KEY_SET_VALUE, KEY_CREATE_SUBKEY und DELETE.

Anmerkungen

Mit den Registrierungswerten in diesem Abschnitt kann festgestellt werden, wo sich die ausführbaren Dateien (z. B. EXE- und DLL-Dateien) befinden. Apps verwenden die Registrierungsschlüssel in der Registrierungsstruktur Lokaler Computer auch zum Speichern und Lesen des Pfads einer ausführbaren Datei. Wenn ein Angreifer diesen Schlüssel ändert, indem er z. B. den Wert des Pfads einer nicht vertrauenswürdigen ausführbaren Datei ändert, könnte eine App die falsche Datei ausführen.

Wenn ein Registrierungsschlüssel scheinbar auf eine ausführbare Datei verweist, prüft dieser Test die ACLs des Schlüssels, um festzustellen, ob der Registrierungsschlüssel einem Benutzerkonto ohne Administratorrechte unangemessene Rechte einräumt.

Dienste, die Benutzerkonten ohne Administratorrechte Zugriff gewähren und anfällig für Manipulationen sind

Dieser Test sucht nach neuen oder geänderten Diensten, die Benutzerkonten ohne Administratorrechten Zugriff gewähren. Hierzu werden die ACLs dieser Dienste geprüft. Neue Dienste dürfen keine schwachen ACLs für den Binärpfad, die Host-DLL, die Registrierungsschlüssel oder den Dienst selbst haben, da hierdurch einem Benutzer ohne Administratorrechte erlaubt werden könnte, die Ausführungsart des Diensts zu ändern.

Was ist zu tun, wenn die App den Test nicht besteht?

Korrigieren Sie die einzelnen Dateien, so wie in Sichere ausführbare Dateien, die schwache ACLs haben beschrieben.

Anmerkungen

Den Diensten sind sowohl allgemeine als auch dienstspezifische Rechte zugeordnet. Dieser Test sucht nach unangemessenen Rechten, die Benutzerkonten ohne Administratorrechten zugeordnet sind. Wenn die Rechte nicht gesichert sind, könnte ein Angreifer den Dienst umleiten, um so beim Start des Diensts eine nicht vertrauenswürdige Datei auszuführen.

Ein Angreifer könnte beispielsweise ChangeServiceConfig aufrufen, um den Pfad der ausführbaren Datei des Diensts zu ändern.

Dienste mit schnellen Neustarts oder Dienste, die innerhalb von 24 Stunden mehr als zweimal neu gestartet werden

Dieser Test sucht nach Diensten, die häufig neu gestartet werden, indem die Dienstkonfiguration geprüft wird. Der Dienst darf innerhalb eines Zeitraums von 24 Stunden nicht mehr als zweimal neu gestartet werden.

Was ist zu tun, wenn die App den Test nicht besteht?

Ändern Sie den Zurücksetzungszeitraum (Reset Period) des Diensts, damit der Dienst innerhalb von 24 Stunden nicht mehr als zweimal neu gestartet wird.

Anmerkungen

Dieser Test sucht nach einer Schwachstelle in Bezug auf die Zufallsgestaltung des Adressraumlayouts (Address Space Layout Randomization, ASLR). ASLR ist ein Feature, das ausführbaren Code in zufällige Speicherbereiche lädt. Dies erschwert das Erstellen von zuverlässigen Exploit-Sicherheitslücken. Wenn ein Angreifer in der Lage ist, einen Dienst wiederholt neu zu starten, kann er mit einem Brute-Force-Angriff ausführbaren Code in alle möglichen Bereiche laden und das ASLR-Feature bezwingen.

Dieser Test prüft die lpsaActions-Elemente der Service Failure Actions-Struktur für die SC_ACTION_REBOOT- und SC_ACTION_RESTART-Werte. Diese Werte können durch Aufruf von ChangeServiceConfig2 konfiguriert werden.

Der Test stellt fest, ob mehr als zwei Aktionen vorhanden sind, ob deren Verzögerungswerte kleiner als 24 Stunden sind und ob der Zeitraum zum Zurücksetzen des Servers kürzer als 24 Stunden ist.