How do we protect against IoT DDOS attacks like Mirai

So I’m going out on a lim and going to say that this is going to be a hot topic for a fair few people, is there a process or procedure that we can follow to change anything such as default passwords or extra security that we can do to help us all prevent our LIFX products from potentially becoming part of someones botnet.

It’s been quite a while since I’ve set up my LIFX account and so on, I know no-ones got that password but I cannot remember if there’s anything I can change from default etc to help step up the security etc?

The question is how much processing power does the bulb have to be able to be part of a botnet, from what I know there is nowhere near enough power to do anything of any value.

Well no, that’s irrelevant to the question, it could be a wifi calulator or toaster, I want to know if there’s a way to update anything / change anything that would stop this from happening?

Like on a router you update the default password etc, what is LIFX doing / what can I do to prevent my bulb getting into this issue, has it already been done, does claiming the bulb mean its only able to be used from that one device etc? What also happens if I loose said device, would removing the bulb and power cycling it refresh it?

Hi, before we go any further this is based on a preliminary understanding of the Mirai attacks and we are monitoring the information coming out from security researchers.

What we know so far is that it hit devices with default credentials and installed a reasonably complex package onto them. The cloud side (their equivalent versions of the LIFX cloud) were not significant targets of this attack. LIFX defends against these attacks with a layered system of defences.

First the LIFX cloud.
We don’t have default credentials on our bulbs. We have our own Public Key Infrastructure (PKI) to authenticate our cloud to our bulbs. This PKI infrastructure allows us to protect the CA private keys by keeping them out of reach and allowing us to only publish the public key component of this system. This allows us to revoke and rotate the operational side of the infrastructure. In the event that any of these keys were compromised we would make sure to contact everyone we could and publish information on how we are mitigating it and repairing from it.

For the infrastructure that receives public connections (not from our bulb or app) we use standard TLS certificates from public CAs to secure all traffic between us and end users.

I can recommend the Coursera introduction to cryptography course if you want to learn more of the theory on this topic. It’s really quite good.

We also have proactive monitoring and alerting on our cloud services. We develop our software with best practices and security in mind and we are frequent readers of OWASP and other security publications.

We do review the ways we handle these keys (and our development practices and reporting procedures) periodically and welcome suggestions and bug reports. We have internal procedures for security bug reporting.

On to the device side of things.
All firmware updates already take place over the secured PKI systems described above. In addition to this firmware updates are signed by our firmware team and the signature is verified in both the updater inside the app and in the bulb itself. Our bulbs also inadvertently benefit from the environment they run in. Due to the heat involved in our bulbs our SOCs are very minimal and don’t have an excess in compute power or storage. While this is not something that makes it more secure it does make it harder to effectively use a compromised bulb in the event that exploits or effective attacks on our updating method are found.

This is not to say that there are not steps that you should consider taking for your LIFX cloud account.

  • Log in to and make sure you periodically check that you don’t have unwanted services or devices authorised on your account.
  • Make sure you use a long and complex password.
  • Do not share your personal access tokens.
  • Revoke and Rotate access tokens periodically.
1 Like

So if I am using the Oauth process for creating keys for users of my app, should I periodically re-request tokens for all my users?

Pretty simple to defend against… disable UPnP, WPS & port forwarding on your router/firewall (for everything). …any decent IoT device (or device in general) will initiate outbound connectivity & does not need to be exposed to the greater Internet.

Here’s a decent article from CERT, specific to the Mirai malware:


Well yes that would be a really good idea if I wasn’t using my port forwarding for FTP & internal server access…

The UPnP off yeah I agree, just as much as people also changing default passwords.

With WPS I also agree, but I’m pretty sure I’ll know when someone’s in my house already before they’ll be pushing the button to add their device no?