Team 8 Paper

From CyberSecurity
Revision as of 05:37, 25 October 2005 by Leonarde (talk | contribs) (→‎Attempt and findings)

Jump to: navigation, search

I will edit the text and integrate it on this page. At 11:30, I will take the text we have here, PDFify it, and e-mail it, along with the source code, to the TAs.

Introduction

The integrated nature of computers made possible through the connectedness of the Internet has put friend and foe closer together. Terrorist and criminal organizations have turned to exploiting the Internet for its potential to disrupt society and for financial gain. Homeland security and cyber security become intertwined when these international organizations target our country’s computer infrastructure. The Group 8 Red Team has conducted a hacking experiment to first understand the vulnerabilities of a single computer and then to shed light on the vulnerabilities of our nation’s computers within the home, its corporations and financial institutions.

Attack techniques

Attempt and findings

In order to discover what potentially exploitable network processes were running on CSE291B, the Red Team ran nmap utility to conduct a comprehensive network port scan. Because firewalls generally close vulnerable ports that aren’t needed by resources outside of an internal network, the team decided to download and run nmap from a machine within the firewall – CSEP291A. Hackers often gain access to a vulnerable, low-value machine in order to exploit a more valuable target that might otherwise be protected by a firewall. Nmap was able to help discover that OpenSSH v3.9, rpcbind, status, and nlockmgr were listening on the ports 22, 111, 1024 and 1025 respectively. No known buffer overruns were found for that version of OpenSSH (although previous versions have had many published exploits).

There is a known vulnerability within rpcbind that allows a denial of service to be waged by flooding it with request messages. The way this attack could be used to exploit the machine was not clear and so the attack was not considered. No other vulnerabilities within the network processes were found. The Red Team investigated the possibility of mounting a password cracking attack. If the hash of the root password could be obtained and if the password was not sufficiently strong, it could be possible with enough computing time to run a dictionary attack or other brute force method to derive the password. But as a standard security precaution, the administrator of the CSEP291B machine had placed the password hashes in a separate shadow file rather than in /etc/passwd with the other account information. This shadow file was readable only by the root user.

On the other hand, the Red Team was aware that most (if not all) the user accounts on the machine were setup by the administrator with the same password as the account name. This meant that the team could have gained access to the other users’ sensitive data. Also, malicious applications or scripts could have been put in place of other custom applications that a privileged user would execute.

The eventual hacking into the target server CSE291B was performed through a buffer overrun attack on an executable file (/tmp/target1) that the team discovered was installed to run as the root user. By causing the executable file to overrun a stack-allocated buffer with a carefully crafted input string, the Red Team was able to force the file to execute code to start a command shell running as root. They were told beforehand where this file was located and were also given the file’s source code. Without this information, the team still could have located all files installed as root by scanning the file system with the findsuid.sh script (see the article “Phrack 49: Smashing the Stack for Fun and Profit” by Aleph One).

Technical discussion

The non-technical reader can skip this section.

After looking at the source code for target1, the Red Team quickly noticed that a buffer overrun attack could be conducted by modifying the inputs to the foo() function. This function copied the buffer with strcpy() without first verifying its inputs. The source string was passed into the application through the first command line parameter whose length and contents were never verified. The target buffer was a fixed length char array of 64 bytes that was defined within the main() function. The team started by creating their own copy of target1 on the development machine (CSE291A). That way, they could trace through disassembled code within the debugger. They could also step through the code at the instant the overrun occurred and inspect the memory. The team members found that the address of the beginning of the buffer was 0xBFFFF930 and the space between the beginning of the buffer and the return address was 80 bytes. Both of these values were used in crafting the exploit code.

The file sploit1.c was modified so that it would generate an environment variable “EGG” that contained the specially-crafted buffer. The code to generate the buffer was taken from the example of exploit #3 in the Phrack article. The beginning portion of the 84 character buffer was padded with NOP operations. Next in the buffer came the shell code. The end of the buffer was filled with a series of addresses that pointed to the estimated beginning of the buffer 0xBFFFF930. Sploit1 was built and then executed to construct the EGG variable to be used in the next part of the exploit.

