Ride the Lightning

Rogue Programmer Plants Logic Bombs to Guarantee Future Work

July 25, 2019

What if programmers add bugs deliberately? As Naked Security reported on July 23, that has actually happened.

Siemens contractor David Tinley recently pled guilty to one count of intentional damage to a protected computer.

According to filings by the United States District Court for the Western District of Pennsylvania:

"TINLEY, intentionally and without Siemens' knowledge and authorization, inserted logic bombs into computer programs that he designed for Siemens. These logic bombs caused the programs to malfunction after the expiration of a certain date. As a result, Siemens was unaware-of the cause of the malfunctions and required TINLEY to fix these malfunctions."

The logic bombs left by Tinley were bugs designed to cause problems in future, rather than at the time he added them. Maybe he did this to avoid looking like the cause of the initial problem with the code. Or perhaps he thought Siemens was less likely to give up on buggy code that was deployed than code that was still in development.

He would fix the bugs by resetting the date the logic bombs were due to go off and his attorney argued he did this to guard his proprietary code rather than to make money.

Tinley was exposed after being forced to give others access to his code while he was on vacation. Siemens, it says, had to fix the buggy system without him in order to put a time sensitive order through it.

Tinley worked as contractor for Siemens for fourteen years, between 2002 and 2016, and engaged in his misconduct for the last two. He faces sentencing in November.

Lesson learned? If a contractor is refusing to let you see their code, or doesn't trust you enough to give you access, that should raise a red flag. And if somebody is making themselves a single point of failure, you have a problem, even if they aren't doing anything malicious.

Another lesson? Programmers and their code both get better with peer review, and modern development practices like continuous test and build cycles are designed to uncover bad code as quickly as possible.

I'm pretty certain that Siemens has now taken those lessons to heart.

Sharon D. Nelson, Esq., President, Sensei Enterprises, Inc.
3975 University Drive, Suite 225|Fairfax, VA 22030
Email: Phone: 703-359-0700
Digital Forensics/Cybersecurity/Information Technology
https://senseient.com
https://twitter.com/sharonnelsonesq
https://www.linkedin.com/in/sharondnelson
https://amazon.com/author/sharonnelson