Security by Obscurity is Underrated

https://utkusen.com/blog/security-by-obscurity-is-underrated.html

In the information security field, we have developed lots of thoughts that can’t be discussed (or rarely discussed):

Never roll your own crypto

Always use TLS

Security by obscurity is bad

And goes like this. Most of them are very generally correct. However, I started to think that people are telling those because everyone is telling them. And, most of the people are actually not thinking about exceptional cases. In this post, I will raise my objection against the idea of “Security by obscurity is bad”.

Risk, Defense in Depth and Swiss Cheese

One of the main goal of defensive security is reducing the risk for the target business. According to the OWASP’s methodology, the risk of an issue is calculated with the formula below:

Risk = Likelihood * Impact

According to this formula, a Remote Code Execution issue poses more risk than a Cross Site Scripting one since the RCE causes more impact. This is easy. But what about the likelihood metric. According to the OWASP, likelihood refers that:

At the highest level, this is a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker

So, if we can reduce the likelihood, we can reduce the overall risk. That’s good. It’s actually very similar to a very common idea called “Defense in Depth”. It’s also referred as “Swiss Cheese Model”

According to this model, you need to build your defense mechanisms in a layered model so that even the attackers pass the first one, they will get caught on the others.

Security by Obscurity

So let’s talk about security by obscurity. It’s a bad idea to use it as a single layer of defense. If the attacker passes it, there is nothing else to protect you. But it’s actually would be good to use it as an “additional” layer of defense. Because it has a low implementation cost and it usually works well.

Let’s think about a couple of scenarios here:

I have a server that runs the SSH with it’s default port 22 and my credentials are: root:123456. What is the likelihood of being compromised?

It’s almost 100% since the hackers are conducting brute force attacks to the services with common credentials globally.

SSH runs in port 22 and my credentials are utku:123456. What is the likelihood of being compromised?

Well, we have eliminated the global brute forcers since we are not using a common username. The likelihood and risk are reduced. However, we still have to deal with targeted attackers. A targeted attacker can guess the username as utku since it’s my name.

SSH runs in port 64323 and my credentials are utku:123456. What is the likelihood of being compromised?

Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. What about the others? To find this out, I did a small survey on my Twitter to find out people’s port scan behaviors.

I'm trying to prove a point for my new article. I need your answers for the question below. (please be honest)-When you do a port scan with nmap to find open ports on the target, are you specify a custom port range to scan all 65,535 ports? (with -p0-65535 parameter)— Utku Şen (@utkusen) September 7, 2020

As you can see here, lots of people tend to scan the default/most popular ports only. So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.

The same thing goes for software vulnerabilities as well. If a vulnerability found in the Microsoft Remote Desktop Protocol, everybody will scan for the port 3389 globally. You can reduce your risk just by changing the default port.

Other Applications

Of course, it’s possible to use the same methodology in other fields other than changing the defaults. For example, the following ideas might be a good idea for some specific cases (not always)

Obfuscating codes: Of course, it’s common knowledge. Hackers are people too. If you obfuscate your code well, they will need to spend more time to find issues. They may give up eventually.

Using random variable names for a web application: Instead of using clear variable names, you can switch them with random strings. It might help just like the code obfuscation.

Using Symmetric Encryption in the Database: When you write data to the database, use a function like encryption_algorithm(data,key). Likewise, when you read data, use a function like decryption_algorithm(data,key). If the attacker can read your backend code, obviously he/she can decrypt your database. But if there is an issue that allows an attacker to read data from the database, but not the backend code (like SQL Injection), the gathered data won’t be helpful for the attacker.

Real Life Applications

Security by obscurity is widely used in physical/real-life security. For example, the president goes from point A to point B with his 30 cars convoy. But he’s not sitting on his own presidential car so that the attacker won’t target him easily. He can be in any car and it reduces the risk of an attack.

Camouflaged animals are using security by obscurity as well. Obscurity reduces the likelihood of being killed. Therefore, they gained this ability in the evolutionary process.

Conclusion

Security by obscurity is not enough by itself. You should always enforce the best practices. However, if you can reduce the risk with zero cost, you should do that. Obscurity is a good layer of security.