In the world of information security, everything that's old is eventually new again. Attacks surface, make headlines,...
recede into the background and then make headlines again the next time the same technique is used.
It seems we experience this phenomenon over and over with the logic bomb attack. Every time a logic bomb is used in a high-profile attack, it seems like it is being discovered for the first time. This time the Whois hacker group set off a logic bomb to disrupt South Korean banks and broadcasting companies, which in turn set off a reaction around the globe.
Though logic bombs have been used in some form or another for a long time, detecting logic bomb attacks in an enterprise system is difficult to do, but failing to do so can have devastating consequences, especially when critical infrastructure is affected. In this tip, we discuss how logic bombs work, including the Whois attack, as well as provide mitigations that enterprises can implement to protect themselves from similar attacks.
How logic bomb attacks work
To combat logic bombs, security pros must first understand how they work. A logic bomb is a line of code within a system or a piece of malware that triggers malicious behavior when a specific condition is met, such as the passing of a certain amount of time or the failure of a user to respond to a command. The logic bomb could be just a line of code, or it could be malicious software set up by the perpetrator to cause damage to a system.
A typical use case for a logic bomb is an insider attack. For example, let's say a privileged user has a grudge against his company and is afraid he might soon be fired. In advance of his firing, he sets up a scheduled job that checks to see if his user account has been active during the past 90 days; if no activity is found, the scheduled job deletes a critical database. Sure enough, the user is fired, and a few months later, once his account has been inactive for 90 days, the database is deleted. In most cases this would be a visible and obvious action, but what makes a logic bomb especially insidious is that it changes its code randomly, making it more difficult to detect and more damaging to the targeted organization.
Code or software containing a logic bomb may not be detected by traditional antimalware tools because they use custom code designed for a particular system and scenario; no signature exists to detect them. As in the case of the above example, logic bombs are typically installed by privileged users who know what security controls need to be circumvented in order to go undetected until they detonate. The malicious code could also be included within an existing piece of software installed on a target system. A logic bomb often bypasses whitelisting or file system integrity checks because a malicious admin, usually the person responsible for a logic bomb, could tamper with or disable whitelisting and file integrity systems.
Outsiders, Whois and DarkSeoul
It's worth noting that logic bombs are not the exclusive purview of insiders. An external attacker that gains privileged access, through leveraging vulnerability in the system, could also set up a logic bomb to remove any evidence of his or her actions, or disable the system if a certain command isn't received from the attacker (often via a command-and-control channel). Of course, the attacker would still need to first gain access to the enterprise systems.
Few details have been publically released about the Whois attack. It affected several customers of the ISP LG U+ and caused their networks to fail. The attack allegedly used the DarkSeoul malware (though this may have been unrelated to the ISP issues, according to Sophos), which caused the infected systems to not boot and contained the logic bomb. DarkSeoul appears to target South Korean systems specifically because it disables popular South Korean antimalware products. There currently is no conclusive evidence that North Korea or China were involved in executing the attacks.
DarkSeoul has been compared to the Shamoon malware that hit Saudi Aramco: Both resulted in corrupted hard drives damaging master boot records to disable target systems. There are few details on the South Korean attack that would tie the two together, other than both pieces of malware taking similar actions. Another possible comparison point is the 1989 virus Disk Killer, which also led to corrupted data on a hard drive damaging the master boot record.
To protect themselves from logic bomb attacks, enterprises should make preparations in four areas: backups, separation of duties, monitoring and strong endpoint protection. While it can't prevent a logic bomb, a thorough backup strategy is a standard recommendation to aid in security incident recovery and should already be part of any security program. Separation of duties can help deter malicious insiders who may be considering installing a logic bomb on a system. This would require a second person to evaluate new code, software or changes for security issues. Without the second person's review, the privileged user could potentially install the malware without detection.
System and log monitoring should also be used to detect when a logic bomb is installed. Logs can be reviewed by a third party to identify if any malicious software or changes have been introduced on the system; particular attention should be paid to logs for critical systems. For example, if the file system integrity checking software is manually disabled for a short period and then re-enabled, investigate the alert to determine what changes were made to the system and if any were malicious. Finally, strong endpoint protection can prevent logic bombs by limiting the ability of unapproved users to make changes to a system; a log of any changes made should be reviewed regularly or as part of an incident response.
From the editors: More on log management
Find out how firewall logging can be used to detect potential network security threats
Learn about logging strategies for cloud environments.
Even though logic bombs have been around almost as long as computing, they remain an effective technique for attackers; in turn, security protections need to adapt. Many of mitigations for logic bombs have been available for years, but logic bombs have improved as new tools and attack methods have been developed. By implementing the recommended new tools and additional monitoring, though, it should be possible for enterprises to successfully detect and prevent logic bomb attacks in the future.
About the author:
Nick Lewis, CISSP, is an information security architect at Saint Louis University. Nick received his Master of Science in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and at Boston Children's Hospital, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.