Zero Day Threat ist ein Begriff für Sicherheitslücken in der Entwicklung, die noch nicht entdeckt wurden. Solche Schwachstellen können von Cyberkriminellen ausgenutzt werden, was sich letztendlich auf die Reputation des Unternehmens auswirkt. Die Entwickler stehen vor der Aufgabe, die Anzahl der Fehler im Code zu minimieren, die eine solche Sicherheitsanfälligkeit verursachen können. Eines der Tools zum Erkennen von Sicherheitslücken ist der statische Code-Analyzer von PVS-Studio für C, C ++, C # und Java.
Zero Day Bedrohung
Zero-Day-Bedrohung ist ein Begriff, der Lücken und Schwachstellen identifiziert, die von Entwicklern zugelassen, aber noch nicht entdeckt wurden. Solange die Sicherheitsanfälligkeit nicht behoben wurde, kann sie verwendet werden, um auf Netzwerke zuzugreifen, einen Computer fernzusteuern, Daten zu manipulieren usw. Dieser Begriff hat sich durchgesetzt, da die Entwickler keinen Tag Zeit haben, den Fehler zu beheben, da noch niemand davon weiß. Zu gegebener Zeit litten so große Unternehmen und Software wie
Adobe ,
Windows ,
Tor Browser und viele andere unter solchen Schwachstellen.
Einige Organisationen hatten Glück, ihre Verwundbarkeit wurde von Personen festgestellt, die sie nicht nutzen wollten, und sie gaben lediglich Informationen zu dem Problem. Zum Beispiel war dies mit
MacOS . Oder es gab ein Update, das neben neuen Funktionen auch versehentlich die Zero-Day-Bedrohung behoben hat.
Es gab jedoch auch andere Situationen. Zum Beispiel musste Google Chrome einmal dringend eine
Sicherheitsanfälligkeit beheben, die es einem Angreifer ermöglichte, beliebigen Code auf dem Gerät eines Opfers remote auszuführen.
Das Problem bei dieser Bedrohung ist, dass es unmöglich ist, sich zu 100% dagegen zu verteidigen, da es schwierig ist, sich gegen das zu verteidigen, was Sie noch nicht wissen. Es gibt jedoch Möglichkeiten, die Wahrscheinlichkeit einer solchen Bedrohung in Ihrem Projekt zu verringern, und wir werden sie später erörtern, beginnen jedoch mit einer kleinen Theorie.
Statische Analyse
Bei der statischen Code-Analyse wird der Programmcode vom Analysegerät überprüft, ohne das Programm selbst zu starten. Die statische Analyse kann als automatisierter Codeüberprüfungsprozess betrachtet werden. In einigen Fällen ist die Wirksamkeit der statischen Analyse der Codeüberprüfung überlegen, sie kann jedoch nicht als vollständige Alternative zur Codeüberprüfung durch mehrere Programmierer angesehen werden. Im Folgenden habe ich versucht, kurz die Vor- und Nachteile der Codeüberprüfung und der statischen Codeanalyse im Verhältnis zueinander zu skizzieren.
CVE und CWE
Common Vulnerabilities and Exposures (CVE) ist eine Datenbank mit Softwarefehlern, die von Cyberkriminellen verwendet werden können. CVE wurde erstellt, um bekannte Softwarefehler zu optimieren. Die meisten Tools für die Informationssicherheit verwendeten ihre eigenen Datenbanken und Namen. Um dieses Chaos zu beseitigen und die Kompatibilität mit verschiedenen Tools zu verbessern, erstellte MITRE 1999 CVE. CVE reichte jedoch nicht aus, um die Codesicherheit zu bewerten. Dies erfordert etwas Präziseres, mit einer detaillierten Beschreibung der Probleme und weniger grob als sie. Daher wurde die CWE-Basis (Common Weakness Enumeration) erstellt, die diese Anforderungen erfüllt. Wenn sich der Fehler in der CWE-Liste befindet, kann dies zu einer Sicherheitsanfälligkeit führen, die vom Angreifer ausgenutzt werden kann und in die CVE-Liste aufgenommen wird. Der Übersichtlichkeit halber können Sie das folgende Euler-Diagramm betrachten.
Einige statische Analysatoren können dem Entwickler mitteilen, dass das Projekt beispielsweise die Bibliothek verwendet, in der sich die Sicherheitsanfälligkeit befindet. Auf diese Weise können Sie eine neuere Version der Bibliothek auswählen, in der die Sicherheitsanfälligkeit bereits behoben wurde, und die Wahrscheinlichkeit von Problemen mit Bedrohungen verringern, die durch den Code einer anderen Person verursacht werden.
Mit dem Aufkommen der Entwicklung von CVE- und CWE-Listen haben sich viele Tools für die Informationssicherheit um ihre Unterstützung gekümmert, einschließlich statischer Analysegeräte. Solche Analysegeräte können als SAST-Lösung angesehen werden. Mit SAST (Static Application Security Testing) können Entwickler Schwachstellen im Quellcode der Anwendung bereits in den frühen Phasen des Softwareentwicklungszyklus finden.
Die Verwendung von SAST in der Entwicklung ist eine weitere Option, um die Wahrscheinlichkeit einer Zero-Day-Bedrohung zu minimieren. Der Analysator, der seine Fehler nach dem CWE klassifiziert, kann erkennen, wo sich eine mögliche Sicherheitsanfälligkeit verbirgt. Durch die Korrektur dieser Fehler erhöht der Entwickler die Zuverlässigkeit seiner Anwendung und verringert die Wahrscheinlichkeit einer 0-Tage-Bedrohung.
Es gibt verschiedene Tools für statische Sicherheitstests. Lassen Sie uns das
PVS-Studio- Tool näher betrachten, um die Möglichkeiten des Umgangs mit Schwachstellen zu demonstrieren. Warnungen von diesem Analysegerät können als CWE eingestuft werden. Schauen wir uns einige Beispiele an.
Warnung PVS-Studio:
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 hat versehentlich einen Tippfehler gemacht. In zwei Fällen wird dieselbe Variable geprüft. Gemessen an der generierten Ausnahme sollte in der zweiten Bedingung die Variable
outputPath überprüft werden. Daher ist ein Teil des Codes nicht erreichbar.
Solche Fehler sehen auf den ersten Blick harmlos aus. Dieser Eindruck kann jedoch sehr irreführend sein. Betrachten Sie einen sehr einfachen und auf den ersten Blick harmlosen Fehler im Zusammenhang mit der Vervielfältigung des
goto- Operators.
Zu einem Zeitpunkt verursachte dieser Fehler eine Sicherheitsanfälligkeit im iOS-Betriebssystem.
CVE-2014-1266 Beschreibung der 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; }
Aufgrund des doppelten
Goto tritt auch eine Situation mit nicht erreichbarem Code auf. Unabhängig von den Bedingungen wird die zweite goto-
Anweisung in den
if- Anweisungen ausgeführt. Dies führt dazu, dass die Überprüfung der Signatur nicht erfolgt. Die Funktion gibt 0 zurück, was bedeutet, dass mit der Signatur alles in Ordnung ist, und dann empfängt das Programm den Schlüssel vom Server, auch wenn ein Problem mit der Signatur vorliegt. Dieser Schlüssel wird benötigt, um Daten während der Übertragung zu verschlüsseln.
Die Folgen eines solchen einfachen Fehlers waren sehr schwerwiegend. Daher ist es nicht sinnvoll zu argumentieren, wie gefährlich dieser oder jener Fehler als CWE eingestuft wird. Es muss nur repariert werden, um den Code sicherer zu machen.
Der beschriebene Fehler konnte übrigens vom PVS-Studio-Analysator leicht erkannt werden. Er würde hier sofort zwei CWE-Warnungen geben:
Schauen wir uns ein anderes Beispiel an. Bereits 2012 wurde das Sicherheitsproblem in MySQL bekannt, bei dem ein Angreifer in die MySQL-Datenbank eindringen konnte. Ich werde einen Codeausschnitt bereitstellen, der als Grund dafür diente.
CVE-2012-2122 Beschreibung : 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 entfernten Angreifern, die Authentifizierung zu umgehen, indem sie sich wiederholt bei bestimmten Umgebungen mit bestimmten Implementierungen der memcmp-Funktion authentifizieren Falsches Passwort, 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); }
Der Rückgabetyp der
memcmp- Funktion
ist int und der Rückgabetyp der
check_scramble- Funktion
ist my_bool , in der Tat
char . Infolgedessen wird ein
int in ein
char umgewandelt , in dem die höherwertigen Bits verworfen werden. Dies führte dazu, dass in etwa 1 von 256 Fällen eine Verbindung mit einem beliebigen Passwort unter Kenntnis des Benutzernamens hergestellt werden konnte.
Wiederum könnte dieser CWE-Fehler neutralisiert und verhindert werden, dass er bereits beim Schreiben des Codes zu einem CVE wird. Der statische Analysator PVS-Studio generiert beispielsweise die folgende Warnung:
CWE-197 (
V642 ): Numeric Truncation Error.
In Fortsetzung dieses Themas schlage ich vor, den Artikel „
Wie kann PVS-Studio bei der Suche nach Sicherheitslücken helfen? “ Zu
lesen .
Fazit
0-Tage-Sicherheitslücken - eine Sache, vor der es keinen garantierten Schutz gibt. Die Wahrscheinlichkeit ihres Auftretens kann jedoch erheblich verringert werden. Hierfür können spezielle SAST-Lösungen wie PVS-Studio eingesetzt werden. Wenn Ihr Projekt Fehler feststellt, die als CWE klassifiziert werden können, sollten Sie diese berücksichtigen und beheben. Trotz der Tatsache, dass nur eine geringe Menge an CWE die CVE-Liste ausfüllt, indem CWE-Fehler beseitigt werden, schützen Sie Ihre Anwendung vor vielen potenziellen Bedrohungen.
Sitelinks
- Laden Sie PVS-Studio herunter und probieren Sie es aus
- Technologien, die im PVS-Studio Code Analyzer verwendet werden, um nach Fehlern und potenziellen Schwachstellen zu suchen
- PVS-Studio Warnklassifizierung nach Common Weakness Enumeration (CWE)
- PVS-Studio Warnklassifizierung nach SEI CERT Coding Standard
Wenn Sie diesen Artikel mit einem englischsprachigen Publikum teilen möchten, verwenden Sie bitte den Link zur Übersetzung: Ekaterina Nikiforova.
PVS-Studio Static Analyzer als Tool zum Schutz vor Zero-Day-Schwachstellen .