Ein Angebot von

Sabotage: Programmierer baute Fehler in Siemens-Software ein, um Job zu behalten

| Autor: Sebastian Gerstl

Ein extern für Siemens arbeitender Programmierer baute gezielt Malware in seinen Code ein, um weiterhin von Siemens Aufträge zu bekommen. Das Unternehmen spricht von Sabotage - aber was war die Software letztlich wert?
Ein extern für Siemens arbeitender Programmierer baute gezielt Malware in seinen Code ein, um weiterhin von Siemens Aufträge zu bekommen. Das Unternehmen spricht von Sabotage - aber was war die Software letztlich wert? (Bild: gemeinfrei / Pixabay)

Einem von Siemens beauftragten Softwareentwickler drohen zehn Jahre Haft: Der Programmierer hatte Logikbomben in seinen Auftragscode eingebaut, so dass das Unternehmen ihn regelmäßig neu beauftragen musste. Der Vorfall wirft Fragen über Stellen- und Finanzwert von Code auf.

Siemens zerrt in den USA einen externen Entwickler vor Gericht. Der Vorwurf: Der Auftragsprogrammierer soll bewusst Malware in den von ihn geschriebenen Code eingebaut haben, um das Unternehmen zu zwingen, ihn stets aufs Neue wieder zu beschäftigen. Für diese vorsätzliche Sabotage drohen ihn nun, nach Aussage der zuständigen Staatsanwaltschaft, vor einem Bundesgericht in Pennsylvania bis zu zehn Jahre Haft und eine mögliche Geldstrafe von 250.000 US-$, wie der Business Insider meldet.

Immer wieder angeheuert, um den eigens gelegten Fehler zu beseitigen

David Tinley, heute 62 Jahre alt, war von der US-Außenstelle von Siemens über mehrere Jahre hinweg als externer Auftragsarbeiter beschäftigt worden. Die Aufgabe des Programmierers erscheint nicht übermäßig aufwändig: Tinley sollte automatisierte Kalkulationstabellen (‚spreadsheets‘) erstellen. Siemens USA verwendete diese Tabellen unter anderem, um Bestellungen für elektronische Ausrüstung zu koordinieren und verwalten.

Also nur ein einmaliger, ausgelagerter Job für die Erstellung eines automatisierten Tabellenkalkulations-Spreadsheets? Nicht, wenn es um die Beauftragung Tinleys ging. Denn Siemens musste den externen Programmierer über zwei Jahre hinweg wiederholt beauftragen, um plötzlich auftretende Fehler und Glitches zu beseitigen. Die Rechtsberichtsplattform Law 360 spricht unter anderem von nicht nachvollziehbaren Fehlermeldungen, Abstürzen oder Schaltflächen, die ihre Größe veränderten. Und immer, wenn es zu den Fehlern kam, heuerte Siemens den Programmierer erneut an, um sie zu beseitigen.

Die Staatsanwaltschaft wirft Tinley vor, nie ernsthaftes Interesse daran gehabt zu haben, diese Fehler zu beseitigen. Stattdessen habe der Programmierer ganz bewusst so genannte Logikbomben in seinen Code eingebaut. Bei dieser Malware werden gezielt Fehler in der Software „gezündet“, wenn bestimmte vorher festgelegte Ereignisse eintreten, wie beispielsweise das Erreichen eines bestimmten Datums. Anstatt diese Bugs zu beseitigen, verschob Tinley regelmäßig nur das Auslösedatum seiner Logikbomben – und zwang das Unternehmen somit, ihn erneut zu holen, wenn die Fehler später wieder auftraten. Da der Code für die von ihm geschriebene Tabelle passwortgeschützt war, hatten Siemens-Mitarbeiter keinen direkten Einblick darauf. Grund für den Passwortschutz sei nach Angabe des Entwicklers gewesen, dass er den von ihm geschriebenen proprietären Code schützen wollte.

