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

But how to get the software source code? As it turned out, grabbing the crown jewels of the company's Secure Communications Group proved to be all too easy, even though the company was one of those that used two- factor authentication, an arrangement under which people are required to use not one but two separate identifiers to prove their identity.

Here's an example you're probably already familiar with. When your renewal credit card arrives, you're asked to phone the issuing company to let them know that the card is in possession of the intended customer, and not somebody who stole the envelope from the mail. The instructions with the card these days generally tell you to call from home. When you call, software at the credit card company analyzes the ANI, the automatic number identification, which is provided by the telephone switch on toll- free calls that the credit card company is paying for.

A computer at the credit card company uses the calling party's number provided by the ANI, and matches that number against the company's database of cardholders. By the time the clerk comes on the line, her or his display shows information from the database giving details about the customer. So the clerk already knows the call is coming from the home of a customer; that's one form of authentication. LINGO TWO-FACTOR AUTHENTICATION The use of two different types of authentication to verify identity. For example, a person might have to identify himself by calling from a certain identifiable location and knowing a password.

The clerk then picks an item from the information displayed about you - most often social security number, date of birth, or mother's maiden name - and asks you for this piece of information. If you give the right answer, that's a second form of authentication - based on information you should know.

At the company manufacturing the secure radio systems in our story, every employee with computer access had their usual account name and password, but in addition was provided with a small electronic device called Secure ID. This is what's called a time-based token. These devices come in two types: One is about half the size of a credit card but a little thicker; another is small enough that people simply attach it to their key chains.

Derived from the world of cryptography, this particular gadget has a small window that displays a series of six digits. Every sixty seconds, the display changes to show a different six-digit number. When an authorized person needs to access the network from offsite, she must first identify herself as an authorized user by typing in her secret PIN and the digits displayed on her token device. Once verified by the internal system, she then authenticates with her account name and password.

For the young hacker Danny to get at the source code he so coveted, he would have to not only compromise some employee's account name and password (not much of a challenge for the experienced social engineer) but also get around the time-based token.

Defeating the two-factor authentication of a time-based token combined with a user's secret PIN code sounds like a challenge right out of Mission Impossible. But for social engineers, the challenge is similar to that aced by a poker player who has more than the usual skill at reading his opponents. With a little luck, when he sits down at a table he knows he's likely to walk away with a large pile of other people's money.

Storming the Fortress Danny began by doing his homework. Before long he had managed to put together enough pieces to masquerade as a real employee. He had an employee's name, department, phone number, and employee number, as well as the manager's name and phone number. Now was the calm before the storm. Literally. Going by the plan he had worked out, Danny needed one more thing before he could take the next step, and it was something he had no control over: He needed a snow-storm. Danny needed a little help from Mother Nature in the form of weather so bad that it would keep workers from getting into the office. In the winter in South Dakota, where the manufacturing plant in question was located, anyone hoping for bad weather did not have very long to wait. On Friday night, a storm arrived. What had begun as snow quickly turned to freezing rain so that, by morning, the roads were coated with a slick, dangerous sheet of ice. For Danny, this was a perfect opportunity.

He telephoned the plant, asked for-the computer room and reached one of the worker bees of IT, a computer operator who announced himself as Roger Kowalski.

Giving the name of the real employee he had obtained, Danny said, "This is Bob Billings. I work in the Secure Communications Group. I'm at home right now and I can't drive in because of the storm. And the problem is that I need to access my workstation and the server from home, and I left my Secure ID in my desk. Can you go fetch it for me? Or can somebody? And then read off my code when I need to get in? Because my team has a critical deadline and there's no way I can get my work done. And there's no way I can get to the office--the roads are much too dangerous up my way.

The computer operator said, "I can't leave the Computer Center." Danny jumped right in: "Do you have a Secure ID yourself?."

"There's one here in the Computer Center," he said. "We keep one for the operators in case of an emergency."

"Listen," Danny said. "Can you do me a big favor? When I need to dial into the network, can you let me borrow your Secure ID? Just until it's safe to drive in." "Who are you again?" Kowalski asked. "Who do you work for. "For Ed Trenton." "Oh, yeah, I know him."

When he's liable to be faced with tough sledding, a good social engineer does more than the usual amount of research. "I'm on the second floor," Danny went on. "Next to Roy Tucker."

He knew that name, as well. Danny went back to work on him. "It'd be much easier just to go to my desk and fetch my Secure ID for me." Danny was pretty certain the guy would not buy into this. First of all, he would not want to leave in the middle of his shift to go traipsing down corridors and up staircases to some distant part of the building. He would also not want to have to paw through someone else's desk, violating somebody's personal space. No, it was a safe bet he wouldn't want to do that.

Kowalski didn't want to say no to a guy who needed some help, but he didn't want to say yes and get in trouble, either. So he sidestepped the decision: I'll have to ask my boss. Hang on." He put the phone down, and Danny could hear him pick up another phone, put in the call, and explain the request. Kowalski then did something unexplainable: He actually vouched for the man using the name Bob Billings. "I know him," he told his manager. "He works for Ed Trenton. Can we let him use the Secure ID in the Computer Center' Danny, holding on to the phone, was amazed to overhear this extraordinary and unexpected support for his cause. He couldn't believe his ears or his luck. After another couple of moments, Kowalski came back on the line and said, "My manager wants to talk to you himself," and gave him the man's name and cell phone number.

