9.8 CVE-2023-1592
Eine als kritisch eingestufte Sicherheitslücke wurde in SourceCodester Automatic Question Paper Generator System 1.0 gefunden. Die Schwachstelle betrifft unbekannten Code in der Datei admin/courses/view_class.php der Komponente GET Parameter Handler. Die Manipulation des Arguments id führt zu einer Sql-Injection. Der Angriff kann aus der Ferne initiiert werden. Der Identifikator dieser Sicherheitslücke ist VDB-223660.
https://nvd.nist.gov/vuln/detail/CVE-2023-1592
Kategorien
CWE-89 : Unsachgemäße Neutralisierung von speziellen Elementen, die in einem SQL-Befehl verwendet werden ('SQL Injection')
Das Produkt konstruiert den gesamten oder einen Teil eines SQL-Befehls unter Verwendung extern beeinflusster Eingaben von einer vorgelagerten Komponente, neutralisiert aber spezielle Elemente nicht oder falsch, die den beabsichtigten SQL-Befehl verändern könnten, wenn er an eine nachgelagerte Komponente gesendet wird. Diese Schwachstelle kann mit dynamischen Werkzeugen und Techniken aufgedeckt werden, die mit der Software interagieren, indem sie große Testsuiten mit vielen verschiedenen Eingaben verwenden, wie z. B. Fuzz-Testing (Fuzzing), Robustheitstests und Fehlerinjektion. Der Betrieb der Software kann sich verlangsamen, aber sie sollte nicht instabil werden, abstürzen oder falsche Ergebnisse liefern. Eine manuelle Analyse kann nützlich sein, um diese Schwachstellen zu finden, aber es kann sein, dass sie nicht die gewünschte Codeabdeckung innerhalb eines begrenzten Zeitrahmens erreicht. Schwierig wird dies bei Schwachstellen, die für alle Eingaben berücksichtigt werden müssen, da die Angriffsfläche zu groß sein kann. Bei allen Sicherheitsprüfungen, die auf der Client-Seite durchgeführt werden, ist sicherzustellen, dass diese Prüfungen auf der Server-Seite dupliziert werden, um CWE-602 zu vermeiden. Angreifer können die clientseitigen Überprüfungen umgehen, indem sie Werte ändern, nachdem die Überprüfungen durchgeführt wurden, oder indem sie den Client ändern, um die clientseitigen Überprüfungen ganz zu entfernen. Diese geänderten Werte würden dann an den Server übermittelt. Wenn die Menge der zulässigen Objekte, wie z. B. Dateinamen oder URLs, begrenzt oder bekannt ist, erstellen Sie eine Zuordnung von einer Reihe fester Eingabewerte (z. B. numerische IDs) zu den tatsächlichen Dateinamen oder URLs und lehnen alle anderen Eingaben ab. Verwenden Sie eine Anwendungsfirewall, die Angriffe auf diese Schwachstelle erkennen kann. Dies kann in Fällen von Vorteil sein, in denen der Code nicht korrigiert werden kann (weil er von einem Dritten kontrolliert wird), als Notfall-Präventionsmaßnahme, während umfassendere Software-Assurance-Maßnahmen angewandt werden, oder zur Gewährleistung einer umfassenden Verteidigung. Wenn Sie PHP verwenden, konfigurieren Sie die Anwendung so, dass sie register_globals nicht verwendet. Entwickeln Sie bei der Implementierung die Anwendung so, dass sie nicht auf diese Funktion angewiesen ist, aber seien Sie vorsichtig bei der Implementierung einer register_globals-Emulation, die Schwachstellen wie CWE-95, CWE-621 und ähnlichen Problemen unterliegt. SQL-Injection in Zeit- und Abrechnungssoftware, wie sie in freier Wildbahn per CISA KEV ausgenutzt wird. SQL-Injektion in ein Dateiübertragungssystem über einen manipulierten Host-Header, wie sie in freier Wildbahn gemäß CISA KEV ausgenutzt wurde. SQL-Injektion in die Verwaltungsoberfläche oder das Benutzerportal eines Firewall-Produkts, die laut CISA KEV in freier Wildbahn ausgenutzt wurde. Ein in Go geschriebenes Automatisierungssystem enthält eine API, die für SQL-Injection anfällig ist und es dem Angreifer ermöglicht, privilegierte Daten zu lesen. chain: SQL-Injektion in eine Bibliothek, die für die Datenbankauthentifizierung vorgesehen ist, ermöglicht SQL-Injektion und Umgehung der Authentifizierung. SQL-Injektion durch eine ID, die eigentlich numerisch sein sollte. SQL-Injektion durch eine ID, die eigentlich numerisch sein sollte. SQL-Injektion über den Benutzernamen. SQL-Injektion über Benutzernamen oder Passwortfelder. SQL-Injektion in ein Sicherheitsprodukt unter Verwendung eines manipulierten Gruppennamens. SQL-Injektion in die Authentifizierungsbibliothek. SQL-Injektion in ein Tool zur Verwaltung von Schwachstellen und zur Erstellung von Berichten, unter Verwendung eines manipulierten Passworts.
Referenzen
CPE
| cpe |
start |
ende |
| Configuration 1 |
| cpe:2.3:a:automatic_question_paper_generator_system_project:automatic_question_paper_generator_system:1.0:*:*:*:*:*:*:* |
|
|
REMEDIERUNG
EXPLOITS
Exploit-db.com
| id |
beschreibung |
datum |
|
| Keine bekannten Exploits |
Andere (github, ...)
| Url |
| Keine bekannten Exploits |
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
beschreibung |
schweregrad |
| 108 |
Command Line Execution through SQL Injection
Ein Angreifer verwendet Standard-SQL-Injection-Methoden, um Daten zur Ausführung in die Befehlszeile zu injizieren. Dies kann direkt durch den Missbrauch von Direktiven wie MSSQL_xp_cmdshell oder indirekt durch die Einspeisung von Daten in die Datenbank geschehen, die als Shell-Befehle interpretiert werden. Irgendwann später holt eine skrupellose Backend-Anwendung (oder könnte Teil der Funktionalität derselben Anwendung sein) die injizierten, in der Datenbank gespeicherten Daten ab und verwendet diese Daten als Befehlszeilenargumente, ohne eine ordnungsgemäße Validierung durchzuführen. Die bösartigen Daten entkommen dieser Datenebene, indem sie neue Befehle erzeugen, die auf dem Host ausgeführt werden. [Der Angreifer injiziert SQL-Syntax in benutzerkontrollierbare Dateneingaben, um die ungefilterte Ausführung der SQL-Syntax in einer Abfrage zu suchen. [Der Angreifer nutzt einen SQL-Injection-Angriff aus, um Shell-Code zu injizieren, der unter Ausnutzung der xp_cmdshell-Direktive ausgeführt werden soll. [Einschleusen bösartiger Daten in die Datenbank] Der Angreifer nutzt SQL-Injection, um Daten in die Datenbank einzuschleusen, die später zur Befehlsinjektion verwendet werden können, wenn sie als Befehlszeilenargument verwendet werden [Auslösen der Befehlszeilenausführung mit eingeschleusten Argumenten] Der Angreifer veranlasst die Ausführung von Befehlszeilenfunktionen, die zuvor eingeschleuste Datenbankinhalte als Argumente nutzen. |
Sehr hoch |
| 109 |
Objektrelationale Mapping-Injektion
Ein Angreifer nutzt eine Schwäche im Code der Datenbankzugriffsschicht, der mit einem ORM-Tool (Object Relational Mapping) generiert wurde, oder eine Schwäche in der Art und Weise, wie ein Entwickler ein Persistenz-Framework verwendet hat, um eigene SQL-Befehle zu injizieren, die gegen die zugrunde liegende Datenbank ausgeführt werden. Der Angriff hier ähnelt der einfachen SQL-Injektion, mit dem Unterschied, dass die Anwendung nicht JDBC verwendet, um direkt mit der Datenbank zu kommunizieren, sondern eine Datenzugriffsschicht nutzt, die von einem ORM-Tool oder -Framework (z. B. Hibernate) generiert wurde. Obwohl der von einem ORM-Tool generierte Code in den meisten Fällen sichere Zugriffsmethoden enthält, die gegen SQL-Injektion immun sind, ist eine SQL-Injektion manchmal dennoch möglich, entweder aufgrund einer Schwäche im generierten Code oder aufgrund der Tatsache, dass der Entwickler die generierten Zugriffsmethoden nicht richtig verwendet hat. [Verwendetes Persistenz-Framework ermitteln] Ein Angreifer versucht herauszufinden, welches Persistenz-Framework von der Anwendung verwendet wird, um eine Schwäche im generierten Code der Datenzugriffsschicht oder eine Schwäche in der Art und Weise, wie die Datenzugriffsschicht möglicherweise vom Entwickler verwendet wurde, auszunutzen. [Auf ORM-Injection-Schwachstellen testen] Der Angreifer injiziert ORM-Syntax in vom Benutzer kontrollierbare Dateneingaben der Anwendung, um festzustellen, ob es möglich ist, die Struktur und den Inhalt von Datenabfragen zu ändern. SQL Injection über die generierte Datenzugriffsschicht durchführen] Ein Angreifer nutzt eine Schwachstelle in den generierten Datenzugriffsmethoden aus, die die Kontrollebene nicht ordnungsgemäß vom Datenplan trennt, oder möglicherweise eine bestimmte Art und Weise, wie der Entwickler den generierten Code missbraucht haben könnte, um die Struktur der ausgeführten SQL-Abfragen zu ändern und/oder völlig neue SQL-Abfragen zu injizieren. |
Hoch |
| 110 |
SQL Injection durch SOAP-Parameter-Manipulation
Ein Angreifer ändert die Parameter der SOAP-Nachricht, die vom Dienstkonsumenten an den Dienstanbieter gesendet wird, um einen SQL-Injection-Angriff zu initiieren. Auf der Seite des Dienstanbieters wird die SOAP-Nachricht geparst und die Parameter werden nicht ordnungsgemäß validiert, bevor sie für den Zugriff auf eine Datenbank auf eine Art und Weise verwendet werden, die keine Parameterbindung verwendet, wodurch der Angreifer die Struktur der ausgeführten SQL-Abfrage kontrollieren kann. Dieses Muster beschreibt einen SQL-Injection-Angriff, wobei der Übermittlungsmechanismus eine SOAP-Nachricht ist. Detect Incorrect SOAP Parameter Handling] Der Angreifer manipuliert die Parameter der SOAP-Nachricht und sucht nach Anzeichen dafür, dass die Manipulation eine Änderung im Verhalten der Zielanwendung verursacht hat. [Probe for SQL Injection vulnerability] Der Angreifer injiziert SQL-Syntax in anfällige SOAP-Parameter, die in der Explore-Phase identifiziert wurden, und sucht nach der ungefilterten Ausführung der SQL-Syntax in einer Abfrage. SQL-Injektion über SOAP-Parameter] Der Angreifer injiziert SQL über SOAP-Parameter, die in der Explore-Phase als anfällig identifiziert wurden, um einen SQL-Injektionsangriff erster oder zweiter Ordnung zu starten. |
Sehr hoch |
| 470 |
Ausweitung der Kontrolle über das Betriebssystem von der Datenbank aus
Ein Angreifer ist in der Lage, den Zugriff auf die Datenbank zu nutzen, um Daten im Dateisystem zu lesen/schreiben, das Betriebssystem zu kompromittieren, einen Tunnel für den Zugriff auf den Host-Rechner zu erstellen und diesen Zugriff zu nutzen, um möglicherweise andere Rechner im selben Netzwerk wie den Datenbankrechner anzugreifen. Traditionell werden SQL-Injektionsangriffe als eine Möglichkeit angesehen, unbefugten Lesezugriff auf die in der Datenbank gespeicherten Daten zu erlangen, die Daten in der Datenbank zu ändern, die Daten zu löschen usw. Fast jedes Datenbankmanagementsystem (DBMS) verfügt jedoch über Funktionen, die einem Angreifer vollständigen Zugriff auf das Dateisystem, das Betriebssystem und den Host, auf dem die Datenbank läuft, ermöglichen, wenn er kompromittiert wird. Der Angreifer kann dann diesen privilegierten Zugang nutzen, um weitere Angriffe zu starten. Zu diesen Möglichkeiten gehören das Aufrufen einer Befehlsshell, das Erstellen von benutzerdefinierten Funktionen, die auf dem Host-Rechner vorhandene Bibliotheken auf Systemebene aufrufen können, gespeicherte Prozeduren usw. Der Angreifer identifiziert ein Datenbankmanagementsystem, das auf einem Rechner läuft, über den er die Kontrolle erlangen möchte, oder in einem Netzwerk, in dem er sich seitlich bewegen möchte. Der Angreifer geht die typischen Schritte einer SQL-Injektion durch und stellt fest, ob eine Injektion möglich ist. Sobald der Angreifer feststellt, dass eine SQL-Injection möglich ist, muss er sicherstellen, dass die Voraussetzungen für den Angriff erfüllt sind. Dazu gehören ein hoch privilegierter Sitzungsbenutzer und die Unterstützung von Stapelabfragen. Dies geschieht auf ähnliche Weise wie die Feststellung, ob eine SQL-Injection möglich ist. Wenn die Voraussetzungen erfüllt sind, wird der Angreifer auf der Grundlage des verwendeten Datenbankverwaltungssystems benutzerdefinierte Funktionen (UDFs) finden oder erstellen, die als DLLs geladen werden können. Ein Beispiel für eine DLL finden Sie unter https://github.com/rapid7/metasploit-framework/tree/master/data/exploits/mysql. Um die DLL zu laden, muss der Angreifer zunächst den Pfad zum Plugin-Verzeichnis finden. Der entsprechende Befehl ist je nach DBMS-Typ unterschiedlich, aber für MySQL kann dies durch Ausführen des Befehls "select @@plugin_dir" erreicht werden. Die DLL wird dann in das zuvor gefundene Plugin-Verzeichnis verschoben, damit die enthaltenen Funktionen geladen werden können. Dies kann auf verschiedene Weise geschehen: Laden von einer Netzwerkfreigabe, Schreiben der gesamten hexadezimalkodierten Zeichenfolge in eine Datei im Plugin-Verzeichnis oder Laden der DLL in eine Tabelle und dann in eine Datei. Ein Beispiel für das Laden der Hex-Zeichenkette mit MySQL lautet wie folgt. select 0x4d5a9000... into dump file "{Plugin-Verzeichnis}udf.dll"; Sobald sich die DLL im Plugin-Verzeichnis befindet, wird ein Befehl zum Laden der UDFs ausgeführt. Ein Beispiel hierfür in MySQL ist "create function sys_eval returns string soname 'udf.dll';" Die Funktion sys_eval ist spezifisch für die oben aufgeführte Beispiel-DLL. Sobald der Angreifer die gewünschte(n) Funktion(en) geladen hat, wird er diese verwenden, um beliebige Befehle auf dem kompromittierten System auszuführen. Dies geschieht durch einen einfachen Select-Befehl an die geladene UDF. Zum Beispiel: "select sys_eval('dir');". Da die Voraussetzung für diesen Angriff ist, dass der Benutzer der Datenbanksitzung ein Superuser ist, bedeutet dies, dass der Angreifer in der Lage ist, Befehle mit erhöhten Rechten auszuführen. |
Sehr hoch |
| 66 |
SQL-Einschleusung
Dieser Angriff nutzt Zielsoftware aus, die SQL-Anweisungen auf der Grundlage von Benutzereingaben konstruiert. Ein Angreifer manipuliert die Eingabestrings so, dass die Zielsoftware SQL-Anweisungen auf der Grundlage der Eingaben erstellt und die resultierende SQL-Anweisung andere als die von der Anwendung beabsichtigten Aktionen ausführt. SQL Injection resultiert aus dem Versagen der Anwendung, Eingaben angemessen zu validieren. [Der Angreifer nimmt zunächst eine Bestandsaufnahme der von der Anwendung bereitgestellten Funktionen vor. [Bestimmen Sie die benutzerkontrollierbaren Eingaben, die für Injektionen anfällig sind. Für jede benutzergesteuerte Eingabe, von der der Angreifer vermutet, dass sie für SQL-Injektionen anfällig ist, versucht er, Zeichen einzufügen, die in SQL eine besondere Bedeutung haben (z. B. ein einfaches Anführungszeichen, ein doppeltes Anführungszeichen, zwei Bindestriche, eine Klammer usw.). Ziel ist es, eine SQL-Abfrage mit einer ungültigen Syntax zu erstellen. [Experimentieren Sie mit SQL-Injection-Schwachstellen] Nachdem Sie festgestellt haben, dass eine bestimmte Eingabe für SQL-Injection anfällig ist, stellen Sie Hypothesen darüber auf, wie die zugrunde liegende Abfrage aussieht. Versuchen Sie iterativ, der Abfrage Logik hinzuzufügen, um Informationen aus der Datenbank zu extrahieren oder um Informationen in der Datenbank zu ändern oder zu löschen. [Nach der Verfeinerung und dem Hinzufügen verschiedener Logiken zu SQL-Abfragen erstellen Sie die zugrundeliegende SQL-Abfrage, die für den Angriff auf das Zielsystem verwendet wird, und führen sie aus. Ziel ist es, mithilfe des im vorherigen Schritt erlangten Wissens Datenbankdaten offenzulegen, zu ändern und/oder zu löschen. Dies könnte das Erstellen und Ausführen mehrerer SQL-Abfragen erfordern, wenn ein Denial-of-Service-Angriff beabsichtigt ist. |
Hoch |
| 7 |
Blinde SQL-Injektion
Blind SQL Injection resultiert aus einer unzureichenden Mitigation für SQL Injection. Obwohl die Unterdrückung von Datenbank-Fehlermeldungen als Best Practice gilt, ist die Unterdrückung allein nicht ausreichend, um SQL Injection zu verhindern. Blind SQL Injection ist eine Form der SQL Injection, die das Fehlen von Fehlermeldungen überwindet. Ohne die Fehlermeldungen, die SQL Injection erleichtern, konstruiert der Angreifer Eingabestrings, die das Ziel durch einfache boolesche SQL-Ausdrücke abfragen. Der Angreifer kann anhand der Ausführung der Abfrage feststellen, ob die Syntax und Struktur der Injektion erfolgreich war oder nicht. Iterativ angewandt, bestimmt der Angreifer, wie und wo das Ziel für SQL Injection anfällig ist. [Hypothesen zu SQL-Abfragen in der Anwendung aufstellen] [Bestimmen, wie Informationen in die Abfragen injiziert werden können] [Vom Benutzer steuerbare Eingaben bestimmen, die für Injektionen anfällig sind] Bestimmen Sie die vom Benutzer steuerbaren Eingaben, die für Injektionen anfällig sind. Versuchen Sie für jede benutzerkontrollierbare Eingabe, von der der Angreifer vermutet, dass sie für SQL-Injection anfällig ist, die im vorherigen Schritt ermittelten Werte zu injizieren. Wenn kein Fehler auftritt, weiß der Angreifer, dass die SQL-Injektion erfolgreich war. Datenbanktyp ermitteln] Ermittelt den Typ der Datenbank, z. B. MS SQL Server oder Oracle oder MySQL, mithilfe logischer Bedingungen als Teil der injizierten Abfragen [Informationen über das Datenbankschema extrahieren] Extrahiert Informationen über das Datenbankschema, indem er die Datenbank dazu bringt, Ja/Nein-Fragen über das Schema zu beantworten. SQL-Injection-Schwachstelle ausnutzen] Verwenden Sie die in den vorherigen Schritten erhaltenen Informationen, um die Datenbank erfolgreich zu injizieren, um Prüfungen zu umgehen oder Daten in der Datenbank zu ändern, hinzuzufügen, abzurufen oder zu löschen. |
Hoch |
MITRE
Sherlock® flash
Machen Sie mit wenigen Klicks ein Foto von Ihrem Computernetzwerk !
Mit der Sherlock® flash Audit-Lösung können Sie ein Audit durchführen, um die Sicherheit Ihres Computerbestands zu erhöhen. Scannen Sie Ihre physischen und virtuellen Geräte auf Schwachstellen. Planung von Patches nach Priorität und verfügbarer Zeit. Detaillierte und intuitive Berichte.
Entdecke dieses Angebot
