Why break even secure CMS on a secure hosting

Obviously, if the site has vulnerabilities, then it can be hacked using web attacks. But even if the site is protected by technical means, it works on a reliable CMS, it can still be compromised. How does this happen and how to protect the site from various hacking options not through web vulnerabilities? Grigory Zemskov, head of Revizium, told about this at the 1C-Bitrix partner conference .

The number of hacks and site owners affected by them is increasing every year. And in the past two years, the problem of site security has become particularly relevant: the number of attacks and the amount of incoming dangerous traffic has increased significantly, and, as a result, the number of hacked resources. Seeing this, webmasters and owners of web projects are gradually beginning to recognize the problem and become interested in the issues of information security sites, in particular, their protection. In order to properly protect your resource, the owner of a web resource must understand what options are available for hacking, how an attacker acts, what attack vectors are most critical and how to close them.

Unfortunately, there are a lot of articles and videos that are misleading for those interested in these issues. The problem here is that the security issue is one-sided, usually only technical protection measures are considered. And not in full, but only those that block web attacks. This gives webmasters a sense of false security and absolutely does not guarantee the uninterrupted operation of a web resource and protection against unauthorized changes. In most cases, the site owner does not have the desire to spend his resources: money, time for project security, therefore, in his opinion, the optimal strategy is chosen: use the popular commercial content management system and place the site on a popular hosting. Everything seems to be logical: a protected system works in a protected environment, that is, you can no longer think about security and protection. But this is just one of the popular misconceptions about site security, along with the fact that only technical protection measures are sufficient.
')
Alas, all these “myths” - about using only web attacks for hacking sites, about CMS security and sufficiency of technical measures, lead to new mass hacking sites. What to do to prevent this from happening? Requires an integrated approach to the issue of site security. Next, we look at why we need to pay constant and close attention to both technical protection tools and organizational measures. This is important if only because there are many options for hacking sites that are performed using non-technical methods and without exploiting web vulnerabilities.

Variants of hacking sites

All options for hacking sites can be divided into three large groups (highlighted in yellow, blue and gray):



The most talk and write about hacking through web attacks. Since this aspect is covered quite well, in this publication I will only briefly mention it, and I would like to focus on two undeservedly forgotten categories: the compromise of resources by technical means without using the “human factor” (yellow block) and breaking through the fault of contractors and employees , that is, those who help maintain the site. In quantitative terms, hacking via the web is about 75%, which is why so close attention is paid to this class.



As for the other two, they are not so popular, but still no less important. According to our statistics, about 5% of incidents account for hacking due to the fault of contractors and employees. But this figure is gradually increasing, since at the moment many websites are being sent for servicing in a web-studio, digital agencies or freelancers.

So, consider the options in order. Let's start with the largest group, hacking the site through web attacks:

• In most cases, this becomes possible as a result of exploiting vulnerabilities.
  
  • in CMS scripts, in plugins and modules . The developers make mistakes: the input parameters are not sufficiently filtered, the data placed in the database is not checked, the information is displayed on the "as is" page, without safe conversions.
  • in the modifications . You can put a secure CMS, but call an inexperienced developer. He will add a plugin, in which he sometimes introduces more than one critical vulnerability and will hack the site through them. The web programmer should be familiar with the principles of secure development, and the site owner should contact experienced contractors.
• The second option for hacking the site is possible due to the brutal force of the administration panels , that is, the selection of logins / passwords. This is a very common type of attack, especially on protected CMS. Users still set short or vocabulary passwords that are easily accessed by intruders and can be picked up in a finite time. As a result, access to the admin panel can be obtained in just a few minutes. The situation is aggravated by the fact that access to the admin panel is usually not limited by additional means, such as two-factor authentication, by the allowed list of IP addresses, and the number of incorrect login attempts is unlimited.

Protection against web attacks

Get rid of web attacks can not be, but they can be counteracted. Below is a list of measures against hacking via the web.

