Ich habe bereits über Ideen geschrieben, die TrojanSource-Vulnerability in anderen Kontexten zu untersuchen - ein Vorkommnis in dem Job, mit dem ich mir das Geld für Kuchen verdiene hat mich jetzt angestachelt, diese Untersuchung tatsächlich umfangreich und gründlich durchzuführen. Dieser Beitrag wurde zum CCC End-of-year event 2021 eingereicht und abgelehnt.

Die Quellen der Präsentation, die ich eingereicht hatte sind hier zu finden, die Präsentation selbst ist hier live zu betrachten.

Die Überschrift ist reißerisch und drückt nur einen kleinen - von mir tatsächlich untersuchten - Bereich des interessanten Gebiets aus. Ich hatte ja bereits untersucht, ob man mit Unicode-Control-Characters in einer Datenbank Unfug anstellen kann - das Ergebnis war positiv.

Durch den schon angedeuteten Auslöser wurde ich motiviert, nachzusehen, ob es nicht auch möglich wäre, die im urprünglichen Paper vorgestellten Angriffsszenarien in SQL-Skripten umzusetzen. Ich suchte mir dazu das Szenario des Auskommentierens aus - Dabei wird Code, der bei oberflächlicher Inspektion durch einen Reviewer als Kommentar wahrgenommen wird in Wirklichkeit durch das Zielsystem als Code interpretiert und so ausgeführt.

Mein Ansatz war, durch einen Kommentar eine WHERE-Klausel in einem SQL-Statement unwirksam zu machen - ganz ähnlich den berühmten SQL-Injection-Angriffen und doch anders. Das Ziel war also, dass ein Reviewer das SQL-Fragment wie folgt wahrnimmt:

select * from example where name<>'John' -- this is a comment

während der Computer (die Datenbank) das folgende Statement ausführt:

select * from example where name<>'John -- this is a comment'

Dafür müssen zwei Ziele erreicht werden:

  1. Der Reviewer muss anderen Text sehen, als die Datenbank verarbeitet
  2. Die Anreicherung mit Unicode-Control-Characters darf bei der Ausführung der manipulieren Statements nicht zu Syntaxfehlern führen
Ich habe zur Untersuchung von Punkt 1 verschiedene Systeme untersucht:

  • Source code management
    • Gitlab
    • Github
    • Gitea
  • Editors (IDE)
    • Gedit
    • Kate
    • Terminal (vim, joe, nano)
    • Intellij Idea
  • Database tools
    • SQL Developer
    • MSSQL Server Studio
    • sQLshell
    • phpMyAdmin
    • pgAdmin
Zur Untersuchung von Punkt 2 wurden folgende Datenbanksysteme getestet:

  • Postgres
  • MS SQL Server
Zunächst stellte ich also mit Punkt 1 die Frage: Kann ein Reviewer die Probleme erkennen? Wie man hier sieht, kann dies sehr schwierig werden: Der Unterschied zwischen dem gültigen und dem manipulierten SQL besteht nur in der unterschiedlichen Einfärbung des Kommentars - eine Feinheit, die im stressigen Arbeitsalltag aus meiner Sicht leicht übersehen werden kann:

Screenshot Gültiges SQL Statement

Screenshot Manipuliertes SQL Statement

Dieses Verhalten zeigen viele der untersuchten Anwendungen.

Für die Anwendungen aus dem Bereich Source Code Management wurde untersucht, wie manipulierte Quelltexte gehandhabt werden - und dies in folgenden Bereichen:

  • eingecheckte Quelltexte
  • Skizzen (Gists)
  • Beschreibungen und Kommentare von Issues
Alle drei von mir untersuchten Systeme wurden durch die Autoren des ursprünglichen Papers darauf hingewiesen, dass die Verwundbarkeit existiert.

Bei Gitlab konnte ich feststellen, dass in allen untersuchten Bereichen die gleichen Maßnahmen ergriffen wurden - hier ein exemplarischer Screenshot:

Screenshot Gitlab Kommentar an einem Issue

Bei Github musste ich feststellen, dass lediglich eingecheckte Dateien und Gists eine entsprechende Warnung auslösten:

Screenshot Github Warnung an einer eingecheckten Datei

Allerdings besteht das Problem weiterhin bei Issues - sowohl in den Beschreibungen als auch Kommentaren:

Screenshot Github Kommentar an einem Issue

Ich reichte daraufhin einen Bugreport ein, der jedoch mit folgender Begründung abgelehnt wurde:

Specifically, the danger presented by the Trojan Source vulnerability
is source code that executes code that does something other than what
it displays. Code snippets inside issue comments do not get executed
and therefore do not present a direct security risk. If the code
inside of an issue comment is ever included in the source code by
adding it to a file inside of GitHub, then the warning message will
be displayed.

Überflüssig zu erwähnen, dass ich die dadurch entstehende Bedrohung als durchaus real ansehe. Ich denke da zum Beispiel an die beliebten Phishing-Mails, die den Einfruck erwecken, als stammten sie vom Chef - wenn es jemand schafft, einen Github-Account zu kapern und dann legitim erscheinende Kommentare zu hinterlassen wie etwa "Kannst Du das folgende SQL bitte im Wirkbetrieb einspielen - sollte den Incident xy lösen" wäre das ein möglicher Weg, schlimme Schäden im System anzurichten.

