Topics created by stuart

@oskar

The link shows the following which is different to the comments you made, is the current link data correct? I want to check for firmware update.

"When should I do a "user data restore" or a "factory reset" on my Hub?
If you ever forget your password to the Flic Hub then the only way you can access it again is to push the restore button on the Hub for 1-2 seconds. We hope you don't forget the password as doing a user data restore will wipe all your paired Flic’s and their existing configurations. You will need to therefore reconfigure all these after a restore.

In case something goes terribly wrong and the Hub is not working properly, you can factory reset the Hub back to default settings. This is achieved by pressing the restore button for 20-25 seconds.
The difference between this and the "user data restore" is that factory reset will also reset the firmware to version 1.0, so if you were using features added in new updates, you will need to update your Hub in order to use these. The Hub will automatically update itself if it has a Internet connection, but it might take up to 24 hours. If you don’t want to wait, you can connect to the Hub using the Flic app and manually trigger the update, or push the pin hole button between 2-5 seconds to initiate a firmware update. The LED will begin to blink slowly to indicate that it is currently downloading and installing a new firmware version. "

@anton said in Flic hub network security:

Hello, I am one of the developers of the hub.

Thanks for your time to look at his.

First of all I would like to ask what kind of technique you are using to decide if a UDP port is open or closed?

nmap -sS -sU -T4 -A -v -PE -PP -PS80,443 -PA3389 -PU40125 -PY -g 53 --script "default or (discovery and safe)" flic

UDP is connectionless so by design they don’t really behave like TCP when doing port scans. With TCP you often either get a Connection Reset response or no response at all if you try to connect to a closed port, at which point you can assume that the port is actually closed. With UDP it does not work like that since you are not guaranteed to get a response in either scenario. And even if a port is temporarily open it does not mean that you actually have a service on the other side listening.

I seem to remember that tools like NMAP use ICMP responses to decide if a UDP port is open (correct me if I’m wrong). But this generates a lot of false positives since a lot of ports are not really bound to a permanent service, but rather temporary ports used by both the Linux OS (DNS requests, NTP requests, etc..) and our host application for different features (like action executions etc). This is normal UDP behavior and not an indication of a security flaw.

Hence the question. It is hard to determine why a UDP port is open so I was interested to find out what should be listening and why.

I am not suggesting that I have found a flaw, just the potential to discover one and without some background on what the hub does, it is is guesswork at this point. I usually only work with Open Source and in that case, I can work it out for myself but as far as I know, the flic hub code is hidden so only people on your team can investigate.

The note about amplification attacks relates to services where a small request can be sent which creates a large response (see https://www.us-cert.gov/ncas/alerts/TA14-017A).

The assumption is that most flic hub users are not security experts therefore it is the responsibility of the device supplier to make sure that the user cannot be exploited. Many IoT vendors are also not thinking about security and the overall outcome is an unsafe and unreliable internet and this is what is behind my question.