Skip to main content Link Search Menu Expand Document (external link)
CS 161 Project 1

Remus (Launched 1975)

  • Username: remus
  • Click to reveal password: ilearned
  • Points: 10
Orion class satellites were some of the first to be launched into orbit. Once
Gobian Union's proudest achievement, these satellites are now disused and ready
to be deorbited. CSA engineers recently deorbited the Orion-class satellite
Romulus and prepared a manual with instructions for hacking into the satellite.

Your job is to deorbit its sister satellite, Remus, using the provided manual.
Old satellites often have messages from the past in their README, so once you
hack into Remus, why not check out what the cosmonauts of the past had to say?

To familiarize you with the workflow of this project, we will walk you through the exploit for the first question. This part has a lot of reading, but please read everything carefully to minimize silly mistakes in later questions!

Log into the remus account on the VM using the password you obtained in the customization step above.

Starter Files

Use the ls -al command to see the files for this user. Each user (one per question) will have the following files:

  • The source code for a vulnerable C program, ending in .c. In this question, this is the orbit.c file.

  • A vulnerable C program (the name of the source file without the .c). In this question, this is the orbit file.

  • exploit: A scaffolding script that takes your malicious input and feeds it to the vulnerable program.

  • debug-exploit: A debugging version of the scaffolding script that takes your malicious input and starts GDB.

  • README: The file you want to read.

Preliminaries

Your task is to read the README file in each user. You can start by trying the cat command, which is used to read files and print them to the output. First, try this with cat WELCOME. You should see the contents of the WELCOME file on your terminal.

Now, try reading the contents of README using cat README. We don’t have permission to read the file! The file is only accessible to the next user.

Luckily, each user also has a vulnerable C program that has permission to read the README file. If exploit the C program, you can take over the program and force it to execute code that reads the README file with its elevated privileges!

Your goal for each question will be to write this exploit as a malicious input to the vulnerable C program in order to access the restricted README file, where you will find the username and password for the next question.

Writing the Exploit

First, open orbit.c and take a look at the source code. You can use cat orbit.c or open orbit.c in a terminal text editor. Notice that this question uses the vulnerable gets function! (If you need a refresher of what gets does, use man gets to check the man pages.)

You can quickly check that this has a memory safety vulnerability. Normally, you would use ./orbit to run the vulnerable program, but because we want to ensure that our addresses are consistent, you should run the program using invoke orbit instead. Run the program, and try typing AAAAAAAAAAAA followed by the Enter key. You should see that the program segfaults!

This means that, if you provide a specially crafted input to the orbit program, you can cause it to execute your own, malicious code, called shellcode. We will write our input using Python 3, stored in an egg file. Whatever bytes are printed from the egg file will be sent as input to the vulnerable program. Note that at the top of all of our files, including the egg file, is a shebang line. The shebang line tells the operating system that this executable should be run as a Python file:

#!/usr/bin/env python3

Your shellcode for this question will cause the vulnerable program to spawn a shell that you can directly interact with. The shellcode is provided in Python 3 syntax below:

SHELLCODE = \
    b'\x6a\x32\x58\xcd\x80\x89\xc3\x89\xc1\x6a' \
    b'\x47\x58\xcd\x80\x31\xc0\x50\x68\x2f\x2f' \
    b'\x73\x68\x68\x2f\x62\x69\x6e\x54\x5b\x50' \
    b'\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80'

In this syntax, note that a function address like 0xffabcd09 becomes b'\x09\xcd\xab\xff'. The order of the bytes are reversed since we work in a little-endian system.

In this question, you will be modifying the egg file. You can use any terminal editor of your choice: We have provided vim, emacs, and nano in the virtual machine.

The script will be treated as a standard Python file. You will want to include the SHELLCODE we have provided above, and your input will be whatever is printed from Python. Note that we’ve provided our own print, the helper function printb. Due to the default python3 encoding being utf-8, print won’t work, so make sure to use printb in any situation where you would normally use print to ensure your byte strings print properly. This question should only require a single printb statement. Also note that by default, Python3 strings are encoded using utf-8 encoding, which can mess up our exploits, so always append strings with b'' to indicate byte encoding.

Running GDB

To find the addresses you need to exploit this program, you will need to try running the vulnerable program under GDB. Normally, you would use gdb orbit in order to run the program. However, to make sure the GDB addresses match the addresses you get from running the program normally, we will use invoke -d orbit instead. This will give you a GDB terminal for you to find addresses and debug the logic of the program.

Running Your Exploit

The exploit wrapper script we have provided will automatically feed the output from the egg script into the input of the vulnerable program. If you’re curious, you can use cat exploit to see how we achieve this. To run it, use ./exploit.

If your egg file is correct, the vulnerable program will launch a shell, and typing cat README (followed by a newline) after running ./exploit should print the contents of README!

Debugging Your Exploit

If your exploit doesn’t work, you can use GDB to see how the program functions while receiving the input from your egg. The debug-exploit wrapper script will automatically run GDB (using invoke -d), with the program receiving the output from your egg as input. To run it, use ./debug-exploit.

From here, you can use gdb as you normally would, and any calls for input will come from your exploit scripts.

Note: Recall that x86 is little-endian, so the first four bytes of the shellcode will appear as 0xcd58326a in the debugger. To write 0x12345678 to memory, use '\x78\x56\x34\x12'.

Write-up

Each question (except for this one) will require a write-up. Each question’s write-up should contain the following pieces of information:

  • A description of the vulnerability
  • How any relevant “magic numbers” were determined, usually with GDB
  • A description of your exploit structure
  • GDB output demonstrating the before/after of the exploit working

Summary

We recommend the following steps (as described above) for every question of this project:

  1. Look at the source code of the vulnerable program and try to find a vulnerability.
  2. Run the program with invoke PROGRAM to make sure you understand what the program is really doing.
  3. Run the program in GDB with invoke -d PROGRAM and find any magic values or addresses you need.
  4. Write your exploit scripts for the question.
  5. Test your malicious scripts with ./exploit. Some questions (including this one) spawn a shell, so try typing cat README followed by a newline.
  6. If it doesn’t work, use ./debug-exploit to debug your exploit. Tweak your exploit, and try again!

To help you out, we have provided an example write-up for this question only. You will need to submit your own write-ups for the rest of the questions.

With the help of the example write-up, write out the input that will cause orbit to spawn a shell. A video demo is also available at this link.

Deliverables

  • A script egg

No writeup required for this question only.

outward

Table of contents