Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Mitnick K.D., Simon V.L. - The Art of Deception (2003)(en)

.pdf
Скачиваний:
45
Добавлен:
28.10.2013
Размер:
5.45 Mб
Скачать

Getting Inside

Okay, so I had by now talked to three or four different people in only a few hours and was already one giant step closer to getting inside the company's computers. But I'd need a couple more pieces before I was home.

Number one was the phone number for dialing into the Engineering server from outside. I called GeminiMed again and asked the switchboard operator for the IT Department, and asked the guy who answered for somebody who could give me some computer help. He transferred me, and I put on an act of being confused and kind of stupid about anything technical. "I'm at home, just bought a new laptop, and I need to set it up o I can dial in from outside."

The procedure was obvious but I patiently let him talk me through it until he got to the dial-in phone number. He gave me the number like it was just another routine piece of information. Then I made him wait while I tried it. Perfect.

So now I had passed the hurdle of connecting to the network. I dialed in and found they were set up with a terminal server that would let a caller connect to any computer on their internal network. After a bunch of tries I stumbled across somebody's computer that had a guest account with no password required. Some operating systems, when first installed, direct the user to set up an ID and password, but also provide a guest account. The user is supposed to set his or her own password for the guest account or disable it, but most people don't know about this, or just don't bother. This system was probably just set up and the owner hadn't bothered to disable the guest account.

LINGO

PASSWOPRD HASH: A string of gibberish that results from processing a password through a one way encryption process. The process is supposedly irreversible; that is, its believed that it is not possible to reconstruct the password from the hash

Thanks to the guest account, I now had access to one computer, which turned out to be running an older version of the UNIX operating system. Under UNIX, the operating system maintains a password file which conrains the encrypted passwords of everybody authorized to access that computer. The password file contains the one-way hash (that is, a form of encryption that is irreversible) of every user's password. With a one-way

hash an actual password such as, say, "justdoit" would be represented by a hash in encrypted form; in this case the hash would be converted by UNIX to thirteen alphanumeric characters.

When Billy Bob down the hall wants to transfer some files to a computer, he's required to identify himself by providing a username and password. The system program that" checks his authorization encrypts the password he enters, and then compares the result to the encrypted password (the hash) contained in the password file; if the two match, he's given access.

Because the passwords in the file were encrypted, the file itself was made available to any user on the theory that there's no known way to decrypt the passwords. That's a laugh - I downloaded the file, ran a dictionary attack on it (see Chapter 12 for more about this method) and found that one of the engineers on the development team, a guy named Steven Cramer, currently had an account on the computer with the password "Janice." Just on the chance, I tried entering his account with that password on one of the development servers; if it had worked, it would have saved me some time and a little risk. It didn't.

That meant I'd have to trick the guy into telling me his username and password. For that, I'd wait until the weekend. 70 You already know the rest. On Saturday I called Cramer and walked him through a ruse about a worm and the servers having to be restored from backup to overcome his suspicions.

What about the story I told him, the one about listing a password when he filled out his employee papers? I was counting on him not remembering that had never happened. A new employee fills out so many forms that, years later, who would remember? And anyway, if I had struck out with him, I still had that long list of other names.

With his username and password, I got into the server, fished around for a little while, and then located the design files for the STH-100. I wasn't exactly sure which ones were key, so I just transferred all the files to a dead drop, a free FTP site in China, where they could be stored without anybody getting suspicious. Let the client sort through the junk and find what he wants.

LINGO

DEAD DROP A place for leaving information where it is unlikely to be found by others. In the world of traditional spies, this might be behind a loose stone in a wall; in the world of the computer hacker, it's commonly an Internet site in a remote country.

Analyzing the Con

For the man we're calling Craig Cogburne, or anyone like him equally skilled in the larcenous-but-not-always-illegal arts of social engineering, the challenge presented here was almost routine. His goal was to locate and download files stored on a secure corporate computer, protected by a firewall and all the usual security technologies.

Most of his work was as easy as catching rainwater in a barrel. He began by posing as somebody from the mail room and furnished an added sense of urgency by claiming there was a FedEx package waiting to be delivered. This deception produced the name of the team leader for the heart-stent engineering group, who was on vacation, but - convenient for any social engineer trying to steal information - he had helpfully left the name and phone number of his assistant. Calling her, Craig defused any suspicions by claiming that he was responding to a request from the team leader. With the team leader out of town, Michelle had no way to verify his claim. She accepted it as the truth and had no problem providing a list of people in the group - for Craig, a necessary and highly prized set of information.

She didn't even get suspicious when Craig wanted the list sent by fax instead of by email, ordinarily more convenient on both ends. Why was she so gullible? Like many employees, she didn't want her boss to return to town and find she had stonewalled a caller who was just trying to do something the boss had asked him for. Besides, the caller said that the boss had not just authorized the request, but asked for his assistance. Once again, here's an example of someone displaying the strong desire to be a team player, which makes most people susceptible to deception.

Craig avoided the risk of physically entering the building simply by having the fax sent to the receptionist, knowing she was likely to be helpful. Receptionists are, after all, usually chosen for their charming personalities and their ability to make a good impression. Doing small favors like receiving a fax and sending it on comes with the receptionist's territory, a fact that Craig was able to take advantage of. What she was ending out happened to be information that might have raised alarm bells with anyone knowing the value of the information - but how could receptionist be expected to know which information is benign and which sensitive?

