# SQL-Injektion bei Produktionsanlagen



## byfluffy (16 Februar 2022)

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.

```
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,

```
x');drop table Material --
```

würde der ganze SQL-Befehl so aussehen:

```
insert into Material values ('MaterialID','MaterialAnzahl','x');drop table Material --')
```

Der erste Befehl ist somit gültig.

```
insert into Material values ('MaterialID','MaterialAnzahl','x')
```

Nach dem Semikolon wird dann allerdings der zweite Befehl ausgeführt.

```
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.

```
--')
```


*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:





						SIOS
					






					support.industry.siemens.com
				





			https://cache.industry.siemens.com/dl/files/336/109779336/att_1054000/v2/109779336_SQL_S7_1500_DOC_de_V21.pdf
		


Artikel von Microsoft zu diesem Thema:








						SQL Injection - SQL Server
					

Hier erfahren Sie, wie Angriffe durch Einschleusung von SQL-Befehlen funktionieren. Schützen Sie sich vor solchen Angriffen, indem Sie Eingaben validieren und Code für die Einschleusung von SQL-Befehlen in SQL Server überprüfen.



					docs.microsoft.com


----------



## blimaa (16 Februar 2022)

byfluffy schrieb:


> Wie kann die Ausnutzung verhindert werden?


oder die Daten nicht direkt als ein Befehl senden, sondern an eine Schnittstelle (z.B API Rest, etc.)
"Material;MaterialId;MaterialName;MaterialMenge"

oder die Daten an eine gespeicherte Prozedur senden (hat etwa den gleichen Effekt)


----------



## byfluffy (16 Februar 2022)

blimaa schrieb:


> 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.


----------



## Heinileini (16 Februar 2022)

byfluffy schrieb:


> 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."


----------



## blimaa (16 Februar 2022)

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.


----------



## maxder2te (16 Februar 2022)

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.


----------



## byfluffy (16 Februar 2022)

> 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.


----------



## Ralle (16 Februar 2022)

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.


----------



## ThomasGCH (3 April 2022)

_Never trust user input_


----------



## Reallife (6 April 2022)

Um das Problem zu minimieren kann man per "Stored Procedures" zugreifen.


----------



## blimaa (6 April 2022)

Reallife schrieb:


> Um das Problem zu minimieren kann man per "Stored Procedures" zugreifen.


Wurde im Beitrag #2 bereits vorgeschlagen


----------

