Nowadays, different systems, applications, frameworks, etc. come with an endless number of configurations that are sometimes not even reviewed. Even within the Systems team, there is often a joke that installing things on Windows is just “next next next…”, or in programming, “follow tutorial X until it works.”
Security is a completely separate point from the functionality of a system/application, and many times they do not even get along. It is usually relatively easy to get a platform up and running, but not so easy to do it securely, both for the ecosystem itself and for the user.
In this article, we are going to look at the dangers that different types of “defaults” can cause in any company, whether due to the inexperience of technicians, the excuse of “it’s on the internal network, nothing will happen,” or even a boss who wants something “for yesterday,” or the technician whose priority will be to make it work, not to make it secure.
Well yes, one of the greatest dangers is default passwords. Not only those that literally come by default in some applications, but also that password everyone in the company knows, the one that is set by default and that, if someone discovers it, gives them access to half of the system’s users — and the worst part is when it’s something like “Company01.”
It is obvious that, with so many systems and the need for different passwords, there will always be a test environment or something that “was only going to be used for testing, but since it works, let’s leave it as it is.” The height of this situation is when it is exposed on the Internet, where millions of bots try every day to access all kinds of services and software using default credentials. Anyone who thinks this is impossible has never seen an IRC chat with more than 150 “users” that were actually Raspberry Pis exposed to the Internet and infected with malware that simply logged into devices using the default username “pi” and password “raspberry.”
At this point, it should go without saying, but even if a device is on an internal network, attackers only need a single hole to access your network. If we also add the possibility of moving from machine to machine, sooner or later we will find a ransom note because the data has been stolen and encrypted, and money is being demanded in exchange.
As a solution, the use of a password manager. There is no excuse for a single default password. Even in cloud environments, there are several services and systems that can handle this management.
Remember to review passwords for routers, Wi‑Fi, local users, databases, web services, and of course, administrators.
Active Directory (AD) is usually a relatively easy task when dealing with just a few users, but by default it does not implement the proper groups or policies needed for good security. Default permissions are also often not secure enough, and as a system or company grows, a more structured set of groups with stricter restrictions becomes necessary.
At the same time, we have Group Policies, whose default values may need to be changed. For example, a regular user should not need access to the Windows CMD console, yet it is enabled by default. How many times have we heard that employees should not connect external devices to their computers? Then why is it enabled by default in AD environments? Even regarding permissions, users running services—such as web services—should be isolated and should not be able to access functions or system files that are not strictly necessary. And yet, privilege escalation often succeeds because default permissions were left unchanged.
The existence of certain default users whose permissions are not properly configured or who are not removed is an additional danger that often goes unnoticed because they are forgotten. Even WordPress is not free from dangerous default configurations, as some of them reveal usernames or even offer a service enabled by default that allows brute‑force attacks—and worse, without any attempt limit.
Lastly, I would add the configurations found in many widely used guides that do not apply secure settings. For example, an employee wants to set up an Apache web service. Since they don’t have time, they search online and pick one of the first four guides they find. The guide explains that you just need to run a few commands and that’s it. Due to lack of time, the employee doesn’t review what they are actually doing and ends up setting an insecure password—or perhaps the guide was written by someone working in a test environment and did not apply any security measures.
Does it sound like a joke that software products have online guides that don’t apply even basic authentication for sensitive data? It sounds absurd, but we now laugh about the time when dozens and dozens of Elasticsearch instances exposed on the Internet leaked sensitive data with no authentication at all. Fortunately, Elasticsearch now asks during setup whether you want authentication or not, although you can still find some instances without restrictions.
There is nothing to gain from trying to find someone to blame, but to prevent these issues from happening again, good security practices must be encouraged. Employees should be trained to properly configure different services, even if it is more difficult. Time must be allocated to correctly implement new functionalities, and periodic security audits should be requested from specialized providers.
Fortunately (although we should not become complacent), some Cloud configurations are now secure by default. For example, they block all access unless someone modifies those values — a practice that improves the security of new environments.
Don’t just look for how to do something; look for how to do it securely.