SPECTRA

Web PHP File Misconfiguration Environment Misconfiguration CMS Exploit
logo

Linux/Unix

10.10.10.229

Easy

Release: 02-28-2021

First of all, we need to enumerate and scan the opened ports. Follow the steps bellow:

  1. Make new dirs for a full and detailed port scan output files. It's a good pratice organize the files the most as possible.
  2. Now, we run a non deep nmap scan command (first 1000 ports), just to list the opened ports.
  3. Move the output files to "nmap_full" dir.
  4. With the last nmap output results, we need rescans the specifics ports with a deep scan, to enumerate services.
  5. Move the output files to "nmap_ports" dir.
TIP: If the listed open ports wasn't returned any information about exploit/vulnerability/payload, try to run a deep scan with nmap using de -p- option, maybe there are high ports opened that wasn't listed before: #nmap -sV -p- -v 10.10.10.229 -oA nmap

Check the commands used for the initial enumeration:

kali@kali:~/htb/spectra

kali@kali: ~/htb/spectra/ # mkdir nmap_full ; mkdir nmap_ports/
kali@kali: ~/htb/spectra/ # nmap -Pn -n -v 10.10.10.229 -oA nmap/
kali@kali: ~/htb/spectra/ # mv nmap.* ./nmap_full/
kali@kali: ~/htb/spectra/ # nmap -sV -p22,80 -v 10.10.10.229 -oA nmap
kali@kali: ~/htb/spectra/ # mv nmap.* ./nmap_ports/
kali@kali: ~/htb/spectra/ # cat ./nmap_ports/nmap.nmap
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0)
80/tcp open http Apache httpd 2.4.25 ((Debian))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
kali@kali: ~/htb/spectra/ #

As we have a open port 80, let's check what service/website is hosted in it.

  1. As most of hack the box machines, is a good pratice edit the /etc/hosts file, to point the IP 10.10.10.229 to spectra.htb domain. # echo "10.10.10.229\tspectra.htb" >> /etc/hosts
  2. After edit the hosts, we can access the link provided in the 80 port website. Let's enumerate those page/sub-pages.
  3. There are some default files/dirs que can always enumerate in a website. But we dont have time to do one by one, so let's dirb the host. Remember to save the output for future use: $ dirb http://spectra.htb/ /usr/share/wordlists/dirb/common.txt > dirb.txt
  4. Using the extension Whappalyzer for firefox/chrome, let's enumerate info from pages/subpages. For CLI, we can use the command whatweb like that: # whatweb http://spectra.htb/desired_path

Information from spectra.htb/main:

  • PHP 5.6.40
  • WebServer Nginx 1.17.4
  • MySQL ???
  • Wordpress 5.4.2
  • Blog: Just one page - Sample Page
  • Blog: Just one post - Hello World
  • Blog: Just one Comment in Hello World post.
  • Blog: Just one Author - Administrator

  1. TIP: The index.php file, didnt return any content. That way, we always can give a try to enumerate the final url directory path, seaching for a 'INDEX OF' page from unsecure/bad configured servers. In our case, enumerating the http://spectra.htb/testing/, we have some files: # whatweb http://spectra.htb/testing/

Information from spectra.htb/testing/:

  • PHP 5.6.40
  • WebServer Nginx 1.17.4
  • MySQL ???
  • Wordpress 5.4.2
  • Source files from a wordpress instalation
  • wp-config.php.save -> plain text file from a php

  1. Let's download wp-config.php.save, and check the content: # wget -O wp-config.php.save http://10.10.10.229/testing/wp-config.php.save

Information from wp-config.php.save:

  • 'DB_NAME', 'dev'
  • 'DB_USER', 'devtest'
  • 'DB_PASSWORD', 'devteam01'

  1. Remember the information we get before. We have some credentials, so let's try log in the WP admin panel page: http://spectra.htb/main/wp-admin

Credentials used to log in:

  • User: devtest / Pass: devteam01 Wrong
  • User: dev / Pass: devteam01 Wrong
  • User: test / Pass: devteam01 Wrong
  • User: admin / Pass: devteam01 Wrong
  • User: administrator / Pass: devteam01 Success!

ADITIONAL COMMENT: We could save time bruteforcing user/pass just observing in the right way the information showed to us. Remember that we have just one author(administrator) in the target blog, so maybe its a username too.

  1. Perfect! Now we have access to the WP Admin Panel. Let's take a look on it, and then, go to next chapter:

