Sicherheits-Cheat-Sheets: Virtual Patching

Das Thema unseres heutigen Artikels ist Virtual Patching.

Virtual Patching ist eine Sicherheitsrichtlinienebene, mit der Exploit-Exploits für bekannte Sicherheitsanfälligkeiten erkannt und verhindert werden sollen.

Der virtuelle Patch funktioniert nach der Datenverkehrsanalyse und verhindert, dass böswilliger Datenverkehr in die anfällige Anwendung gelangt. Auf diese Weise verhindert der virtuelle Patch gegebenenfalls die Ausnutzung der Sicherheitsanfälligkeit, ohne den Quellcode der Anwendung zu ändern. Normalerweise wird ein virtueller Patch auf Firewalls für Webanwendungen (WAF) implementiert.

Warum also virtueller Patch, warum nicht einfach den Code aktualisieren?

Das Aktualisieren des Codes ist natürlich die erste und empfohlene Lösung, aber es ist nicht immer möglich, ob es sich um einen Mangel an Ressourcen in der Organisation handelt (alle Entwickler sind bereits beschäftigt und können nicht auf Notfall-Patches umgestellt werden), die Software eines anderen Benutzers verwendet wird (wie kann ich den Code hier ändern) oder nur ein wenig umgeschrieben werden muss wenn nicht die gesamte Anwendung für diesen Patch.
Dies bedeutet nicht, dass sich das virtuelle Patchen und das Aktualisieren des Codes gegenseitig ausschließen! Sie werden normalerweise von verschiedenen Befehlen ausgeführt (im Hinblick auf die Besonderheiten dieser Prozesse), so dass das Patchen und Aktualisieren parallel erfolgen kann.

Die Vorteile des virtuellen Patches sind folgende:

• Eine schnelle (relativ) Lösung, um die Sicherheitsanfälligkeit zu schließen, bis kein vollwertiger Patch mehr möglich ist.
• Wenn es sich bei der Webanwendung um Ihr Produkt handelt, werden möglicherweise vorhandene Geschäftsprozesse nicht verletzt. Wenn also der nächste Patch für das Produkt beispielsweise in einem Monat geplant ist, müssen Sie nicht den gesamten Zeitplan brechen.
• Die Möglichkeit, Schwachstellen mit Mitgliedern eines anderen Teams zu schließen, wenn die Entwickler dies derzeit nicht können.
• Aktualität - Wenn Sie vorgefertigte Software verwenden, ist nicht bekannt, wann der Patch für Ihr Produkt veröffentlicht wird, und Sie möchten ihn natürlich nicht anfällig machen.

Nachteile des virtuellen Patches:

• Dies ist immer noch kein Allheilmittel. Bei der Verwendung können nicht alle Angriffsvektoren abgedeckt werden, wodurch die Gefahr einer Operation bestehen bleibt.
• Der Nachteil aller temporären Lösungen ist die Wahrscheinlichkeit, dass die temporäre Lösung dauerhaft wird. Das Unternehmen wird entscheiden, dass, sobald es funktioniert, wir es nicht mehr berühren und die Dinge so lassen, wie sie sind.
• Dies ist eine Add-On-Lösung, die Sicherheitsanfälligkeit selbst verschwindet nicht, sondern verbirgt sich einfach hinter einer zusätzlichen Schutzschicht.

Die Vorbereitung für den virtuellen Patch kann in folgende Schritte unterteilt werden:

1. Vorbereitung
2. Identifizierung der Bedrohung
3. Analyse
4. Erstellen Sie einen virtuellen Patch
5. Implementierung und Testen
6. Wiederherstellung / Fortsetzung der Arbeit

Öffentliche Verwundbarkeit

Nehmen Sie zum Beispiel SQL Injection und ModSecurity WAF (seit Open Source).

WordPress Shopping Cart Plugin  WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php  reqID   SQL Injection. 

Das WordPress Shopping Cart Plugin für WordPress enthält einen Fehler, durch den ein Angreifer möglicherweise eine SQL-Injection ausführen kann. Das Problem liegt im Skript /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php, in dem der Parameter reqID nicht korrekt bereinigt wird.

Dies kann es einem Angreifer ermöglichen, SQL-Abfragen im Backend einzubetten oder zu manipulieren, was zu der Möglichkeit führt, einen illegalen Zugriff auf Daten zu erhalten, mit allen sich daraus ergebenden Konsequenzen.

