Obscure but not Secure

Back when I started learning how to "hack," I ran into a TryHackMe box. I remember this particular box because it had this weird configuration that surprised/frustrated me. So any newbie learning network security knows the common ports and their services: port 23 for Telnet, 22 for SSH, 21 for FTP. Well, this particular lab used some obscure port for SSH or Telnet. Spoiler alert: it was not secure.

That lab taught me an interesting concept: Security by Obscurity. Security by Obscurity is the flawed notion that by hiding or making an asset difficult to find, it would deter attackers from pwning the said assets (hard to argue with the logic 😂). But hiding assets or moving things around to deter an attacker without following sound security practices, such as patching systems, always proves to be a fatal flaw.

Some examples of Security by Obscurity attempts include :

1. Using proprietary encryption algorithms breaks one of the cardinal rules of modern cryptography: "Never roll your own crypto."
2. Renaming login URLs or sensitive endpoints. Renaming the standard login paths ("/admin", "/payment") to random paths such as ("/bankname_Hiddenlogin") does little to deter attackers if proper/secure authentication and authorization mechanisms are not implemented on those endpoints.
3. Placing services behind random port numbers. Let's be serious. If the vulnerability exists, an attacker will find it regardless of the port.
4. Denying access to Security teams and pentesters. Refusing to offer access to scoped assets for testing purposes. Your security team / pentesters are on your side; remember, "Early detection saves lives"(It's Pink October, forgive me ). It's always better for your team to identify the vulnerabilities before an attacker does.

I'm sure you get the point now. I get not wanting to make the job easy for a potential attacker, but secrecy is not a viable alternative to security (annoying quote). The only way to stop or deter an attacker is to secure the systems and follow sound security practices. Some of these sound security practices I keep referring to include:

1. Implementing Multi-factor authentication
2. Ensuring that software and firmware updates are deployed to fix security vulnerabilities and phasing out end-of-life (EOL) systems.
3. Implementing the principle of least privilege to ensure users and employees only have access to the necessary data and systems needed for their jobs.
4. Organising regular awareness training to educate employees on how to recognize social engineering attempts such as phishing and how to handle these incidents.

Dangers of Security by Obscurity

Security by Obscurity creates a false sense of security where organizations are unaware of risks present within their systems. Almost like hiding your head in the sand and pretending your problems do not exist. This also leads to complacency, where you could be less inclined to take precautions to keep your system safe if you believe that its obscurity makes it secure.

Also, security by obscurity makes it difficult to patch any discovered vulnerabilities; relying on secrecy in an attempt to prevent attacks depends heavily on communication and coordination between team members. If a team member is unaware of the changes made by another team member, it makes remediation of vulnerabilities very taxing. Security via Obscurity is not a reliable primary security measure that would offer protection against a determined and skilled attacker.

To conclude, obscurity is not an alternative to security. Work must be done to ensure that all systems are safe and secure.