Buffer OverflowsDuring 1996, a series of articles about buffer overflows and the havoc they can create was published, changing application security forever. One such article authored by Aleph One, "Smashing the Stack for Fun and Profit," detailed the profound effects of buffer overflows on poor programming practices.
In essence, buffer overflows occur when an attacker or other malicious user stuffs more data into a buffer than is allocated. For the technically inclined, this type of overflow input is generally associated with C programming language functions similar to strcpy (), strcat (), and sprintf (). These are merely examples as there are many other types of exploitable functions. Buffer overflows cause a segmentation violation to occur. This type of input can be exploited to gain access to the target system. Buffer overflows are not limited to remote attacks, they can also occur from within the local network.
In this example, the UNIX-based application, Sendmail, will be used. Suppose there is a fixed-length buffer of 255 bytes. This buffer defines the amount of data that can be stored as input to the VRFY command. In this example, the Sendmail application will be running at Root. What is the result if an attacker connects to the Sendmail application and sends a block of data consisting of 10,000 "V" s to the VRFY command rather than the expected user name? The system will crash, essentially causing a denial-of-service attack, as the VRFY buffer is overrun because it is only designed to expect an input of not more than 255 bytes of user input. If the attacker inputs a specific code that overflows the buffer and executes the command /bin/sh, the attacker could reach root access.
When the attack is executed by the system, a special assembly code known as egg is sent to the VRFY command as part of the string used to overflow the buffer. On being overrun, the attacker can set the return address of the offending function allowing the alteration of the program flow. Instead of the function returning to its proper memory location, the attacker executes the code that was sent included as part of the buffer overflow data that will run with root privileges.
It is important to note that buffer overflow codes are specific to systems' architecture and operating systems. For example, a buffer overflow targeting a BSD UNIX, based on an Intel processor will not be effective on a Solaris operating system running on a SPARC processor. From this brief explanation, auditors can see that buffer overflows are extremely dangerous and are the bane of most system administrators. For the most part, attackers must be fairly talented to create a workable egg; however, most system-dependent eggs have been discovered and programmed, and are available from attacker Web sites on the Internet.
Many common system vulnerability lists have a description of the exploit, the systems on which it is effective, and the CVE (Common Vulnerability and Exposure) number.
In the Domain Name Server, DNS, known as BIND, Berkley Internet Domain, there are security vulnerabilities in older versions prior to 8.2.2 with patch 5. Good reason for auditors to look at the application update and change policy of the organization, right? Older and unpatched BIND versions can be corrupted by attackers that allow them to redirect Internet traffic to sites not of the owner's choosing. Poorly configured BIND can allow attackers to download all the names, operating systems, and IP addresses of the organization's internal network. With this knowledge, attackers can search for specific tools targeting machines in your network to gain unauthorized access to your systems.
CGI ScriptingCommon Gateway Interface (CGI) is the means by which Web page developers collect and display your input to a Web-based form. CGI scripts are frequently written in PERL (Practical Extraction and Report Language) and uploaded to the CGI-BIN directory located on the Web server. In some cases, developers and vendors have distributed these scripts with vulnerabilities already in them.
CGI scripts can be written in almost any standard input programming language, but PERL is the most common. It is important to note that for each executed CGI script there is a new process started that will be terminated when the CGI has finished. Usually data is sent to the server to be executed or manipulated, and is returned to the user in the form of HTML or images.
By way of review, CGI processing generally follows this way: The user accesses a Web page that requests user-input. After making the input, the user clicks the Send button and sends the data to the Web server for processing. The server forwards the data to the CGI application, sometimes called the CGI script, as these are small programs, where the user-input is processed. After processing the data, it is returned to the server and the server returns the data to the user. It can be seen the potential for vulnerabilities exist with the user-input data. CGI is used to perform functions that normal Web pages cannot. For example, CGIs manage databases of user accounts, calculations, form-input data processing, etc. There are easily available CGI scripts available as part of Web servers, downloaded from CGI Web sites, or developers may write their own.
Before placing a Web server into a production environment, developers should make certain the CGI code has been thoroughly reviewed by quality control managers and auditors for programming errors. It is imperative that CGI scripts are tested thoroughly and retested before being allowed into a production environment. It is equally important that CGI scripts have delimited input in that only expected input and input length are permitted, denying all other types of input.
Attackers have discovered they can corrupt these scripts and cause them to do things they were not intended to do. For example, it is possible for attackers to access collected credit card numbers by corrupting the CGI scripts. It is also possible for attackers to gain root access to the Web server and deface your E-commerce site. If you do not have any production need for CGI scripts, remove them from your system.
In keeping with policy and procedures, auditors should note that all unnecessary services should be disabled or removed thereby reducing the number of vulnerabilities. Also, ensure the Web server software is updated and documented regularly. This will go a long way to minimizing unauthorized intrusions.
Remote Procedure CallsRPC allows a computer to launch and run a program on another computer. Many client-server architectures depend on this functionality. Those systems that are most frequently affected by RPC vulnerabilities are those based on the UNIX platform, such as Linux, Solaris, AIX, HP-UX, and IRIX. It is important to remember from an auditing perspective that RPC vulnerabilities can be exploited by buffer overflows resulting in the attacker being granted root privileges. The best means to deal with RPC vulnerabilities is to update the operating system's security patches. And, if RPC functionality is not necessary for system functionality, disable or remove it.
Default installations of operating systems and applications frequently use installation scripts to facilitate the installation of the software. In many cases, most of the program's functions are enabled with the least amount of interaction from the installer. Installation scripts usually install more features than the majority of users need. Although this installation action is convenient for users, it deposits potentially dangerous vulnerabilities. They become more serious, as administrators and managers do not actively update software components. For example, it is common for some operating systems and applications to install default passwords for many of their features. If these features or default passwords are not disabled or removed, they provide an easily accessible entry-point for the attacker. In addition, many users do not realize the default features that have been installed. Left unattended, these services provide ready access to attackers both inside and outside the organization. Likewise, it is important that all software is updated on a regular basis, allowing for patches and newer versions to address current vulnerabilities. Change control, management, and documentation is not just a drill. It is a matter of system survivability.
Software installers must have standard installation procedures mandating the removal or disabling of unnecessary features and updating software. It is important these installation procedures are written and disseminated to all employees authorized to install software and hardware. Auditors must review the software installation process, making certain all unnecessary features, passwords, and services are removed or disabled, and that all software is regularly updated and those updates are appropriately documented.
Weak, default, or missing passwords is another common systems failing. Most of today's systems are configured to use passwords as the first, and many times, the only line of access restriction. User identification is relatively easy to acquire, and regrettably many business have unauthorized dial-up access that bypass firewall protections.
A more glaring problem is the account that does not have any password protection. As a matter of business sense, all weak passwords, accounts without passwords, and default passwords must be removed from the system or disabled. System attackers usually look for applications and accounts with easy password access. They have downloaded utilities that attack password accounts and are successful more often than not when poor password policies and procedures exist. Auditors should carefully review the company's password and software installation policies and procedures. Testing passwords is easily accomplished by using commercial software solutions available from vendors such as www.accessdata.com.
It is not a matter of if a critical incident will happen; it is only a matter of when. Count on it, it will happen, and it will happen at the worst possible moment. It is Murphy's Law! Recovery from critical incidents requires accurate, reliable, easily accessible backups and tested methods of restoring data. It is a common mistake for organizations to make frequent backups of their data, but never take the time to verify that the backed-up data is viable or that their recovery and business restoration procedures will actually work under the worst possible conditions.
One of the secondary faults of backed-up data is that of physical security and accessibility. More than one security administrator has lost sleep after discovering an attacker has entered the company's system and destroyed sensitive information. Because the backed-up data was stored on a server within the system, the attacker destroyed those files also.
