Security Through Obscurity?
This my first ever post and I feel it’s a pertinent one to mention.
What is it and why is it bad?
Security through obscurity can be said to be bad because it often implies that the obscurity is being used as the principal means of security. Obscurity is fine until it is discovered, but once someone has worked out your particular obscurity, then your system is vulnerable again. [source: https://en.wikipedia.org/wiki/Security_through_obscurity]
Security is an often overlooked topic in organizations. I’ve heard many different arguments for why things were configured a certain way. Once thing that stands is security through obscurity should never be overlooked. Things are always secure, until they’re not. You should never expose something publicly that is not meant to be exposed publicly.
For example:
A typical company, that has publicly hosted domains, will have a public facing presence on the internet. This usually means there will be a public IP address with a Network Area Translation, or NAT for short, to a private IP address on a corporate or cloud network.
This private IP address is typically hosted in an isolated area called a demilitarized zone, or DMZ for short.
The DMZ is designed to be an isolated area of a company network. You need special rules to get in or out of this particular network. And in many cases there are special rules to allow you in to the systems/applications etc. that are within that network.
The main purpose of the NAT is to translate an public IP address into a private IP address. The private IP address is unknown to the public.
When we type the name for websites like “duckduckgo.com” or “reddit.com” our computers know how to translate these into an IP address (there is a lot of magic happening behind the scenes here that we won’t discuss).
Generally, speaking these names translate to a public IP address. That public IP address then is translated by network appliances to a private IP address (as previously mentioned).
There are scenarios, for example when you are on a corporate network or corporate virtual private network, VPN. Where applications used by the company are resolving to private IP addresses. This is normal and expected.
That’s a lot of explaining, right?…
Not entirely, there is a lot more at play that we won’t cover. But for arguments sake the norm for appropriate security is things that should be kept private are not to be exposed publicly.
There are specific networks in the protocol for IP version 4 (IPv4) that are meant to be private. This is the RFC 1918 standard for IPv4. We have several large groups of private IP addresses that are inaccessible publicly unless you specifically allow that traffic into your network through a NAT.
This changes with IPv6, but that is out of scope of the scenario in question.
For the purpose of this case will use “example.com” as the public domain record. Think of “example.com” as “google.com”, you can access it anywhere with an internet connection.
I came across a case in which I discovered an application with a public name record “example.com” was returning an IPv4 private IP address. At its surface, this does not seem to be a particularly large issue. As previously stated with RFC 1918 (the private IP scope) – I am unable to access that site since we are unable to access private resources from a public network without a NAT.
Currently, I’m safe. Nothing to worry about, right?…
Wrong.
Why is this bad?
With public cloud and rapid deployments, dealing with infrastructure at scale, things change quickly. Someone may change the way the code is deployed and inadvertently change the way that application is deployed and give it a public NAT. Now we have what should be a private application on a public network.
-or-
“example.com” has exposed private information. Let’s say “example.com” has an application that is designed to be public and they host through “public.example.com”. A malicious user or program can now take the previously exposed private information and attempt to apply it through this new attack vector.
The point is, just because something at its face may seem secure you need to think about things from every possible angle. It does not mean you should not implement things or delay the implementation of applications. It just means security should be at the forefront of every design that you create and that obscurity does not lead to solid security practices.
