A Look into Insidious Threats – The Logical Bomb

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?

About the Author: Emmanuel Carabott

Emmanuel Carabott (CISSP) Certified Information Systems Security Professional has been working in the IT field for the past 18 years. He has joined GFI in 1999 where he currently heads the security research team.
Emmanuel is also a contributor to the GFI Blog where he regularly posts articles on various topics of interest to sysadmins and other IT professions focusing primarily on the area of information security.

4 Comments

Sue Walsh September 27, 2010 at 6:33 am

Disgruntled employees can be a huge security nightmare. There was just a case in Baltimore where a disgruntled employee installed a keylogger to steal his co-workers login info and programmed his bosses’s computer to replace a Powerpoint presentation with pornographic images-during a big meeting! It wasn’t until after that happened that the company decided they needed to put some security solutions in place. Kind of closing the barn door after the horses have escaped, don’t you think?

Emmanuel Carabott October 25, 2010 at 6:03 pm

Indeed, security can be a tricky business. It is understandable that sometimes businesses decide to take the risk instead of mitigating because they think it is unlikely that such an event will happen to them. Of course unlikely doesn’t mean safe and if they’re hit then they decide that it’s time to act.

I think this is the point when one should realize that their previous choice was the wrong one. If you’re hit it doesn’t mean the odds have suddenly become worse for your business, if anything the odds may have somewhat lowered a bit (lighting doesn’t strike twice in the same spot kind of thinking) yet now the added security justifies the cost. To me that simply means that security justified the cost even previously; however, the business went with the unfortunate frame of mind that the specific risk couldn’t possibly happen to it.

Of course I am not saying that every single risk should be mitigated either. There is a line where the cost doesn’t justify the benefit; however, the ‘this can never happen to me’ frame of mind is dangerous when deciding where to draw that line.

Mary K. December 12, 2010 at 6:09 pm

@sue walsh

Good point. I guess, despite all our discussions against external and third party threats to our systems, the most vulnerable access point would be the remote users themselves. No matter how secure we make our servers, our systems, or our workstations. How do you defend your own system against the people who are supposedly using it? The person who is employed to be building your security may very well be the biggest threat to it in the future.