It all started when one of my ‘Skiddy’ friends and I went for a sleepover at our ‘Geeky’ friend’s place. The first few words that came out of his mouth (Skiddy friend) as we walked into our Geeky friend’s apartment was,
“I wish you had Wi-Fi so I could connect to it and show you this web-based (bandwidth intense) App I have running remotely on one of my servers; but then again, I am picking up other Wi-Fi signals. Unfortunately their signals are really weak, like my Hacking skills!”
Laughing, he went on to say,
“If only I had mad skills (l337 h4x0r), I would have connected to one of the nearby Wi-Fi networks and piggybacked its Internet connection to show you!”
My Geeky friend replied,
“I do have Wi-Fi but because of people like you, it’s running in stealth mode!”
It immediately registered and he (Skiddy friend) replied,
“Security by Obscurity, really!?”
These chain of events brought about the whole 'Security by Obscurity' debate. What is 'Security by Obscurity?' The definitions from these two ‘tech junkies’ left us more confused. As we Console-gamed the night away, we agreed on the following 'Security by Obscurity' definitions (opinions):
Security by Obscurity involves securing of systems through the reliance of unknown or hidden weakness in the model or implementation of a particular system.
It also involves the concealing or addition of a protective security layer to an already hardened system or technology. In the end, the overall security posture is increased.
Sounds a bit confusing right?
Using the above definitions, some real life examples are as follows:
Definition 1 – A computer user who writes down his or her login password on a piece of paper and keeps the piece of paper under his or her keyboard. In this example, it’s literally right out in the open for anyone to grab, but not everyone can find it or will know it’s there. Someone who is really dedicated can find it and log straight in.
Definition 2 – A Systems Administrator who hosts a web-based service on an alternate port (e.g port 8443) whose pages are secured by an SSL Certificate and only allows users from a specific IP Address range to be able to connect to it. This scenario is not hack proof but the implementation tries to add another layer of security on an already secured setup.
Some Practical Examples
That being said, as our game pads did nothing but allow us to dig deeper into virtual reality, I posed the question:
What real life examples of Security by Obscurity have we come across, fiddled with or currently have running?
These are some real life examples that Skiddy, Geeky and I came up with:
We realised that as former System Administrators we have come across (in most cases) colleagues who have tried to narrow down the number of malicious user attacks or malicious bots connecting to specific services running on specific ports by renaming the Port Number(s), as most of these attacks are automated scans done by bots that look for specific ports.
This has seen the amount of traffic to these Ports dropping considerably. Examples are Admins who rename ports like SSH Service Ports from 22, Remote Desktop Service Ports from 3389 or Web-based Services Ports from 80 or 8080 to something else.
In some cases it might actually not even involve renaming the port as such but implementing Network Address Translation (NAT) at a firewall level that points to these services or ports.
SSID Wi-Fi Disabling
This brought about the whole Security by Obscurity argument. SSID Wi-Fi disabling basically involves hiding one's Wireless Network name from being broadcasted.
We can argue that a Wi-Fi SSID in itself is a Network name and not a password. Some will argue that, at times the fact that one announces the presence of a Wireless network (by broadcasting the Wi-Fi Network’s SSID) draws unnecessary attention, especially to some Script Kiddies and hackers who are generally intrigued by these ‘boundaryless signals’ (Geeky’s opinion).
So why broadcast them? But then again, let’s leave this debate for another day.
Default CMS Admin Backend URL Renaming
Online presence in the form of websites is on the increase and of particular interest are Content Management Systems (CMSes) like Joomla, Drupal, WordPress and MODX to name a few.
In order for one to be able to create new posts, update posts or delete posts for blogging, informative, marketing purposes, etc one has to log into the Admin Backend portal that allows them to make the necessary changes.
The different CMSes come with default backend URLs to access their respective Admin panels. For example, by default Joomla is http://sitename/administrator;
Drupal is http://sitename/?q=user;
WordPress is http://sitename/wp-admin and
MODX is http://sitename/manager to name a few.
To prevent bots (that usually run specific scripts from checking specific URL patterns) from targeting one’s site or prevent malicious users from targeting your site through the use of Google dorks, most Administrators rename the Admin Backend URLs.
Local Built-in Administrator User Account Disabling
The Local Built-in Admin Account is known to possess ‘Super Cow’ powers. Usually when a malicious user has access to the User Account Login screen on a specific PC, be it remotely via RDP, VNC etc or physically, they usually know that to be able to run applications with Full Permission, they need to log in with an Administrative account (or escalate their privileges).
Besides, every hacker's dream is owning the Administrator Account (Windows) or Root Account (Linux).
Unfortunately, Windows is designed inherently in such ways that the Administrator is present by default and most users enable it for ease of use. All it takes for a successful login is to get the Username and Password right, so why give away the first clue?
That is, Administrator or Root user account name and let them only guess the password. It is highly advisable to disable the Administrator or Root account. This makes the local user enumeration process on the local machine difficult for the malicious perpetrator.
Steganography involves concealing or embedding a message within something that is seemingly harmless or which doesn’t attract itself as an object of scrutiny. For example messages can be concealed in images, text files, music files etc.
It’s usually ideal to use in place of encryption as it is plainly invisible or where use of encryption is illegal.
Is a method where sensitive information is converted to cipher text and one needs to have a secret key to be able to read or decipher the message. Encrypted messages or data can be intercepted but denies the message contents to the interceptor if they do not have the decryption keys.
SSH Port Tunneling
SSH Port tunneling is the process of preventing people from snooping or eavesdropping your traffic and requires one to force or redirect all traffic to go via or through an artificial and encrypted electronic passage irrespective of whether they are connected to the internet via a public or private network. SSH Port Tunneling is also known as a poor System Admin’s VPN (Virtual Private Network).
Each example above, either falls under one of the two definitions or both. I personally think ‘Security by Obscurity’ can either be good or bad security.
I consider it good if it is used as an additional protective security layer to an already hardened system or technology, and bad if one relies on it and ONLY uses it to conceal an already vulnerable or weak system (as such a scenario only buys time, eventually someone will find and expose or exploit the weakness).
Note: This post basically lists some of the real life examples of Security by Obscurity we have come across, fiddled with or currently have running! In my next article I will list steps and preventative measures one can take to achieve the above, supported by examples.
That being said, even after taking the necessary listed preventive steps, it does not mean the measures taken are hacker proof, but assuming we are adding it to a system that already has decent controls in place, "Security by Obscurity, really?" I will chant DJ Carl Cox’s slogan on this one, “Oh yes, Oh yes!!!”