Why hack even secure CMS on secure hosting



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

    Every year, the number of hacks and site owners affected by them is growing. And in the last two years, the problem of site security has become especially urgent: the number of attacks and the amount of incoming dangerous traffic has increased many times, and, as a result, the number of hacked resources. Seeing this, webmasters and owners of web projects are gradually beginning to become aware of the problem and become interested in issues of information security of sites, in particular, their protection. In order to properly protect your resource, the owner of the web resource must understand what are the options for hacking, how the attacker works, which attack vectors are most critical and how to close them.

    Unfortunately, there are a lot of articles and videos that mislead those interested in these issues. The problem here is that the issue of security is addressed one-sidedly, usually only technical means of protection 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 smooth operation of the web resource and protection against unauthorized changes. In most cases, the site owner does not want to spend his resources: money, time on the security of the project, therefore, in his opinion, the optimal strategy is chosen: use the popular commercial site management system and place the site on a popular hosting. Everything seems to be logical: a secure system works in a secure 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 technical protection measures alone are sufficient.

    Alas, all these “myths” - about using only web attacks to hack sites, about the security of CMS and the sufficiency of technical measures, lead to new massive hacking sites. What to do to prevent this from happening? An integrated approach to the issue of site security is required. Further we will consider why it is necessary to pay constant and close attention to both technical means of protection, 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 using web vulnerabilities.

    Website hacking options


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



    Most of all they say and write about hacking through web attacks. Since this aspect is covered quite well, in this publication I will just mention it in passing, and I would like to focus on two undeservedly forgotten categories: compromising resources by technical means without using the “human factor” (yellow block) and hacking through the fault of contractors and employees , that is, those who help maintain the site. In quantitative terms, hacks through the web account for about 75%, which accounts for such close attention to this class.



    As for the other two, they are not as popular, but still no less important. According to our statistics, hacking caused by contractors and employees accounts for about 5% of incidents. But this figure is gradually growing, because at the moment, many sites are being serviced by web studios, digital agencies or freelancers.

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

    • In most cases, this becomes possible as a result of exploiting vulnerabilities.
      • in CMS scripts, in plugins and modules . Developers make mistakes: the input parameters are not filtered enough, the data placed in the database is not checked, information is displayed on the page "as is", without safe conversions.
      • in revisions . You can put a secure CMS, but at the same time call an inexperienced developer. He will add a plug-in, in which he will sometimes add more than one critical vulnerability and through them they will hack the site. A web programmer should be familiar with the principles of safe development, and the site owner should contact experienced contractors.
    • The second option of hacking the site is possible thanks to the brute force of the administration panels , that is, the selection of logins / passwords. This is a very common type of attack, especially against secure CMS. As before, users set short or dictionary passwords, which are easily sorted out by attackers and can be picked up in a finite amount of 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, an allowed list of IP addresses, and the number of incorrect login attempts is unlimited.

    Web Attack Protection


    You cannot get rid of web attacks, but they can be counteracted. Below is a list of anti-hacking measures via the web.

    1. It is necessary to update CMS and scripts . With each new version, security patches are released: vulnerabilities are closed, errors are fixed. All this allows you to reduce the likelihood of a hack through the web, although it does not protect against it by 100%, because unfortunately new “holes” may appear in new updates.
    2. It is necessary to minimize the volume of plugins in the CMS . The more plugins, the more likely there are vulnerabilities. Ideally, use the solution “out of the box”, with patches and critical updates applied that cover all known public vulnerabilities in the CMS core. But, since functionality is not always enough, before installing plugins, you must definitely check how secure and secure they are.
    3. Improvements should be given to experienced web developers who have an idea about the security of sites and the 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 traffic proxy services statistics, 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 both an external service (Web Application Firewall / AntiDDOS) and a web server module (naxsi / mod_security). Another useful feature of WAF is virtual patch vulnerabilities. It is not necessary (and not always possible) to patch the scripts, but WAF can perform virtual patching, that is, block dangerous requests on the fly, preventing the exploit from being exploited. In addition to the service and the web server module, the firewall can also be built into the CMS. Of course, it cannot be a full-fledged replacement for external services WAF or AntiDDOS,
    5. It is necessary to use plugins and services to protect against brute force . Say, installed on VPS Fail2ban after several unsuccessful login attempts for a while blocks the client. This makes it difficult and time-consuming to select a password.

    Some webmasters already apply the listed technical means and protection measures, and therefore consider their sites invulnerable. But, alas, the site can still be hacked and infected.

    If the CMS is invulnerable


    Why even hacking 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 give a few of them:

    • From our practice, the most popular option is hacking through account neighbors. For example, a hosting is hosted on a shared hosting site, the security of which is given great attention: it runs on an updated version of the CMS, technical protection measures are applied to it. But on the same shared account, two dozen sites with vulnerable versions of CMS can be placed, or an old test version of the site can be placed that everyone has long forgotten about, and a file downloader can be opened in it or the admin panel can be accessed without authentication. Such unprotected sites are the source of security problems. Through their vulnerabilities, you can embed a site administrator in a database, download a web shell or backdoor, and then gain full 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 (the account files have a common user of the operating system), that is, the scripts of one site can read, modify, delete scripts, templates and the database of another site on the same account. This is the reason for mass hacking of sites on the account, when the same type of infection is observed on all resources of the virtual platform.

      This applies not only to shared hosting, but also to VPS servers. Often, even with the 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. In a couple of seconds, several dozens of malicious scripts will be downloaded to each site, and the treatment process will be reminiscent of scooping up water from a holey boat: malicious code was removed from one site, and it again “switched” to the cured one. Therefore, one of the basic rules of site security is the isolated placement of sites.
    • The next option for hacking a secure site is the bruteforce of SFTP / FTP accounts or SSH accesses . For their convenience and to the delight of attackers, webmasters set weak dictionary passwords that fall into the TOP-100, TOP-1000 popular and are selected in a couple of hours.
    • The third option is hacking through phpMyAdmin (as well as other tools used by web developers and administrators). PhpMyAdmin is a database administration tool. It is distributed under an open source license, convenient, simple, affordable, it is installed on all hosting and dedicated servers running popular panels. The most interesting thing is that his address is almost always fixed. That is, you can type site_name / myadminor / phpmyadmin, and the phpmyadmin login form 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 an SQL query, you can embed malicious code into templates, read or create files on disk. And this may already be backdoors, allowing you to download 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 owner of the site or the webmaster simply does not understand how the virus appears in the code of the page.

      In fact, he sometimes does not even know about the existence of phpMyAdmin, its public availability and the possibility of hacking a site through it.

      The reader may ask: how does an attacker know the logins 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 sounds. 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 queries to Google to search for indexed vulnerable scripts and sensitive files.



      Enter it in the search bar and get about 288 files that contain an open username, password, host. It remains only to take them from there, go to the / myadmin page (or similar for a specific hosting) and log in to conduct operations with the database.

      The second option to simply get the password from the database is to search for backups. An attacker can gain unauthorized access to the site’s backups if they are located in the root directory of the site (often called backup.zip, backup.tar.g, etc.) or in case of unsafe configuration of the web server when the backup directory is open for reading through a direct link (and sometimes it is even indexed by a search engine). That is, attackers for some fixed paths (in Wordpress it is wp-content / uploads or / backups) can iterate over various file names and upload the site’s backup. This archive contains the configuration file, which stores the necessary access to the database.
    • Another option for website infection is when the webmaster voluntarily installs the 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 site is hacked.
    • And the last option, which is rarely found in large hosters, but occasionally occurs among owners of dedicated servers, is to “root” the server (hack the server and gain administrative authority). This is possible if the software, operating system components and services contain vulnerabilities or configuration errors. If the VPS server is not administered by a specialist, then it is quickly hacked 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. The interception or theft of access, that is, the compromise of access to the site.
    2. Brute force attack on services: SFTP, FTP, SSH or hosting admin panel.
    3. Hacking sites through "neighbors".
    4. Compromise of the hosting server, i.e. gaining unauthorized access through vulnerabilities or configuration errors.

    Hacking protection


    How to protect yourself from this?

    1. You need to choose the right host, pay attention to the used technical tools and services, the presence of isolation of sites inside accounts. All this greatly reduces the likelihood of hacking.
    2. Host 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 whose sites are located in isolation within a shared account. There are not many of them, but they are.
    3. Use IP restriction or two-factor authentication when entering the control panel, when working with FTP and SSH. It is necessary to establish additional protection, that is, restrict access only to a trusted circle of people.
    4. Change your passwords regularly. Obvious advice followed by units. This protects in many cases, even when access is compromised. If the attacker did not manage to use them, then a regular change of passwords allows you to maintain your access to sites. The fact is that you do not know if there was a fact of compromise and you need to proceed from a pessimistic scenario. Therefore, as a preventive measure, it is necessary to regularly set new passwords.

      In addition, it is important not only to change them, but to have some developed security policy that defines the procedure for changing passwords in terms of frequency and strength. This should be a planned and supported process.
    5. When working with the site via FTP / admin panel, use a VPN to prevent the interception of access, sensitive and confidential data.
    6. Forget FTP and block it on the hosting, as it is not secure. If your account has such an opportunity, enable SFTP - this is an add-on on the SSH protocol for working with files. Currently, it is supported on almost all hosting sites. From the point of view of working with files, you will not notice the difference with 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 transfer these popular functions to this account. If you hack it, then they will get only limited access to site management.

    When the contractor or employee is to blame


    Sometimes the “vulnerability” through which a website is hacked and infected is a person himself. In particular, the employees and contractors serving the site: content managers, SEO specialists, web developers. What security issues await the site owner in this case?

    1. Unscrupulous contractor . Often there are situations when sites are given to freelancers who are not always conscientious. For example, it is likely that as a result of cooperation he will not like something, that he will seem to have little money, he will be offended by criticism and will begin to blackmail the site owner with accesses. Or he will simply use his administrator privileges and damage the site. Since the contractor has full control over the site, it can inject malicious code into the pages, it can start selling links from the Sape.ru/Trustlink/ exchange, etc., and place unauthorized advertising on it. And sometimes the site owner or project manager does not realize that the former webmaster “parasitizes” the web resource, leaving it with his “bookmarks”.
    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. A freelancer finds the same plug-in on a “warez” site, takes money from the customer to purchase, but actually downloads it for free. In the “null” version there will be some “payload” in the form of a backdoor or “black” seo links. The site owner will most likely never know about this, because he will not check what the freelancer has installed.
    3. Access leakage is also a very serious point, because often contractors do not think about the security of client accesses and sites, 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 what partners do with them, no one knows. These accesses can be transferred openly through messengers over an insecure network connection, stored in text files, stored in various insecure CRMs, etc. As a result, the chances of disclosing these accesses are many, and it will be difficult to find the reason for 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 him there is a hacker who intercepts traffic on the same WIFI network. Or a router through which a specialist in a coworking cafe works is infected with a trojan. Malicious software collects all these accesses and transfers them to attackers. Now this is no longer uncommon, intercepting 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 . Say a contractor comes with a phishing email: “Your site has been hacked! Please change your password urgently! ” and link. Frightened performer clicks the link in confusion, he opens the familiar CMS authorization form, but he does not notice that the page is loaded from the fraudulent site of the attacker. Enters a 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 security measures.

    1. Manage access . The owner must know when and how to change them, who has them, to whom to transfer them, and to what extent. This will protect against many problems.
    2. Carry out a security audit after the contractor has completed the work. Files, database and pages of the site can be checked independently using available scanners or integrity monitoring tools, or you can contact the appropriate security experts.
    3. Instruct contractors . Be sure to draw up a guide to safe work with the site for employees and contractors and instruct on it. Many experts can perform their tasks perfectly, but not think about the security of the site.
    4. Work under contract and with trusted companies . Collaboration with freelancers often leads to security issues with the site.

    Finally


    Safety 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, will your site be securely protected.

    Also popular now: