Security through Obscurity has been in tech news recently because of NimzaLoader, a new piece of malware written in a somewhat esoteric language, Nim. As the Threat Team from Network Detection and Response provider BluVector wrote about the threat, “…from an attacker’s position, security by obscurity can sometimes be used to their advantage, especially if their goal is to evade detection by legacy signature-based detection tools. These tools require signatures be created and distributed to provide detection of threats, so if a new threat is sufficiently different to existing threats, it will not be detected.”
Security through obscurity (STO) is a popular topic of debate within the security community because you can easily come up with thought experiments around the value of secrecy vs. transparency. Wikipedia says that “Security through Obscurity is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component.” It’s remarkably hard to find other definitions of STO that don’t resort to illustrative examples.
Woodrow Hartzog and Evan Selinger write in the Atlantic, “Obscurity is the idea that when information is hard to obtain or understand, it is, to some degree, safe. Safety, here, doesn’t mean inaccessible. Competent and determined data hunters armed with the right tools can always find a way to get it. Less committed folks, however, experience great effort as a deterrent.”
One hypothetical offered in discussion on Stack Overflow is that security through obscurity is burying a bag of money in the woods. The secrecy of the location is the only thing protecting it. (A treasure chest would add an additional layer of security, in the form of a lock). Is there a difference between keeping the location of a treasure a secret and keeping your banking password a secret? Well, it’s much easier to change a password than dig up and rebury your money.
But some worry that security through obscurity can backfire – you can probably reset your password if you lose it, but if you forget where you buried your money, you’re out of luck. Robert Graham at Security Boulevard had a lengthy discussion of security through obscurity, with a 0day vulnerability example:
“[R]unning SSH on a non-standard port, such as 7837 instead of 22, [is] a hypothetical example.
“Let’s continue this hypothetical. You do this. Then an 0day is discovered, and a worm infecting SSH spreads throughout the Internet. This is exactly the sort of thing you were protecting against with your obscurity.
“Yet, the outcome isn’t what you expect. Instead, you find that the all your systems running SSH on the standard port of 22 remain uninfected, and that the only infections were of systems running SSH on port 7837. How could this happen?
“The (hypothetical) reason is that your organization immediately put a filter for port 22 on the firewalls, scanned the network for all SSH servers, and patched the ones they found. At the same time, the worm runs automated Shodan scripts and masscan, and thus was able to nearly instantaneously discover the non-standard ports.
“Thus you cleverness made things worse, not better.”
What’s your favorite hypothetical (or real life!) example of the benefits or pitfalls of security through obscurity? Share this article and tag Cyber.Media with your security through obscurity example.