The Art of Deception: Controlling the Human Element of Security (23 page)

This one point is so important that I reiterate it throughout this book: Verify, verify, verify. Any request not made in person should never be accepted without verifying the requestor's identity--period.

Cleaning Up For any company that does not have security guards around the clock, the scheme wherein an attacker gains access to an office after hours presents a challenge. Cleaning people will ordinarily treat with respect anyone who appears to be with the company and appears legitimate. After all, this is someone who could get them in trouble or fired. For that reason, cleaning crews, whether internal or contracted from an outside agency, must be trained on physical security matters.

Janitorial work doesn't exactly require a college education, or even the ability to speak English, and the usual training, if any, involves non-security related issues such as which kind of cleaning product to use for different tasks. Generally these people don't get an instruction like, "If someone asks you to let them in after hours, you need to see their company ID card, and then call the cleaning company office, explain the situation, and wait for authorization."

An organization needs to plan for a situation like the one in this chapter before it happens and train people accordingly. In my personal experience, I have found that most, if not all, private sector businesses are very lax in this area of physical security. You might try to approach the problem from the other end, putting the burden on your company's own employees. A company without 24-hour guard service should tell its employees that to get in after hours, they are to bring their own keys or electronic access cards, and must never put the cleaning people in the position of deciding who it is okay to admit. Then tell the janitorial company that their people must always be trained that no one is to be admitted to your premises by them at any time. This is a simple rule: Do not open the door for anyone. If appropriate, this could be put into writing as a condition of the contract with the cleaning company.

Also, cleaning crews should be trained about piggybacking techniques (unauthorized persons following an authorized person into a secure entrance). They should also be trained not to allow another person to follow them into the building just because the person looks like they might be an employee.

Follow up every now and then--say, three or four times a year--by staging a penetration test or vulnerability assessment. Have someone show up at the door when the cleaning crew is at work and try to talk her way into the building. Rather than using your own employees, you can hire a firm that specializes in this kind of penetration testing.

Pass It On: Protect Your Passwords More and more, organizations are becoming increasingly vigilant about enforcing security policies through technical means--for example, configuring the operating system to enforce password policies and limit the number of invalid login attempts that can be made before locking out the account. In fact, Microsoft Windows business platforms generally have this feature built in. Still, recognizing how easily annoyed customers are by features that require extra effort, the products are usually delivered with security features turned off. It's really about time that software manufacturers stop delivering products with security features disabled by default when it should be the other way around. (I suspect they'll figure this out soon enough.)

Of course, corporate security policy should mandate system administrators to enforce security policy through technical means whenever possible, with the goal of not relying on fallible humans any more than necessary. It's a no-brainer that when you limit the number of successive invalid login attempts to a particular account, for example, you make an attacker's life significantly more difficult.

Every organization faces that uneasy balance between strong security and employee productivity, which leads some employees to ignore security policies, not accepting how essential these safeguards are for protecting the integrity of sensitive corporate information.

If a company's policies leave some issues un-addressed, employees may use the path of least resistance and do whatever action is most convenient and makes their job easier. Some employees may resist change and openly disregard good security habits. You may have encountered such an employee, who follows enforced rules about password length and complexity but then writes the password on a Post-it note and defiantly sticks it to his monitor.

A vital part of protecting your organization is the use of hard-to-discover passwords, combined with strong security settings in your technology.

For a detailed discussion of recommended password policies, see Chapter 16.

As many of the stories here demonstrate, the skilled social engineer often targets lower-level personnel in the organizational hierarchy. It can be easy to manipulate these people into revealing seemingly innocuous information that the attacker uses to advance one step closer to obtaining more sensitive company information.

An attacker targets entry-level employees because they are typically unaware of the value of specific company information or of the possible results of certain actions. Also, they tend to be easily influenced by some of the more common social engineering approaches--a caller who invokes authority; a person who seems friendly and likeable; a person who appears to know people in the company who are known to the victim; a request that the attacker claims is urgent; or the inference that the victim will gain some kind of favor or recognition.

Here are some illustrations of the attack on the lower-level employee in action.

THE HELPFUL SECURITY GUARD Swindlers hope to find a person who's greedy because they are the ones most likely to fall for a con game. Social engineers, when targeting someone such as a member of a sanitation crew or a security guard, hope to find someone who is good-natured, friendly, and trusting of others. They are the ones most likely to be willing to help. That's just what the attacker had in mind in the following story.

Elliot's View Date/time: 3:26 a.m. on a Tuesday morning in February 1998. Location: Marchand Microsystems facility, Nashua, New Hampshire

Elliot Staley knew he wasn't supposed to leave his station when he wasn't on his scheduled rounds. But it was the middle of the night, for crying out loud, and he hadn't seen a single person since he had come on duty. And it was nearly time to make his rounds anyway. The poor guy on the telephone sounded like he really needed help. And it makes a person feel fine when they can do a little good for somebody.

