“Attack to the fuel depot” or break the SCADA system on PHDays VI

PHDays organizers traditionally showed their organization skills, as always something new, interesting and of course a large number of stands under the control of SCADA systems. A rare opportunity to try their hand at breaking into the life support system of a large city, deploy an anti-missile system and fire a shot, arrange a train accident, flood the city, take control of the dam and much more.

All participants, and we are not an exception, are attracted by the opportunity to gain experience with SCADA, which manages industrial facility models. We found the booth of InfoTeKS company very interesting - “Attack on fuel storage”, which we managed to conquer. Below is the hacking sequence, who cares.

Terms of the contest "Attack on the fuel warehouse"
Baseline: The attack consists of two phases.
1. Stage: It is necessary to find a hint in the “Digital bar” to start the first stage of the attack. As a result of the first stage of the attack, it is required to master a certain “secret” to proceed to stage No. 2. The first stage is considered to be successfully completed if the actions of the violator were not noticed by the firewall.
2. Stage: Having received the “secret”, the attacker proceeds to the second stage of the attack. The task is to submit an unauthorized team to fill the punch.
Purpose: To carry out unauthorized discharge of fuel of 50 or 100 liters.
Permitted: Use your own laptop, with any necessary software.
Forbidden: Any physical impact on the layout of the fuel depot. The intruder will be immediately suspended from participation in the competition.

So, stage 1.
Known:
WiFi
SSID: step_default
PASS: 00000000
FTP
login: user
pass: Zb1HjJ9I
')


Having connected to the network via DHCP we get IP 50.50.50.12. and scan the available network.
sudo netdiscover -i wlan0 result gives us several IPs, each of which is scanned to open ports via nmap.
nmap -Pn - from the entire list, the most interesting was IP: 50.50.50.3, with open ports 22 (SSH), 21 (FTP), 80 (HTTP) and 7777 (not known service). I immediately remembered that we have a login and password for the FTP server. After authorization on FTP, the file 7777.zip is detected. Download and try to unpack, but it was not there, the archive is password-protected. Enter all that we know from the conditions of the job and found along the way. Nothing helped. Decided to postpone the issue and move on. Through the browser, open 50.50.50.3 and see the following:



It would seem an ordinary picture, but the experience of passing HackQuest did not pass without a trace. Download the picture and study the contents.



Using cat, we find some value at the end of the file " TnpjM056bzNPVFU0TWpRMk5nbz0K ". Upon reflection, they came to the conclusion that this is Base64 and executed the following command:

echo TnpjM056bzNPVFU0TWpRMk5nbz0K | base64 -d
got the answer - Nzc3Nzo3OTU4MjQ2Ngo =

doing this trick again, this time with the result
echo Nzc3Nzo3OTU4MjQ2Ngo = | base64 -d
in response - 7777: 79582466

So, now we have new meanings, the question remains: "Where to put them!?". Attempts to log in with this data via FTP and SSH, as well as using the password to the * .zip archive, did not produce a result. We remembered that port 7777 was also open on the remote machine. We connect via telnet and get the message “Tell me your ID”. Since the first part of the response is an indication of the port (7777), it is assumed that the second requested ID.



Everything is done right! The result was another FLAG ( Ffl42Nm5b4 # 445 ). Without departing from the ticket office, we recall that we also have a file named 7777.zip. Enter the received data as a password and voila, the archive is unpacked. Inside the archive, the johny file, looking at the contents of which our sysadmin, without a shadow of a doubt, pronounced the sentence “This is an SSH key” and did the following:



Using the SSH key and the file name as the account name (johny), we connected to the 50.50.50.3 server and received new data in response
IG10: YourPassPhrese987

IG10 turned out to be another Wi-Fi access point. Having connected to IG10, we started all over again.

sudo netdiscover -i wlan0
this time attention was attracted by the fact that the network had two address spaces - 192.168.2.1/24 and 192.168.20.1/24
It is noteworthy that the gateway (192.168.1.1 & 192.168.20.1) had the same MAC, which means that there is only one router on the network. For access to both subnets prescribed route.

sudo route add-net 192.168.0.0 netmask 255.255.0.0 gw 192.168.20.1

Next, they took up spoofing. To supply fuel to a robot connected to the IG10 network's WiFi, a command was sent, which, in turn, was processed on the server and issued a command to dump the fuel. Unfortunately, we didn’t save the * .pcap file with the data collected via spoofing, so we’ll have to explain it on our fingers.
We found that when pressing the fuel reset button with IP 192.168.20.7 (presumably a robot), via modbus protocol, towards IP 192.168.2.2 (presumably the control server), a packet is transmitted to port 502. Thus, we defined the roles of devices. It remains only to reproduce the re-sending of the packet, we already had all the necessary information for this. However, we didn’t work out the replay of the sending package by our own because of the complexity of sending the generated package. Github came to the rescue by downloading the necessary lib and modifying it a little to fit my goals, I managed to reproduce the data sent by the robot - the command to dump the fuel.