Vorbereitungsphase

Wie in vielen Prozessen ist die Vorbereitung auf virtuelle Patches eine wichtige Komponente. Bevor Sie mit einer entdeckten Sicherheitsanfälligkeit (oder noch schlimmer mit einem Echtzeitangriff) umgehen können, müssen Sie einige Dinge tun. Die Vorbereitung besteht nicht darin, während des Angriffs zu verstehen, wie virtueller Patch funktioniert und wie WAF in die aktuelle Infrastruktur integriert wird, wenn es nicht vorhanden ist, sondern bestimmte und gut durchdachte Maßnahmen zu ergreifen.

Hier sind einige kritische Punkte, die in Vorbereitung behandelt werden müssen:

• Überwachen von Sicherheitslücken vom Anbieter oder aus öffentlichen Quellen - Wenn Sie Software von Drittanbietern verwenden, stellen Sie sicher, dass Sie alle Notfallmailings von Anbietern abonniert haben. Auf diese Weise bleiben Sie über neue Sicherheitslücken in Ihrer Software und den zugehörigen Patches auf dem Laufenden.
• Bereiten Sie alle erforderlichen Arbeiten im Voraus vor, damit virtuelle Patches in die Produktion gelangen können. Virtuelle Patches müssen schnell erstellt werden, sodass der übliche Überprüfungsprozess für Patches hier nicht funktioniert. Da virtuelle Patches den Quellcode nicht ändern, müssen sie nicht in der gleichen Menge getestet werden wie normale Software-Patches. Es lohnt sich, virtuelle Patches derselben Kategorie wie Updates für Antivirenprogramme oder Signaturupdates für IDS zuzuweisen. Dies wird den Prozess der Einführung in die Produktion erheblich beschleunigen.
• Erstellen Sie Dienstprogramme für das virtuelle Patchen im Voraus - da das Hauptkriterium für das virtuelle Patchen die Geschwindigkeit ist, ist die Installation neuer Software, wenn Sie ein Notfall-Patch benötigen, gelinde gesagt, eine schlechte Idee.
• Erhöhen Sie die Protokollierung für Ihre Systeme - Der von den meisten Servern standardmäßig verwendete Protokollstandard (CLF) bietet nicht genügend Daten, um auf Vorfälle korrekt zu reagieren. Sie müssen Zugriff auf folgende Daten haben:
  
  ◦ URI anfordern (einschließlich QUERY_STRING)
  ◦ Alle Anforderungsheader (einschließlich Cookies)
  ◦ Vollständiger Anfragetext (einschließlich POST-Laden)
  ◦ Vollständige Antwortheader
  ◦ Vollständiger Antwortkörper

Bedrohungserkennungsstufe

Diese Phase beginnt, wenn die Organisation feststellt, dass die Webanwendung eine Sicherheitsanfälligkeit aufweist. Im Allgemeinen gibt es zwei verschiedene Ansätze zur Identifizierung von Schwachstellen - proaktiv und reaktiv.

Proaktiver Ansatz

Der Fall, in dem die Organisation Sicherheitsaufgaben übernimmt und die folgenden Aufgaben ausführt:

• Dynamische Bewertung der Anwendung - Pentests und / oder automatische Bewertungstests werden in einer laufenden Webanwendung durchgeführt, um Mängel zu identifizieren.
• Überprüfung des Quellcodes - Eine manuelle und / oder automatische Bewertung des Quellcodes einer Webanwendung wird durchgeführt, um Mängel festzustellen.

Reaktiver Ansatz

Es gibt drei reaktive Hauptmethoden zum Erkennen von Sicherheitslücken:

• Eine Nachricht des Anbieters - wenn Ihr Softwareanbieter Informationen zu einer entdeckten Sicherheitsanfälligkeit veröffentlicht.
• Public Publishing ist die Veröffentlichung einer entdeckten Sicherheitsanfälligkeit für Software, die Sie in öffentlichen Quellen verwenden. In diesem Fall sollte Ihre Antwort auf die Sicherheitsanfälligkeit schneller sein als beim Melden vom Anbieter, da mehr Personen über die Sicherheitsanfälligkeit informiert sind.
• Sicherheitsvorfall - Dies bedeutet, dass der Angriff bereits ausgeführt wird. Es sind sofortige Maßnahmen erforderlich, um die Sicherheitsanfälligkeit zu konkretisieren und zu schließen.

Analysephase

