Team 8 Paper

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.