When the Red Team executed the target1 app and passed in the EGG variable, a segmentation fault occurred. Tracing through the code in the debugger, it was discovered that the buffer beginning wasn’t located where it was before; it was no longer at 0xBFFFF930 but was now located at 0xBFFFF990 – a difference of 96 bytes. It seemed that some of the times when target1 app was loaded, it was executed with a slightly different stack location. This was not, however, caused by Address Space Layout Randomization since that feature of the operating system had been turned off. Since the margin of error for the estimated location of the buffer was greater than the size of the buffer, it would be impossible to consistently point the return address to the shell code, even if the beginning of the buffer were padded with NOPs.

For that reason, it was decided to change the buffer overrun approach. The team modified sploit.c so that all of the shell code was contained in a separate, much larger buffer (2048 bytes) that was placed in the environment variables. The beginning of this buffer was also padded with NOP instructions. A separate string of return codes (still 84 bytes) was passed into to target1 on the command line in order overrun the buffer and to point the executable to the shell code in its new location. The environment variable containing the shell code was now loaded in memory from 0xBFFFF3D1 to 0xBFFFFBCB and the value that chosen as the return code (0xBFFF950) was well within the previously observed margin of error. After making these changes and re-executing the exploit, the buffer overrun worked and opened a new command shell on the first try.

Sploit1 was then changed it to point to /tmp/target1 and was re-run against the test server. Sploit1 worked on the first try, and the Red Team had gained root access.

Damage estimation

Home computer

On a home computer, it is difficult to measure the damage done considering the fact that many people utilize their computer in different ways. But let us do two examples, one computer with the minimal functions and another computer that has a lot of programs. The simpler computer, we will call Computer A, will probably cost the user the value of the computer itself, as a tangible object. Computer A will probably only use the computer to type a memo here and there, web surf, and save some papers that he or she wrote. This type of person will probably not have the technical skills to patch or repair the damage done by the attack. They will need to seek outside help to get their computer up and running again. So let us calculate what an attack such as the one Red Team performed on the CSEP291B machine. With root access, Red Team was able to access any files within that machine. Had this happened to the simple Computer A, the victim’s files and paper could easily be tampered with or worse, deleted. Estimating the dollar value of these papers is complicated, but for simplicity sake lets say each paper was worth $50 (calculating time, effort, and throwing in minimum wage). Since this user is average and not technical savvy, we will guess that this person types one paper a month, and has had the computer for 3 years (until it is time to upgrade) so we assume the person has about 36 papers. If all his or her papers were deleted, but no physical harm done to the computer itself the total loss would be (36 papers X $50) + $0 computer damage = $1800 worth of papers. If this person seeks outside help and the charge is minimum wage, $6.75 and the consultant looks over it for four hours, the outside help’s bill would be $6.75 X 4 hours = $27.00. So the total estimated damage done for Computer A is $27.00 + $1800 = $1827 (more or less considering the real worth to each individual).

For the home computer with more functions than Computer A, the value damage may be slightly more to considerably more, depending on what the user has installed. This user of Computer B will have more skills than the user of Computer A. So let us assume that the user of Computer B has all of his or her family pictures, music, some personal data, and of course, those monthly papers he or she writes. How would this change the damage done? One can assign exceptional sentimental value to personal belongings such as pictures. Let us even go as far as saying these pictures were meant to be confidential as in the recent Britney Spears baby pictures case. With unlimited access a hacker could purloin such photos quite easily. Some magazines were reportedly willing to spend a surprising $1-2 million for publishing rights. If a hacker had infiltrated her computer and stolen the photographs and leaked them online and did not withdraw them, her deals with the magazine would devalue, and she would not realize the $1-2 million. We can see how quickly economic damages can escalate even for a single computer.