Bill's Story Bill Goodrock had a simple goal, one he had held on to, unaltered, since age twelve: to retire by age twenty-four, not ever touching a penny of his trust fund. To show his father, the almighty and unforgiving banker, that he could be a success on his own.

Only two years left and it's by now perfectly clear he won't make his fortune in the next twenty-four months by being a brilliant businessman and he won't do it by being a sharp investor. He once wondered about robbing banks with a gun but that's just the stuff of fiction--the risk-benefit

trade-off is so lousy. Instead he daydreams about doing a Rifkin--robbing a bank electronically. The last time Bill was in Europe with the family, he opened a bank account in Monaco with 100 Francs. It still has only 100 francs in it, but he has a plan that could help it reach seven digits in a hurry. Maybe even eight if he's lucky.

Bill's girlfriend Anne-marie worked in M&A for a large Boston bank. One day while waiting at her offices until she got out of a late meeting, he gave in to curiosity and plugged his laptop into an Ethernet port in the conference room he was using. Yes!--he was on their internal network, connected inside the bank's network.., behind the corporate firewall. That gave him an idea.

He pooled his talent with a classmate who knew a young woman named Julia, a brilliant computer science Ph.D. candidate doing an internship at Marchand Microsystems. Julia looked like a great source for essential insider information. They told her they were writing a script for a movie and she actually believed them. She thought it was fun making up a story with them and giving them all the details about how you could actually bring off the caper they had described. She thought the idea was brilliant, actually, and kept badgering them about giving her a screen credit, too.

They warned her about how often screenplay ideas get stolen and made her swear she'd never tell anyone.

Suitably coached by Julia, Bill did the risky part himself and never doubted he could bring it off.

I called in the afternoon and managed to find out that the night supervisor of the security force was a man named Isaiah Adams. At 9:30 that night I called the building and talked to the guard on the lobby security desk. My story was all based on urgency and I made myself sound a little panicky. "I'm having car trouble and I can't get to the facility," I said. "I have this emergency and I really need your help. I tried calling the guard supervisor, Isaiah, but he's not at home. Can you just do me this onetime favor, I'd really appreciate it?" The rooms in that big facility were each labeled with a mail-stop code so I gave him the mail-stop of the computer lab and asked him if he knew where that was. He said yes, and agreed to go there for me. He said it would take him a few minutes to get to the room, and I said I'd call him in the lab, giving the excuse that I was using the only phone line available to me and I was using it to dial into the network to try to fix the problem.

He was already there and waiting by the time I called, and I told him where to find the console I was interested in, looking for one with a paper banner reading "elmer"--the host that Julia had said was used to build the release versions of the operating system that the company marketed. When he said he had found it, I knew for sure that Julia had been feeding us good information and my heart skipped a beat. I had him hit the Enter key a couple of times, and he said it printed a pound sign. Which told me the computer was logged in as root, the super-user account with all system privileges. He was a hunt-and-peck typist and got all in a sweat when I tried to talk him through entering my next command, which was more than a bit tricky:

echo 'fix:x:0:0::/:/bin/sh' >> /etc/passwd

Finally he got it right, and we had now provided an account with a name fix. And then I had him type

echo 'fix: :10300:0:0' 55 /etc/shadow

This established the encrypted password, which goes between the double colon. Putting nothing between those two colons meant the account would have a null password. So just those two commands was all it took to append the account fix to the password file, with a null password. Best of all, the account would have the same privileges as a super-user.

The next thing I had him do was to enter a recursive directory command that printed out a long list of file names. Then I had him feed the paper forward, tear it off, and take it with him back to his guard desk because "I may need you to read me something from it later on."

The beauty of this was that he had no idea he had created a new account. And I had him print out the directory listing of filenames because I needed to make sure the commands he typed earlier would leave the computer room with him. That way the system administrator or operator wouldn't spot anything the next morning that would alert them there had been a security breach. I was now set up with an account, a password, and full privileges. A little before midnight I dialed in and followed the instructions Julia had carefully typed up "for the screenplay." In a blink I had access to one of the development systems that contained the master copy of the source code for the new version of the company's operating system software.

I uploaded a patch that Julia had written, which she said modified a routine in one of the operating system's libraries. That patch would, in effect, create a covert backdoor that would allow remote access into the system with a secret password.

NOTE The type of backdoor used here does not change the operating system login program itself Rather, a specific function contained within the dynamic library used by the login program is replaced to create the secret entry point. In typical attacks, computer intruders often replace or patch the login program itself, but sharp system administrators can detect the change by comparing it to the version shipped on media such as cd , or by other distribution methods.

I carefully followed the instructions she had written down for me, first installing the patch, then taking steps that removed the fix account and wiped clean all audit logs so there would be no trace of my activities, effectively erasing my tracks.