Zwei Jahre lang kam der Programmierer mit der Masche durch. Dann wurde ihm sein eigenes schlechtes Timing zum Verhängnis: Als im Mai 2016 seine Logikbombe einmal wieder zündete, befand er sich gerade im Urlaub. Da Siemens allerdings dringende Aufträge abzuwickeln hatte, zwang das Unternehmen den Entwickler schließlich dazu, der IT-Abteilung sein Passwort für den geschützten Code auszuhändigen. Dadurch stießen die Mitarbeiter schließlich auf die gezielt platzierte Malware.

Insgesamt habe Siemens für die Untersuchung der wiederholt auftretenden Schäden etwa 42.000 US-$ ausgegeben – was in den USA den Bestandteil einer Straftat erfüllt, wenn durch vorsätzliche Handlungen mehr als 5.000 US-$ Schaden entstehen. Tinley’s Anwälte argumentierten hingegen, dass der Entwickler durch seine Taten kein Geld verdient hätte; seine Absicht sei einzig und allein gewesen, seine selbstentwickelte Arbeit zu schützen. Letztendlich bekannte sich der Programmierer allerdings vor Gericht schuldig. Über die endgültige Höhe der Strafe soll in den kommenden Tagen entschieden werden.

Ab wann bekommt gute Software einen echten Wert?

Ob das Vorgehen des Programmierers illegal und unethisch war, sollte keine Frage darstellen. Aber das Verfahren wirft eine ganze Reihe weiterer Fragen auf: Warum verlässt sich ein Unternehmen wie Siemens auf Tabellenkalkulation zur Automatisierung seiner Prozesse? Wenn das Unternehmen letztendlich doch intern die Möglichkeit hatte, den Code auf Schwachstellen zu überprüfen, warum wurde der Auftrag überhaupt an einen externen Entwickler gegeben. Warum wurde die Situation zwei Jahre lang einfach toleriert? Und auch wenn (abgesehen von den von Siemens-Anwälten bezifferten Schaden) nicht bekannt ist, wie viel Siemens an Tinley letztlich für seine Arbeiten zahlte: wie viel war dem Unternehmen ein Stück Code für die Automatisierung einer wahrscheinlich lästigen, aber letztlich doch essentiellen Aufgabe wert? Wie kann oder darf ein Unternehmen sich zwei Jahre lang mit der Qualität von Code abfinden, der regelmäßig und häufig von Fehlern befallen wird?

Möglicherweise kam Tinley so lange mit seiner Logikbombe im Code durch, weil das Produkt, dass er abliefert, ein Stück Softwarecode zur reinen internen Verwendung war – eine Kleinigkeit, auf das man intern keine Ressourcen verwenden wollte. Der Auftrag selbst war offenbar zu wenig Wert – weswegen er auf die Idee verfiel, sich immer wieder für kleine Beträge zum Reparieren der selben kleinen Arbeit anheuern zu lassen. Selbst wenn es effektiv nur um ein Makro ging: Offenbar ist auch großen Unternehmen ordentliche, gute Software immer noch viel zu teuer – oder einfach zu wenig wert.

Tod durch Software – Kein Patch kann fatale Fehler wieder richten

Tod durch Software – Kein Patch kann fatale Fehler wieder richten

20.03.19 - Zwei Abstürze in nur fünf Monaten, 346 Tote – das ist die tragische Bilanz, die derzeit dafür sorgt, dass mit der Boeing 737 MAX eines der modernsten Flugzeuge weltweit nicht starten darf. Eine Software zur Verbesserung der Flugsteuerung soll Schuld tragen. Wie kann so etwas heute noch passieren? lesen

Risiko Insider-Angriffe – Code-Manipulationen erkennen

Risiko Insider-Angriffe – Code-Manipulationen erkennen

24.05.18 - Nicht nur versehentliche Fehler gefährden die eigene Software: Auch böswillige Angriffe durch Insider stellen ein erhebliches Risiko dar. Um absichtliche Code-Manipulationen und versteckten Schadcode zu finden, bietet sich die statische Analyse an. Eigener, aber auch Code aus fremden Händen sollte damit überprüft werden. lesen

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 46047305 / Security)