Bei Gitea hatte ich zunächst den Eindruck, dass man von der Trojan Source Attacke noch keine Kenntnis erlangt hatte, da weder Dateien noch andere Aspekte irgendwie vor entsprechend manipuliertem Text warnten:

Screenshot Gitea, eingecheckte Datei

Mein Bugreport wurde sehr schnell mit dem Hinweis auf einen Pullrequest beantwortet. Man diskutiert also bereits sehr lange über die Ausgestaltung der Warnung, vergisst aber, diese aktiv zu schalten. Aus meiner Sicht ein eher fragwürdiges Herangehen an das Problem.

Für die Editoren/IDEs lasse ich hier die entsprechenden Screenshots sprechen:

Screenshot Gedit - mangelhaft

Screenshot Kate - mangelhaft

Screenshot Vim - ausreichend

Screenshot Joe - hervorragend

Screenshot Nano - verwirrend

Screenshot Intellij Idea - hervorragend

Auch für die Datenbank-Tools werden wieder die Screenshots sprechen:

Screenshot SQL-Developer - ausreichend

Screenshot MS SQL Server Studio - hervorragend

Screenshot sQLshell - ausreichend

An dieser Stelle sei eine kurze Ausschweifung gestattet: Die Sprache Java wurde zwar im ursprünglichen Paper bereits behandelt - allerdings nur in ihrer kompilierten Form.

Es existiert aber noch das Projekt BeanShell, das Java-Code zur Laufzeit interpretieren und ausführen kann. Dafür wiederum existiert mit der BeanShell Konsole eine REPL-Umgebung, die in der aktuellen Release gegen entsprechende Angriffe keinen Schutz bietet, da kein Syntax-Highlighting erfolgt:

Screenshot BeanShell Konsole in aktueller Release

Ich forkte daher die aktuelle Snapshot-Version und ereichte damit zumindest ein Syntax-Highlighting, das bei aufmerksamem Lesen auf solche Probleme aufmerksam machen würde:

Screenshot Aktuelle Snapshot-Version der BeanShell Konsole mit meinen Änderungen

Im Zuge dieser Untersuchungen führte ich den bereits als Screenshot bei der sQLshell gezeigten Dialog.

Beide untersuchten Datenbanken zeigten, dass die in das SQL-Statement eingestreuten Unicode-Control-Characters keine Syntaxverletzungen hervorriefen und die Statements verarbeitet wurden - damit ist dann auch klar, dass solche Angriffe erfolgreich sein können - die folgenden Screenshots zeigen eine Tabelle mit beispieldaten und das erwartete Resultat verglichen mit dem tatsächlichen:

Screenshot Beispiel-Tabelle mit Daten

Screenshot Erwartetes Ergebnis

Screenshot Tatsächliches Ergebnis

Hierauf aufbauend könnte man weitere Analysen vornehmen - beispielsweise:

  • Trojan NoSQL
  • Andere interpretierte oder Domain Specific Languages
  • andere Projekte überzeugen, entsprechende Gegenmaßnahmen zu ergreifen

Artikel, die hierher verlinken

Release der Gegenmaßnahmen gegen Trojan Source und Trojan SQL

19.12.2023

Mit Version 1.4.0 wurden die Gegenmaßnahmen gegen Trojan Source und Trojan SQL endlich in einer Release auf Repsy zur Verfügung gestellt.

Jahresendveranstaltung des CCC - mit mir!

02.01.2023

Ich habe dieses mal an der Jahresendveranstaltung des CCC aktiv mitgewirkt - nachdem mein Beitrag letztes Jahr ja noch abgelehnt worden war.

BeanShell 3.0.0-SNAPSHOT Fork sofort aktualisieren!

12.09.2022

Ich habe heute einen Bug in der OpenSource-Variante der BeanShell auf GutHub gefunden, dessen Behandlung mich wieder einmal ziemlich sprachlos zurückgelassen hat...

Trojan Source - Nachschlag

15.03.2022

Ich habe weitere interessante Fakten zu der Trojan Source Attacke des letzten Jahres ausgegraben...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Aviator + Websockets

    15.06.2019

    Nachdem ich in den letzten Wochen und Monaten meine Zeit und Energie in die sQLshell gesteckt habe - was sowohl Bugfixing als auch neue Features betraf - habe ich nun endlich die Zeit gefunden, ein bereits lange überfälliges Feature an dWb+ und speziell am aviator zu implementieren.

    Weiterlesen...

Neueste Artikel

  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...
  • Apache HTTPCore5 funktioniert nicht mit Docker

    Ich habe neulich drei Stunden meines Lebens verschwendet weil ich unbedingt die neueste Version der HTTPCore5 Library von Apache einsetzen wollte.

    Weiterlesen...
  • Entwurfsmodus für beliebige SVG Graphiken

    Nachdem ich in der Vergangenheit immer wieder Weiterentwicklungen der Idee vorgestellt habe, Graphiken mit dem Computer so zu ezeugen dass sie eine gewisse "handgemachte" Anmutung haben, habe ich nunmehr die durchschlagende Idee gehabt:

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.