Now consider the case of identity theft. Many home computer users have personal information stored in their computers. If a hacker attacks one of these computers, they can attain information and possibly steal a person’s identity. According to the Identity Theft Resource Center, a victim spends “an average of 600 hours recovering from this crime” and if these hours are “indicated [in the] victim wages, this equals $16,000 in potential or realized income”. If the Federal Bureau of Investigation enters the case to investigate, "the average cost ... is $20,000”.

Walmart's Corporate VP

A Corporate computer used by a VP of Wal-Mart would have a lot of business related information on it that could be used to the attackers benefit. Wal-Mart in 2002 alone imported over $12 billion in Chinese goods. Access to this computer would give the attacker knowledge of what merchandise was being shipped where and its contents. A shipment of soap is not that interesting but diverting a truck or even a whole container full of LCD televisions or other expensive electronics to a site that an attacker can seize the goods and make personal use of them is very attractive. A corporate computer may also contain information about an impending buy out of a competitor or marketing strategy to capture more market share. An attacker can also hijack the VP’s computer and request information from the HR department thus having access to some of the 1.4 million Wal-Mart employees valuable information such as SSN and home addresses.

A Denial of Service attack could lead to spoiled food not being shipped across the Wal-Mart network or stores not receiving timely shipments of goods leading to lost revenues and negative customer relations. Wal-Mart does conduct $256 billion of sales of which 7% is the Chinese import market and very critical to its bringing the lowest prices to its customers.

Charles Schwab NYSE

If a Charles Schwab computer was infiltrated, it is not exactly known what the amount could be loss. This computer may or may not contain information of Charles Schwab clients, so for simplicity sake we will assume that it is used only for buying or selling orders on the New York Stock Exchange. If Team 8 had been able to access the usernames and passwords, many of the orders could have be tampered with. The company according to aboutschwab.com could bring in a total revenue of “$1.138 billion” in a “3-month period”. This considerable amount or perhaps all of the revenue could be misguided to some bank account in Switzerland or possibly invested in a false investment group. Another attack that Team 8 could have done was denial of service. If Team 8 had encountered some confidential information when using the stolen usernames and passwords, plans to buy or sell on a certain day could be hindered by deleting plans or changing plans. Therefore Charles Schwab could lose billions if a break-in or break in the transmission of information occurs. Then there would be distrust in the clientele if word got around of the break in. This distrust in the security of Charles Schwab would have a domino like effect causing many to withdraw their business with Charles Schwab. Schwab’s clients are paying for dependability of Schwab to make transactions on their behalf in a timely manner because stocks are time sensitive. Any breach of contract whether, it be purchasing in a timely manner, to purchasing the amount requested by clients, to keeping buyers financial information confidential, would make Schwab less appealing and decrease confidence in current and future business transactions.

year Virus/Worm Estimatated Damage
1999 Melissa Virus $80 Million
2000 LoveBug Virus $10 Billion
2001 Code Red I & II Worms $2.6 Billion
2001 Nimda Virus $590 Million- $2 Billion
2002 Klez worm $9 Billion
2003 Slammer Worm $1 Billion
2003 Blaster Worm $525 Million

Value to terrorists

Scalability

Since machines of all operating systems are vulnerable to buffer overflow attacks and so many machines are networked, the technique scales quite readily. It is also fairly future-proof, as companies will continue to run outdated operating systems and software such as Linux 1.0 and Windows 98 until there is a business justification to upgrade. Therefore, the technique scales from one to many machines easily, especially where clusters of machines exist running precisely the same software; these clusters include Google, Amazon, even servers for the United States Patent Office and congressional offices. In thinking like a terrorist organization, we need to determine the size of the target and who the target is. We, the United States, are often the target of potential attacks. Being a terrorist, they want maximize their impact on the physical world by disrupting points within computer networks within programs that the targeted victims depend on to go about their everyday activities.

Feasability of acquiring knowledge

