Technische Unterstützung
Dokumentation
Anmeldung
Kontakt
Die Bugs hinter den Schwachstellen Teil 2
Joao Correia
November 14, 2022 - Technischer Evangelist
Wir befassen uns weiterhin mit den Code-Problemen, die die Schwachstellen in der IT-Welt verursachen. In diesem Teil unserer fünfteiligen Blogserie, in der wir diese Fehler untersuchen, gehen wir die Fehler Nr. 20 bis Nr. 16 der Mitre CWE Top 25 Liste für das Jahr 2022 durch - mit Kontext und zusätzlichen Informationen zu den tatsächlichen Codeproblemen, die zu Schwachstellen in Anwendungen und Systemen im Allgemeinen führen.
Den vorherigen Beitrag dieser Serie finden Sie hier.
20 - Falsche Standardberechtigungen
Diese Klasse von Fehlern entsteht durch die Art und Weise, wie Softwarepakete vorbereitet werden - entweder auf der Ebene des Betriebssystems oder der Anwendung -, indem sie Berechtigungen für eine Untergruppe von Objekten enthalten, die zu weit gefasst sind. In der Regel handelt es sich dabei um ausführbare Dateien mit Berechtigungen, die es nicht privilegierten Benutzern ermöglichen, diese Dateien auszuführen, obwohl sie dazu nicht in der Lage sein sollten, oder diese Dateien mit solchen Berechtigungen laufen zu lassen, dass sie andere Komponenten des Systems auf unbeabsichtigte Weise manipulieren können.
Es kann auch andersherum passieren: Wenn eine Berechtigung für eine ausführbare Datei zu restriktiv ist, findet das Betriebssystem automatisch eine Alternative, die sich an einem vom Angreifer kontrollierten Ort befindet (und nicht die im Originalpaket enthaltene Komponente).
Das Hauptrisiko besteht darin, dass dies die Standard Berechtigungen sind, d.h. sobald das Paket bereitgestellt wird, ist es sofort gefährdet, ohne dass eine weitere Aktion erforderlich ist. Dies verlagert den Risikovektor von Verwendung auf Bereitstellung.
19 - Unzulässige Einschränkung von Operationen innerhalb der Grenzen eines Speicherpuffers
Bei dieser Anomalie, die gewöhnlich als "Pufferüberlauf" oder "buffer overrun" bezeichnet wird, wird versucht, eine Position im Speicher zu lesen, die außerhalb des für eine bestimmte Variable vorgesehenen Bereichs liegt, oder an eine solche Stelle zu schreiben.
Dies kann entweder durch die absichtliche Übergabe eines Speicherplatzes geschehen, der außerhalb des Puffers liegt, oder durch die Verwendung des Ergebnisses einer Operation als Lese-/Schreibposition, ohne zu überprüfen, ob dies im gegebenen Kontext akzeptabel ist oder nicht.
Nehmen Sie das folgende Beispiel:
int main (int argc, char **argv) {
char *items[] = {"A", "B", "C", "D"};
int index = AskUserForIndex();
printf("You selected %s\n", items[index-1]);
}
(Codebeispiel angepasst an das unter https://cwe.mitre.org/data/definitions/119.html)
Wenn der Benutzer in diesem Beispiel "5" als Index eingibt, wird das Programm dem gerne nachkommen und den Inhalt einer Speicherstelle außerhalb des Arrays zurückgeben. Je nach Betriebssystem und Speicherarchitektur können mehrere Dinge passieren: Es können Speicherwerte außerhalb des Programmbereichs zurückgegeben werden, das Programm kann abstürzen, ein anderes Programm kann abstürzen (wenn ein Schreibvorgang stattfindet), der Systemstatus kann beeinträchtigt werden oder nichts stürzt ab und der Angriff kann wiederholt werden. Es ist möglich, große Mengen an Speicher zu lesen, indem der Vorgang mit verschiedenen Indexwerten wiederholt wird.
Diese Klasse von Fehlern kann Probleme beim Lesen, aber auch beim Schreiben von Werten in einen Puffer verursachen - indem mehr Daten geschrieben werden, als der Puffer aufnehmen kann. Wenn der Speicherbereich direkt nach dem Puffer zufällig ein Flag enthält, das angibt, ob der Benutzer über Privilegien verfügt oder nicht, kann eine einfache Byte-Änderung einen normalen Benutzer in einen Administrator verwandeln.
Obwohl diese Art von Code-Fehlern in der Regel in Programmierkursen gelehrt wird, und auch, wie man sie vermeiden kann, indem man vor jedem Speicherzugriff eine Überprüfung durchführt, ist es manchmal nicht offensichtlich, wo das Problem überhaupt auftritt. Statische Code-Analyse-Tools, Peer-Review und Pair Programming sind allesamt Möglichkeiten, um diese Fehler zu finden, bevor sie in den Produktionscode gelangen.
Ein weiteres verwandtes Konzept in der Programmierung ist der "Kanarienvogel" (analog zum Kanarienvogel im Kohlebergwerk), bei dem ein Wert direkt nach dem Puffer geschrieben und dann auf sein Vorhandensein überprüft wird, nachdem ein Wert in den Puffer geschrieben wurde. Wenn der ursprüngliche Wert nicht mehr vorhanden ist, kann der Programmierer davon ausgehen, dass ein Pufferüberlauf stattgefunden hat, und die Anwendung absichtlich zum Absturz bringen, um weiteren Schaden zu verhindern, oder ihn durch eine Warnung an den Benutzer oder einen anderen Mechanismus beheben. Obwohl dies nützlich ist, können clevere Angreifer dies umgehen, indem sie den Canary-Wert als Teil des neuen Wertes einfügen, um ihn nicht auszulösen.
18 - Fehlende Authentifizierung für eine kritische Funktion
Jede Funktion, die die Funktionalität verändert, sollte überprüfen, ob der Akteur, der die Aktion ausführt, dazu berechtigt ist oder nicht, und die Aktion verhindern, wenn der Akteur nicht dazu berechtigt ist. Wenn eine Anwendung dies nicht validieren kann, fällt sie in diese Kategorie.
Anwendungen führen häufig Aufgaben wie das Hinzufügen, Entfernen, Ändern oder Löschen von Daten, Benutzern oder Verbindungen aus. Fehlt nur eine dieser Aktionen, z. B. eine Authentifizierungsprüfung für die gesamte Anwendung, so ist diese gefährdet oder unzuverlässig. Da jeder dieser Vorgänge mehrere Schritte umfasst, sollte die Validierung idealerweise bei jedem Schritt oder, falls dies nicht möglich ist, an den Eingangspunkten jedes Prozesses erfolgen.
Ein weiteres typisches Beispiel sind fehlende Authentifizierungsprüfungen bei Cloud-basiertem Speicher (d. h. "undichte S3-Buckets"), bei denen vertrauliche Daten versehentlich öffentlich zugänglich gespeichert werden.
17 - Unsachgemäße Neutralisierung von Spezialelementen, die in einem Befehl verwendet werden
Wann immer eine Eingabe von einer Anwendung akzeptiert und dann ausgeführt wird, könnte sie, wenn sie nicht ordnungsgemäß überprüft wird, zusätzliche Befehle, Parameter oder Flags enthalten, die den beabsichtigten Zweck verändern.
Wenn eine Systemanwendung einen Befehl mit einem vom Benutzer eingegebenen Parameter ausführen soll, könnte ein gewiefter Benutzer ein Befehlsabbruchzeichen einfügen, gefolgt von einem anderen Befehl, der dann mit der gleichen Berechtigungsstufe wie das ursprüngliche Programm ausgeführt wird. Diese Art von Problemen ist eng mit den Fehlern "SQL-Injection" und "unsachgemäße Kontrolle des generierten Codes" verwandt, da sie alle auf implizites Vertrauen in Eingaben zurückzuführen sind.
Die Ursache des Problems liegt in der Regel auf der Architekturebene, wo Sicherheitsaspekte nicht angemessen berücksichtigt werden, so dass unsichere Verhaltensweisen in Anwendungen eingeführt werden. Als Faustregel gilt, dass keine Eingabe jemals als vertrauenswürdig eingestuft werden sollte - idealerweise sogar auf der Ebene der einzelnen Funktionen, mindestens aber auf der Anwendungsebene.
16 - Fehlende Berechtigung
In #18 haben wir gesehen, wie Teile einer Anwendung eine Authentifizierungsprüfung verpassen können. In diesem Beitrag sehen wir uns an, wie eine fehlende Autorisierung ebenfalls zu Problemen führen kann.
Es ist üblich, dass Websites sensible Bereiche durch Authentifizierungsmechanismen schützen, aber jede einzelne Seite muss diese Prüfung durchführen, auch auf die Gefahr hin, dass durch den direkten Zugriff auf eine URL Informationen preisgegeben werden, die sonst unerreichbar wären. Dies gilt auch für Downloads/Uploads/Abfragen und nicht nur für Seitenzugriffe.
Auf der traditionellen Anwendungsebene kommt es zu einer fehlenden Autorisierung, wenn einem Benutzer oder einer extern aufrufenden Anwendung implizites Vertrauen entgegengebracht wird.
Wie bei Nr. 17 stammt der Fehler in der Regel aus der Architekturphase der Entwicklung, in der keine angemessenen Sicherheitstaktiken zur Durchsetzung geeigneter Zugriffskontrollmechanismen auf allen Ebenen berücksichtigt wurden. Die Identifizierung und anschließende Korrektur des Codes für eine bestimmte Anwendung, nachdem diese Art von Fehler identifiziert wurde, ist in der Regel mit einem hohen Arbeitsaufwand verbunden, da der Code umfangreich überarbeitet werden muss, um im Nachhinein ordnungsgemäß gesichert zu sein.
Auf der Ebene des Betriebssystems tritt diese Art von Problem auf, wenn einem Tool keine Zugriffskontrollliste zugeordnet ist, so dass jeder Benutzer es ausführen kann.