1. It is necessary to update CMS and scripts . With each new version, security patches come out: vulnerabilities are closed, bugs are fixed. All this allows to reduce the likelihood of hacking through the web, although it does not protect against it by 100%, because, unfortunately, new “holes” may appear in the new updates.
2. It is necessary to minimize the amount of plugins in the CMS . The more plugins, the greater the likelihood of vulnerabilities. Ideally, use the solution out of the box, with applied patches and critical updates that cover all known public vulnerabilities in the CMS core. But, since the functionality is not always enough, before installing plug-ins, you need to check whether they are protected and safe.
3. Improvements should be given to experienced web developers who have an idea about the security of sites and sources of problems, that is, they understand the need to filter input and output parameters, secure authentication and authorization algorithms, secure data storage, etc.
4. Traffic must be filtered . According to statistics of traffic proxying services, about 50% of all requests come from bots, and about a quarter of those requests are attacks on a web resource. Filtering requests to the site blocks attacks, spurious traffic and reduces the load during DDOS and brute-force attacks. You can filter using either an external service (Web Application Firewall / AntiDDOS) or a web server module (naxsi / mod_security). Another useful feature of WAF is virtual vulnerability patching. It is not necessary (and not always possible) to put patches on scripts, but WAF can perform virtual patching, that is, block dangerous requests on the fly, preventing it from exploiting the vulnerability. In addition to the service and the web server module, the firewall is built into the CMS. Of course, it cannot be a full-fledged replacement of external WAF or AntiDDOS services, but it partially reduces the likelihood of hacking as a result of web attacks.
5. It is necessary to use plugins and services to protect against brute force . For example, installed on VPS Fail2ban, after several unsuccessful authorization attempts, blocks the client for a while. This makes it difficult and stretches the password in time.

Some webmasters are already using the listed technical means and protection measures, and therefore consider their sites invulnerable. But, alas, the site can still hack and zavirusovat.

If CMS is invulnerable

Why break even invulnerable CMS on a secure hosting? The reason lies in the fact that there are other options for compromising or infecting sites, it is not necessary that the site be hacked through vulnerabilities in scripts. I will cite a few of them:

• From our practice, the most popular option is hacking through account neighbors . For example, on a virtual hosting site is placed, the safety of which pays great attention: it works on an updated version of CMS, applied to it the technical means of protection. But on the same shared-account, another two dozen sites with vulnerable CMS versions can be placed, or an old test version of the site, about which everyone has long forgotten, can be placed, and the file downloader can be opened in it or the admin panel available without authentication. Such unprotected sites are sources of security problems. Through their vulnerabilities, you can embed a site administrator into a database, load a web shell or a backdoor, and then gain complete control over your hosting account. Why is this possible? On shared accounts, where there is no physical isolation of sites from each other, all data is located inside the common file space (account files have a common operating system user), that is, scripts of one site can read, modify, delete scripts, templates and database of another site on the same account. This is the cause of massive hacking sites on the account, when the same type of infection is observed on all resources of the virtual site.
  
  This applies not only to virtual hosting sites, but also to VPS servers. Often, even with technical feasibility and absolute cheapness, a single administrative account (admin user) is created on a dedicated server, and several dozens of sites on different CMS are located inside it. And to hack the entire account, it is enough to have one single critical vulnerability on any of these sites. For a couple of seconds, several dozens of malicious scripts will be downloaded to each site, and the treatment process will resemble scooping up water from a leaky boat: the malicious code was removed from one site, and it “switched” to the cured again from another. Therefore, one of the basic rules of site security is the isolated placement of sites.
