Linux security, think about the future
You can often find the opinion that linux is safe. So far - this is truly true, no one has made a particularly careful effort to create attacking programs, which is why an illusion of security is created. However, let us try to pay attention in advance to those things in the linux system that might be of interest to intruders in the future.
This article does not claim to be a complete overview of the problems, I just want to outline the contours of a problem that already exists, but so far it hasn’t been solved in any way. Some of the described methods of protection can be made to work now, some of them should be forced to implement the authors of system software.
Update For some readers, for some readers, the general idea of ​​the article turned out to be incomprehensible, so I will state it explicitly: the idea is to show some concrete examples of the use of known attacks (if you can call it “attack”, of course) in the linux environment. Linux is no safer in some aspects than other systems.
')
It makes no sense to talk about the ways of penetration, harmful software will still leak to any system. And no antivirus will help. Also, we will not go deep into the types of malware, let them be “Trojans” and “pests”. Trojans are a variety of keyloggers, password hijackers and other spies. Pests are document erasers and system destroyers. Further, all this will be called in one word "virus". We also omit the issue of sabotage at the system level, that is, we assume that the virus in / usr / bin does not get through.
So, a virus in the system, for example, through a hole in libflash, the downloaded binary started up; for survival, he needs to register himself in autoload. In the modern system for this there are many different ways, often extremely difficult to calculate. In each Desktop Environment (DE), there are several ways to launch applications when DE starts. For example, KDE has the ~ / .kde / env directory, all the files from which are executed when the system boots, the ~ / .kde / Autostart directory works the same way (there is a difference between these two directories, but in this article it is not essential). It is enough to put an executable script file there to launch the virus and that's it. A more cunning option is to scan this directory and embed the launch command already in the existing script.
We don’t even talk about such trifles as masking the name of a virus in the process list. A virus can easily impersonate anything.
In addition to the DE tools, there are various startup scripts like ~ / .xsession or ~ / .profile , or .zshrc . With a lot of desire, you can probably even shove some destructive stuff in ~ / .fonts.conf .
How to fight? No While there are no means of reliable control, no one (of the authors of the software) bothers with a mess in the scripts. A paranoid solution is to read the hashsms from critical user configs files and store them in a place inaccessible for change by the user. Then, when you start all the hashs checks.
In addition to registering itself in the autorun file, the virus can add a bunch of useful information to it in the configuration files. One of the most attractive goals can be the PATH environment variable. Let me remind you that this variable stores a list of paths that will be used to search for an executable program. Usually, the PATH variable looks like this: / usr / bin: / bin , and the virus can modify it like ~ / bin: / usr / bin: / bin . This is fraught with the fact that now the program, typed without specifying the full path, will first be searched in the user directory, and only then in the system directory. And in the user directory there will be a caring program with the name ssh or sudo ; the user will not notice anything, and the critical data entered by him will safely merge.
Decision? Use only full paths when running programs. However, this is not a guaranteed protection. A more reliable solution would be to restrict access to modification of critical environment variables.
Everything is completely sad here. As a rule, one team is enough to inflict maximum damage - rm -rf ~ / . After that, you can say goodbye to all the data.
Also, nothing prevents you from encrypting all the data in your home directory, as some Windows viruses do.
It is also possible and smaller sabotage, for example, writing in the configs of browsers any rubbish (changing the home page, for example). It is impossible to centrally deal with this, the application authors should understand here.
Undoubtedly, cybercriminals will be greatly facilitated by the standard layout of application profiles. For example, almost always the profile of the Opera will be in the ~ / .opera directory . So partly you can be saved by changing the standard paths of profiles, many applications allow you to do this.
Decent security requires a fair amount of paranoia. Significantly complicate the life of the virus will help the system control launched applications (comparison of hashsum executable files and scripts). To prohibit the "catch" on the disc can be a ban on recording on this same disc. At the same time, it is necessary to provide some way of modifying the configuration files.
The described methods and options - this is just what comes to mind when trying to think about the problem. Surely, there will be some more sophisticated methods (such as using ~ / .fonts.conf ), but for starters, that's enough. Here are the only software manufacturers, including system software, on questions such a primitive household security do not think much. And it would be necessary.
This article does not claim to be a complete overview of the problems, I just want to outline the contours of a problem that already exists, but so far it hasn’t been solved in any way. Some of the described methods of protection can be made to work now, some of them should be forced to implement the authors of system software.
Update For some readers, for some readers, the general idea of ​​the article turned out to be incomprehensible, so I will state it explicitly: the idea is to show some concrete examples of the use of known attacks (if you can call it “attack”, of course) in the linux environment. Linux is no safer in some aspects than other systems.
')
It makes no sense to talk about the ways of penetration, harmful software will still leak to any system. And no antivirus will help. Also, we will not go deep into the types of malware, let them be “Trojans” and “pests”. Trojans are a variety of keyloggers, password hijackers and other spies. Pests are document erasers and system destroyers. Further, all this will be called in one word "virus". We also omit the issue of sabotage at the system level, that is, we assume that the virus in / usr / bin does not get through.
Autostart
So, a virus in the system, for example, through a hole in libflash, the downloaded binary started up; for survival, he needs to register himself in autoload. In the modern system for this there are many different ways, often extremely difficult to calculate. In each Desktop Environment (DE), there are several ways to launch applications when DE starts. For example, KDE has the ~ / .kde / env directory, all the files from which are executed when the system boots, the ~ / .kde / Autostart directory works the same way (there is a difference between these two directories, but in this article it is not essential). It is enough to put an executable script file there to launch the virus and that's it. A more cunning option is to scan this directory and embed the launch command already in the existing script.
We don’t even talk about such trifles as masking the name of a virus in the process list. A virus can easily impersonate anything.
In addition to the DE tools, there are various startup scripts like ~ / .xsession or ~ / .profile , or .zshrc . With a lot of desire, you can probably even shove some destructive stuff in ~ / .fonts.conf .
How to fight? No While there are no means of reliable control, no one (of the authors of the software) bothers with a mess in the scripts. A paranoid solution is to read the hashsms from critical user configs files and store them in a place inaccessible for change by the user. Then, when you start all the hashs checks.
Disguise
In addition to registering itself in the autorun file, the virus can add a bunch of useful information to it in the configuration files. One of the most attractive goals can be the PATH environment variable. Let me remind you that this variable stores a list of paths that will be used to search for an executable program. Usually, the PATH variable looks like this: / usr / bin: / bin , and the virus can modify it like ~ / bin: / usr / bin: / bin . This is fraught with the fact that now the program, typed without specifying the full path, will first be searched in the user directory, and only then in the system directory. And in the user directory there will be a caring program with the name ssh or sudo ; the user will not notice anything, and the critical data entered by him will safely merge.
Decision? Use only full paths when running programs. However, this is not a guaranteed protection. A more reliable solution would be to restrict access to modification of critical environment variables.
Sabotage
Everything is completely sad here. As a rule, one team is enough to inflict maximum damage - rm -rf ~ / . After that, you can say goodbye to all the data.
Also, nothing prevents you from encrypting all the data in your home directory, as some Windows viruses do.
It is also possible and smaller sabotage, for example, writing in the configs of browsers any rubbish (changing the home page, for example). It is impossible to centrally deal with this, the application authors should understand here.
Undoubtedly, cybercriminals will be greatly facilitated by the standard layout of application profiles. For example, almost always the profile of the Opera will be in the ~ / .opera directory . So partly you can be saved by changing the standard paths of profiles, many applications allow you to do this.
findings
Decent security requires a fair amount of paranoia. Significantly complicate the life of the virus will help the system control launched applications (comparison of hashsum executable files and scripts). To prohibit the "catch" on the disc can be a ban on recording on this same disc. At the same time, it is necessary to provide some way of modifying the configuration files.
The described methods and options - this is just what comes to mind when trying to think about the problem. Surely, there will be some more sophisticated methods (such as using ~ / .fonts.conf ), but for starters, that's enough. Here are the only software manufacturers, including system software, on questions such a primitive household security do not think much. And it would be necessary.
Source: https://habr.com/ru/post/81724/
All Articles