Difference between revisions of "Team 8 Paper"

From CyberSecurity
Jump to: navigation, search
(defenses and references)
(added Cal edits)
Line 31: Line 31:
 
== Damage estimation ==
 
== Damage estimation ==
 
=== Home computer ===
 
=== Home computer ===
 +
 
=== Walmart's Corporate VP ===
 
=== 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 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 NYSE ===
 
=== 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.
 +
 +
 +
  
 
== Value to terrorists ==
 
== Value to terrorists ==

Revision as of 02:51, 25 October 2005

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.


Attack techniques

Attempt 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.

Technical discussion

The non-technical reader can skip this section.

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.


Damage estimation

Home computer

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 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 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.



Value to terrorists

Scalability

Feasability of acquiring knowledge

Value for achieving aims of terrorists

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.

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

References

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