Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Security Features

{mospagebreak toctitle= Introduction}

Introduction

The unfortunate bottom line of networking security problems is that hacking happens because it is allowed to happen. Most cases of fraud could have been prevented if people had just adhered to sensible protocols and properly implemented available security solutions. It cannot be stressed enough that the big problem with IT security is people - you, me, and the vast majority of people in the world who interface with IT systems.

It is far easier to get vital information from a person than it is to extract it from a well organized and protected computer system. That's seems like a fantastic statement, but it is absolutely true. If a complete security architecture is deployed, maintained and followed, then it is very difficult to penetrate systems. But humans are another problem entirely.

Absolute faith in a security system can ultimately be its greatest weakness, as people grow accustomed to it and fail to hold up their end of the bargain. Every wall has a gate through which people can walk; conventional hacking involves breaking this gate down. Social engineering is getting the gate keepers to wave you past with a smile on their faces.

To focus your mind for the next couple of minutes while you read through this article, let me tell you a story. For the distinct purpose of legality, I'm going to clearly state that this story is a figment of my imagination.

Hiding In Plain Sight

Suppose that I'm asked by a firm to configure some Internet application servers. This is a very high profile hacking target: an online financial institution.

I'm hired to work on a server farm. After introducing myself to the staff and conducting some initial meetings, I get to work at a console that is provided for me in the main IT area. I bring in my own laptop and configure it for DHCP and simply plug into the system. Out of habit, I run a quick scan looking for other devices that are running in promiscuous mode (sniffing) on the system. This might point to a previous or current visitor, or company security software looking for illegal activity on the network.

The server room is located several floors up, and all entrances and elevators are secured by access control cards, not unlike a credit card. For me to access this area I have to ask someone to accompany me and provide access by swiping their card. I need to do this a couple of times a day as the need arises.

Following a short period of working on site, everyone is tired of traveling around the building using their key cards to open doors and operate elevators on my behalf. Trust builds as familiarity breeds contempt, and within two weeks I'm getting a loan of employees' pass cards, and a short time later I have my own temporary key card.


Nirvana

In the server room, I go to the KVM switch to access my servers. There I find all kinds of devices running, logged in - and completely unattended. Device #1 is a newly-built Win 2003 server in default state; device #2 is the mail server, and is logged in; devices 3, 4 and 5 are my servers, and other devices, one with a Cisco firewall dashboard on-screen, all open for business. One machine that was locked sat there like a magnet. For the fun of it I tried the administrator password from the servers that I was working on and would you believe it, I got in - with a common password! Absolute total hacking nirvana!

For my convenience, I needed to have remote command line access to my target servers to stop and start specific server processes. I'm not a lover of VNC so I put on Netcat and configured it to run as a remote command shell. Absolute complete hacking orgasm!!!

So here I am, an Average Joe consultant, and after a very short time, I have root access to everything that matters in that organization. I've essentially hacked nothing, in the electronic sense of the word.

Such trust is stunning, and very, very foolish. I'm a good guy and I took it to the IT manager who wasn't at all impressed that I raised the issue. Having completed my contract I went on to other things, returning to this firm several months later for a routine server health check.

I couldn't resist asking the obvious question: what had changed since my last visit? Well I found that all the servers were no longer left idly open as they had been before. But it didn't really matter, because they all still had the same administrator password.

Stop Being Polite, And Stop Worrying About Convenience!

The door that takes ten seconds to close is a gateway to any area that is subject to controlled access. Someone swipes their card and quickly swing the door open and walks through; this leaves an opportunity for illicit access by an intruder ghosting the door.

Worse, consider the polite employee who sees a beautiful girl coming up behind him, laden with a heavy briefcase, and holds the door open with a smile. Or how about the network that allows anyone to configure for DHCP and then lets them plug and play from any terminal?

How about the simple example of someone sitting at their desk and getting a call from "The IT department." The warm voice says, "Hi there, I just need your username and password" - that probably wouldn't work, right? Well, what if the person has scoped you out ahead of time, and perhaps knows something about you or your family, and starts off the conversation with "I was out with your wife at the book club last night, she was telling me all about such and such..." This goes on for three minutes and the person, too polite to say "Umm, sorry, but I don't actually know who the hell you are..." develops a sense of trust with this person. When the "IT person" then drops that request for a password or similar, they are much more likely to hand it over.


Covering Up The Break In

Let's take a slightly different angle on this, while staying with the central theme of security flaws.

Again, for the record, this is a figment of my imagination.

