Amazon Redshift JDBC-Treiber: SQL Injection durch Kommentare

Table of Contents

Eine kritische Sicherheitslücke wurde in bestimmten Versionen des Amazon Redshift JDBC-Treibers entdeckt, die zu einer SQL Injection führen kann. Diese Schwachstelle CVE-2024-32888 betrifft die Nutzung der nicht-standardmäßigen Verbindungseigenschaft preferQueryMode=simple in Kombination mit anfälligem SQL-Code, der einen Parameterwert negiert. Der Fehler gleicht der Schwachstelle CVE-2024-1597 im Posgresql-JDBC Treiber.

  • com.amazon.redshift:redshift-jdbc42 (Maven)
  • Versionen ≤ 2.1.0.26

Die Sicherheitslücke wurde in der folgenden Version behoben:

  • 2.1.0.28

Die SQL Injection tritt auf, wenn die Verbindungseigenschaft preferQueryMode=simple verwendet wird und der SQL-Code Parameterwerte negiert. Der Standardmodus des Treibers ist nicht betroffen. Nutzer, die den Standardmodus verwenden, sind sicher. Es ist wichtig zu beachten, dass preferQueryMode kein unterstützter Parameter im Redshift JDBC-Treiber ist und von PostgreSQL JDBC-Treiber geerbter Code ist.

Bedingungen für die Ausnutzung:

  1. Ein Platzhalter für einen numerischen Wert muss unmittelbar von einem Minuszeichen (-) gefolgt sein.
  2. Ein zweiter Platzhalter für einen String-Wert muss nach dem ersten Platzhalter in derselben Zeile stehen.
  3. Beide Parameter müssen vom Benutzer kontrolliert werden.

Wenn diese Bedingungen erfüllt sind, kann der Treiber im einfachen Abfragemodus den negativen Wert des ersten Parameters inline setzen, wodurch die resultierende Zeile als SQL-Kommentar behandelt wird. Dadurch wird die Anführungszeichen des zweiten Parameters konsumiert, und wenn dieser eine neue Zeile enthält, erscheint der resultierende Text unescaped im finalen SQL-Befehl.

Beispiel:

PreparedStatement stmt = conn.prepareStatement("SELECT -?, ?");
stmt.setInt(1, -1);
stmt.setString(2, "\nWHERE false --");
ResultSet rs = stmt.executeQuery();

Im einfachen Abfragemodus würde das resultierende SQL wie folgt aussehen:

SELECT --1,'
WHERE false --'

Der Inhalt des zweiten Parameters wird in den Befehl injiziert, was zu Änderungen an der Anzahl der Ergebnisspalten und der WHERE-Klausel führt. Ein ausgeklügelteres Beispiel könnte andere SQL-Befehle ausführen.

Auswirkungen

Die Auswirkungen dieser Sicherheitslücke sind schwerwiegend:

  • Vertraulichkeit: Hohe Gefahr durch den möglichen Diebstahl von sensiblen Informationen.
  • Integrität: Hohe Gefahr durch die Möglichkeit, Daten zu manipulieren.
  • Verfügbarkeit: Hohe Gefahr durch die Möglichkeit, die Anwendung zu stören.

Um die Sicherheitslücke zu beheben, sollten Benutzer ihre JDBC-Treiber auf die gepatchte Version 2.1.0.28 aktualisieren. Alternativ kann die Verwendung der Verbindungseigenschaft preferQueryMode=simple vermieden werden. Standardmäßig verwenden die meisten Installationen den erweiterten Abfragemodus, der nicht von dieser Schwachstelle betroffen ist.

Benutzer des Amazon Redshift JDBC-Treibers sollten umgehend handeln, um diese kritische Sicherheitslücke zu beheben und ihre Systeme vor möglichen SQL Injection-Angriffen zu schützen. Eine Aktualisierung auf die neueste Version des Treibers oder die Vermeidung des einfachen Abfragemodus kann einen erheblichen Beitrag zur Sicherheit der Anwendung leisten.

Related Posts

Check Point warnt vor lauernden Gefahren im Foxit PDF-Reader

Eine offene Schwachstelle wird derzeit von Hackern für Phishing ausgenutzt

Read More

Privilege Escalation in D-Link Router DIR-X4860 möglich

Eine Sicherheitslücke CVE-2024-34070 im D-Link Router DIR-X4860 ermöglicht es Angreifern, die über den HNAP-Port (HTTP Network Access Protocol) zugreifen können, erhöhte Privilegien zu erlangen und Befehle als root auszuführen. Durch die Kombination einer Authentifizierungsumgehung mit der Befehlsausführung kann das Gerät vollständig kompromittiert werden.

Read More

PostgreSQL: COPY-Befehl erlaubt System-Shell Zugriff

PostgreSQL hat sich als robustes und flexibles Datenbanksystem etabliert. Dennoch gibt es bestimmte Funktionen, die von Angreifern ausgenutzt werden können, wenn sie nicht ordnungsgemäß gesichert sind. Eine solche Funktion ist der COPY-Befehl, der sich als Achillesferse von PostgreSQL herausgestellt hat. Nachfolgend wird erläutert, warum dieser Befehl bei Hackern beliebt ist und wie er ausgenutzt werden kann.

Read More