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

Hackerangriff auf Landtechnik Hersteller Lemken stoppt Produktion

Der Landtechnikhersteller Lemken ist Opfer eines Hackerangriffs geworden, der das Unternehmen zur Einstellung der Produktion gezwungen hat. Seit dem Angriff am Samstag, dem 11. Mai 2024, bleiben an den Standorten weltweit viele Bildschirme schwarz und die Produktion ist zum Erliegen gekommen.

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

Froxlor: Blind XSS Schwachstelle führt zur vollständigen Kompromittierung

In der beliebten Webhosting-Management-Software Froxlor wurde eine schwerwiegende Sicherheitslücke entdeckt. Blind Cross-Site Scripting (Blind XSS) Schwachstelle ermöglicht es Angreifern, die Kontrolle über die Anwendung zu übernehmen. Diese Sicherheitslücke wurde unter der CVE-Nummer CVE-2024-34070 registriert und betrifft alle Versionen vor 2.1.9.

Read More