Among many of our clients we are noticing that fairly often the login panel for administration of the sites are left publicly and easily accessible, either through easy to guess URLs or unpatched vulnerabilities.
While this is not an immediate threat, an exposed and obvious administrative login panel can make it significantly easier for attackers to breach the site, especially if access controls are limited to username and password combinations alone. This situation allows for simple brute forcing, signing in with compromised credentials/obtaining credentials, or in the case of unpatched systems, access by exploiting vulnerabilities. Even in cases where the admin login panel URL is complex and hard to guess, path disclosure vulnerabilities can be used to locate it.
An example of such is a recent vulnerability in the all native unpatched versions of Magento 2. On sites affected by this vulnerability, the following case sensitive URLs can be used to bypass exclusions and end up being redirected to the admin login panel regardless of whether the default URL has been changed and can therefore be used to easily locate it. For example your-magento2-website.com followed by any of the paths below, can be used to be automatically redirected to the administration logon page:
/catalog/Adminhtml_category/
/cms/ADMINHTML_page
/cms/aDminhtml_page
/cms/adMInhtml_page
Magento has released patches addressing this issue.
Other vulnerabilities such as the Magento unauthenticated SQL Injection issue (PRODSECBUG-2198) can lead to sensitive data leakage and the compromise of admin credentials, which or course can then be used by threat actors to login to exposed admin panels and breach the site.
In addition, there are many sites with publicly accessible instances of the Adminer solution. Mentioned previously in another blog post about the Adminer vulnerability, certain outdated versions are vulnerable to an exploit that can be used to compromise database credentials.
We find that the solution is occasionally left in situ by web developers who no longer need it but forgot to remove or restrict access to it. We also see it being uploaded by attackers who use it as a more subtle backdoor onto the site, especially in the case of the vulnerable versions. We strongly recommend ensuring that any Adminer files are removed if no longer necessary, and kept up to date and locked down if in use.
It’s recommended best practice to ensure your website is kept up to date with the latest software and patches, and this should always be a priority. However, as there is an inevitable gap between a new vulnerability being discovered and a patch being released, there remains a certain level of constant risk.
An immediate way of helping reduce this risk is by obscuring and restricting access to your admin login panels. In the case of Magento 2 the admin panel location can be changed within the env.php file and within the local.xml file for Magento 1 (you can find a guide on how to do this here). We also recommend restricting access so that only whitelisted IP addresses can access the page, which can be done through access configuration files (.htaccess for Apache servers and nginx.conf files for nginx servers) or by using a Web Application Firewall. A further recommendation is the adoption of multifactor authentication controls, as these provide significant security benefits, but that’s a topic for another blog post that we will be releasing in the near future....
