Warum CVEs bei der Lösung oberste Priorität haben sollten
Ich habe bereits erläutert, warum Anwendungssicherheit ein Stapel ist . Ich sage dies noch einmal, weil wir manchmal daran erinnert werden müssen, dass moderne Anwendungen niemals allein bereitgestellt werden. Das sind sie nicht.
Jede moderne Anwendung wird auf einer Art Plattform bereitgestellt. Das könnte Apache oder IIS sein. Es könnte sich um einen Oracle- oder IBM-Anwendungsserver handeln. Könnte node.js mit Express oder Python mit allen erforderlichen Bibliotheken sein. So wie wir uns bei der Vernetzung auf Betriebssysteme und Virtualisierung/Container verlassen, sind Anwendungen bei der Handhabung von Dingen wie TCP und HTTP auf Plattformen und Bibliotheken angewiesen.
Darüber hinaus verwenden Entwickler Bibliotheken für die Funktionalität. Das Rad neu zu erfinden ist Zeitverschwendung, daher greifen Entwickler auf Open Source und andere Möglichkeiten für JSON-Parser, Dateiverwaltung, Authentifizierung und Autorisierung sowie Datenbankunterstützung zurück. Auch UI-Layout und -Verwaltung. Heutzutage greifen die meisten Entwickler auf Bibliotheken zurück, um diese Funktionen bereitzustellen. So können sie sich auf das konzentrieren, was Mehrwert bietet: Geschäftslogik und Dienste.
Bei einer Untersuchung von Anwendungen durch Contrast Labs im Jahr 2017 wurde festgestellt, dass „Softwarebibliotheken von Drittanbietern 79 % des Codes einer Anwendung ausmachen.“ Für Java lag der Durchschnitt bei 107 verschiedenen Bibliotheken. Für .NET? 19. Anekdotisch verwende ich mindestens fünf verschiedene Bibliotheken mit node.js.
Was Sie jedoch stutzig machen sollte, sind die Erkenntnisse, die sie hinsichtlich der Sicherheitslage im Zusammenhang mit dieser Spaltung gewonnen haben.
Obwohl 79 % einer App aus Bibliotheken bestehen, machen diese nur 2 % der bekannten Schwachstellen (CVE) aus. Mit 97,3 % der Schwachstellen macht benutzerdefinierter Code so ziemlich den Rest aus.
Dieses unverhältnismäßige Sourcing-Sicherheitsrisiko zwischen Bibliotheken und Schwachstellen könnte erklären, warum eine SANS-Umfrage ergab, dass „obwohl 23 % der Befragten in hohem Maße auf Softwareprodukte und -dienste von Drittanbietern (COTS, Cloud-basierte Dienste und Open-Source-Software) angewiesen sind, sie nicht genügend Verantwortung für die Gewährleistung der Sicherheit von Drittanbieterlösungen übernehmen.“ Nur 23 % der Sicherheitsprogramme umfassen COTS.“
Hmmpf. Nun, das könnte die niedrige Reaktionsrate bei der Behebung von Sicherheitslücken erklären, die von Kenna Security gemeldet wird. Bereits 2015 berichtete Kenna Security über eine Studie, die an einer Stichprobe von 50.000 Organisationen mit 250 Millionen Schwachstellen und über einer Milliarde (MILLIARDE) Sicherheitsverletzungen durchgeführt wurde. Dabei stieß man auf zwei sehr interessante Erkenntnisse hinsichtlich der Behebung von Schwachstellen:
- Im Durchschnitt benötigen Unternehmen 100 bis 120 Tage, um Schwachstellen zu beheben.
- Nach 40–60 Tagen liegt die Wahrscheinlichkeit, dass ein CVE ausgenutzt wird, bei über 90 Prozent.
- Die Zeitspanne zwischen der wahrscheinlichen Ausnutzung einer Schwachstelle und der Schließung dieser beträgt etwa 60 Tage.
Mit anderen Worten: Die meisten Organisationen beheben diese 2 % der Schwachstellen nicht schnell genug, um nicht von einer dieser Schwachstellen betroffen zu sein. Vielleicht weil sie sich in Bibliotheken befinden, die nicht in das Sicherheitsprogramm der Organisation einbezogen sind.
Unabhängig davon, warum das so ist , muss es oberste Priorität haben. Und lassen Sie mich erklären, warum.
Früher mussten Angreifer:
- Informieren Sie sich über die Sicherheitslücke
- Suchen Sie nach einer Opferseite
- Versuch, einen Exploit auszuführen
Dies erfolgte manuell und war zeitaufwändig. Sofern Sie kein prominentes Ziel waren, würde niemand seine Zeit mit Ihnen verschwenden.
Heutzutage werden Schwachstellen mit der Geschwindigkeit des Internets (das ist, falls Sie sich das fragen, die Lichtgeschwindigkeit) weitergegeben. Optisches Rückgrat, wissen Sie) und die Zielerkennung erfolgt automatisiert. Skripte und Bots können kompromittierte Websites viel schneller (und kostengünstiger) aufspüren und markieren als Menschen. Auf die gleiche Weise werden aus ungesicherten IoT-Geräten Botnetze in der Größe des Todessterns aufgebaut . Durch Automatisierung wird nicht nur die Produktivität der Guten verbessert.
Dabei handelt es sich um nicht zielgerichtete Angriffe. Wenn man so will, sind das Gelegenheitsangriffe, die nicht geplant sind. Sie verfügen möglicherweise nicht über wertvolle oder interessante Daten, aber Sie verfügen über Ressourcen. Und die Ressourcen können dazu verwendet werden, weitere Opfer zu finden und weitere Angriffe zu verüben, und, na ja, Sie wissen, wie das endet.
Besonders häufig kommt es nach der Veröffentlichung eines CVE zu nicht zielgerichteten Angriffen. Das liegt daran, dass Ihr benutzerdefinierter Code einzigartig ist. Er weist zwar zahlreiche Schwachstellen auf, aber es erfordert Zeit und Mühe, diese zu finden. Die Ausnutzung eines CVE, das in einer häufig genutzten Bibliothek oder Plattform vorhanden ist, ist ein Kinderspiel. Diese Gelegenheit ist zu gut, um sie sich entgehen zu lassen, denn die Kapitalrendite ist sehr, sehr, sehr hoch. Im Verizon DBIR von 2015 wurde festgestellt, dass „70 % der Angriffe bekannte Schwachstellen ausnutzten, für die Patches verfügbar waren.“
Aus diesem Grund sollte das Patchen – entweder durch tatsächliche Software-Updates oder virtuell durch den Einsatz einer Web Application Firewall – oberste Priorität haben, wenn in einer der 79 % der Bibliotheken, aus denen Ihre Anwendung besteht, ein neuer CVE-Fehler auftritt. Wenn sich dieser CVE auf die Plattform bezieht (denken Sie an Apache Killer) , sollte die Priorität „Alles fallen lassen“ höher sein, da das Fingerprinting von Web- und App-Servern sogar einfacher ist als das Scannen nach Schwachstellen in Bibliotheken.
Die Wahrheit ist: Auch wenn Ihre Bekanntheit nicht hoch genug ist, um ins Visier zu geraten, besteht für Sie immer noch ein Risiko. Sie verwenden wahrscheinlich denselben Stack wie namhafte Organisationen, und das bedeutet, dass Sie wahrscheinlich auch Ziel nicht zielgerichteter Angriffe werden. Wenn Sie der Meinung sind, dass dies nicht der Fall sein wird, bedenken Sie, dass ich in der CVE-Datenbank alle veröffentlichten CVEs im Zusammenhang mit node.js finden kann. Dann gehe ich schnell zu builtwith.com und suche nach Websites, die mit Express erstellt wurden – einem Node.js-Framework. Ich erfahre nicht nur, dass die Site „ 230.116 aktive Websites kennt, die Express verwenden, und weitere 263.872 Websites , die Express in der Vergangenheit verwendet haben“, sondern sie stellt auch praktischerweise einen Link zum Herunterladen dieser Websites bereit.
Es ist nicht ganz das Shodan.io der Web-Apps, aber es ist nicht viel schwieriger, eins und eins zusammenzuzählen und einen erfolgreichen Exploit zu entwickeln.
Machen Sie also nicht den Fehler zu glauben, dass ein CVE in einer Bibliothek oder Webplattform ignoriert werden kann, nur weil Sie nicht „groß genug“ sind.
Auf diese Weise landen Leute bei Twitter im Trend. Und nicht im guten Sinne.
Passen Sie auf. Priorisieren Sie Reaktionen auf CVEs, die Ihren gesamten App- Stack betreffen. Von oben nach unten.