Using a different style of manipulation, Craig acted confused and naive

to convince the guy in computer operations to provide him with the dial up access number to the company's terminal server, the hardware used as a connection point to other computer systems within the internal network.

MITNICK MESSAGE

Everybody's first priority at work is to get the job done. Under that pressure, security practices often take second place and are overlooked or ignored. Social engineers rely on this when practicing their craft.

Craig was able to connect easily by trying a default password that had never been changed, one of the glaring, wide-open gaps that exist throughout many internal networks that rely on firewall security. In fact, the default passwords for many operating systems, routers, and other types

of products, including PBXs, are made available on line. Any social engineer, hacker, or industrial spy, as well as the just plain curious, can find the list at http://www.phenoelit.de/dpl/dpl.html. (It's absolutely incredible

how easy the Internet makes life for those who know where to look. And now you know, too.)

Cogburne then actually managed to convince a cautious, suspicious man ("What did you say your last name was? Who's your supervisor?") to

divulge his username and password so that he could access servers used by

the heart-stent development team. This was like leaving Craig with an open door to browse the company's most closely guarded secrets and download the plans for the new product.

What if Steve Cramer had continued to be suspicious about Craig's call? It was unlikely he would do anything about reporting his suspicions until he showed up at work on Monday morning, which would have been too late to prevent the attack.

One key to the last part of the ruse: Craig at first made himself sound lackadaisical and uninterested in Steve's concerns, then changed his tune and sounded as if he was trying to help so Steve could get his work done. Most of the time, if the victim believes you're trying to help him or do him

some kind of favor, he will part with confidential information that he would have otherwise protected carefully.

PREVENTING THE CON

One of the most powerful tricks of the social engineer involves turning the tables. That's what you've seen in this chapter. The social engineer creates the problem, and then magically solves the problem, deceiving the victim into providing access to the company's most guarded secrets. Would your employees fall for this type of ruse? Have you bothered to draft and distribute specific security rules that could help to prevent it?

Educate, Educate, and Educate...

There's an old story about a visitor to New York who stops a man on the street and asks, "How do I get to Carnegie Hall?" The man answers, "Practice, practice, practice." Everyone is so vulnerable to social engineering attacks that a company's only effective defense is to educate and train your people, giving them the practice they need to spot a social engineer. And then keep reminding people on a consistent basis of what they learned in the training, but are all too apt to forget.

Everyone in the organization must be trained to exercise an appropriate degree of suspicion and caution when contacted by someone he or she doesn't personally know, especially when that someone is asking for any sort of access to a computer or network. It's human nature to want to trust others, but as the Japanese say, business is war. Your business cannot afford to let down its guard. Corporate security policy must clearly define appropriate and inappropriate behavior.

Security is not one-size-fits-all. Business personnel usually have disparate roles and responsibilities and each position has associated vulnerabilities. There should be a base level of training that everyone in the company is required to complete, and then people must also be trained according to their job profile to adhere to certain procedures that will reduce the chance that they will become part of the problem. People who work with sensitive information or are placed in positions of trust should be given additional specialized training.

Keeping Sensitive Information Safe

When people are approached by a stranger offering to help, as seen in the stories in this chapter, they have to fall back on corporate security policy that is tailored as appropriate to the business needs, size, and culture of your company.

NOTE

Personally, I don’t believe any business should allow any exchange of passwords. Its much easier to establish a hard rule that forbids personnel from ever sharing or exchanging confidential passwords. Its safer, too. But each business has to assess its own culture and security concerns in making this choice

Never cooperate with a stranger who asks you to look up information,

enter unfamiliar commands into a computer, make changes to software settings or - the most potentially disastrous of all - open an email attachment

or download unchecked software. Any software program - even one that appears to do nothing at all - may not be as innocent as it appears to be.

There are certain procedures that, no matter how good our training, we tend to grow careless about over time. Then we forget about that training at crunch time, just when we need it. You would think that not giving out your account name and password is something that just about everybody knows (or should know) and hardly needs to be told: it's simple common sense. But in fact, every employee needs to be reminded frequently that giving out the account name and password to their office computer, their home computer, or even the postage machine in the mail room is equivalent to giving out the PIN number for their ATM card.

There is occasionally - very occasionally - a quite valid circumstance when it's necessary, perhaps even important, to give someone else confidential information. For that reason, it's not appropriate to make an absolute rule about "never." Still, your security policies and procedures do need to be very specific about circumstances under which an employee may give out his or her password and - most importantly--who is authorized to ask for the information.

Consider the Source

In most organizations, the rule should be that any information that can possibly cause harm to the company or to a. fellow employee may be given only to someone who is known on a face-to-face basis, or whose voice is so familiar that you recognize it without question.

In high-security situations, the only requests that should be granted are ones delivered in person or with a strong form of authentication--for example, two separate items such as a shared secret and a time-based token.

Data classification procedures must designate that no information be provided from a part of the organization involved with sensitive work to anyone not personally known or vouched for in some manner.

NOTE

Incredibly, even looking up the name and phone number of the caller in the company's employee database and calling him back is not an absolute guarantee social engineers know ways of planting names in a corporate database or redirecting telephone calls.