Empfohlene Schritte für die Analysephase:

• Bestimmen Sie, wie das virtuelle Patchen für Ihren Fall geeignet ist - es eignet sich hervorragend, um Mängel im Zusammenhang mit Eingaben (z. B. Injektionen) zu beheben, bietet jedoch möglicherweise keinen ausreichenden Schutz für Angriffe anderer Arten oder Kategorien. Eine detaillierte und gründliche Analyse des zugrunde liegenden Problems sollte durchgeführt werden, um festzustellen, ob die virtuelle Patch-Software ein angemessenes Maß an Erkennung und Abdeckung bietet.
• Beauftragen Sie Ihre Systeme mit der Verfolgung von Fehlern / Aufgaben - geben Sie Schwachstelleninformationen zur weiteren Verfolgung und Untersuchung in Ihren Tracker ein.
• Überprüfen Sie die Sicherheitsanfälligkeit - suchen Sie den offiziellen Namen der Sicherheitsanfälligkeit, falls vorhanden. Wenn es durch proaktive Methoden erkannt wurde, müssen Sie ihm eine eindeutige Nummer / einen eindeutigen Namen geben.
• Bestimmen Sie das Risiko. Es ist immer wichtig zu wissen, wie kritisch die Auswirkungen der Ausnutzung dieser Sicherheitsanfälligkeit für Sie sein können. Zum Beispiel, ob es sich um ein Informationsleck oder um einen Zugriff auf die Datenbank handelt.
• Bestimmen Sie, welche Softwareversionen gefährdet sind. Es ist wichtig zu wissen, ob Sie gefährdet sind oder nicht.
• Bestimmen Sie, unter welchen Softwarekonfigurationen ein Problem auftreten kann. Einige Schwachstellen können nur bei bestimmten Softwarekonfigurationen auftreten.
• Erstellen Sie eine Liste der Proof of Concept-Exploits oder -Nutzlasten, die während des Angriffs / Tests verwendet wurden. Viele Veröffentlichungen zu Schwachstellen werden von PoC-Code begleitet, der die Schwachstelle demonstriert. Wenn solche Daten verfügbar sind, analysieren Sie sie. Dies ist nützlich für die Weiterentwicklung und das Testen eines virtuellen Patches.

Phase der Erstellung eines virtuellen Patches

Das Erstellen eines guten virtuellen Patches ist an zwei Aspekte gebunden:

• Keine Fehlalarme - blockieren Sie niemals den normalen Verkehr trotz der Umstände
• Ohne Fehlalarme - verpassen Sie niemals einen Angriff, auch wenn der Angreifer bewusst versucht, der Erkennung zu entgehen.

Es müssen Anstrengungen unternommen werden, um die Auswirkungen dieser beiden Regeln zu minimieren. Es ist möglicherweise nicht möglich (was am häufigsten vorkommt), diese beiden Regeln zu befolgen, aber es ist wichtig zu bedenken, dass es bei virtuellen Patches darum geht, das Risiko zu verringern.

Manuelle Erstellung eines virtuellen Patches
Positiver Ansatz (Whitelisting, Whitelisting) im virtuellen Patch

Bei diesem Ansatz wird eine unabhängige Eingabevalidierung für die Webanwendung erstellt. Der Ansatz bestimmt die Eigenschaften gültiger Daten (Zeichensatz, Länge usw.) und verbietet alles, was diesen Bedingungen nicht entspricht. Durch das Definieren der Regeln für jeden Parameter auf jeder Seite der Webanwendung wird die Anwendung unabhängig vom Quellcode in eine zusätzliche Schutzebene eingebunden.

Ein Beispiel für die Erstellung eines virtuellen Patches basierend auf der Whitelist in ModSecurity
Um einen virtuellen Patch für die Positivliste zu erstellen, müssen die normalen erwarteten Werte überprüft werden können. Wenn die korrekte Protokollierung im Rahmen der Vorbereitungsphase vorkonfiguriert wurde, sollten Sie durch die Protokollprüfung in der Lage sein, das Format der erwarteten Eingabewerte zu verstehen.

Ein Beispiel.

In diesem Fall sollte der Parameter reqID nur Ganzzahlen enthalten, damit wir diesen virtuellen Patch anwenden können:

 # # ,     1    "reqID" # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'" SecRule &ARGS:/reqID/ "!@eq 1" # # ,   reqID     # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "!@rx ^[0-9]+$" 

