Keine Patches, keine Sicherheit
Im Bereich der Cybersicherheit gehen wir oft davon aus, dass die regelmäßige Suche nach Updates und deren Anwendung die Sicherheit unserer Systeme gewährleistet. Eine feine Nuance wird jedoch häufig übersehen. Wenn wir sagen, dass wir "alle verfügbaren Patches" eingespielt haben, meinen wir eigentlich, dass wir alle Patches eingespielt haben, die "von unserem Distributionsanbieter bereitgestellt wurden". Und genau hier liegt der mögliche Fallstrick: Eine vollständige Abdeckung ist nicht immer gewährleistet.
Das CVE-Punktespiel entschlüsseln
CVE-Bewertungen können verwirrend sein. Experten sind sich oft nicht einig, wie sie eine bestimmte Schwachstelle bewerten, was zu einem subjektiven Ansatz bei der Schwachstellen- und Risikoanalyse führt. Diese Subjektivität kann dazu führen, dass Schwachstellen entweder überschätzt oder unterschätzt werden, was ihre potenzielle Bedrohung angeht.
Mit der bevorstehenden Version 4.0 des CVE-Bewertungssystems wird versucht, diese Subjektivität zu verringern. Dennoch bleibt das Problem bestehen: Softwarehersteller passen manchmal die offiziellen CVE-Bewertungen an oder ignorieren sie, was sie dazu veranlasst, keine Patches für bestimmte Sicherheitslücken zu veröffentlichen. Diese Inkonsistenz kann dazu führen, dass Benutzer verwundbar sind. Darüber hinaus bestimmt die Bewertung einer CVE-Schwachstelle die Anwendbarkeit der verschiedenen Compliance-Anforderungen in Bezug auf das Patchen dieser Schwachstelle.
Einhaltung der Vorschriften ≠ Sicherheit
Das bloße Patchen von Software zur Einhaltung von Compliance-Standards ist nicht gleichbedeutend mit einer wirklich sicheren Umgebung. Der bürokratische Charakter der Konformität hinkt oft der sich schnell entwickelnden Bedrohungslandschaft hinterher, so dass die Systeme gefährdet sind.
Das Fehlen von Patches für eine bestimmte Sicherheitslücke verstärkt nur die Illusion von Sicherheit, die Sie erhalten, wenn Sie Patches zur Einhaltung von Compliance-Anforderungen bereitstellen. Ihr Bericht über die Einhaltung der Sicherheitsvorschriften kann makellos sein - Sie haben alle Patches installiert, für die Sie Patches hatten -, aber Ihr System hat immer noch zahlreiche Sicherheitslücken.
Aber ich bekomme meine Pflaster von einem seriösen Anbieter
Ein weiterer weit verbreiteter Irrglaube ist, dass der Bezug von Patches von seriösen Anbietern Sicherheit garantiert. Unsere Nachforschungen ergaben jedoch zahlreiche Fälle (Hunderte), in denen Red Hat keine Patches für kritische Sicherheitslücken in seinen Betriebssystemen RHEL 7 oder CentOS 7 veröffentlicht hat, obwohl diese noch offiziell unterstützt werden. Beispiele hierfür sind:
CVE-2023-2953 (7.1 CVSS v3.1, Red Hat Score 7.1): Eine Schwachstelle in OpenLDAP, einer weit verbreiteten zentralisierten Identitätsmanagement-Plattform. Red Hats Standpunkt: wird nicht behoben.
CVE-2023-27534 (8.8 CVSS v3.1, Red Hat Score 3.7): Ein Fehler in der Behandlung von Pfadüberquerungen durch curl beim Zugriff auf SFTP-Ressourcen. Red Hats Standpunkt: wird nicht behoben.
CVE-2022-1292 (9.8 CVSS v3.1, Red Hat Score 6.7): Ein Skript-Problem in OpenSSL, das auch Pakete wie MySQL betrifft. Die Lösung von Red Hat: Fixes nur für die Versionen 8 und 9 verfügbar. Beachten Sie, dass im Internet mit minimalem Aufwand ein Proof-of-Concept-Exploit-Code für diese spezielle Sicherheitslücke verfügbar ist.
Und viele andere CVEs folgen dieser Linie.
Es ist bemerkenswert, dass Red Hat manchmal Schwachstellen mit einer niedrigeren Punktzahl bewertet als die ursprünglichen NIST CVE-Scores. Eine niedrigere Punktzahl bedeutet, dass eine bestimmte Schwachstelle nicht mehr in eine bestimmte Risikostufe passt (d. h. kritisch, hoch, mittel usw.). Das macht die Schwachstellen nicht weniger gefährlich. Es macht sie nur ungepatchte.
Die Änderungen der Bewertung von Red Hat spiegeln in der Regel die Risikoanalyse wider, die auf mehreren Faktoren basiert mehreren Faktoren die nicht immer mit realen Anwendungsszenarien übereinstimmen. Je nachdem, wie Sie Ihr System nutzen oder welche Konfigurationsänderungen Sie vornehmen, kann sich die Bedrohung durch eine bestimmte Schwachstelle ändern, so dass sich das Profil gegenüber der ursprünglichen Einstufung durch den Hersteller verändert. Solange Sie sich immer an die Vorgaben halten, ist das meistens richtig. Wenn Sie jedoch etwas Umgebungsspezifisches tun, das bei der ursprünglichen Bewertung nicht berücksichtigt wurde, spiegelt die Risikoanalyse, die die Bewertung herabgesetzt hat, nicht mehr das tatsächliche Risiko wider, das mit dem Nichtpatchen dieser Schwachstelle verbunden ist.
Die singuläre Schwachstelle, die eine Katastrophe heraufbeschwört
Denken Sie an folgende Analogie: Wenn Sie eine Schüssel mit 100 Pralinen hätten und wüssten, dass eine davon Sie sehr krank machen könnte, würden Sie trotzdem eine nehmen? Schon eine einzige ungepatchte Schwachstelle kann alle bestehenden Sicherheitsmaßnahmen gefährden. Eine ganze Serverflotte mit zahlreichen ungepatchten Sicherheitslücken zu betreiben, ist eine hochriskante Strategie und ein perfektes Rezept für eine Katastrophe.
TuxCare Extended Lifecycle Support: Eine Lösung
TuxCare bietet rückportierte Patches von Upstream-Projekten an, die umfassendere und zeitnähere Korrekturen gewährleisten als die offiziellen Anbieter. Wenn CVEs, die vom NIST als hoch oder kritisch eingestuft werden, nicht von Upstream-Projekten gepatcht werden, erstellt das TuxCare-Team diese Patches und stellt sie unseren ELS-Abonnenten-Repos zur Verfügung. Benutzer von Systemen wie CentOS 7 werden vielleicht überrascht sein , wie viele Updates sie erhalten, wenn sie den ELS von TuxCare abonnieren. Zum Beispiel haben Abonnenten unseres CentOS 6 ELS-Service weit über 300 Patches, die nie vom Upstream-Anbieter bereitgestellt wurden. Für CentOS 7 können wir diese Patches bereitstellen vor dem EOL-Datum zur Verfügung stellen.