Several weeks ago we were given a camera from one of our clients who said – “could you please check if it works correctly, something is not right”.
When we asked them about camera’s IP address, we got “I don’t know”. Well, it’s not the first time we hear that.
Fortunately, manufacturer has implemented MDNS-based camera discovery feature in own VMS (video management system). It worked and after performing discovery process we found IP address of the camera is 10.22.107.41 (By the way this was factory IP address for the cam, so it wasn’t changed by client).
So far so good, we tried to access the camera, but suddenly got “wrong password” response. For sure that meant the customer had changed default password. So we asked him for the actual one but got – you guessed it – “I don’t know, some other engineers have set it”.
I need to mention here this was a Mobotix IP camera. Mobotix provides extremely strict rules about password reset – you just can’t do it yourself and it’s needed to send a camera to manufacturer and pay money for unlocking. In addition to that serial number will be checked to check camera origin, sales channel and whether it’s listed as ‘stolen’.
..”But”, he continued, “If you do port forwarding to the camera for us, we’ll try to guess what password we’ve set, it might be one of our usual passwords”.
Great, so our task is to set NATting. Only one problem arises – we need to know whether default gateway was set in the camera and if yes – which one? As you probably understand, there was no chance to get this information from a customer. Quite usual story by the way.
So I arranged packet capture hoping to find any clue and asked to reboot the camera (it was in our remote office).
Capturing startup process is very useful, as in the beginning any device performs initial procedures requests etc. Later a device could enter some quiet and stable state, and who knows what algorithms are implemented in it about sleeping or renewal.
The resulting pcap is below:
What can we find useful?
- This is what MDNS resolution looks like.
- Hmm, we have IPv6 enabled too. We could make use of it, but there is no IPv6 present in Ukraine yet. Otherwise we could push default gateway information using Router Advertisements, set translation, but – not today.
- Yes, p.2 is about that 🙂
- Leaving some multicast group. No idea what is it all about.
- This one looks really, really promising! ARP frame asking for 10.255.255.254 with no reply (of course). To mantion, ARPing for such address means the cam is in /8 size subnet. Is it an attempt to find gateway’s MAC?
- Looks like some proprietary broadcast. Not much sense to dig into it.
What if we pretend to be a gateway having 10.255.255.254 on our internal router interface and also set up PAT from it to our public address?
I went this way and… Bingo! We got an access from outside to the cam.
Case solved, time elapsed: 5 minutes.
.. If you’re curious: the end of the story is – they couldn’t manage to recall the password anyway, none of their attempts succeeded… But that’s totally different story.