In the previous article, we started to look at methods for finding and removing viruses in Linux, this article will list the remaining techniques for dealing with malware in a Linux system.

Find and remove malware that runs regularly

Linux synchronization tasks are also often used by attackers to inject malicious files. Common ones include cron, systemd-timers, at, and homemade resident processes.

Common places for cron jobs:

/etc/crontab

/etc/cron.*

/var/spool/cron/

You can also view the list of cron jobs for the current user with the following command:

crontab -l

The location of systemd-timers is in the /etc/systemd subdirectory, which can be viewed with the following command:

systemctl list-unit-files | grep timer

The list of at scheduling commands can be viewed with the following command:

$ at -l

The scheduled tasks of resident processes are determined by the process designer and cannot be uniformly checked, so such problems can only be solved by using a Live CD to start the system and then clean up any suspicious startup files.

Refuse these actions:

1. The synchronization task itself is relatively simple, but when checking, it is necessary to distinguish between which ones are bundled with the system and which ones have been changed or added. If this is not defined correctly, then the system itself may not work correctly;

2. In addition to checking the configuration script itself, it is also necessary to check the target script called by it, as well as the scripts and programs called by the target script. The actual workload and complexity should not be underestimated;

Find and remove modified or added system files

Simple and crude infection of system executable files and dynamic link files is a generic craft of malware. Various Linux distributions contain commands that can be used to compare whether a program has been modified since installation in order to detect fake programs.

The Redhat system can use the following commands:

rpm -Va

Debian/Ubuntu systems can use the following commands:

dpkg -l | awk '/^ii/ { print $2 }' | xargs debsums | grep -vE 'OK$'

You can also use professional antivirus software to perform a full scan and search for infected files.

Refuse these actions:

1. The verification tool built into the system does not store information about all installation files, so the verification process is not completely reliable;

2. The built-in system check tool itself can also be hacked, and the check may be meaningless;

3. If a malicious program infects a file installed by the user, the check cannot detect an anomaly in the file at all;

Locate and restore common configuration files and system settings

The cunning hunter hides where he is least expected. Shell environment variables are most often overlooked by users. Spoofing PATH/LD_LIBRARY_PATH/LD_PRELOAD/LD_AUDIT/alias can actively trigger malicious code execution when users execute commands.

PATH Variable - This variable determines how the system finds the target program when the user runs the program. By default, normal users include /bin, /usr/bin, /usr/local/bin, etc. Root users additionally have /sbin, /usr/sbin, /usr/local/sbin, and so on. If an attacker spoofs the contents of the PATH variable, the user can run unexpected malware.

You can use the following command to view the current contents of PATH:

env | grep PATH

The LD_LIBRARY_PATH/LD_PRELOAD/LD_AUDIT and other similar variables affect the actual dependent code linked by the dynamic linker at run time and should be empty by default. If an attacker spoofs the contents of a variable, the user will unknowingly download and run malicious code while the program is running.

You can view the contents of such variables with the following command:

env | grep LD_

The /etc/ld.so.preload configuration file can perform a similar function and should not be ignored in a check.

The alias command is a built-in shell command that allows users to change the actual command run semantics. Attackers can use this command to create false appearances, allow normal user commands to load malicious code to execute, and even hide or modify the results of normal commands.

For example, the following command will cause the user's ls command to always return empty directories:

$ alias ls=echo

You can run the alias command to see all current command aliases:

$ alias

System environment variables are usually affected by system and user directory configuration files.

/etc/profile

/etc/profile.d

/etc/environment

/etc/bashrc

User directory configuration files:

~/.profile

~/.bashrc

~/.bash_profile

~/.bash_logout

~/.zshrc

If the user is using the X Window Service, the configuration file also includes:

~/.xprofile

~/.xinitrc

An attacker can also directly inject malicious code into a configuration file that automatically runs when a user logs in. And there are many more configuration files that can write malicious code to the system.

Modifying the /etc/modprobe* or /etc/modules* files may allow the system to load malicious kernel module code;

Modifying the /etc/initcpio or /etc/initramfs file may cause malicious code to be written to an early memory image at system startup;

Similarly, changing files in /etc/yum or /etc/apt can allow your system's update operation to load malicious code for attackers;

Even changing /etc/hosts can turn your frequently visited sites into poisoned sites controlled by hackers.

In conclusion, the length of this list is mostly up to the attacker's imagination.

Refuse these actions:

1. The list is too long to list here, repairs are more tedious than reinstalls;

2. When checking, it is necessary to distinguish between which configuration files and system parameters are included with the system, and which have been changed or added.

Check and repair system business files

What to do if hackers got to your own business programs and data? An attacker has logged in, modified your site's code, or added small code to your site. It is also possible that he got through a loophole in the code of your site, what to do?

According to the user ID of your server process, if it is the root user ID, stop reading, back up the data, reinstall the system, fix the code vulnerability, and then redeploy the service with a dedicated unprivileged user.

When deploying, confirm that the service user does not have write permissions to any files on the system other than the user's required download directory. If this is a normal user, delete all files owned by the user after backing up the data.

If an attacker has permission to write system files, their actions may include, but are not limited to:

- Modify server configuration files or service directory configuration files, add or modify service content, and create backdoors.

- Modify or add service directory program files, inject a Trojan backdoor from a single sentence.

- Increase the service catalog package and prepare for yourself a luxurious back door of the Trojan horse.

- Add or change the default service control password, for example, to help you add or change a user in the tomcat control directory to make it a backdoor.

If you don't store signature information and a file directory for every file in your program, it's almost impossible to find files modified or added by an attacker in a large amount of code.

When your business is under attack, "mining" is probably the least of your worries. During this time, the server's business data may be stolen or tampered with. Also, experienced hackers can inject well-designed triggers or backdoor programs generated by stored procedures in the database. Even if you restore the data, the hacker can return at any time.

Refuse these actions:

1. A three-foot freeze doesn't happen overnight. If such a problem occurs in a system, it is very likely that the whole idea of developing and deploying the system needs to be reworked and restarted. Don't think about how to fix it, stop the loss first;

2. When checking, it is necessary to distinguish which files have been changed or added.

Check and repair the bootloader and kernel files

Theoretically, hackers could inject malicious code into the system boot sector, disk boot sector, or even a BIOS hardware module or router nvram configuration area.

In fact, the notorious CIH virus of the last century targeted the system startup code and the BIOS hardware itself. According to public information, hackers have viruses that attack the underlying code of the equipment as a weapon. In this case, if the commercial antivirus software cannot detect the virus, you can only call a virus expert.

Of course, to prevent this from happening, you can try the secure boot feature, which requires the interaction between the BIOS and a supported operating system. Specific technical details can be found in the official motherboard and operating system documentation.

Epilogue

In fact, there will inevitably be viral agents that we have not mastered yet. The Linux kernel itself consists of tens of millions of lines of code, and the system, once installed, has tens of thousands of files. Finding well-designed malware on a system of this magnitude is like finding a needle in a haystack. We recommend that users who have a virus-infected system back up their data and reinstall the system directly.

Mainton Company - custom software development and testing, SEO and online advertising since 2004.