Soon the company would begin shipping the new operating system upgrade to their customers: Financial institutions all over the world. And every copy they sent out would include the backdoor I had placed into the master distribution before it was sent out, allowing me to access any computer system of every bank and brokerage house that installed the upgrade.

LINGO PATCH Traditionally a piece of code that , when placed in an executable program, fixes a problem.

Of course, I wasn't quite home free--there would still be work to do. I'd still have to gain access to the internal network of each financial institution I wanted to "visit." Then I'd have to find out which of their computers was used for money transfers, and install surveillance software to learn the details of their operations and exactly how to transfer funds.

All of that I could do long distance. From a computer located anywhere. Say, overlooking a sandy beach. Tahiti, here I come. I called the guard back, thanked him for his help, and told him he could go ahead and toss the printout.

Analyzing the Con The security guard had instructions about his duties, but even thorough, well- thought-out instructions can't anticipate every possible situation. Nobody had told him the harm that could be done by typing a few keystrokes on a computer for a person he thought was a company employee.

With the cooperation of the guard, it was relatively easy to gain access to a critical system that stored the distribution master, despite the fact that it was behind the locked door of a secure laboratory. The guard, of course, had keys to all locked doors.

Even a basically honest employee (or, in this case, the Ph.D. candidate and company intern, Julia) can sometimes be bribed or deceived into revealing information of crucial importance to a social engineering attack, such as where the target computer system is located and--the key to the success of this attack--- when they were going to build the new release of the software for distribution. That's important, since a change of this kind made too early has a higher chance of being detected or being nullified if the operating system is rebuilt from a clean source.

Did you catch the detail of having the guard take the printout back to the lobby desk and later destroying it? This was an important step. When the computer operators came to work the next workday, the attacker didn't want them to find this damning evidence on the hard-copy terminal, or notice it in the trash. Giving the guard a plausible excuse to take the printout with him avoided that risk.

MITNICK MESSAGE When the computer intruder cannot gain physical access to a computer system or network himself, he will try to manipulate another person to do it for him. In cases where physical access is necessary for the plan, using the victim as a proxy is even better than doing it himself, because the attacker assumes much less risk of detection and apprehension.

THE EMERGENCY PATCH You would think a tech support guy would understand the dangers of giving access to the computer network to an outsider. But when that outsider is a clever social engineer masquerading as a helpful software vendor, the results might not be what you expect. A Helpful Call The caller wanted to know Who's in charge of computers there? and the telephone operator put him through to the tech support guy, Paul Ahearn.

The caller identified himself as "Edward, with SeerWare, your database vendor. Apparently a bunch of our customers didn't get the email about our emergency update, so we're calling a few for a quality control check to see whether there was a problem installing the patch. Have you installed the update yet?"

Paul said he was pretty sure he hadn't seen anything like that.

Edward said, "Well, it could cause intermittent catastrophic loss of data, so we recommend you get it installed as soon as possible." Yes, that was something he certainly wanted to do, Paul said. "Okay," the caller responded. "We can send you a tape or CD with the patch, and I want to tell you, it's really critical--two companies already lost several days of data. So you really should get this installed as soon as it arrives, before it happens to your company."

"Can't I download it from your Web site?" Paul wanted to know.

"It should be available soon--the tech team has been putting out all these fires. If you want, we can have our customer support center install it for you, remotely. We can either dial up or use Telnet to connect to the system, if you can support that."

"We don't allow Telnet, especially from the Internet--it's not secure," Paul answered. "If you can use SSH, that'd be okay," he said, naming a product that provides secure file transfers. "Yeah. We have SSH. So what's the IP address?"

Paul gave him the IP address, and when Andrew asked, "and what username and password can I use," Paul gave him those, as well. Analyzing the Con Of course that phone call might really have come from the database manufacturer. But then the story wouldn't belong in this book.

The social engineer here influenced the victim by creating a sense of fear that critical data might be lost, and offered an immediate solution that would resolve the problem.

Also, when a social engineer targets someone who knows the value of the information, he needs to come up with very convincing and persuasive arguments for giving remote access. Sometimes he needs to add the element of urgency so the victim is distracted by the need to rush, and complies before he has had a chance to give much thought to the request.

THE NEW GIRL What kind of information in your company's files might an attacker want to gain access to? Sometimes it can be something you didn't think you needed to protect at all.

Sarah's Call "Human Resources, this is Sarah."

"Hi, Sarah. This is George, in the parking garage. You know the access card you use to get into the parking garage and elevators? Well, we had a problem and we need to reprogram the cards for all the new hires from the last fifteen days."

"So you need their names?"

"And their phone numbers."

"I can check our new hire list and call you back. What's your phone number?"

"I'm at 73 . . . Uh, I'm going on .break, how about if I call you back in a half- hour?"