• The next option for hacking a secure site is brute force SFTP / FTP accounts or SSH access . For their convenience and to the delight of intruders, webmasters set weak vocabulary passwords that fall into the TOP-100, TOP-1000 popular and are selected in a couple of hours.
• The third option is hacking via phpMyAdmin (as well as other tools used by web developers and administrators). PhpMyAdmin is a database administration tool. Distributed under the open source-license, convenient, simple, affordable, it is put on all hosting and dedicated servers running popular panels. The most interesting is that his address is almost always fixed. That is, you can type site_name / myadmin or / phpmyadmin, and the authorization form phpmyadmin will open. If you enter the password and login from the database, which can be learned by various methods, you will get access to the database. And then using a SQL query, you can embed malicious code into templates, read or create files on disk. And this may already be backdoors, allowing you to upload arbitrary files and execute arbitrary code. Many hackers directly inject code into the database without leaving any traces in the file system. That is, the site owner or webmaster simply does not understand how the virus appears in the page code.
  
  In fact, he sometimes does not even know about the existence of phpMyAdmin, its public accessibility and the possibility of hacking the site through it.
  
  The reader may ask: how can an attacker learn usernames and passwords from the database, because for this you need to access the CMS configuration file? In fact, getting data to connect to the database is much easier than it seems. Sometimes a request to the Google search engine allows you to find a lot of indexed files containing various “sensitive” information. For example, backups of sites with a settings file, or erroneously indexed configuration files. As an example, you can take one old query from the Google Hacking Database - a hacker database containing Google queries for searching indexed vulnerable scripts and sensitive files.
  
  
  
  Enter it into the search bar and get approximately 288 files that contain an open login, password, host. It remains only to take them from there, go to the page / myadmin (or similar for a particular hosting) and log in to conduct operations with the database.
  
  The second option to simply get a password from the database is to search for backups. An attacker can gain unauthorized access to site backups if they are in the root directory of the site (often called backup.zip, backup.tar.g, etc.) or in the case of an insecure web server configuration when the backup directory is open for read by direct link (and sometimes even search engine indexes it). That is, attackers for some fixed paths (in Wordpress this is wp-content / uploads or / backups) can iterate through different file names and unload the backup of the site. This archive contains a configuration file that stores the necessary access to the database.
• Another option for infecting a site is when a webmaster voluntarily installs an infected component . For example, instead of buying a plug-in or template for a site, it downloads the same archive from “warez” sites or a catalog of topics. And in this plugin, a backdoor or malicious code is already “sewn”. Naturally, after a while such a website is hacked.
• And the last option, which is rarely found among large hosters, but occasionally arising among owners of dedicated servers, is server “rooting” (hacking the server and obtaining administrative authority). This is possible if the software, operating system components, and services contain vulnerabilities or configuration errors. If a VPS server is not administered by a specialist, then it is quickly cracked through known vulnerabilities, and then, as a result, all sites located on it are also hacked.

To summarize, hacking methods are not via the web:

1. Interception or theft of access, that is, compromise access to the site.
2. Brute-force attack on services: SFTP, FTP, SSH or administrative hosting panel.
3. Hacking sites through "neighbors".
4. Compromise hosting server, that is, obtaining unauthorized access through vulnerabilities or configuration errors.

Burglary protection

How to protect yourself from this?

1. It is necessary to select the hosting provider correctly, pay attention to the used technical means and services, to the presence of isolation of sites within the accounts. All this greatly reduces the likelihood of hacking.
2. Place sites in isolation. Do not save on security, do not be lazy to create separate accounts for sites. Ideally, you need to place each site on a separate account. If this is a server, also create a separate user account for each site. Now you can even find a hosting company, in which sites are hosted in isolation within a shared-account. There are not many, but they are.
3. Use IP restriction or two-factor authentication when logging into the control panel, while working with FTP and SSH. It is necessary to install additional protection, that is, to restrict access only to a trusted circle of persons.
4. Change passwords regularly. Obvious advice, followed by units. This protects in many cases, even when access is compromised. If the attacker did not have time to use them, then a regular change of passwords allows you to save your access to the sites. The fact is that you do not know whether there was a fact of compromise and you need to proceed from the pessimistic scenario. Therefore, as a preventive measure, it is necessary to regularly set new passwords.
   
   In addition, it is important not just to change them, but to have some kind of a developed security policy defining the procedure for changing passwords in terms of frequency and persistence. This should be a planned and supported process.