The concept of buffer overflows is neither concealed nor esoteric. Any undergraduate education, and some secondary education programs will contain this subject matter in their curricula. Just like everyday people, terrorist are also somewhat concerned with cost; whether it is about money or valuable and expendable team members. With cyber attacks, the cost are much lower compared to that of physical attacks. For instance, in physical attacks, such as suicide bombers, the cost of recruiting and training members outweighs that of cyber terrorism. Although cyber terrorism may require longer training, it is less expensive and less intensive in the long run. This longer training is also beneficial because a terrorist group is able to maintain a number of members, as opposed to suicide bombings which is a one time deal.

Value for achieving aims of terrorists

Root access to systems is by definition unlimited, and so are the possibilities. Everything hinges on the nature of the machine compromised.

Defacement usually affects compromised machines connected to the Internet that are typically higher profile, such as www.whitehouse.gov or www.google.com. During the days immediately preceding and following the commencement of war in Iraq in March of 2003, over 3,000 sites were defaced with both pro- and anti-war messages. Such defacements receive some press, but sites are generally able to recover quickly and the defacements do little to further public support or education of terrorist aims. While the financial damage to an individual site may be meaningful, the economy as a whole does not suffer.

Denial of service (DOS) for public facing internet sites may be useful for publicity, but as average "script kiddies" can perform such tasks occasionally, pulling this off does not gather much interest. Rather, a DOS attack against core trading machines at a national stock exchange could cost billions of dollars, depending on the outage. This would be noticed.

Root access to SCADA-type systems could result in serious catastrophe on the order of a national emergency by disrupting infrastructure and possibly causing physical damage that would take quite a while to recover from.

Defenses

Implementing technology to solve buffer overruns is usually less expensive than more policy-oriented, nontechnical solutions. These solutions typically involve one time expenses to upgrade compilers or purchase software scanning technology. As buffer overflows have been so widespread, so damaging, and so easy to implement, corporate and higher education research and development have yielded several innovations to mitigate and/or prevent damage.

Home

Unfortunately the home user has little defense against buffer overflows other than keeping their systems up to date with the latest patches. Home users applying patches incur low costs, since many operating systems (Debian Linux, Microsoft Windows 2000 and later, etc) can be configured to automatically update. Since most consumers use common, off-the-shelf applications typically tested for compatibility by operating system manufacturers, application compatibility issues are not encountered as frequently.

To prevent information disclosure, both home and corporate users can use encryption to scramble the contents of documents so that they are only readable by those with the keys to unscramble them. Some packages such as Pretty Good Privacy (PGP) are free but not necessarily easy to use. Of course, this is only effective if they keys are stored separately from the sensitive documents.

Developer

At a level of "source code," the human-readable instructions written by programmers, several techniques are available to harden code to buffer overflow attacks. In one method, strcpy(), the function that is implicatable in the majority of attacks, has a companion function called strncpy(). The function is defined in the official ANSI standard for the C language and hence needs no additional third party libraries. Although the names differ by just one letter, the implementation difference is significant. Recall that the nature of a buffer overflow is to overflow a buffer when one sequence of characters is copied to another location. With the strncpy() function, a programmer can specify a limit on how many characters are copied. Hence, if the programmer defines the buffer to be only 64 characters long, then he can direct the strncpy() function to copy at most 64 characters. As an added precaution, strncpy() pads the remainder of the target buffer with "null" characters.

However, strncpy is no panacea and it can be misused. CERT security advisories are peppered with buffer overflows that occurred; strncpy was used but incorrectly. Therefore it is inadvisable to take up a Y2K-style line-by-line search and replace for code that uses strcpy() unless further analysis is done. Furthermore, the cost to examine and repair each line of code could be on the order of tens of dollars, including testing.

Compilers take source code written by programmers and produce "executable" files that instruct the computer to perform a sequence of operations. When the compiler generates code, it can add instructions that can increase security. In a technology originally developed by Crispin Cowan in 1998, the compiler supports adding code that, when run, places a "canary" value prior to the return address in the stack. If an attacker attempts to overflow the buffer, he destroys the canary value as well. If the program checks the value of the canary and finds that it has changed, it halts to prevent any damage.

