Ist I2C eine hackbare Schwachstelle?

Fiktives Szenario: Ein selbst gebauter von einem Arduino Nano 33 BLE gesteurter Ausgabeautomat für Getränke hat alle Elektronik intern verbaut, (keiner kann von aussen darauf zugreifen), bis auf die Taster AN/AUS zur Bedienung sowie ein I2C gesteuertes LED Display (sowas in der Art hier: "MakerHawk I2C OLED Anzeigemodul I2C SSD1306 0,91 zoll")

Die Frage ist jetzt ob ein findiger Hacker sich am zugänglichen I2C des Displays einhängen könnte um den Arduino zu übernehmen.

Oder ist so etwas genauso auszuschließen wie bei den einfachen Tasten (die lediglich auf An/Aus abgefragt werden und keine Angriffsfläche bieten insofern das Programm natürlich nicht schlampig geschrieben ist und sich über die Menüs zu ungeplanten Zuständen führen lässt.)

Das jemand 20000V in den I2C oder die Taster leitungen jagdt und den Ardu Röstet ist jetzt weniger meiner Sorge, dann gibt der Automat ja auch nichts mehr aus lol

Ein Display ansteuern über I2C kann ich aber ich habe zu wenig Ahnung vom Protokoll intern um zu wissen ob man da irgendwie Rückwirkend auf den Arduino zugreifen kann. Zum Beispiel würde ich niemals den USB Port des Arduinos offen liegen lassen an diesem fiktiven Verkaufsautomat.

Hat jemand von Euch vielleicht einen tieferen Eindruck in die I2C Architektur?

viele Grüße,
Markus

Hallo,

wenn man annimmt das nur ein Display am I2C Bus hängt, dann sollte, wenn nicht schlampig programmiert und keine Debugmöglichkeiten aktiv sind, sowieso keine Eingangsabfrage im Protokoll drin stehen. Wofür auch, ein Display liefert nichts zurück. Abgesehen von ACK Bestätigungen.

Falls noch mehr I2C Devices im Automaten stecken könnte es natürlich sein das sich welche fleißig unterhalten. Wenn hier sauber programmiert wurde, werden alle unbekannten Kommandos abgewiesen und führen zu keinem Fehler. Im besten Fall wurden alle Datenübertragungen noch verschlüsselt. Das gilt nicht nur für I2C. Falls sich jemand auf den Bus einklingt und lauscht.

Fiktives Szenario

Iss klar!
Fiktiv, aber konkrete Ansagen, sollen wir liefern...

Zum Beispiel würde ich niemals den USB Port des Arduinos offen liegen lassen an diesem fiktiven Verkaufsautomat.

Aber die I2C Leitungen würdest du offen liegen lassen?

aber ich habe zu wenig Ahnung vom Protokoll

Das ist schade!
Kannst aber nur du ändern.

Suchtipp: "I2C Multimaster"

Oder ist so etwas genauso auszuschließen wie bei den einfachen Tasten (die lediglich auf An/Aus abgefragt werden und keine Angriffsfläche bieten insofern das Programm natürlich nicht schlampig geschrieben ist und sich über die Menüs zu ungeplanten Zuständen führen lässt.)

Der Ersteller könnte Fehler oder Backdoors eingebaut haben - die wir nicht sehen.

Da wir mangels Sketch, verwendeter Libs, Schaltplänen, Systemaufbau und vorliegender Hardware das nicht prüfen können ist sowas nur mit "ist nicht auszuschließen" beantwortbar.

Bei "übernehmen" denke ich an ausführbaren oder interpretierbaren Code, der in ein System eingeschleust und anschließend aktiviert werden kann. Bei den kleinen Arduinos wird sowas im laufenden Programm garnicht vorgesehen, bei größeren Systemen wird hingegen meist Wert auf einspielbare Updates gelegt - warum auch immer. Doch selbst dann werden Updates übers Netz geladen und nicht über I2C.

Das "fiktive" Szenario an diesem "fiktiven" Automaten wäre doch, dass jemand diesen Jackpottet.
Also alle Waren oder sogar das (Wechsel-)Geld ausgeben lässt.

Eine Idee wäre den I2C mit sinnlosen Daten zu fluten und intern für einen Bufferoverflow sorgen. Dieser könnte im Zweifel für unvorhergesehene Verhalten sorgen. Oder schlicht zu einem Neustart des µC.
Zumindest ist es eher unwahrscheinlich, dass ohne Kentnisse des Codes, eine gezielte Attacke möglich ist.

Ansonsten halte ich es wie noiasca. Ohne Einblick kann Dir niemand eine definitive Aussage machen.

Hi,
hey super vielen dank für das Feedback, ich würde euch gerne den Sketch zeigen, aber das dauert noch, denn noch ist nichts programmiert. Ich bekomme den Arduino für diesen Versuch vermutlich den Samstag, aber ich bin dran :wink:

Zum Feedback:
Also der I2C würde nur offenliegen insofern jemand das Display rausreißt, oder anbohrt oder weiß gott wie an ihn ran kommt, da der aber außen am Gehäuse liegt kann man das nicht verhindern, ich brauche das Display ja aussen. Natürlich lege ich den I2C nicht als Steckbuchse nach draussen :wink: Der arduino kann ja sicher im Inneren des Automaten liegen. Und es ist wirklich fiktiv ich plane jetzt nicht konkret einen Getränkeautomat aufzustellen :wink: Nur eine Bastelei und Versuche.

-Und ja, dann also nur output über den Master im I2C, also durch den Arduino an das LCD. inputs werden dann nicht vom Master abgefragt. Dann sollte ja eh nichts zurück kommen oder verarbeitet /falsch verarbeitet werden können .Außer dem Return signal soweit ich das im Ablauf von I2C gesehen habe, und da kann jemand nicht viel hacken, wenn er es nicht sendet steht die kiste, sendet er mehr, wird nichts davon als irgend eine input eine reaktion beim Master auslösen. Also so zumindest meine hoffnung :wink:

