SQL-Injektion bei Produktionsanlagen

wollbit

Level-2
Beiträge
51
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Tag alle zusammen.
Ich habe mich in den letzten Tagen mit dem Thema SQL-Injektion bei Produktionsanlagen auseinandergesetzt und wollte euch hier meine Ergebnisse mitteilen, da ich dieses Thema für wichtig halte und hier noch nichts dazu gefunden habe.
Das Ganze wurde an einem Testaufbau ausprobiert.

Bitte schreibt mir, wenn etwas nicht passt oder fehlt.
Etwas genauer ist das Ganze im Artikel von Microsoft beschrieben.


Was ist eine SQL-Injektion? (Beispiel)

Wenn Daten von einem SQL-Server abgefragt oder gespeichert werden sollen, werden dafür bestimmte SQL-Befehle genutzt.

In diesem Beispiel werden drei Werte (Strings) in die Tabelle Material eingetragen.
SQL:
insert into Material values ('MaterialID','MaterialAnzahl','MaterialBeschreibung')

Bei einer SQL-Injektion wird eine Variable eines SQL-Befehls so manipuliert, dass der eigentliche Befehl verändert oder eine zweiter angehangen wird.

Wenn der String 'MaterialBeschreibung' diesen Inhalt hat,
SQL:
x');drop table Material --

würde der ganze SQL-Befehl so aussehen:
SQL:
insert into Material values ('MaterialID','MaterialAnzahl','x');drop table Material --')

Der erste Befehl ist somit gültig.
SQL:
insert into Material values ('MaterialID','MaterialAnzahl','x')

Nach dem Semikolon wird dann allerdings der zweite Befehl ausgeführt.
SQL:
drop table Material
Dies würde die Tabelle löschen. Dafür muss der Angreifer aber den Tabellennamen kennen oder Glück beim Raten haben.

Mit den beiden Minuszeichen wird der Rest als Kommentar markiert.
SQL:
--')


Wo ist diese Schwachstelle nutzbar?
Die Schwachstelle ist dort nutzbar, wo Strings von außen in die Anlage gelangen und von dort in eine SQL-Datenbank geschrieben werden.
Das können z. B. Eingabefelder für Benutzer am Panel, Barcode Lesegeräte oder RFID Lesegeräte sein.
Beispiel: Material wird angeliefert und der Barcode an der Anlage mit einem Lesegerät gescannt. Jeder in der Lieferkette könnte den Barcode austauschen.


Wie kann die Ausnutzung verhindert werden?
Tabellen besser nicht Material nenne.
Länge der Strings auf die notwendige Größe reduzieren.
Wenn die Zeichen ; und ‘ entfernt werden, würde der Befehl einen Syntaxfehler erzeugen und somit nicht ausgeführt.
Mehr im Artikel von Microsoft.


Testaufbau und Quellen
Für den Testaufbau wurde eine S7 1511 und ein Microsoft SQL-Server genutzt.

Kommunikation S7 SQL-Server:

Artikel von Microsoft zu diesem Thema:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
oder die Daten nicht direkt als ein Befehl senden, sondern an eine Schnittstelle (z.B API Rest, etc.)
"Material;MaterialId;MaterialName;MaterialMenge"
Dann muss bei der Schnittstelle eine Prüfung erfolgen. Wenn der String nur weitergeschoben wird, löst das nicht das Problem.
 
Dann muss bei der Schnittstelle eine Prüfung erfolgen.
Aber sicher doch:

"Solange der eingefügte SQL-Code syntaktisch richtig ist, kann eine Manipulation nicht programmgesteuert erkannt werden. Aus diesem Grund müssen Sie die Gültigkeit aller Benutzereingaben überprüfen und sorgfältig den Code überprüfen, der in dem von Ihnen verwendeten Server die erstellten SQL-Befehle ausführt."
 
Hi
Ja prüfen schon, aber man hat nun die Möglichkeit. Oder man verwendet danach z.B. entity framework um in die DB zu schreiben, diese soll ja injection sicher sein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Frage an den TE:

Was willst du uns mit dem Beitrag sagen? SQL-Injections sind ein alter Hut und einer der Klassiker unter den Sicherheitslücken.

Solche Dinge passieren heute auch erfahrenen Software - Entwicklern in IT-Umgebungen immer wieder.

Der eigentliche Unsinn (und imho die Wurzel dieses Beitrags) ist, dass man eine SPS direkt auf eine SQL-Datenbank zugreifen lässt - und sich Leute bei Siemens anmaßen, für sowas ein "Anwendungsbeispiel" online zu stellen, und dabei eine Zielgruppe ansprechen, die oftmals schon mit den Begriffen UTF8 und 'nullterminierter' string überfordert sind. Dass hier nur nonsense rauskommen kann und jede Menge Sicherheitslücken liegt auf der Hand.

Die Leute beim SIOS vergessen immer wieder zu warnen, dass das was sie da abliefern lediglich ein Proof-of-concept ist - nicht mehr und nicht weniger! Die Anwender sollten sich dessen bewusst sein!

Ein anschauliches Beispiel, was passiert wenn man packages unreflektiert einfach einsetzt, hat uns Log4Shell geliefert.
 
Was willst du uns mit dem Beitrag sagen? SQL-Injections sind ein alter Hut und einer der Klassiker unter den Sicherheitslücken.
Die Leute beim SIOS vergessen immer wieder zu warnen, dass das was sie da abliefern lediglich ein Proof-of-concept ist - nicht mehr und nicht weniger! Die Anwender sollten sich dessen bewusst sein!
Nicht jedem ist das bekannt. Ich habe das hier noch nicht gelesen.
 
Ja, warum nicht auf so etwas hinweisen? Nicht immer ist das für einen selbst wichtig und nicht immer muß etwas passieren, aber zumindest hat man eine Idee davon.
 
Zurück
Oben