Implementing this feature is cheaper since it only requires rebuilding rather than modifying existing code. There are extensions to gcc, a compiler commonly used on UNIX platforms, and newer Microsoft compilers include a "gs" flag to enable this technology. In fact, at Microsoft, all code must be compiled using this flag.


Corporate IT

At the enterprise level, automatic updates can cause major headaches -- regardless of whether or not they are applied. Administrators are often reluctant to deploy operating system patches for fear that a critical line of business (LOB) application may go offline. For example, the Windows XP Service Pack 2 rollout was dubbed "Update-Crash Day" since it caused some versions of Adobe Photoshop, WordPerfect Office, and even antivirus products such as Norton Antivirus and eTrust EZ Armor, to stop working. Administrators must perform a cost-benefit analysis to determine whether a patch is worth applying, much like a doctor (vendor) advises patients, but ultimately the patient (IT administrator) makes the decision.

LOB applications are vulnerable to buffer overflows, but it is less likely that they would be exploited since they are usually not available on the open internet to the malicious hacker community at-large. To secure LOB applications, business customers can implement some of the following defenses.

Corporate policy oriented defenses create processes such as the "secure development lifecycle" (SDLC) for software development that include activities such as threat modeling and internal and external security audits prior to releasing software. An organization of any level can pick up these processes, but due to high overhead costs, the cost likely grows faster than linearly with the size of the organization. Furthermore, the SDLC only helps with new code; existing code must either be grandfathered in (dangerous) or subject separate, more expensive review processes.

Public policy

What can governments do to decrease vulnerabilities? A popular recent approach addresses penalties for failure to perform due diligence in creating secure software. The California legislature passed SB 1386 which provides economic damages for each instance of personally identifiable information (PII) publicly disclosed without permission. Any company that exposes data due to an attack is liable, and there is strong incentive to harden security around this data. One possible downside of this is that IT security spend may concentrate on areas with legal ramifications rather than a holistic approach.

Another approach borrows the concept of licensed professional engineers from civil engineering and applies it to computer science. After a disaster in 1937 which killed many schoolchildren in Texas, the Texas Board of Professional Engineers was created which tests and licenses civil engineers, and many projects require the use of such engineers. In fact, Texas has been concerned about software engineers illegally using the word engineer in their title. Such a license for computer software engineers would ensure some standards of knowledge, particularly about security. However, the industry would first have to agree on some standards; certifications exist today for various platforms but security is typically not a focus.

Finally, governments can follow an approach similar to that taken to ensure accessibility requirements in software were met: by opting not to purchase software products that do not meet a well-defined standard of security. Making software accessible to disabled persons was not a priority until the Americans with Disabilities Act was deemed to apply to software and web sites.


Summary

The buffer overflow is one of the most pervasive and exploitable security holes, affecting code deployed on every operating system and every hardware platform. Vendors consistently patch buffer overflows and the volume of patches can inundate even the most determined IT administrators. The Red Team was able to attain root, or administrator-level, access to a target machine with minimal effort using only text freely dissemenated on the Internet. Furthermore, the economic and noneconomic damages can vary from around $1,000 to billions of dollars, depending on the number of machines affected, and there are already existance proofs of damage at almost every financial order of magnitude. For terrorists, buffer overflows can be exploited to provide free publicity in the form of defacements and public exposure of corporate vulnerabilities, but so far critical control systems have not been affected. The lack of large damage to national infrastructure is likely due to the prescience and strength of existing security systems. However, as networks, including SCADA and financial trading systems, become more connected through open channels, the risk increases proportionally.

IT administrators and CTOs in all sectors must advocate for internal excellence in secure deployment of IT and secure development for line of business applications. In industry, security must be a key performance indicator (KPI) to ensure visibilty at the boardroom level. Except for security firms, cybersecurity is a cost center whether implemented or not; the costs of latter dwarf the former. Through awareness campaigns and proper process implementation, everyone from home users to corporate datacenters to managers of critical infrastucture can mitigate potential damages with far-reaching implications.

References

Retrieved from "http://cubist.cs.washington.edu/CyberSecurity/index.php?title=Team_8_Paper&oldid=2382"