Logic Bomb as Cyberattack: Algorithm to Detect and Steps to Recover

Abstract:

Cyberattacks are one of the biggest threats to the Computer World. Security researchers and professionals are continuously making various efforts to prevent such attacks. Most of the time these attacks come from outside, but sometimes it can be insider attacks. Insider attacks can be more lethal, as the malicious person will have authorized system access. A logic Bomb is one of such example of an insider attack; a successfully triggered logic bomb can cause system failure, auto-deletion of hard drives, manipulation of data, etc. Logic Bombs are generally hidden or embedded in genuine code where they stay dormant till their conditions are not satisfied, this makes them very hard to detect. This malware is normally programmed by developers of software. Attackers usually exploit the software development lifecycle to insert a logic bomb. Such a type of hidden malicious code in the system software can be a serious threat to their IT infrastructure security. This paper involves the study of a logic bomb attack, its prevention measures, proposed detection algorithm, and steps to recover from it.

Introduction:

Cyberattacks are performed by both outsider and insider entities. In a comparison of both; insider attacks can be more dangerous as the malicious person will have authorized access to the system and network. One such effective insider attack is the Logic bomb attack.

A logic bomb is a piece of malicious code that lies dormant hidden within legitimate software until a condition is satisfied to trigger its payload. This malware is normally embedded by developers into genuine software. A logic bomb has a flaw that it only works for software for which it has been designed, it doesn’t replicate on other applications. The presence of a Logic bomb in the system poses great risks to their security and integrity.

Richard Clarke (Former White House counterterrorism expert) shares his concerns about the cyber war in his book named “Cyber War: The Next Threat to National Security and What to do about it.” In this book, Clarke mentions that the U.S. is very vulnerable to this type of attack because its infrastructure is much more dependent on computer networks in comparison with other countries. He showed concern that malicious code developers could trigger logic bombs, shutting down the banking and various other systems.

One such cyberattack occurred in South Korea on 2013-3-20 at 14:00:00 local time, a logic bomb in the code erased the hard drives of banks and media companies. It triggered on a specific time and date and started wiping all data from machines. At least two broadcasting companies and three banks were attacked by wiping their hard drives and master boot record. This attack prevented South Koreans from making ATM transactions as the attack put some ATMs out of operation. According to security researchers, the malicious code also included a module to connect remote Linux machines for deleting their master boot record.

A time Bomb is the subclass of a logic bomb. It is programmed to get executed at a specific time and date. It will stay inactive until its specific condition is not met. The execution of a time bomb will result in destructive effects on the system and network. Time bomb like “Friday the 13th” activates on a specified day and date and deletes the files from infected computers.

It is very hard to detect a logic bomb in the testing phase. Functional testing cannot detect such malicious code as a tester are unlikely to supply values which will trigger the bomb. Static analysis tools are unable to detect this bomb as they are aimed at finding programming mistakes like failure to validate a user input or failing to protect against a buffer overflow. Requirements-based testing also fails to detect bombs, as a tester is unlikely to enter the values required to trigger them. It cannot be detected by dynamic tools either, because their execution may not result in runtime errors, which is usually detected by dynamic analysis.

Antivirus based on anomaly detection may not detect logic bombs as it will not cause events which are externally observable such as unusual system calls. Signature detection is also not a full-proof solution, as the malicious code is custom embedded to its host software, and may not have a unique signature.

Prevention against Logic Bomb:

As logic bombs are mostly planted by software developers of the same company or externally hired contractors, the best practices that involve putting procedural and technical controls should be in place. Following are some necessary steps to prevent a logic bomb attack:

• Conduct a complete background check of developers at the time of joining.
• Keeping an eye on employees having signs of dissatisfaction, anger, revenge, etc.
• Provide only the necessary access to developers to avoid any misuse of resources.
• Implementing the principle of least privilege. It will ensure less possible targets for an attacker.
• Keep the system up to date. Patching system regularly will make it more difficult for a malicious developer to attack system.
• Prepare a baseline for the known process and regularly compare it to the current view. This will be useful to find rogue processes.
• Secure account management and password controls. Ensure different password for each host systems.
• Monitoring auto-updating software. Use Integrity checker to validate if any software has been modified.
• Perform regular backups, use endpoint protection and use business email screening functionality for mails.
• Log all activities of system users and monitor log files for unusual patterns.
• Separation of development and testing process.
• Manual inspection of critical program code.

Detection against Logic Bomb:

When a logic bomb is triggered, it can show many destructive symptoms like system failure, file deletion, etc. This proposed theoretical logic bomb detection algorithm works on the host level. It scans the system for common symptoms of the logic bomb attack and then calculates the number of occurrences. If the frequency of symptoms goes beyond its predefined threshold value then according to the algorithm it is a suspected logic bomb attack.

Input:

Let S be the set of logic bomb attack symptoms.

S= {s1, s2, s3…. sn}; For example: s1 = system/software failure and s2 = auto-deletion of file.

Let T be the set of threshold frequency of all symptoms.

T= {t1, t2, t3…. tn}

BEGIN

scan log file for symptoms

calculate frequency of individual symptoms (i.e. s1f, s2f, s3f…. snf)

IF (s1f > t1 OR s2f > t2 OR s3f > t3…. snf > tn) THEN

Print “suspected logic bomb attack”

ELSE

Print “no suspicious activity found”

END IF

END

Recovering from Logic Bomb attack:

I. Quarantine (Isolate) the infected system from the network to prevent more damage. If the network has been attacked then disconnect the whole network or at least part of the network where critical data resides.

II. Look for symptoms and review all relevant log files to find the start of an attack. In this way, you will be able to locate the logic bomb in the infected host system.

III. Collect the evidence for the Investigation of the Incident. This will help to find the attacker behind the logic bomb attack.

IV. Remove the logic bomb from the system in a safe mode. Perform various checks to make sure malware has been removed from the system.

V. Restore the system with your last backup (If available). Make sure that your last backup doesn’t have the same logic bomb.

VI. Plug in the system to the network.

VII. Monitor the system/software for a few months to make sure that everything is working properly.

Conclusion:

This paper discusses in detail logic bomb attacks by disgruntled or greedy developers. It also explains various ways to prevent the system from such an attack. A theoretical algorithm is proposed in this paper to detect such an attack. Finally, steps to recover from such type of attack are explained.