Insidious Threats – Logical Bomb (Emmanuel Carabott)
When we think of security we generally get a mental picture of a war against viruses and hackers.  The reason for this is that these are by far the most common threats an administrator will face; however, it’s important to keep in mind that while common they are not the only threats and neither are they the most dangerous.
Administrators face various threats and they generally have software available to help them perform their duties – virus scanners, patch deployment tools, log analysers and vulnerability scanners are all effective against most attacks. There is one insidious threat however, that is designed to be very stealthy, no software can generally detect its presence and when triggered its effect can be devastating. I am talking about a logical bomb.
What is a logical bomb?
A logical bomb is a piece of code that is slipped into a script or application which a business uses generally planted there for insurance or revenge purposes. It is likely to be used by an employee who fears that he might get fired soon and wants to get revenge should that happen. At other times it is deployed as part of a larger plan to make money or cause financial loss to the business. A logical bomb is designed to silently wait for a trigger. The trigger can be a specific date or any special condition, for example monitoring for a file or a code to appear on a specific website. Once the conditions are met the logical bomb would go off and in most cases it is generally designed to wipe out and do as much damage as possible to a company IT infrastructure.
Perhaps the most famous use of a logical bomb was actually by the CIA in 1982. Having been tipped off that the KGB was planning to steal a pipe line control system they had a logical bomb inserted in the code. This had allegedly led to an explosion so big that it was seen from space.
Logical bombs are not a tool used exclusively by spies; there were many cases in which people were caught planting logical bombs sometimes for revenge but also for gain. In 1992 a General Dynamics employee was arrested after a logical bomb he planted was discovered. His motivation was for the logical bomb to cause damage after he leaves the company so that he would later be employed as a highly paid consultant to fix the damage which the same bomb caused. In 2006 Roger Duronio, unhappy with a bonus he got, set a logical bomb that when triggered wiped out the company web server. His plan was to prevent trading by the company for a time which he hoped would drive the company stock down. He planned to short sell his shares and make a profit from the disaster.
How would one protect against Logical Bombs?
There aren’t many options that one can employ against logical bombs. The biggest problem is that they can be deployed virtually anywhere – on the perpetrator’s personal machine, on a test machine, hidden in a script, hidden in the code of a product, hidden in a SQL Server or even in a service. Some of these vectors can, however, be protected by employing good auditing and monitoring software.
A Source Control System might expose a suspicious modification on a script by a developer who generally doesn’t need to modify the particular file. IT may also detect an inconsistency if the file changed without going through the source control system; however, it will not be effective in every possible case.
Periodical Code Review is an expensive option but can help avoid disaster. One nightmare scenario for a company would be that of a logical bomb being planted in the software that the company ships to customers.  If such a logical bomb was designed to wipe customers’ systems on trigger, the legal and financial loss of such an event would be incalculable not to mention the complete demolition of the brand name.
Segregation of duties is a system that might offer some protection against logical bombs. By having different employees restricted to a specific task, a potential attacker will have to expose himself to carry out such an attack. For example if an attacker were to try and change a script on a web server to introduce a logic bomb where segregation of duties is being employed, such an attacker will have to get access to the source code, modify the file and have the script uploaded. Each step with the exception of the code changes need to be performed by employees other than the attacker. While it might not be difficult for that person to invent a reason in order to get access to the source code and get it uploaded, the fact that he would be exposing himself could prove to be an effective deterrent.
Employing backups and an effective disaster recovery plan is perhaps the safest option. Should a logical bomb trigger and delete data/bring down servers you will want to have a mechanism in place to revert as quickly as possible and minimize the damage.
Have you ever had any issues with logical bombs? How did you find it and fix it?

When we think of security we generally get a mental picture of a war against viruses and hackers.  The reason for this is that these are by far the most common threats an administrator will face; however, it’s important to keep in mind that while common they are not the only threats and neither are they the most dangerous.

Administrators face various threats and they generally have software available to help them perform their duties – virus scanners, patch deployment tools such as GFI LanGuard, log analysers and vulnerability scanners are all effective against most attacks. There is one insidious threat however, that is designed to be very stealthy, no software can generally detect its presence and when triggered its effect can be devastating. I am talking about a logical bomb.

What is a logical bomb?

A logical bomb is a piece of code that is slipped into a script or application which a business uses generally planted there for insurance or revenge purposes. It is likely to be used by an employee who fears that he might get fired soon and wants to get revenge should that happen. At other times it is deployed as part of a larger plan to make money or cause financial loss to the business. A logical bomb is designed to silently wait for a trigger. The trigger can be a specific date or any special condition, for example monitoring for a file or a code to appear on a specific website. Once the conditions are met the logical bomb would go off and in most cases it is generally designed to wipe out and do as much damage as possible to a company IT infrastructure.

Perhaps the most famous use of a logical bomb was actually by the CIA in 1982. Having been tipped off that the KGB was planning to steal a pipe line control system they had a logical bomb inserted in the code. This had allegedly led to an explosion so big that it was seen from space.

Logical bombs are not a tool used exclusively by spies; there were many cases in which people were caught planting logical bombs sometimes for revenge but also for gain. In 1992 a General Dynamics employee was arrested after a logical bomb he planted was discovered. His motivation was for the logical bomb to cause damage after he leaves the company so that he would later be employed as a highly paid consultant to fix the damage which the same bomb caused. In 2006 Roger Duronio, unhappy with a bonus he got, set a logical bomb that when triggered wiped out the company web server. His plan was to prevent trading by the company for a time which he hoped would drive the company stock down. He planned to short sell his shares and make a profit from the disaster.

How would one protect against Logical Bombs?

There aren’t many options that one can employ against logical bombs. The biggest problem is that they can be deployed virtually anywhere – on the perpetrator’s personal machine, on a test machine, hidden in a script, hidden in the code of a product, hidden in a SQL Server or even in a service. Some of these vectors can, however, be protected by employing good auditing and monitoring software.

A Source Control System might expose a suspicious modification on a script by a developer who generally doesn’t need to modify the particular file. IT may also detect an inconsistency if the file changed without going through the source control system; however, it will not be effective in every possible case.

Periodical Code Review is an expensive option but can help avoid disaster. One nightmare scenario for a company would be that of a logical bomb being planted in the software that the company ships to customers.  If such a logical bomb was designed to wipe customers’ systems on trigger, the legal and financial loss of such an event would be incalculable not to mention the complete demolition of the brand name.

Segregation of duties is a system that might offer some protection against logical bombs. By having different employees restricted to a specific task, a potential attacker will have to expose himself to carry out such an attack. For example if an attacker were to try and change a script on a web server to introduce a logic bomb where segregation of duties is being employed, such an attacker will have to get access to the source code, modify the file and have the script uploaded. Each step with the exception of the code changes need to be performed by employees other than the attacker. While it might not be difficult for that person to invent a reason in order to get access to the source code and get it uploaded, the fact that he would be exposing himself could prove to be an effective deterrent.

Employing backups and an effective disaster recovery plan is perhaps the safest option. Should a logical bomb trigger and delete data/bring down servers you will want to have a mechanism in place to revert as quickly as possible and minimize the damage.

Have you ever had any issues with logical bombs? How did you find it and fix it?

Get your free 30-day GFI LanGuard trial

Get immediate results. Identify where you’re vulnerable with your first scan on your first day of a 30-day trial. Take the necessary steps to fix all issues.

Try free for 30 days