Eine Zero-Day-Sicherheitsanfälligkeit (0-Day-Sicherheitsanfälligkeit) ist eine Computersoftware-Sicherheitsanfälligkeit, die während des Entwicklungsprozesses eingeführt und von den Entwicklern noch nicht entdeckt wurde. Zero-Day-Schwachstellen können von Hackern ausgenutzt werden, was sich auf die Reputation des Unternehmens auswirkt. Entwickler sollten versuchen, die Anzahl der Fehler zu minimieren, die zu solchen Schwachstellen führen. PVS-Studio, ein statischer Codeanalysator für C-, C ++ -, C # - und Java-Code, ist eines der Tools, mit denen Sicherheitsprobleme erkannt werden können.
Zero-Day-Schwachstellen
Eine
Zero-Day-Sicherheitsanfälligkeit (auch als
0-Day- Sicherheitsanfälligkeit bezeichnet) ist eine Computer-Software-Sicherheitsanfälligkeit, die für diejenigen, die an der Abschwächung der Sicherheitsanfälligkeit interessiert sein sollten (einschließlich des Herstellers der Zielsoftware), unbekannt ist oder von diesen nicht behoben wird. Bis die Sicherheitsanfälligkeit behoben ist, können Hacker sie ausnutzen, um Computerprogramme, Daten, zusätzliche Computer oder ein Netzwerk nachteilig zu beeinflussen. Der Begriff bedeutet, dass die Entwickler keinen einzigen Tag haben, um den Fehler zu beheben, da noch niemand davon weiß. Einige der bekannten Anbieter und Softwareprodukte wie
Adobe ,
Windows ,
Tor-Browser und viele andere waren in der Vergangenheit von Zero-Day-Sicherheitslücken betroffen.
Einige hatten das Glück, eine Sicherheitslücke gefunden und gemeldet zu haben, die nicht ausgenutzt werden sollte. Der Fall von
MacOS ist ein solches Beispiel. In einigen anderen Fällen haben die Entwickler selbst einen Patch erstellt, mit dem sie zwar neue Funktionen hinzugefügt, aber auch eine Zero-Day-Sicherheitsanfälligkeit behoben haben, ohne es zu wissen.
Andere hatten weniger Glück. Beispielsweise musste Google Chrome vor nicht allzu langer Zeit dringend eine
Sicherheitsanfälligkeit beheben, die ausgenutzt werden konnte, um beliebigen Code aus der Ferne auszuführen.
Das Problem ist, dass Sie keinen 100% igen Schutz vor diesen Sicherheitslücken garantieren können, da Sie eine Bedrohung, die Sie nicht einmal kennen, nicht effektiv bekämpfen können. Es gibt jedoch Möglichkeiten, die Wahrscheinlichkeit des Auftretens solcher Fehler in Ihrem Programm zu verringern. Dies wird das Thema dieses Artikels sein. Wir sollten uns jedoch zunächst mit einer Theorie befassen.
Statische Analyse
Die statische Analyse ist eine Methode zum Überprüfen des Quellcodes eines Softwareprogramms mithilfe eines Analysegeräts, ohne das Programm selbst auszuführen, und kann als automatisierte Codeüberprüfung angesehen werden. Manchmal kann eine statische Analyse viel effektiver sein als eine Peer-Code-Überprüfung, sie kann sie jedoch nicht vollständig ersetzen. Ich habe versucht, die Vor- und Nachteile der Codeüberprüfung und der statischen Analyse in der folgenden Tabelle zusammenzufassen:
CVE und CWE
Common Vulnerabilities and Exposures (CVE) ist eine Datenbank mit Informationen zu Sicherheitslücken und -risiken. Der ursprüngliche Zweck bestand darin, bekannte Softwarefehler in einer zusammenhängenden Liste zusammenzufassen. In der Vergangenheit verwendeten die meisten Tools für die Informationssicherheit ihre eigenen Datenbanken und Namen für solche Defekte, und es sollte Ordnung in dieses Chaos gebracht und die Kompatibilität zwischen verschiedenen Tools hergestellt werden, für die die MITRE Corporation 1999 CVE entwickelte. CVE stellte sich jedoch heraus nicht ausreichen, um die Codesicherheit abzuschätzen. Es wurde ein anderes System mit einer genaueren Klassifizierung und detaillierteren Beschreibungen benötigt. So entstand die Common Weakness Enumeration (CWE). Wenn ein Fehler in der CWE aufgeführt ist, kann dies eine ausnutzbare Sicherheitsanfälligkeit verursachen und auch zur CVE-Liste hinzugefügt werden. Das folgende Euler-Diagramm zeigt die Beziehungen zwischen den Standards.
Einige statische Analysatoren können Sie informieren, wenn Ihr Projekt beispielsweise eine Bibliothek mit einer Sicherheitsanfälligkeit verwendet. Wenn Sie dies wissen, können Sie eine neuere Version der Bibliothek mit dem behobenen Fehler herunterladen, um Ihren Code weniger anfällig für Sicherheitsbedrohungen zu machen, die durch einen Fehler im Code eines anderen Benutzers verursacht werden.
Da die Entwicklergemeinde die CVE- und CWE-Standards anerkannte, wurden sie auch von vielen Tools für die Informationssicherheit, einschließlich statischer Analysegeräte, unterstützt. Analysegeräte, die diese Klassifizierungen unterstützen, können als SAST-Lösungen angesehen werden. Mit SAST (Static Application Security Testing) können Entwickler Schwachstellen im Quellcode von Programmen in den frühesten Phasen des Softwareentwicklungszyklus erkennen.
SAST ist eine weitere Methode, um die Wahrscheinlichkeit von Zero-Day-Schwachstellen in Ihrem Projekt zu minimieren. Ein Analysegerät, das den CWE-Standard unterstützt, kann Ihnen mitteilen, wo eine potenzielle Sicherheitsanfälligkeit lauert, sodass Sie sie beheben können, um die Zuverlässigkeit Ihrer Anwendung zu erhöhen und die Wahrscheinlichkeit einer 0-Tage-Bedrohung zu verringern.
Es gibt eine Vielzahl von SAST-Tools. Ich werde den
PVS-Studio Analyzer als Beispiel nehmen, um zu zeigen, wie diese Tools bei der Bekämpfung von Schwachstellen helfen können. Warnungen dieses Analysegeräts sind als CWE klassifiziert. Einige Beispiele sind unten angegeben.
PVS-Studio-Diagnosemeldung:
CWE-561 : Dead Code (
V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
Dieser Code enthält einen Tippfehler: Die Bedingungen beider
if- Anweisungen überprüfen dieselbe Variable. Die Meldung, die der Ausnahme beigefügt ist, schlägt vor, dass die zweite Bedingung stattdessen die Variable
outputPath überprüfen sollte. Dieser Fehler hat einen Teil des Codes unerreichbar gemacht.
Solche Bugs mögen harmlos erscheinen, aber dieser Eindruck ist falsch. Werfen wir einen Blick auf einen anderen trivialen und scheinbar harmlosen Fehler, der mit einer doppelten
goto- Anweisung zu tun hat.
Dieser Fehler verursachte einmal eine Sicherheitslücke in iOS.
Die
CVE-2014-1266- Sicherheitsanfälligkeit: Die SSLVerifySignedServerKeyExchange-Funktion in libsecurity_ssl / lib / sslKeyExchange.c in der Funktion "Sicherer Transport" in der Datensicherheitskomponente in Apple iOS 6.x vor 6.1.6 und 7.x vor 7.0.6, Apple TV 6.x vor 6.0.2 und Apple OS X 10.9.x vor 10.9.2 überprüft die Signatur in einer TLS Server Key Exchange-Nachricht nicht, wodurch Man-in-the-Middle-Angreifer SSL-Server mithilfe einer beliebigen Methode fälschen können privater Schlüssel für den Signierschritt oder Weglassen des Signierschritts.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
Wie im ersten Beispiel führte das Duplikat
goto hier zu nicht erreichbarem Code: Unabhängig von den Bedingungen der
if- Anweisungen würde die zweite
goto- Anweisung trotzdem ausgeführt. Infolgedessen würde die Signatur nicht überprüft, die Funktion würde 0 zurückgeben, was bedeutet, dass die Signatur in Ordnung war, und das Programm würde einen Schlüssel vom Server erhalten, selbst wenn die Signaturprüfung fehlschlug. Mit diesem Schlüssel werden die übertragenen Daten verschlüsselt.
Dieser triviale Fehler hatte drastische Auswirkungen. Der Vorfall zeigt, warum es sinnlos ist zu spekulieren, ob dieser oder jener CWE-Defekt gefährlich ist oder nicht - Sie müssen ihn nur aus Sicherheitsgründen beheben.
Übrigens, PVS-Studio hätte diesen Fehler leicht finden können, indem es ihn mit zwei CWE-Warnungen gleichzeitig meldete:
Hier ist ein weiteres Beispiel. Vor langer Zeit, im Jahr 2012, wurde in MySQL eine Sicherheitslücke entdeckt, die von einem Angreifer ausgenutzt werden könnte, um in die MySQL-Datenbank zu gelangen. Unten sehen Sie das fehlerhafte Codefragment, in dem die Sicherheitsanfälligkeit aufgetreten ist.
Die
CVE-2012-2122- Sicherheitsanfälligkeit: sql / password.c in Oracle MySQL 5.1.x vor 5.1.63, 5.5.x vor 5.5.24 und 5.6.x vor 5.6.6 und MariaDB 5.1.x vor 5.1.62 , 5.2.x vor 5.2.12, 5.3.x vor 5.3.6 und 5.5.x vor 5.5.23 ermöglichen es Angreifern, in bestimmten Umgebungen mit bestimmten Implementierungen der memcmp-Funktion die Authentifizierung zu umgehen, indem sie sich wiederholt bei der authentifizieren dasselbe falsche Kennwort, was schließlich dazu führt, dass ein Token-Vergleich aufgrund eines nicht ordnungsgemäß überprüften Rückgabewerts erfolgreich ist.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
Die Funktion
memcmp gibt einen Wert vom Typ
int zurück , während die Funktion
check_scramble einen Wert vom Typ
my_bool zurückgibt , der in Wirklichkeit
char ist . Der
int- Wert wird implizit in
char umgewandelt , wobei die höchstwertigen Bits abgeschnitten werden. Dies führte dazu, dass ungefähr 1 von 256 Versuchen, sich mit einem beliebigen Kennwort anzumelden, für einen bekannten Benutzernamen erfolgreich war.
Auch dieser CWE-Defekt hätte bereits in der Codierungsphase neutralisiert und verhindert werden können, dass er viel früher zu einer CVE-Sicherheitslücke wird. PVS-Studio meldet dies beispielsweise als
CWE-197 (
V642 ): Numeric Truncation Error.
Weitere Informationen zum Thema finden Sie im Artikel "
Wie kann PVS-Studio beim Erkennen von Sicherheitslücken helfen? ".
Fazit
Sie können nicht 100% sicher sein, dass Ihr Programm vor 0-tägigen Sicherheitslücken geschützt ist. Sie können jedoch die Wahrscheinlichkeit ihres Auftretens verringern. Dies geschieht mit speziellen SAST-Tools wie PVS-Studio. Stellen Sie sicher, dass Ihr Projekt Fehler enthält, die als CWE-Probleme eingestuft sind. Auch wenn nur wenige CWE-Fehler auf der CVE-Liste landen, hilft die Behebung, Ihr Programm vor vielen potenziellen Bedrohungen zu schützen.
Referenzen
- Laden Sie PVS-Studio herunter und testen Sie es
- Technologien, die im PVS-Studio Code Analyzer zum Auffinden von Fehlern und potenziellen Schwachstellen verwendet werden
- Klassifizierung von PVS-Studio-Warnungen nach der Common Weakness Enumeration (CWE)
- Klassifizierung von PVS-Studio-Warnhinweisen nach dem SEI CERT Coding Standard