By default, most open source applications will expose the administrative panel to the world by default, but why? Why is this a core design?
From a security perspective, its design leaves a lot to be desired. It’s the number one abused vector by bad actors used to compromise sites and the reasoning is simple – website owners are bad administrators by default.
Open-Source Administrative Panels
If you’re wondering what I’m referring to, I’m alluding to the page you use to log into your site. Here is an example of the most common administrative panels for open-source CMS applications:
- WordPress – [yoursite]/wp-admin or /wp-login.php
- Jooma! – [yousite]/administrator
- Magento – [yoursite]/magento/admin
- Drupal – [yoursite]/admin
**Some of these are dependent on the version you’re running
The information above is known to the world as a whole, good and bad, and it’s why you see scenarios like this:
This image was provided by Anthony D. Paul and shows continuous sustained brute force login attempts against his WordPress sites.
Why this is happening is anyone’s guess, but there is a high probability it is an automated system. I bet if you analyzed the POST requests you’d find the combinations being used are boilerplate payloads. It’s likely no more a function of his sites finally being scanned, being identified to have WordPress, and now the system automatically checking to see if they are able to penetrate further.
Attacks like this are the result of one basic feature – exposing admin panels to the world by default.
Protecting Admin Panels
Although being the #1 abused vector for more than a decade, it always surprises me the resistance I get when I ask website owners why they expose it to the world by default.
I can narrow down the reasons for why the admin panel is not hardened to three reasons:
- I run a community, and we require the admin panel to log in;
- I travel a lot, I don’t want to bother with creating a whitelist;
- I manage multiple editors, they can access the site from anywhere;
The only reason that carries weight is the one with regards to a community. That one is especially challenging in today design. In an ideal world, we would create a secondary authentication mechanism that doesn’t use the main access point for community sites (but I digress).
That being said, the most effective hardening you can apply to your administrative panel is to employ a default-whitelist mechanism.
This will out perform any rate throttling, attempt limiter or blacklisting mechanism you deploy. Unless you want to make it your business to constantly check and analyze requests, which might sound fun at first until you realize it doesn’t stop. Bad actors typically have more options, and time, than the patience or interest most website owners have.
You can’t abuse what you can’t reach.
A whitelist mechanism allows you to block the world, and only accept legitimate users. There are a couple of different ways to do this. The two most popular is IP whitelisting and Browser Authentication.
Here at NOC, we offer browser authentication, so if you try to go to noc.org/wp-admin you will be greeted with:
This ensures that only those allowed to access our Admin page can access it. Managing access is simple, the platform issues you an authentication URL that you save as a bookmark.
You save the bookmark in your browser dash and when you need to access it immediately grants access to your site.
Benefits of Hardening Administrative Panels
In case being the #1 abused vector is not enough of a reason to deploy this kind of hardening, you’ll be happy to know it also has the ability to protect against the #2 abused vector – software vulnerabilities.
Here are just a few that would have been mitigated by hardening wp-admin:
- MailPoet (Circa 2014) – MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites
- Reflective XSS in WordPress Plugin Admin Pages – this one effected 7 different plugins (circa 2020)
- Duplicate-Page WordPress Plugin (Circa 2019)