5. When working with the site via FTP / in admin panel, use VPN to prevent interception of sensitive and sensitive data.
6. Forget about FTP and block it on a hosting as it is unsafe. If your account has this feature, connect SFTP - this is an add-on for the SSH protocol for working with files. Currently, it is supported on almost all hosting. From the point of view of working with files, you will not notice the difference from FTP, but from the point of view of security, the difference is enormous.
7. If you very often use some functions in the control panel, then create a separate account with limited functionality and bring these popular functions to this account. If you hack it, you will get only limited access to site management.

When a contractor or employee is at fault

Sometimes the “vulnerability” through which a site is hacked and infected is a person himself. In particular - employees and contractors serving the site: content managers, SEO-specialists, web developers. What security problems lie in wait for the site owner?

1. Unscrupulous contractor . Often there are situations when sites are given to service to freelancers who are not always conscientious. For example, there is a chance that as a result of cooperation, something will not please him, it will seem like little money, he will take offense at criticism and start blackmailing the site owner with access. Or he simply uses his administrator privileges and damages the site. Since the contractor has full control over the site, he can inject malicious code onto the pages, he can start selling links to it from the Sape.ru/Trustlink/en, etc., and place unauthorized advertisements. And sometimes the site owner or project manager does not realize that the former webmaster is “parasitic” on a web resource, leaving his “bookmarks” on it.
2. It happens that the contractor installs plugins that contain vulnerabilities or backdoors. For example, the site owner finds a beautiful gallery plugin for the site and asks the freelancer to buy and configure this module. The freelancer finds the same plug-in on the "warez" site, takes money from the customer for the purchase, but actually downloads it for free. In the “null” version there will be some “useful” load in the form of a backdoor or “black” seo-links. The site owner most likely will never know about this, because he will not check what the freelancer has installed.
3. Access leakage is also a very serious moment, because contractors often do not think about the security of client accesses and websites, and carelessly dispose of them. For example, a large digital agency usually works on various tasks with partners (subcontractors) to whom client access is transferred, and nobody knows what partners do with them. These accesses can be transmitted openly via instant messengers over an insecure network connection, stored in text files, stored in various unprotected CRM, etc. As a result, the chances of disclosing data accesses mass, and it will be quite difficult to find the cause of the compromise.
   
   The most vivid example is when such a partner of a large digital agency sits in a cafe, updates the site via FTP, and somewhere near it a hacker settles down, which intercepts traffic in the same WIFI network. Or the router through which the specialist in the coworking cafe works is infected with a trojan. Malicious software collects all these accesses and transmits to attackers. Now this is not uncommon, interception of traffic in open networks - the operation is very simple and effective. Therefore, working in a public place without an active VPN is almost a crime.
4. And the last option is the use of social engineering . Let's say the contractor comes a phishing email: “Your site has been hacked! Please change the password immediately! ”And the link. The frightened performer in confusion clicks on the link, he opens a familiar form of authorization CMS, but he does not notice that the page is loaded from the fake website of the attacker. Enters the password and the latter is safely sent to the hacker.

What to do? How to protect yourself?
To protect against such incidents and problems, the site owner, along with technical means, must implement organizational protection measures.

1. Manage access . The owner should know when and how to change them, who they are, to whom they should be transferred and to what extent. This will protect against many problems.
2. Conduct a security audit after the contractor has completed the work. Files, database and pages of the site can be checked on your own using available scanners or integrity monitoring tools, or you can contact the appropriate security specialists.
3. Instruct contractors . It is imperative to draw up a manual on safe working with the site for employees and contractors and instruct on it. Many experts can perfectly perform their tasks, but do not think about the security of the site.
4. Work under the contract and with proven companies . Collaboration with freelancers often turns into security issues with the site.

Finally

Security is an ongoing process that requires close attention. Only in the case of an integrated approach to security, which includes the mandatory use of technical means and organizational measures, your site will be reliably protected.