Authors: Kevin D. Mitnick,William L. Simon
Tags: #Computer Hackers, #Computer Security, #Computers, #General, #Security
Detecting Authorized Changes in Applications Robert was able to replace the helpdesk.exe application by exploiting a misconfiguration with FrontPage authoring. After he accomplished his goal of obtaining the source code to the company's flagship product, he left his "hacked" version of the helpdesk application so he could return at a later date. An overworked system administrator may never realize that a hacker covertly modified an existing program, especially if no integrity checks are made. An alternative to manual checks is to license a program like Tripwire3 that automates the process of detecting unautho- rized changes.
Permissions Erik was able to obtain confidential database passwords by viewing files in the /includes directory. Without these initial passwords, he might have been hindered in accomplishing his mission. Having exposed sensitive Chapter 8 Your Intellectual Property Isn't Safe 189
database passwords in a world-readable source file was all he needed to get in. The best security practice is to avoid storing any plaintext pass- words in batch, source, or script files. An enterprise-wide policy should be adopted that prohibits storing plaintext passwords unless absolutely necessary. At the very least, files containing unencrypted passwords must be carefully protected to prevent accidental disclosure.
At the company that Robert was attacking, the Microsoft IIS4 server had not been configured properly to prevent anonymous or guest users from reading and writing files to the Web server directory. The external password file used in conjunction with Microsoft Visual SourceSafe was readable by any user logged in to the system. Because of these miscon- figurations, the attacker was able to gain full control of the target's Windows domain. Deploying systems with an organized directory struc- ture for applications and data will likely increase the effectiveness of access controls.
Passwords In addition to the other common password management suggestions described throughout this book, the success of the attackers in this chap- ter highlights some additional important points. Erik commented that he was able to predict how other company passwords would be constructed based on the passwords he had been able to crack. If your company is using some standardized, predictable method that employees are required to follow in constructing passwords, it should be clear that you're extending an open-door invitation to hackers.
Once an attacker obtains privileged access to a system, obtaining pass- words of other users or databases is a high priority. Such tactics as search- ing through email or the entire file system looking for plaintext passwords in email, scripts, batch files, source code includes, and spread- sheets is quite common.
Organizations that use the Windows operating system should consider configuring the operating system so that LAN Manager password hashes are not stored in the registry. If an attacker obtains administrative access rights, he can extract the password hashes and attempt to crack them. IT person- nel can easily configure the system so the old-style hashes are not stored, substantially increasing the difficulty of cracking the passwords. However, once an attacker "owns" your box, he or she can sniff network traffic, or install a third-party password add-on to obtain account passwords.
An alternative to turning off LAN Manager password hashes is to con- struct passwords with a character set not available on the keyboard by using the
not attempt to crack passwords using such characters from the Greek, Hebrew, Latin, and Arabic alphabets.
Third-Party Applications Using custom-built Web scanning tools, Erik discovered an unprotected log file generated by a commercial FTP product. The log contained the full path information for files that were transferred to and from the sys- tem. Don't rely on default configurations when installing third-party software. Implement the configuration least likely to leak valuable infor- mation, such as log data that can be used to further attack the network.
Protecting Shares Deploying network shares is a common method of sharing files and direc- tories in a corporate network. IT staff may decide not to assign passwords or access control to network shares because the shares are only accessible on the internal network. As mentioned throughout this book, numerous organizations focus their efforts on maintaining good perimeter security, but fall short when securing the internal side of the network. Like Robert, attackers who get into your network will search for shares with names that promise valuable, sensitive information. Descriptive names such as "research" or "backup" just make an attacker's job significantly easier. The best practice is to adequately protect all network shares that contain sensitive information.
Preventing DNS Guessing Robert used a DNS guesser program to identify possible hostnames within a publicly accessible zone file of the domain. You can prevent dis- closing internal hostnames by implementing what is known as a split- horizon DNS, which has both an external and an internal name server. Only publicly accessible hosts are referenced in the zone file of the exter- nal name server. The internal name server, much better protected from attack, is used to resolve internal DNS queries for the corporate network.
Protecting Microsoft SQL Servers Erik found a backup mail and Web server running Microsoft SQL Server on which the account name and password were the same as the one iden- tified in the source code "include" files. The SQL server should not have been exposed to the Internet without a legitimate business need. Even though the "SA" account was renamed, the attacker identified the new account name and password in an unprotected source code file. The best Chapter 8 Your Intellectual Property Isn't Safe 191
practice is to filter port 1433 (Microsoft SQL Server) unless it is absolutely required.
Protecting Sensitive Files The attacks in the main stories of this chapter succeeded in the end because the source code was stored on servers that were not adequately secured. In highly sensitive environments such as a company's R&D or development group, another layer of security could be provided through the deployment of encryption technologies.
Another method for a single developer (but probably not practical in a team environment, where a number of people require access to the source code of the product in development) would be to encrypt extremely sensitive data such as source code with products such as PGP Disk or PGP Corporate Disk. These products create virtual encrypted disks, yet function in a way that makes the process transparent to the user.
Protecting Backups As made clear in these stories, it's easy for employees -- even those who are especially conscientious about security matters -- to overlook the need to properly secure backup files, including email backup files, from being read by unauthorized personnel. During my own former hacking career, I found that many system administrators would leave compressed archives of sensitive directories unprotected. And while working in the IT department of a major hospital, I noted that the payroll database was routinely backed up and then left without any file protection -- so any knowledgeable staff member could access it.
Robert took advantage of another aspect of this common oversight when he found backups of the source code to the commercial mailing list application left in a publicly accessible directory on the Web server.
Protecting against MS SQL Injection Attacks Robert purposefully removed the input validation checks from the Web- based application, which were designed to prevent a SQL injection attack. The following basic steps may prevent your organization from being victimized using the same kind of attack Robert was able to use:
Never run a Microsoft SQL server under the system context.
Consider running the SQL server service under a different
account context. 192 The Art of Intrusion
When developing programs, write code that does not gener-
ate dynamic SQL queries.
Use stored procedures to execute SQL queries. Set up an
account that is used only to execute the stored procedures,
and set up the necessary permissions on the account just to
perform the needed tasks.
Using Microsoft VPN Services As a means of authentication, Microsoft VPN uses Windows Authentication, making it easier for an attacker to exploit poor passwords for gaining access to the VPN. It may be appropriate in certain environ- ments to require smart card authentication for VPN access -- another place where a stronger form of authentication other than a shared secret will raise the bar a few notches. Also, in some cases, it may be appropri- ate to control access to the VPN based on the client's IP address.
In Robert's attack, the system administrator should have been moni- toring the VPN server for any new users added to the VPN group. Other measures, also mentioned previously, include removing dormant accounts from the system, ensuring that a process is in place to remove or disable accounts of departing employees, and, where practical, restrict- ing VPN and dial-up access by day of the week and time of day.
Removing Installation Files Robert was able to obtain the mailing lists he was after not by exploiting the mailing list application itself but by taking advantage of vulnerability in the application's default installation script. Once an application has been successfully installed, installation scripts should be removed.
Renaming Administrator Accounts Anyone with an Internet connection can simply Google for "default password list" to find sites that list accounts and passwords in the default state as shipped by the manufacturer. Accordingly, it's a good idea to rename the guest and administrator accounts when possible. This has no value, however, when the account name and password are stored in the clear, as was the case with the company described in the Erik attack.4
Hardening Windows to Prevent Storing Certain Credentials The default configuration of Windows automatically caches password hashes and stores the plaintext passwords used for dial-up networking. Chapter 8 Your Intellectual Property Isn't Safe 193
After obtaining enough privileges, an attacker will attempt to extract as much information as possible, including any passwords that are stored in the registry or in other areas of the system.
A trusted insider can potentially compromise an entire domain by using a little social engineering when his workstation is caching passwords locally. Our disgruntled insider calls technical support, complaining that he cannot log in to his workstation. He wants a technician to come assist immediately. The technician shows up, logs in to the system using her credentials and fixes the "problem." Soon thereafter, the insider extracts the password hash of the technician and cracks it, giving the employee access to the same domain administrator rights as the technician. (These cached hashes are double-hashed, so it requires another program to unravel and crack these types of hashes.)
A number of programs, such as Internet Explorer and Outlook, cache passwords in the registry. To learn more about disabling this functional- ity, use Google to search for "disable password caching."
Defense in Depth The stories in this chapter demonstrate, even more vividly than others in the book, that guarding the electronic perimeter of your company's net- works is not enough. In today's environment, the perimeter is dissolving as businesses invite users into their network. As such, the firewall is not going to stop every attack. The hacker is going to look for the crack in the wall, by attempting to exploit a service that is permitted by the fire- wall rules. One mitigation strategy is to place any publicly accessible sys- tems on their own network segment and carefully filter traffic into more sensitive network segments.
For example, if a backend SQL server is on the corporate network, a secondary firewall can be set up that only permits connections to the port running the service. Setting up internal firewalls to protect sensitive information assets may be something of a nuisance but should be con- sidered an essential if you truly want to protect your data from malicious insiders and external intruders who manage to breach the perimeter.
THE BOTTOM LINE Determined intruders will stop at nothing to attain their goals. A patient intruder will case the target network, taking notice of all the accessible systems and the respective services that are publicly exposed. The hacker may lie in wait for weeks, months, or even years to find and exploit a new vulnerability that has not been addressed. During my former hacking career, I'd personally spend hours upon hours of time to compromise 194 The Art of Intrusion
systems. My persistence paid off, since I always managed to find that crack in the wall.
The hacker Erik put forth the same persistence and determination in his efforts to obtain the highly prized source code over a two-year period. And Robert, as well, undertook a complex, intricate series of steps both in his single-minded efforts to steal millions of email addresses to sell to spammers and in his effort, like Erik, to obtain source code that he had targeted.
You understand that these two hackers are by no means alone. Their degree of persistence is not uncommon in the hacker community. The people responsible for securing an organization's infrastructure must understand what they could be up against. A hacker has unlimited time to find just one hole, while overworked system and network administra- tors have very limited time to focus on the specific task of shoring up the organization's defenses.
As Sun Tzu wrote so eloquently in The Art of War (Oxford University Press, 1963): "Know thyself and know thy enemy; in a hundred battles you will never be in peril. When you are ignorant of the enemy, but know thyself, your chances of winning or losing is equal . . ." The message is clear: Your adversaries will spend whatever time it takes to get what they want. Accordingly, you should conduct a risk assessment to identify the likely threats against your organization, and these threats should be taken into account while you are developing a security strategy. Being well pre- pared, and exercising a "standard of due care" by drafting, implement- ing, and enforcing information security policies, will go a long way to keeping the attackers at bay.