Debugging
As discovered previously, the current user has a sudo privileged to execute a custom binary executable as the root
user
A brief assessment was made and it appeared to be a program designed to review/modify stocks.
Here, I will look further into the binary by running it with strace, a simple debugging tool
rektsu@zipping:/home/rektsu$ strace /usr/bin/stock
execve("/usr/bin/stock", ["/usr/bin/stock"], 0x7fff10f60100 /* 16 vars */) = 0
brk(NULL) = 0x563d4ce3f000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffedbbf9ae0) = -1 EINVAL (Invalid argument)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f64e4727000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=18225, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 18225, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f64e4722000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3206\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2072888, ...}, AT_EMPTY_PATH) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2117488, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f64e4400000
mmap(0x7f64e4422000, 1544192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f64e4422000
mmap(0x7f64e459b000, 356352, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19b000) = 0x7f64e459b000
mmap(0x7f64e45f2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f1000) = 0x7f64e45f2000
mmap(0x7f64e45f8000, 53104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f64e45f8000
close(3) = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f64e471f000
arch_prctl(ARCH_SET_FS, 0x7f64e471f740) = 0
set_tid_address(0x7f64e471fa10) = 31143
set_robust_list(0x7f64e471fa20, 24) = 0
rseq(0x7f64e4720060, 0x20, 0, 0x53053053) = 0
mprotect(0x7f64e45f2000, 16384, PROT_READ) = 0
mprotect(0x563d4b4d5000, 4096, PROT_READ) = 0
mprotect(0x7f64e475d000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f64e4722000, 18225) = 0
newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x5), ...}, AT_EMPTY_PATH) = 0
getrandom("\x9f\x8c\x89\x2c\xa2\x97\x44\xfd", 8, GRND_NONBLOCK) = 8
brk(NULL) = 0x563d4ce3f000
brk(0x563d4ce60000) = 0x563d4ce60000
newfstatat(0, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x5), ...}, AT_EMPTY_PATH) = 0
write(1, "enter the password: ", 20Enter the password: ) = 20
read(0,
It still prompts for authentication. I will provide the password; St0ckM4nager
read(0, St0ckM4nager
"St0ckM4nager\n", 1024) = 13
openat(AT_FDCWD, "/home/rektsu/.config/libcounter.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(1, "\n================== Menu ======="..., 44
================== Menu ==================
) = 44
write(1, "\n", 1
) = 1
write(1, "1) See the stock\n", 171) See the stock
) = 17
write(1, "2) Edit the stock\n", 182) Edit the stock
) = 18
write(1, "3) Exit the program\n", 203) Exit the program
) = 20
write(1, "\n", 1
) = 1
write(1, "select an option: ", 18Select an option: ) = 18
read(0,
openat(AT_FDCWD, "/home/rektsu/.config/libcounter.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Upon authentication, I see that the binary made a system call to attempt to load a shared library file at /home/rektsu/.config/libcounter.so
openat
: This is a system call in Unix-like operating systems (Linux, in this case) used to open files or directories. It takes a file descriptor and a pathname as argumentsat_fdcwd
: This is a special value that represents the current working directory as a file descriptor. It’s used as the starting point for relative pathnames/home/rektsu/.config/libcounter.so
: This is the pathname of the file that the program is trying to open. It’s an absolute path, starting from the root directory, and it points to a file named “libcounter.so” within the “.config” directory under the user’s home directory (rektsu
in this case)o_rdonly | o_cloexec
: These are flags used when opening the file.O_RDONLY
indicates that the file is being opened for reading only, andO_CLOEXEC
indicates that the file descriptor should be closed automatically when executing a new program usingexec
-1
: This is the return value of theopenat
system call. A return value of -1 typically indicates an error occurred during the system callenoent (no such file or directory)
: This is an error code that indicates the reason for the failure. In this case, the error message “No such file or directory” suggests that the file specified in the pathname doesn’t exist at the given location
rektsu@zipping:/home/rektsu$ ll .config
total 8
drwxrwxr-x 2 rektsu rektsu 4096 aug 30 16:10 ./
drwxr-x--x 7 rektsu rektsu 4096 aug 30 15:19 ../
The /home/rektsu/.config
directory is empty
Additionally, the directory was brought up during the root cronjob enumeration with PSPY
Since the current user is able to write to the directory, it is possible to exploit the binary by hijacking the library