-Ich gehen mal davon aus das ich im Sketch keine Fehler in der Abfrage des I2C und der Taster eingebaut habe ob absichtlich oder nicht :wink:

-Den I2C fluten geht leider nicht da ich ihn ja fürs display brauche. Sonst könnte ich ihn auch garnicht zugänglich machen :wink:

Hmmmm,
das verstehe ich nicht. Du baust einen Automaten, der koplett geschlossen ist, aber das Display baumelt irgendwie draußen herum?

Old-Papa

lol neues Designmerkmal !
Nein Unsinn, das Display ist schon eingebaut, aber da man es sehen muss ist es halt direkt an der aussenseite.
Jetzt könnte irgend jemand her gehen kloppt es mit einem Hammer Kaputt oder bohrt es an und schon ist er am I2C dran.

Jetzt könnte irgend jemand her gehen kloppt es mit einem Hammer Kaputt oder bohrt es an und schon ist er am I2C dran

Warum sollte sich ein Angreifer damit begnügen.

Wenn er sich schon der Sachbeschädigung schuldig machen will, wird er doch die Tür aufbrechen.

Wat issn hier los?
Text geschrieben, kurz gesehen und dann krude Englische Fehlermeldun, Text weg…
Ist mir gestern auch schon passiert.

Old-Papa

Nen Angreifer könnte in der Bank die Scheiben einschlagen oder bohrt die Schlösser auf und schon ist er im Netzwerk.
viel lukrativer.

... ist zwar nicht eine Situation die sich eine Bank wünscht, aber ich gehe davon aus, dass sie mit so einem Angriffszenario nicht nur rechnet sondern auch aktiv Maßnahmen dagegen ergriffen hat.

rayjunx:
jemand das Display rausreißt, oder anbohrt oder weiß gott wie an ihn ran kommt,

Also....
wenn deine fiktive Ausseneinheit mechanisch beschädigt wird, ist auch damit zu rechnen, das diese elektrisch ebenfalls anderes macht, als vorgesehen.

Wenn Du verhindern willst, das durch irgendwelche (elektrischen) Einwirkungen die Steuerelektronik Zustände annimmt die Du nicht willst, musst Du Dir ein passendes Konzept machen.
Da ist der I2C das kleinste Übel.
Wobei. EMV wäre noch ein Stichwort.

Natürlich ist ein Getränkeautomat vermutlich ein dummes Beispiel für die Anwendung.
Den aufwendig zu sichern wegen ein paar Flaschen lol
Das müsste dann schon etwas Wertvolleres und besser gepanzertes sein, zum Beispiel ein selbst gebastelter Tresor, das trifft den fall evtl besser. Da kann die Elektronik innen drin sein aber er braucht Bedienelemente wie eben ein Display, wird ja auch schon so gemacht. Die müssen die Displays ja auch irgendwie ansteuern. Und ich hatte so im hinterkopf das so ziemlich alles gehackt werden kann, deshalb kam die Frage auf wie man es anstellen müsste das Elektronisch keine Sicherheitslücke entsteht, und das obwohl man irgendwie ein OLED Display und die Bedientasten anschließen muss.
So bleibt die I2C als potentielle Schwachstelle, oder auch nicht, je nachdem ob deren Architektur eben einen Angriff her gibt, aber ich wage nicht zu behaupten da auch nur ansatzweiße genug Ahnung habe um die Frage zu beantworten :wink:
:o

-Und natürlich hängen wir die Kiste nicht ans Netzwerk, WLAN oder Bluetooth :wink:

Und Danke Noiasca Deine ganzen Punkte sollte man dann schon beachten, sind notiert :wink:

noiasca:
ich gehe davon aus, dass sie mit so einem Angriffszenario nicht nur rechnet sondern auch aktiv Maßnahmen dagegen ergriffen hat.

Frag mal die Geschädigten, deren Schliessfächer über eine Tiefgarage geleert wurden und die keinen Cent ersetzt bekamen. ... Ich denke die sind auch davon ausgegangen, das das unmöglich ist. :wink:

Lesenswert:

"die Architektur von I2C" ist dein kleinstes Problem.

Es geht um deine Implementierung, dein Program, die Libs die DU eingebunden hast.

Z.B.: Was macht dein Programm wenn im falschen Moment der Bus einfriert? Hast du Timeouts aktiviert? Liest du I2C Fehler?
Hört die Pumpe auf? Hört der Stellmotor auf? Geht alles in ein Failsafe?
Erholt sich der Controller?

Das hat per se mal gar nichts mit I2C zu tun, sondern wie sicher du dein System gestaltest.

my_xy_projekt:
Frag mal die Geschädigten, deren Schliessfächer über eine Tiefgarage geleert

die sind aber nicht durchs LAN-Kabel gekrochen oder? ^^

von den letzten beiden Fällen in Ö vom Herbst habe ich keine Detailinformationen (außer dass es “leider” nur zwei Mitbewerber getroffen hat…)

noiasca:
die sind aber nicht durchs LAN-Kabel gekrochen oder? ^^

Das nicht, aber es gibt immernoch - so wie da - die Fehlerquelle Mensch. Egal ob Alarm einfach ausschalten oder gar nicht erst implementieren.
Aber hast ja schon Bezug darauf genommen...

EMV ist interessant… aber Stören wäre wohl weniger das problem, wenn man das system abschießt, gut dann sperrt das Teil halt. Aber kann man einen Arduino Kontaktlos übernehmen? Das wär ein Ding! :o