Concept: Security by Deception with Emulation
December 15, 2007 – 6:27 pm by Shane
It is time to think of computer security in a new way.
In the physical world that we can feel and touch, security involves denying access through physical means such as implementing locks, infrared monitoring, closed circuit television, biometrics, human guards, alarms, card access control systems, vaults, and much more. Similar approaches have been implemented in computer security such as interactive logons, smart cards, biometrics, intrusion detection, and encryption.
Security measures and mechanisms implemented in both the physical world and in computing are very alike. Yet the physical world is very different than that of a world of 1s and 0s that make up our computing systems of today.
Introducing Security by Deception
NOTE: The only security by deception currently in widespread implementation that I know if is a honey pot.
With computing came another dimension, nothing like the physical world that we were used to interacting in before circuit boards and operating systems. As shown by modern operating systems, we can manipulate computers into emulating just about anything we want.
dontstealmyrsshackosis
So why are we thinking of computer security like we think of physical security?
With that in mind I would like to present an idea. Security by deception.
What if instead of denying access, the computer granted access to an intruder. The operating system would then launch an emulator in somewhat of a chroot jail. The emulator could be a GUI or command line. I am no security expert, but how would an intruder know the difference between a real shell and an emulator?
This, in turn, would severely slow an intruder from breaking into your system with something such as a brute force cracker. The brute force cracker would have no way of knowing if it has cracked a real login or is simply logged in to a emulation shell since the system would accept all logins.
Example:
dontstealmyrsshackosis
Hackers point of view:
Johnny Cracker is attempting to brute force your server. He discovers that upon the first attempt by using THC Hydra to crack the root login through SSH that access to the system has been granted. He logins to the SSH session and he is in the system. Johnny Cracker gets his kicks by destroying systems so he executes rm -rf / to delete all the files on the server. He quickly exits the SSH session and disconnects from the Internet going on about his day feeling successful.
Security by Deception and what really happened:
The server is programmed to accept all possible logins, but only for real user names and passwords do you get redirected into the real system shell. For any possible character combinations that are entered upon login, except for real user names and passwords, the shell is redirected to a separate, emulated SSH session that is running on another server (maybe virtualized). Thus, when Johnny Cracker logged in, he only assumes that he is on the real server and destroyed the real data. When in fact, he only deleted fake data that affected nothing except, for example, a VMWare server that is set to restore a snapshot every 30 minutes.
Where emulation comes in to play:
Suppose this concept is one day implemented in systems all around the world. At this time, it is also a known fact that many systems implement this technique to secure data and system integrity. An attacker or a brute force program could simply execute an ifconfig command to see if the IP address matches the system currently being scanned, and if not, it moves on to the next login attempt. This would still slow the brute force program, but the status of the login would easily be known.
An emulator could detect where the SSH session was connecting from and simply assign a variable to the IP address response when ifconfig was executed. Therefor, unless you know the system, there would be no way for the attacker to know whether the session is in an emulation shell, or the real system.
dontstealmyrsshackosis
This could be applied to almost any type of computing system such as web server administration interfaces, and so on. Maybe this will get some gears turning with the experts trying to fight all the answers to today’s computer security issues. Maybe someone can enlighten me as to why this approach is not implemented in most systems today. I would refer to a widespread implementation as the next generation of information security.
Tags: Concept, Deception, Emulation, Featured, Security
16 Responses to “Concept: Security by Deception with Emulation”
“For any possible character combinations that are entered upon login, except for real user names and passwords, the shell is redirected to a separate, emulated SSH session that is running on another server (maybe virtualized)” IMO,Wouldn’t that cause DoS attacks much easier to perform? Assume 100s of bots trying to connect and your box invoking a seperate virtual shell for each attempted login?
By Mariappan on Dec 16, 2007
Sure, but it would matter, it would be redirected to a honey pot system through a transparent SSH session running VMware with resource limitations. ;)
By Shane on Dec 16, 2007
I think it is a good approach to prevent brute-force password cracking attacks, but how can this approach be implemented for an SQL Injection?
Maybe, you can make a fake database and can execute real queries on it, but if the database schema and properties will be same for all times/situations then that can be easily distinguishable.
Thanks!
By Mesut TİMUR on Dec 16, 2007
I see two issues with this:
Usability - What if a user accidentally types in the wrong password? If there is no easy method of determining whether they are on the real system or not, then they’re going to get pissed off when the work they do gets deleted.
Increase Attack Surface - You also have to lock that other machine down enough so that it cannot be leveraged to attack your other machine. If you segregate it away well enough, this might not be an issue; but would you want to risk it?
And even if you eliminated those two issues, then the benefit is still pretty tiny. Sure; brute forcing passwords becomes infeasible since it’d take too long -> so just implement time delays in your login process, so that it becomes infeasible without needing to waste so much effort deceiving the attacker.
By kuza55 on Dec 16, 2007
@Mesut - I currently see no use for this concept in that respect. This is simply for authentication.
Being able to inject SQL is an application vulnerability.
@kuza - Usability - There could be something as simple as a certain file in the home directory, or a different login banner. Things that only a system admin would know.
Increased attack surface - I can understand where you are coming from on this one. But then again, with the proper emulation technology, this would not be a concern.
And yes, there are other ways to prevent brute forcing such as fail2ban, etc.
Thanks for the feedback everyone.
By Shane on Dec 16, 2007
Well, the idea is good, but needs a lot of refining :)
i don’t think a hacker is interested in only doing a “rm -rf /” hackers now are interested in getting information, which will not be in that emulated shell, and they could somehow make robots that can detect if the account logged in to a real system or an emulated one.
By charafantah on Dec 17, 2007
This sounds like an interesting idea, but the first thing I would try is to “call home” in order to verify if network connections to the outside are allowed.
If they are allowed I’m happy because I could relay attacks via this server.
If there is no way out, I would get a little suspicious.
The “call home”-test could also be automated.
Maybe I’m missing something, but that would be one of my first checks.
greets,
R
By r0bert on Dec 17, 2007
Thanks for the feedback r0bert and charafantah. Once again, we are talking about emulation here, so everything is deceptive.
By Shane on Dec 17, 2007
that was worth reading, thx for sharing the deception.
Rajj
By Rajj on Dec 18, 2007
Thanks for the good post, I enjoyed reading it.
And just in case some of you don’t know this, I think it is possible to achieve this by installing a hardened operating system (like gentoo hardened), and just install a few services.
Then you can virtualize many other environments using “vserver”, and protect them with gr-security. Then install the webserver in one virtual OS, install SSH in another and so on. Then if an attacker manages to break into the SSH server, it would be difficult for him to know that he is in a virtual server. Then it would be very very difficult for him to reach the webserver, and even more difficult to escape from the chrooted environment.
And you can also install some services as intrusion detection systems in the mother server to protect the virtual servers, this way the attacker will never see them and he won’t be able to install rootkits or put a backdoor in the server.
I think many of you already know this, but maybe its worth saying. I’m sure you can achieve this “Security by deception” idea implementing security schemes like the one I explained above. ¿What do you guys think?
By trew on Dec 18, 2007
Hooray! I knew someone had the knowledge to connect the dots on this one. =)
By Shane on Dec 18, 2007
This is an interesting topic to me and I was working on similar ideas in my security concepts paper:
http://www.subspacefield.org/security/security_concepts.html#tth_sEc19.14
By Travis H. on Dec 19, 2007
Why not “procass” the hacker like the body processes fluids. IN andOUT the body takes harmful material and simply processes it.Some aspect of the hackers work would trigger a rerouting and sweep him out by a special port. Or his presence
would trigger a flow of energy and sweep him back out. I dunno I’m not really too computer literate
but well any thought might lead to a solution.
Doug Rosbury
By Doug Rosbury on Apr 21, 2008
Perhaps an easier approach is to simply keep virtualized targets listening on default ports like 22, 3389, 23 etc and change your actual ports to non-standard ports. I haven’t tried that myself but simply changing my SSH ports stopped all brute force attacks on my servers to my surprise. I guess my SSH port is outside the common port scanning range.
A few other points.
1) I wouldn’t make it too easy for hackers to get into your fake server or they’ll know it’s a fake. Either use easily crackable passwords or authenticate successfully after a short but random number of attempts.
2) Your bandwidth cannot be limited by virtualization nor emulation so setting up a target, even if it’s a trap, could clog your connection with hackers.
By linuxamp on May 6, 2008