Dieser virtuelle Patch analysiert den Parameter reqID und lässt nur Ganzzahlen in der Eingabe zu. Es ist jedoch zu beachten, dass der Angriffsvektor fast nie einzeln ist und der Angreifer sein Glück auf andere Weise versuchen kann.

Negativer Ansatz (Blacklisting, Blacklisting) im virtuellen Patch

Dieser Ansatz basiert auf einer Liste von Regeln, die bestimmte bekannte Angriffe definieren, anstatt nur gültigen Datenverkehr zuzulassen.

Ein Beispiel für die Erstellung eines virtuellen Patches auf der Grundlage der Sperrliste in ModSecurity

Zum Beispiel PoC-Code aus einer öffentlichen Quelle:

 http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1 

Nach der Analyse der Last sehen wir, dass der Angreifer ein einfaches Anführungszeichen einfügt und am Ende SQL-Logik hinzufügt. Basierend auf diesen Daten können wir einfache Anführungszeichen verbieten:

 SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "@pm '" 

Achten Sie darauf, keine virtuellen Patches für bestimmte Exploits zu erstellen

Das sieht natürlich attraktiv und zeitsparend aus. Wenn pentest beispielsweise XSS auf Ihrer Seite gefunden und die folgende Belastung verwendet hat:

 <script> alert('XSS Test') </script> 

Es wäre unvernünftig, ein virtuelles Patch zu erstellen, das eine solche Last spezifisch blockiert, so attraktiv es auch in Bezug auf Aufwand und Geschwindigkeit sein mag. Es muss ein virtueller Patch erstellt werden, um das Problem als Ganzes und nicht den spezifischen Fall zu schließen.

Erstellen Sie automatisch virtuelle Patches

Die manuelle Erstellung von Patches kann aufgrund der wachsenden Anzahl von Sicherheitslücken unerträglich werden, und die Automatisierung ist ein notwendiger Schritt. Wenn Schwachstellen mithilfe automatisierter Tools (z. B. Schwachstellenscanner) entdeckt wurden, können möglicherweise Berichte dieser Tools in Patches konvertiert werden. Die beliebtesten Tools für die Patch-Automatisierung sind der direkte Import in WAF (sofern Ihre Lösung dies unterstützt), OWASP ModSecurity-CRS-Skripts (Core Rule Set) und ThreadFix Virtual Patching.

Implementierungs- und Testphase

Um unseren neuen virtuellen Patch korrekt zu testen, benötigen wir möglicherweise die folgenden Tools:

• Webbrowser
• Webdienstprogramme für Terminals (z. B. Curl und Wget)
• lokaler Proxy
• ModSecurity AuditViewer

Schritte:

• Implementieren Sie zunächst virtuelle Patches im Modus "Nur Protokolle", um sicherzustellen, dass der normale Benutzerverkehr nicht blockiert wird (falsch-positive Option).
• Wenn die Sicherheitsanfälligkeit mit bestimmten Tools oder Befehlen entdeckt wurde, fordern Sie eine erneute Überprüfung an.
• Wenn der erneute Test fehlschlägt, weil der virtuelle Patch umgangen werden kann, müssen Sie zum Analyseschritt zurückkehren, um zu bestimmen, wie das Problem am besten behoben werden kann.

Phase der Wiederherstellung / Fortsetzung

• Aktualisieren Sie die Daten in Ihrem Ticket-System. Obwohl die Fristen für die Installation virtueller Patches möglicherweise noch nicht abgelaufen sind, ist es besser, Änderungen in Ihrem Tracking-System zu verfolgen und zu aktualisieren. Dies wird es ermöglichen, das ursprüngliche Problem angemessener und vollständiger zu behandeln, wobei die Wahrscheinlichkeit geringer ist, dass einige Details übersehen werden. Außerdem können Sie die Zeit, die für die einzelnen Phasen der Problemlösung aufgewendet wurde, genauer einschätzen.
• Regelmäßige Neubewertung - dies hilft zu verstehen, welche virtuellen Patches bereits / bald entfernt werden können, da beispielsweise ein vollwertiger Quellcode-Patch angewendet wurde / wird.
• Richten Sie Berichte über Ihre virtuellen Patches ein - so können Sie besser nachvollziehen, wann und wie oft sie beteiligt sein werden. Auf diese Weise erhalten Sie Statistiken darüber, an welchen Orten ein erhöhtes Risiko für Sie besteht.