Team 8 Main
Can you edit here: Team_8_Paper. --dan
Looking at the two different outlines that have been posted, I suggest we somehow combine the two. Elijah's outline has more of a public policy structure to it, but it lacks the criteria for the red team project. Eric's outline is to the point, but it i'm pretty sure the professors don't want a paper that structured in a simple question-answer format. So here is a suggestion:
Contents
I. Problem Identification
Security breach compromised information 2. What kinds of attacks could have been attempted and what would their effort and costs to implement:
a. Buffer Overrun of Custom Built Applications (we succeeded rooting the machine through the target1 application) b. Password Cracking Attack (we knew all of the other groups’ usernames and their default passwords. We could have compromised their data) c. Denial of Service Attack (not attempted) d. Virus Attack (not attempted) e. Worm Attack (not attempted, no vulnerabilities found) f. Phishing attack (not attempted) g. Remotely Executed Exploit (no vulnerabilities found)
II. Evidence of Problem
--Leonarde 14:08, 24 October 2005 (PDT)
Remote network attack
Remotely compromising a machine (hacking) is often done by communicating to a process that is listening on a certain network port. That process must also have an exploitable defect in the way that it processes incoming messages. These defects generally take the form of copying incoming data into an unchecked buffer. By creating a malformed or larger than expected message, an attacker can cause the process to overrun a stack-allocated buffer and then cause the process to execute any arbitrary code the attacker wishes (often through a telnet session that the attacker can execute further commands with). Hacking sites publish lists of known vulnerabilities to common applications as well as offer exploit code to use. An attacker needs only use certain network tools—like nmap—to search through all network ports and ascertain the versions of the listening applications. If the nmap reports a vulnerable process, the attacker can then target the process with the appropriate message.
Attack with console access
When the attacker has direct console access to a target machine, executing buffer overrun exploits becomes easier. The attack no longer requires malformed network message passed into a process—it can be mounted against incorrect processing of any input type: a file, command-line parameter, environment variable, etc. The scope of the attack is also widened to any application that the user has privilege to execute. If the attacker is able to exploit an application set to run as root, he/she will be able to open a command shell and to run arbitrary commands as root.
Exploits can not only be mounted against well known applications with published defects, they can be run against custom written application code as well. The chances of finding defects goes up when the attacker has access to the application source code. These conditions that were found on the CSE291B machine that was the target of the Red Team exercise. The Red Team was given a copy of source code of an application target1 that was found to be installed as root. Through inspection of the code, it was discovered that a command line parameter was copied into a fixed length buffer without checking the bounds of the input against the buffer length. The team was able to construct a small application that created input to overrun the buffer and open a shell as root. (see the appendix for how this exploit was conducted)
Red Team's Approach and Findings
In order to discover what potentially exploitable network processes were running on CSE291B, the Red Team ran nmap to conduct a comprehensive port scan. Because firewalls generally close network vulnerable ports that aren’t needed by resources outside of an internal network, we decided to download and run nmap from a machine within the firewall – CSEP291A. Nmap was able to help us 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 version had many published exploits). There is a 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.
III. Constuct alternative
One simple way to avoid attacks altogether is to work offline. Not putting yourself out there to be vulnerable is the only way to prevent such attacks. But one must question whether the benefits of online use outweigh taking full on prevention and working offline. Working offline may allow a user to use a downloaded or copied web page, but they will not have access to an updated page or may be missing images, video, or audio files that are fundamental to the web page. And although this seems like a simple solution, it is economically unfeasible because of all the benefits we enjoy as a society. Take the WIKI for instance; it is a website that completely revels in being able to have updated information at the click of a button. Although this may be a quick and easy solution, it is painful and slow-moving process which can lead to less production.
The next option would be to avoid computer languages that actually check the data that is going to be written into an array. Many languages offer the option to warn the user that a unique data assignment is being made to accommodate the maxed out overflow. In a time were processors are becoming faster and faster it may be worth the trade off to sacrifice speed for a lot more safety. The reason C and C++ are generally used is the fact that it is quicker due to its lack of boundary checking.
5. Feasibility for defending against such attacks.
a. home b. corporate c. financial d. protection is cost effective e. what is the lowest-cost provider for protection f. list of possible policy levers for government
IV. Criteria and Tradeoffs
--Elijah Esquibel 24 October 2005 --Charistel Trina Ticong 24 October 2005
When a successful exploit on a computer has occurred, it is quite difficult to give an overall range on how much dollar value damage is done. One must look at the use of the computer, is it a personal computer or corporate computer? What does the computer contain and are there back up files? Was the information personal or meant to be kept confidential? Also one must look at the attack that was performed, does it affect overall use of files or does it temporarily dysfunction the computer? We will give an evaluation on how these complications effects the damage in dollar value to a computer in these three scenarios: 1) a home computer, 2) Corporate computer used by a corporate VP of Walmart to order products from China, and 3) a Charles Schwab computer that is used to buy and sell orders of New York Stock Exchange.
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, who uses their computer in such a way as Computer A, 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 8 performed on the CSEP291B machine. Red Team 8 was able to access the various usernames and passwords 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 that means the person has about 36 papers (1 paper X 12 months X 3 years = 36). And 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? Well as human beings we seem to put a lot of value in sentimental objects, so pictures would be worth considerably more. Let us even go as far as saying these pictures were meant to be confidential as in the Britney Spears baby pictures case. Let us pretend that the stolen pictures were taken from her private computer. Had Red Team 8 done the same thing to her computer they could have deleted her pictures or in fact taken the pictures for themselves. Since, as sad as it may seem, her pictures with the baby are worth more than some or our houses, some magazines were reportedly willing to spend a surprising $1-2 million for publishing rights. But if Red Team 8 had infiltrated her computer, and stolen the photographs and leaked them online and did not withdraw them, her deals with the magazine would go belly up, and she would not see the $1-2 million (many of the online leaks have withdrawn the photos, so her deals with the magazine are still up in the air). A possible loss of $1-2 million is a possibility for a personal computer.
To make the Computer B user more relatable, the discussion of identity theft will preside. Many home computer users have personal information stored in their computers. If Red Team did an attack on one of these computers they would be able to 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”. A third party to this crime could possibly be the Federal Bureau of Investigation. They may come in and investigate, and also according to Identity Theft Resource Center the “FBI estimates the average cost per financial crime investigation is $20,000”. To sum things up on home computer loses; the amount can vary from a couple of thousands to even millions of dollars.
Corporate computer
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 billon dollars 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 billon dollars of sales of which 7% is the Chinese import market and very critical to it’s brining the lowest prices to its customers.
Charles Schwab computer
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.
V. Outcomes
--Elijah Esquibel 24 October 2005 --Charistel Trina Ticong 24 October 2005
4. What is the feasibility and strategy value of the techique(s) to a terrorist org?
a. scalability b. feasibility c. potential value for terrorist aims
--Leonarde 21:50, 23 October 2005 (PDT) How about this outline?:
1. What we did to probe the machine: (I'll take this -- Eric Leonard)
a. Determined the operating system (through nmap and redhat-version file) b. Determined applications installed on the system and their versions (nmap) and potentially exploitable applications (findsuid.sh) c. Determined open ports on a system (nmap) d. Investigated password file and passwords of other user accounts (/etc/passwd)
2. What kinds of attacks could have been attempted and what would their effort and costs to implement:
a. Buffer Overrun of Custom Built Applications (we succeeded rooting the machine through the target1 application) b. Password Cracking Attack (we knew all of the other groups’ usernames and their default passwords. We could have compromised their data) c. Denial of Service Attack (not attempted) d. Virus Attack (not attempted) e. Worm Attack (not attempted, no vulnerabilities found) f. Remotely Executed Exploit (no vulnerabilities found)
3. What is the dollar value of damage through our successful exploit to a
a. Home computer b. Corporate computer used by a corporate VP of Walmart c. Charles Schwab computer to buy/sell orders on NYSE.
4. What is the feasibility and strategy value of the techique(s) to a terrorist org?
a. scalability b. feasibility c. potential value for terrorist aims
5. Feasibility for defending against such attacks.
a. home b. corporate c. financial d. protection is cost effective e. what is the lowest-cost provider for protection f. list of possible policy levers for government
Technical details for mounting the buffer overflow attack
--Leonarde 13:58, 24 October 2005 (PDT)
To hack into the target server CSE291B, the Red Team began by investigating the possibility of performing a buffer overrun attack on an executable file (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 could 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, they 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).
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.