Now we have access to the frontend system, we need to get a shell access, so lets check some interesting points and find how to exploit it.

  1. Searching in google for "wp admin exploit", you will find something about reverse shell/webshell in php.
  2. For this walkthrough, we will use a ReverShell in PHP from http://pentestmonkey.net/tools/php-reverse-shell
  3. One time we have it downloaded, we need to edit the reverser shell file, with the listening information from our machine(atacker), to receive a shell from the target machine (victim)

Change the vars to fit your machine info:

  • IP: Put your machine ip address.
  • PORT: Choose a port for the handler that will receive the shell.

In WP pentest, usually we get a shell, uploading a reverse shell to the host with some upload input field. Its exactly how we'll send the payload. We can send files to WP with 'Plugins' page, 'Themes' page or any upload fields WITHOUT file extension filter, so we can upload a php file as a image or a .zip file.

  1. First, we acess the Plugin install page: http://spectra.htb/main/wp-admin/plugin-install.php
  2. Click on "Upload plugin" button, and then "Browse" button.
  3. Search for your reverse shell in php already edited with your handler info, and send it to the page by clicking in the button "Install Now".
  4. Now we have to start a handler with Ncat, before run the reverse shell, or we won't receive the shell on our terminal. # rlwrap nc -nlvp 1234
  5. With the handler running, we can run the reverse shell. By default, WP uploaded files are stored on /wp-content/uploads/YYYY/MM/file.ext path. That way, we can start our reverse shell accessing the link: http://spectra.htb/main/wp-content/uploads/2021/07/rsp.php

First view info:

  • User: nginx
  • Group: nginx
  • $ sudo -l without permission to execute as sudo.

The user Nginx didnt have access to anything. We need to gain user access to catch the flag.

  1. For the usual enumeration, we used to list the directories, searching for interesting files and folders, that could help us to gain any type of access. I suggest start allways with /etc/, /opt/, /tmp, because usually we have info there, we just need to check if the current user have access to read/edit them.
  2. At /home/, we can list the avaiables users on system, exactly the ones, we need privesc.
  3. In /otp/, we have a interesting file called "autologin.conf.orig". Lets'a check the content:


Script analysis:

  • Read a password from a file.
  • Scan for 2 directories: /mnt/stateful_partition/etc/autologin/ and /etc/autologin/
  • Check for a file called 'passwd' and if exists, read it content.
  • The first path /mnt/stateful_partition/etc/autologin/passwd, does not exist.
  • The second path /etc/autologin/passwd, does exist.
  • Checking the file /etc/autologin/passwd content, we have: SummerHereWeCome!!


With the new password, we need enumerate from wich user we can gain access:



Credentials tried:

  • User: chronos / Pass: SummerHereWeCome!! Wrong
  • User: katie / Pass: SummerHereWeCome!! Success!
  • User: root / Pass: SummerHereWeCome!! Wrong
  • User: user / Pass: SummerHereWeCome!! Wrong

Used the credentials from katie for a ssh session:



Cathing the flag!

  • Checking the user with $ whoami
  • Checking the user UID, GID and groups: $ id
  • Listing current directory with $ ls
  • Show user.txt content with $ cat user.txt

We didnt have access to anything with the user nginx, but with katie, we full shell access through SSH. We need to gain root access to catch the flag.

  1. For the usual enumeration, we start listing user katie's permission: $ sudo -l
  2. Now, we have that User katie may run the following commands on spectra: (ALL) SETENV: NOPASSWD: /sbin/initctl
  3. Apparently, katie has access to the initctl service manager. It take us to list the availables services, to check if there's some vulnerability: $ sudo -u root /sbin/initctl list
  4. Several services named "Test"
  5. List services .conf files on /etc/init that katie has access: $ ls -la /etc/init/ | grep "developers"
  6. Check for a file called 'passwd' and if exists, read it content.
  7. Several services .conf files named "Test".
  8. Before edit the file, we need stop the service: $ sudo -u root /sbin/initctl stop test
  9. Now we pick any "test" file and edit it: $ nano /etc/init/test8.conf
  10. Delete the lines beetween the code blocks "script" and "end script", and put the command $ chmod +s /bin/bash and save the file.
  11. Now we need to start the service again to run the .conf file: $ sudo -u root /sbin/initctl start test


The final step to catch the root flag, consists in run the service, change the permission from /bin/bash to run it with the proprietary (root) permission.



Root Privesc actions:

  • The service "Test" is started.
  • Bash now can be started with root permission: $ /bin/bash -p"
  • Checking the user with $ whoami
  • Checking the user UID, GID and groups: $ id
  • Listing root directory with $ ls /root
  • Show root.txt content with $ cat root.txt