2.2. Social and Physical Vulnerabilities

One fascinating field of vulnerabilities has almost nothing to do with code: the land of shoulder surfers, piggybackers, and social engineers. Some of the most famous system attackers use entirely noncode vulnerabilities to get to their targets. Kevin Mitnick's book The Art of Deception details dozens of cases where individuals use nontechnical schemes to get access to confidential information. You can build a site that limits such attacks, but you'll probably never be able to fully protect against a social engineering attack by a talented and dedicated attacker. One example from my own life shows how our best intentions for security can go wrong.

2.2.1. The Vendor Password Please?

A client needed a way for vendors to perform maintenance on the website. The client uses a secure virtual private network system to provide access from outside the firewall into the servers that run the website. Company policy is to change passwords every month so that an attacker who learns the password would be able to use it for only one month. Every month when the password changes, each vendor simply calls the IT support desk and requests the new password. Initially to get the password a caller was required to identify himself by name, confirm the vendor he worked for, confirm the project, and confirm the name of the internal employee who is the project sponsor.

This process has been going on for years, and more vendors are using the process. The IT support team has gotten much smarter about how it handles these requests. They now use the same password for all of the vendor accounts. When a vendor calls and says, "I need the new vendor admin password," the IT support person reads the common password off the little sticky note attached to the wall. The vendor can then use this common password with his username to gain access to the servers. An enterprising social engineer with some time on his hands could combine this weakness with a little information gathering about other vendors to take control of many of the servers and steal information or simply use them as relay points for other attacks.

This example plays on the innate human desire to help another person. The IT support person wants to help the vendors to get their job done. This is an important tool in the attacker's toolbox, but only one of them. Social engineers often flip the example around and will offer to help out end users in order to gain their trust and abuse them.

2.2.2. This Is IT; Can I Help?

In large corporations, emails and phone numbers follow predictable patterns. Phone numbers are often split apart sequentially based on office and cube number or for different departments. If social engineers get the direct line for the front desk and find another couple of phone numbers for individuals posted online, they can then get a sense of the numbering scheme for all numbers and start dialing.

With this information, an attacker can call pretending to be the IT department: "Hi, this is Charlie in IT. Has anyone helped you yet with that ticket you submitted a little while ago?" It would only take a few hours (or minutes, depending on the company) of probing different numbers until the attacker could find someone who did indeed submit an issue and needed help. The attacker can then begin building trust with the user by asking basic questions and probing for more information about the company. Once the attacker has built some rapport, she could direct the user to an "internal diagnostic utilities" website, which the attacker has built to appear legitimate by using the company's logo and colors. Of course, this utility is not a real troubleshooting utility but another weapon in the attacker's arsenal that the end user is being instructed to install. If the user lacks the permission to install the file, the attacker could probe for the user's password: "Yeah, that's a permissions issue, I'll have to upgrade your account temporarily. What's your username and password?" Both anecdotally and according to several studies, users are often perfectly willing to give out their password to someone pretending to be an IT support technician.

With a little persistence, the attacker can gain control of several user accounts and, hopefully, get some spying tools installed on several desktops. From that point, it's just a matter of a little additional creativity and motivation to be able to steal money or information—or both—from the company. And the attacker can do this with little more than an offer to help employees who are waiting for help from the support department.

However, code exploits are the kind you hear about most often in the news, probably for two reasons:

• They can occur on a massive scale, which makes the story more interesting for a large number of users. Social engineering attacks are more likely to impact a single company or single individual, and that company would be embarrassed about sharing the news of the attack.

• Weaknesses in code are easy to protect against by applying patches, whereas changing security habits to protect against social engineering is a difficult process.

For a much more thorough review of social engineering attacks, I do recommend The Art of Deception. In addition to providing valuable examples of security procedures for any company, it is also highly entertaining.

2.2.3. Let's Get Physical

Physical access to a typical server is virtually the same as giving someone the administrator password. Once someone has physical access, the person can install a network monitor to sniff and steal all the passwords (at least all the unencrypted passwords). If server downtime isn't a concern, the intruder can also reboot the machine and, in most cases, use special commands that can only be input directly on the physical machine in order to get the administrator password and from there get access to all data and accounts on the machine.

Fortunately, most servers are well protected inside data centers with security monitoring at the doors, video cameras, and fancy key-card systems. But what about your backups? What about the copy of the site that you gave to a consulting firm so the consultants can work on the new version of the site in their environment? The lesson here is that you must protect your data virtually (with code and configuration) and physically and, further, that you must do so not only on your server but every time you make a copy of the data. For your routine backups a good solution is to encrypt the database file prior to moving it to the backup medium. But what should you do if you need to share a copy of the database with someone who needs to work on it, but you want to protect the privacy of your users?

2.2.4. Sanitizing a Typical Drupal Database

One possibility is to sanitize the database in a way that retains all meaningful data but retains the right amounts of data in typical fields so that the database is still useful for performance testing. The main strategy is to insert meaningless data on top of private fields and erase some tables that can be easily regenerated and that contain sensitive messages, as shown here:

UPDATE users SET mail = CONCAT(name, '@localhost'), init =
  CONCAT(name, '@localhost'),
UPDATE comments SET mail = CONCAT(name, '@localhost'), hostname =
  '127.0.0.1';
TRUNCATE accesslog;
TRUNCATE cache;
TRUNCATE cache_filter;
TRUNCATE cache_menu;
TRUNCATE cache_page;
TRUNCATE sessions;
TRUNCATE watchdog;

Depending on which contributed modules you have installed, you may need to clear out information from some other tables as well. A useful technique to find those columns is to create an export of your database and then use a text-search utility like grep to search for email addresses from common providers:

grep "@yahoo.com" my_database_backup.sql

This command will find tables and columns in the database that will need to be sanitized using one of these techniques prior to distributing the database.