I got a call from a friend one evening, announcing with some glee that a client I had consulted for in the past was about to get creamed. I played the game and persuaded my buddy to let me see what he had obtained on this firm. So we go for a beer, and he pulls out his ultra small laptop (of which I'm envious) and brings up a file on screen that clearly should not have been available to him - or anyone else, for that matter.

It is a Microsoft Excel file that has been cracked through brute force attack using Elcomsoft's file cracker. This is the type of file that would typically be kept by a database administrator. In that file is the username and password of every Oracle database (DB) user in this organization, the OS systems passwords to all machines running the DBs, and usernames and passwords to all ancillary machines used for routing requests for credit card clearance payments gateways.

The Exposure Was Staggering

I had actually created some of these passwords myself during my efforts for the firm. It had connection details for every database account that you can think of, including external links to other sites through VPNs and so on.

And then, with a smile, he said: "there's more." He had the names of many files that appeared to belong to staff, many of whom I knew personally. I asked if he was completely nuts to be in possession of this stuff, as he is a security head with a reputation to protect.

It wasn't a big deal for him though, as quite simply, the files were available online. Someone had posted them to a site! So it wasn't a case that he had some form of unique access: everyone who had access to the web site where they were visible had access, and the ability to download and play with the stuff. What in the name of all that is holy had happened?

I immediately got on the phone to my IT managerial contact in that organization and brought the contents of the file to his attention. He was stunned, and not simply by the fact that the file had been exposed: he didn't realize that such a file existed at all! And worse, he knew well that only a small and very select few within his firm could have access to that level of data, and therefore it had to be one of them who was responsible for its existence in the first place.

That Horrible '0 Sh1t' Moment

Just when it seemed that things couldn't get any worse, my buddy in security calls and suggests something that was going to make this mess turn into a catastrophe: he had seen some stuff that indicated that these files were in fact from a backup tape. A backup tape? Why of course, now it all made sense. With so much material relating to user files in one place, the idea of a backup tape made perfect sense: a hacker entering the system though electronic means would be unlikely to waste time with low grade files when there is a possibility of hitting a root. Or in this case, every root!

Having gotten over the implications of the find, the IT manager now had to comprehend the extent of the damage. However, to do that, he had to rely completely on the expertise of the very people who had created the file in the first place. This act was a sackable offense on its own.

Now he was in a big jam; he couldn't proceed without the collaboration of his closest technical associates, yet he knew full well that both the file creator, and the source responsible for the backup tape leaving his IT building, were working inside his managerial domain.


What Would You Do If You Were In His Position?

He felt that he had to seal the problem without exposing his key staff to higher management scrutiny. Call it loyalty, shrewdness, or just a plain old 'cover your ass' strategy, but he decided to batten down the hatches, attempt to retrieve the floating information from its online source, patch up all possible holes that he could find, slap a couple of people on the wrists, and ride out any storms that might have arisen.

There was no serious attempt to assess damage. This event clearly indicated that there was direct complicity between an administrative user and the hacker(s).

What was the potential for data damage? Databases containing tens of thousands of personal records possibly exposed. Machines handling thousands of credit card transactions possibly exposed. The complete network and server architecture was possibly exposed, and the highest echelon of IT administrators directly implicated in the firing line.

And it all went quietly away. This is a very subtle social engineering strategy that is often risked by hackers. If the potential for considerable damage to friends and brand is big enough, then there is a good chance that an intrusion will be allowed to sink from view, very quietly.

So what am I saying?

Am I implying that in addition to instances where you have been the victim of fraud and you know about it, that there are others that you do not know about? That there is a possibility that thieves out there may have information about you that has been stolen, and the situation has been elaborately covered up by the custodial organization? That there are instances where staff that have administrative responsibility for systems interact with hackers?

Am I saying that that's how it gets done? Am I saying that that's how the staggering levels of IT related fraud happen with almost total immunity from prosecution? That in many cases, where there is a significant threat to destabilization of a company infrastructure, or brand damage, or market depreciation, then an organization may decide to ride the hit and tighten security?

And More Examples...

Other examples of social engineering are also rampant, including some that apply to the end-user directly. Phishing is a form of social engineering. Another good example came about recently when hackers used excerpts from BBC News stories in emails, with a link at the end saying "Read more..." Users click on the link without checking it, or even questioning why they're getting emails from the BBC, and the next thing they know they're getting spyware and Trojans downloading onto their machines.

The list goes on and on, and so do the mistakes. In the problems that I have outlined above, it wasn't the security architecture that failed, it was the implementation, maintenance and basic adherence to protocol that did. The risks that this pose, both to the person and to the organization, are clear. Everything from credit card details to military secrets can be uncovered through clever social engineering, which essentially uses a lot of the manipulation tricks of the spy trade.

Discuss this in the Forums