Security through obscurity, minority and obsolescence 10-11-2012, 04:03 PM
#1
Introduction
Security through obscurity is a controversial idea in computer sec community. It is based on an assumption that it's more difficult to hack something you know less about or something that isn't well known.
Basics
Is security through obscurity a good security practice?
In general - no. Even unpopular, old, obfuscated, encrypted closed-source software run on experimental computers with strange processor arhitecture can be hacked. There are some useful implementations of this security model if you know what you're doing.
Elements of security through obscurity in 'mainstream' security
Even the biggest opponents of security through obscurity will agree that some things need to be hidden. Configuration files, activity logs, private keys and passwords should never be revealed, even in the most disclosure- or correctness-centered environment, for obvious reasons.
Security through obscurity (and related models) as an additional layer of security
The only way you can somewhat reliably use this model (and related ones, I'll describe them later in this post) is as an additional layer of security. Chosing correct software, fixing bugs, designing correct business logic and avoiding misconfigurations is still a priority. Why? Because security through obscurity does not remove any existing security problems. It just hopes that the hacker will be slowed down enough for you to have time to fix them or that he'll simply get tired, give up and search for the other target.
Types of security through obscurity and their implementation
Closed source software
The idea here is that because we can't see the source codes, it should be more difficult to find vulnerabilities. As anyone with computer experience knows, this idea is extremely WRONG. While the attackers are slowed down, it simply isn't enough. Think about it - all those super secret anti-piracy measures that game devlopers put into their products get cracked pretty fast. The same goes for software that might get you hacked. Java, Adobe Reader and Internet Explorer are all closed source and still they are terrible security-wise.
Why is that? Because closed source is worse for the developers than for the hackers. If a hacker finds a vuln in an open source software, he can usually identify the problem in source code (especially when most bugs in open source software are found by looking into source code). If the same hacker finds a vuln in a closed source software, it's usually through scanning for certain errors, reverse engineering or trial and error. He can't pinpoint it to the specific part of the source, this is something that only the developers can do, so the time between finding a vuln and fixing a vuln is significantly longer than in open source (assuming that both open source and closed source software are currently supported).
That said, you should never disclose sources of configured PHP files as they may contain sensitive information. This is even more important if you customize sources (more about customization later).
Minor customizations
This is about introducing minor changes to the expected pattern. This is almost always a good thing if you can do it without fucking everything up. Change filenames and catalog names (don't forget to modify source codes to reflect your changes). Place services on different ports. Avoid using default settings. Use decoys and honeypots. This way, you'll confuse both the attackers and automated scanners. Obviously, you should keep those changes minor so that you won't accidentally create more vulns.
Hiding and spoofing
Related to previous one and also usually a good thing. Here you make your software appear to be something else. Changing the layout/GUI so it appears to be different software. Fake version info. Banner grabbing spoofing. Bonus points for making it look like something vulnerable to exploits that don't work on your software of choice. But remember - it's difficult to spoof a webserver or OS. Those can be fingerprinted easily.
Encryption and obfuscation
Self-explanatory. Encryption is good and you should use it. Secure connection, encrypted sensitive data etc. are all great. Obfuscation is usually not necessary, unless you suspect the possibility of being hacked from whitebox position. Even then, it's better to simply stop working with people who hack you.
Also, there is crypting. It obfuscates or encrypts either compiled executables or any code for interpreted languages. It's good for malwares when you want to avoid being detected by AV software and other fun stuff, not useful otherwise.
Security through minority
Security through minority is using software not many people use. It's usually as bad security practice as overreliance on closed sources (not many people use it -> not many people find errors -> errors can sit there for a long time without being reported) but there are exceptions. If the software has active and security-oriented community, it's a very good idea to use it.
Security through minority is a great thing when choosing a hashing function. Because most of the hashes are broken with rainbow tables, a strong but obscure hash will take a long time to be broken.
Custom software
Like one above but with software specifically designed for you. Again, not good unless your team is good and focused on security.
Uncommon CPU and/or OS
This is an interesting way of reducing the impact of buffer overflows, system shell access and command execution. As the machine code required for getting anything out of buffer overflow will be different and so will be OS commands, it might take quite some time for your attacker to learn it. Also, the less known the OS the less viruses work on it. The downside is, of course, the fact that you're going to work with something much different and probably counter-intuitive so your work will be much harder. Also, remember that even the most obscure OS needs to be secure.
Security through obsolescence
This one is all about finding 'old but gold' things. While avoiding updates is both counter-intuitive and a horrible security practice, there are specific cases in which obsolete solutions are better than the current ones.
Correctly implemented security through obsolescence has all the advantages of security through minority and/or uncommon CPU and OS without any of the disadvantages. The basic idea here is that you need something that is:
Summary
Security through obscurity should never be used alone. It can be a useful additional layer of protection if used wisely. From techniques described here, I highly reccommend spoofing, customization, encryption and security through obsolescence. But remember - never forget that you always need to avoid bugs and misconfigurations, use strong passwords, have ways of preventing virus infections etc. Those things cannot be replaced.
Security through obscurity is a controversial idea in computer sec community. It is based on an assumption that it's more difficult to hack something you know less about or something that isn't well known.
Basics
Is security through obscurity a good security practice?
In general - no. Even unpopular, old, obfuscated, encrypted closed-source software run on experimental computers with strange processor arhitecture can be hacked. There are some useful implementations of this security model if you know what you're doing.
Elements of security through obscurity in 'mainstream' security
Even the biggest opponents of security through obscurity will agree that some things need to be hidden. Configuration files, activity logs, private keys and passwords should never be revealed, even in the most disclosure- or correctness-centered environment, for obvious reasons.
Security through obscurity (and related models) as an additional layer of security
The only way you can somewhat reliably use this model (and related ones, I'll describe them later in this post) is as an additional layer of security. Chosing correct software, fixing bugs, designing correct business logic and avoiding misconfigurations is still a priority. Why? Because security through obscurity does not remove any existing security problems. It just hopes that the hacker will be slowed down enough for you to have time to fix them or that he'll simply get tired, give up and search for the other target.
Types of security through obscurity and their implementation
Closed source software
The idea here is that because we can't see the source codes, it should be more difficult to find vulnerabilities. As anyone with computer experience knows, this idea is extremely WRONG. While the attackers are slowed down, it simply isn't enough. Think about it - all those super secret anti-piracy measures that game devlopers put into their products get cracked pretty fast. The same goes for software that might get you hacked. Java, Adobe Reader and Internet Explorer are all closed source and still they are terrible security-wise.
Why is that? Because closed source is worse for the developers than for the hackers. If a hacker finds a vuln in an open source software, he can usually identify the problem in source code (especially when most bugs in open source software are found by looking into source code). If the same hacker finds a vuln in a closed source software, it's usually through scanning for certain errors, reverse engineering or trial and error. He can't pinpoint it to the specific part of the source, this is something that only the developers can do, so the time between finding a vuln and fixing a vuln is significantly longer than in open source (assuming that both open source and closed source software are currently supported).
That said, you should never disclose sources of configured PHP files as they may contain sensitive information. This is even more important if you customize sources (more about customization later).
Minor customizations
This is about introducing minor changes to the expected pattern. This is almost always a good thing if you can do it without fucking everything up. Change filenames and catalog names (don't forget to modify source codes to reflect your changes). Place services on different ports. Avoid using default settings. Use decoys and honeypots. This way, you'll confuse both the attackers and automated scanners. Obviously, you should keep those changes minor so that you won't accidentally create more vulns.
Hiding and spoofing
Related to previous one and also usually a good thing. Here you make your software appear to be something else. Changing the layout/GUI so it appears to be different software. Fake version info. Banner grabbing spoofing. Bonus points for making it look like something vulnerable to exploits that don't work on your software of choice. But remember - it's difficult to spoof a webserver or OS. Those can be fingerprinted easily.
Encryption and obfuscation
Self-explanatory. Encryption is good and you should use it. Secure connection, encrypted sensitive data etc. are all great. Obfuscation is usually not necessary, unless you suspect the possibility of being hacked from whitebox position. Even then, it's better to simply stop working with people who hack you.
Also, there is crypting. It obfuscates or encrypts either compiled executables or any code for interpreted languages. It's good for malwares when you want to avoid being detected by AV software and other fun stuff, not useful otherwise.
Security through minority
Security through minority is using software not many people use. It's usually as bad security practice as overreliance on closed sources (not many people use it -> not many people find errors -> errors can sit there for a long time without being reported) but there are exceptions. If the software has active and security-oriented community, it's a very good idea to use it.
Security through minority is a great thing when choosing a hashing function. Because most of the hashes are broken with rainbow tables, a strong but obscure hash will take a long time to be broken.
Custom software
Like one above but with software specifically designed for you. Again, not good unless your team is good and focused on security.
Uncommon CPU and/or OS
This is an interesting way of reducing the impact of buffer overflows, system shell access and command execution. As the machine code required for getting anything out of buffer overflow will be different and so will be OS commands, it might take quite some time for your attacker to learn it. Also, the less known the OS the less viruses work on it. The downside is, of course, the fact that you're going to work with something much different and probably counter-intuitive so your work will be much harder. Also, remember that even the most obscure OS needs to be secure.
Security through obsolescence
This one is all about finding 'old but gold' things. While avoiding updates is both counter-intuitive and a horrible security practice, there are specific cases in which obsolete solutions are better than the current ones.
Correctly implemented security through obsolescence has all the advantages of security through minority and/or uncommon CPU and OS without any of the disadvantages. The basic idea here is that you need something that is:
- well researched enough for the bugs to be found and already fixed
- compatible and functional so it can do everything you need to do without big modifications
- easy or well described so you won't have problems using it
- in active development (either by the original developers or by the community) so that if the bug is found, it can be fixed
Summary
Security through obscurity should never be used alone. It can be a useful additional layer of protection if used wisely. From techniques described here, I highly reccommend spoofing, customization, encryption and security through obsolescence. But remember - never forget that you always need to avoid bugs and misconfigurations, use strong passwords, have ways of preventing virus infections etc. Those things cannot be replaced.
![[+]](https://sinister.li/images/modern/collapse_collapsed.png)