Danny called the manager and went through the whole story one more time, adding details about the project he was working or and why his product team needed to meet a critical deadline. "It'd be easier if someone just goes and fetches my card," he said. "I don't think the desk is locked, it should be there in my upper left drawer."

"Well," said the manager, "just for the weekend, I think we can let you use the one in the Computer Center. I'll tell the guys on duty that when you call, they should read off the random-access code for you," and he gave him the PIN number to use with it.

For the whole weekend, every time Danny wanted to get into the corporate computer system, he only had to call the Computer Center and ask them to read off the six digits displayed on the Secure ID token.

An Inside Job Once he was inside the company's computer system, then what? How would Danny find his way to the server with the software he wanted? He had already prepared for this.

Many computer users are familiar with newsgroups, that extensive set of electronic bulletin boards where people can post questions that other people answer, or find virtual companions who share an interest in music, computers, or any of hundreds of other topics. What few people realize when they post any message on a newsgroup site is that their message remains on line and available for years. Google, for example, now maintains an archive of seven hundred million messages, some dating back twenty years! Danny started by going to the Web address http://groups.google.com.

As search terms, Danny entered "encryption radio communications" and the name of the company, and found a years-old message on the subject from an employee. It was a posting that had been made back when the company was first developing the product, probably long before police departments and federal agencies had considered scrambling radio signals. The message contained the sender's signature, giving not just the man's name, Scott Press, but his phone number and even the name of his workgroup, the Secure Communications Group.

Danny picked up the phone and dialed the number. It seemed like a long shot-- would he still be working in the same organization years later? Would he be at work on such a stormy weekend? The phone rang once, twice, three times, and then a voice came on the line. "This is Scott," he said.

Claiming to be from the company's IT Department, Danny manipulated Press (in one of the ways now familiar to you from earlier chapters) into revealing the names of the servers he used for development work. These were the servers that could be expected to hold the source code containing the proprietary encryption algorithm and firmware used in the company's secure radio products.

Danny was moving closer and closer, and his excitement was building. He was anticipating the rush, the great high he always felt when he succeeded at something he knew only a very limited number of people could accomplish.

Still, he wasn't home free yet. For the rest of the weekend he'd be able to get into the company's network whenever he wanted to, thanks to that cooperative computer center manager. And he knew which servers he wanted to access. But when he dialed in, the terminal server he logged on to would not permit him to connect to the Secure Communications Group development systems. There must have been an internal firewall or router protecting the computer systems of that group. He'd have to find some other way in.

The next step took nerve: Danny called back to Kowalski in Computer Operations and complained "My server won't let me connect," and told the IT guy, "I need you to set me up with an account on one of the computers in your department so I can use Telnet to connect to my system." The manager had already approved disclosing the access code displayed on the time-based token, so this new request didn't seem unreasonable. Kowalski set up a temporary account and password on one of the Operation Center's computers, and told Danny to "call me back when you don't need it any more and I'll remove it."

Once logged into the temporary account, Danny was able to connect over the network to the Secure Communications Group's computer systems. After an hour of on-line searching for a technical vulnerability that would give him access to a main development server, he hit the jackpot. Apparently the system or network administrator wasn't vigilant in keeping up with the latest news on security bugs in the operating system that allowed remote access. But Danny was.

Within a short time he had located the source code files that he was after and was transferring them remotely to an e-commerce site that offered free storage space. On this site, even if the files were ever discovered, they would never be traced back to him.

He had one final step before signing off: the methodical process of erasing his tracks. He finished before the Jay Leno show had gone off the air for the night. Danny figured this had been one very good weekend's work. And he had never had to put himself personally at risk. It was an intoxicating thrill, even better than snowboarding or skydiving.

Danny got drunk that night, not on scotch, gin, beer, or sake, but on his sense of power and accomplishment as he poured through the files he had stolen, closing in on the elusive, extremely secret radio software.

Analyzing the Con As in the previous story, this ruse only worked because one company employee was all too willing to accept at face value that a caller was really the employee he claimed to be. That eagerness to help out a co worker with a problem is, on the one hand, part of what greases the wheels of industry, and part of what makes the employees of some companies more pleasant to work with than employees of others. But on the other hand, this helpfulness can be a major vulnerability that a social engineer will attempt to exploit.

One bit of manipulation Danny used was delicious: When he made the request that someone get his Secure ID from his desk, he kept saying he wanted somebody to "fetch" it for him. Fetch is a command you give your dog. Nobody wants to be told to fetch something. With that one word, Danny made it all the more certain the request would be refused and some other solution accepted instead, which was exactly what he wanted. The Computer Center operator, "Kowalski, was taken in by Danny dropping the names of people Kowalski happened to know. But why would Kowalski's manager - an IT manager, no less - allow some stranger access to the company's internal network? Simply because the call for help can be a powerful, persuasive tool in the social engineer's arsenal.

MITNICK MESSAGE This story goes to show that time-based tokens and similar forms of authentication are not a defense against the wily social engineer. The only defense is a conscientious employee who follows security policies and understands how others can maliciously influence his behavior.

Could something like that ever happen in your company? Has it already?

PREVENTING THE CON It seems to be an often-repeated element in these stories that an attacker arranges to dial in to a computer network from outside the company, without the person who helps him taking sufficient measures to verify that the caller is really an employee and entitled to the access. Why do I return to this theme so often? Because it truly is a factor in so many social engineering attacks. For the social engineer, it's the easiest way to reach his goal. Why should an attacker spend hours trying to break in, when he can do it instead with a simple phone call?