Companies across the world have shifted their focus from old-school cyber threats to all the advanced security breaches. However, things have changed in this sector — black hats have started to make the best use of old hacking methods by tweaking them a little. One such attack is Logic Bomb.
What Is A Logic Bomb Attack
A logic bomb is a string of malicious code injected in software that it only works when there is a response to an event that was assigned in the code. For example, if the launch of Google Chrome is the event in the code that was assigned when the user would open the Google Chrome browser, the attack would take place. Sometimes (just like a good old-fashioned doomsday flick) it can even simply be date and time. There are several other ways a hacker can use the logic bomb attack and two of the most famous ways are:
Fake or cloned software: This software come with a pre-loaded arbitrary code. These logic bombs are designed in such a way that the bomb blasts or starts to exploit as soon as you launch that software.
Keylogger: This use case is quite different from a generic Logic Bomb as it has two phases. The first phase is manipulating or influencing the user to install the logic bomb and the second phase is about waiting for the event to occur. Here, the logic bombs mostly get triggered when the user performs a task where s/he has to enter certain credentials
There are two types of triggers — negative and positive. The positive trigger is when the conditions are met or when an event occurs, while on the other hand, a negative trigger is when the conditions are not met. One of the examples of the negative trigger would be entering the wrong credentials during logging in.
Instances Of Notorious Logic Bomb Attacks
Recently, a former Siemens contractor has pled guilty to planting logic bombs inside some spreadsheets that he created for the company. David Tinley, a 62-year-old resident of Harrison City, Pennsylvania, was hired by Siemens and was assigned the job of creating automated spreadsheets. But Tinley took the opportunity to exploit the company and make more money by injecting a logic bomb in the spreadsheets.
For years, the logic bomb (which was set with the time/date event) was getting triggered again and again, and every time the spreadsheet run into an error, Tinley would just reset the clock and it was all good to go.
This is not the only instance, in 2017 an Indian-origin IT contractor named Mittesh Das was found guilty of planting a logic bomb in US military systems. In 2012, Das was assigned as the person in charge of managing the servers controlling payroll systems, but he injected a logic bomb in the US Army Reserve payroll systems, and it was triggered to delete files and butcher services.
How To Avoid Logic Bombs
Logic Bombs are mostly injected by people who have access to software’s backend — either contractor, services provider, or someone from your in-house engineering. And if you specifically focus on keeping an eye on these threat actors, follow the following tips:
Find Out Whether Your Service Provider/Vendor Is Trustworthy
Take a look at their previous works and see if it has some bad records (especially in terms of security). You can ask the vendor to show you some use cases or testimonials. Another approach could be asking directly previous clients about how the service and the product were — whether they faced any security issues.
Have The Master Key With You
Always have access to the back of any product or service a vendor provides. If they are not ready to give the access (if in case there is such protocol), you can ask them to log in and show you the back end. Do a thorough audit, time to time, and make sure there is suspicious code running.
Immediate Action
If you ever witness any suspicious error happening, have a word with your vendor or service provider right away. Ask them to run an audit under all the company’s security team.
Keep An Active Eye On Employees Who Are Not On Good Terms With Management
There are instances when engineers with significant coding knowledge have acted as insider threats. So, make sure you know which employee is working on what. Also, ask the developers to run you through the code at certain time intervals — it would not only help you keep track of the progress but also help you spot malicious codes.
Most of the time when an employee has some grudge with the company, s/he tends to take wrong steps and there are instances when employees have injected malicious code in systems before leaving the company. So, make sure you run a thorough check on all the processes he was working on under his/her presence.
