Next movement in IoT pentest when you have restricted information

Question

I am a newbie cyber security engineer working on IoT. Today, a task is given to me. The task was making pentest to a cooker. Because of the privacy, I cannot share the brand of the cooker. The cooker has its own wifi card and connects to wifi. You control the cooker using your mobile phone. There are many recipes in the mobile application and you select one of them to cook, or you can also write your own recipe into the mobile app (for example you give commands as to its temperature, time, vapour pressure etc).

Before the first start, you need to match the cooker and your smartphone. When they match, wifi of both device must be open and they must be in the same network.

My attempt: As I said, I am a newbie and so I am trying to make the pentest as if I am trying to solve CTF. Firstly, I made port scanning using "rustscan","nmap" and "nessus". The only open tcp port was 6668 whose service was "irc" without showing its version. Both vuln library of nmap and nessus could not find any vulnerability. Moreover, there were 3 "open|filtered" UDP ports such that port 67,68 whose service is "dhcps" and port 5353 whose service is "zeroconf" without showing any version number.

When I listen the network using wireshark, i saw that the communication is made using always different ports.For example, if the previous packet has been sent to port 54321, the next one has been sent to 54320, and this process continues consecutively.

I could not see any "mqtt" or any other IoT protocol in wireshark, so it did not give me something.

After those attempts, I am stuck in there. I do not know what I should do. There is not any bin file to make firmware analysis. I thought to make reverse engineering to a mobile application, but they (seniors) do not want it.

If you were me, what would you do? What is the next movement? What can I do using this information (1 tcp and 3 udp ports).

Addentum: How can I examine this irc port, I tried to connect it using netcat "nc 192.168.200.14 6668", but nothing happened. What is your recommendation to inspect this port?

Answer 1

I am a pentester but I've not particularly worked on IoT devices before. With the situation you've described, I think my next steps would be to look at the network traffic more, both to and from the cooker while trying to create a broad variety of network traffic.

If the traffic to the cooker is unencrypted you can try replaying traffic and modifying it, maybe you can get some unexpected behaviour. If the traffic from the cooker is unencrypted you might see more data than gets shown in the app hinting at potential further avenues of attack.

If traffic is encrypted you might want to try MitM'ing it. Install a proxy cert on your testing phone and see if you can connect. You might have limited success with this as they may use cert pinning. You may also be able to forcibly downgrade the connection to plaintext, though that should be unlikely to work.

If the cooker itself has an update feature, you could try running that. It might connect via the phone or directly, but you may be able to intercept the update and potentially analyse it.

Assuming you have permission to perform destructive testing to some degree, you may want to try to see if the cooker itself has some sort of hidden USB port or other physical connection interface. I say "permission to perform destructive testing" because it may be behind a panel or something that you may need to remove in order to access it. This sort of thing may be present for technicians to perform servicing etc. As such, it may provide a wealth of information.