Cyber Security Blog

Updated article to include a slight amount of technical descriptions.

Internet connected devices are known to be vulnerable, but what would happen to an IOT light bulb that was hacked? Most would do things that aren’t harmful to the users, mostly because they lack the knowledge of how dangerous IOT devices can be.

We were asked to hack an internet connected light bulb per the request of the giant tech company who made it. Yes, an internet connected light bulb. We were testing the security of the light bulb when I started to wonder about a feature that the light bulb had. This feature allowed for people to remotely increase or decrease how bright the light is. Cool, but did they put rate limiting in place for the light bulb, so it can’t exceed a level of voltage that would make it explode and shatter everywhere? My hypothesis was that they most likely did not put rate limiting in place, so this light bulb should be able to explode.

This was my hypothesis, which we tested, since the person we were co authoring the exploit with had a secure environment to try and make the lightbulb explode. The light bulb was put in a box to make sure no one could be harmed if the light bulb exploded and shattered everywhere. It certainly did work, the glass shattered inside the box as the light bulb exploded due to a lack of rate limiting, which would’ve stopped this attack.

The lightbulb let you change the voltage via your phone. We used a well known software program for information security professionals called burpsuite to alter the request going to the light bulb and changing the amount of voltage it was to send from the maximum limit that the app allowed to a level of voltage that made the light bulb shatter.

What would happen if someone hacked the light bulbs across the homes of people who used it? They would be harmed at best, however this is not a laughing matter, especially due to how bad the security was. There were hard coded passwords and the email account associated to the development work for the lightbulb that were accessible on github. No, we are not joking. Sadly this is the reality we live in. A highly insecure reality with companies making it even more insecure by not fixing the most basic issue, which in this case was rate limiting.

Due to how vulnerable the light bulb was, it is and was absolutely unsafe. Unsafe to the point that we don’t believe it belongs in people’s homes. Fortunately the company announced in March 2017 that they had discontinued the sales of these lightbulbs. But they are still supporting the light bulbs that have already been purchased. The issue was reported, but we do not know if it was fixed or if these light bulbs still are still able to shatter.

This is only one internet connected nightmare device that we have audited. Our conference called Critical Con focuses solely on security flaws that can harm, kill, or assault the users and ways to possibly solve these issues September 15th and 16th in Westlake Village, California. If you would like to speak or would like to come, go to the website https://criticalcon.com.

How do you report security issues that are life threatening? This has been a question looming over the disclosures of security flaws for the talks at critical con, a conference that focuses on attacks that to some degree are life threatening. So how does one disclose that type of issue?

The answer to that question is an ever changing one based on multiple factors. Let’s discuss just a few of those possible scenarios. Let’s say a medical device company hires you to audit their products and you find a cyber security issue that is life threatening, what do you do?

Let’s take a step back. Before doing that audit you need a special legal agreement with the company, one that explicitly says you can publish a life threatening security threat, since the issue endangers peoples lives.

The company should also be given the appropriate amount of time to adhere to all regulation that may be in place, enough time to write a patch that won’t cause more issues and then send it out to everyone, before you publish.

What if this device is inside someone and doesn’t get remote updates, but gets updates in close proximity? Then, much like a non internet connected car that has to be recalled and fixed, people will have to go to their doctors office to get an update, if it’s a medical device. The fact that people may refuse to be updated falls outside the scope of this article.

So we’ve identified one way to report an issue, but what if the company won’t let you talk about the issue or you can only say a limited amount? That’s a dilemma, one that may end up in the hands of regulation, sadly. We don’t let people eat poisoned food and there are strict rules around food, so the disclosure of food that shouldn’t be digested is possible by employees who report it to the fda. That same rule would make sense to apply to devices that threaten lives, but this is ultimately up to lawmakers.

What if you don’t work for the company?

If you find a security issue in a device that is life threatening and you don’t work for the company, don’t report it via any bug bounty platform or you may end up in the above scenarios due to their legal agreements. Instead report it via email. If you can’t find an email, contact researchers who work in that area and see if they have any contacts. If you can’t contact them via email or find any researchers in that sector put up a tweet along the lines of ” hey @fictitiouscompany, you have a security flaw that endangers your users lives. Who do I contact?”

That in itself will get enough buzz, that the company will most likely respond. After you report to them then you wait and give them appropriate time to patch, which you would work out with them. If there is no way to report to the company, then you post the issue publicly, but you leave out what is vulnerable and for Pete’s sake, do not give working exploit code that if used is life threatening if the company hasn’t even had a chance to try to patch it. True, it is the companies fault, they didn’t have a way to get the information security report from you and you may want to make the company realize their mistake, so they’ll fix it, but at what cost are you willing to make them realize their mistake? If this is a life threatening exploit, which means it can, harm, kill, or assault the users then you are really hurting innocent civilians who are simply trying to survive if you go old school public disclosure without contacting the company. I am not aware of a scenario where putting up a fully functioning exploit to download that threatens someone’s life, before the company has a chance to review it serves any ethical purpose.

Issues that effect websites can be handled publicly like described above in most cases, but when we are talking about living beings, you’re in a whole new world of information security disclosure and you can’t operate as if you are just reporting another vulnerability.

As you can tell this is a lengthy topic, but for this post we believe this is enough ways to handle security disclosure of a life threatening nature to show you just how complicated this topic is.

If you are interested in the security of devices that can be life threatening if hacked, you will want to come to the critical con conference September 15th and 16th in Westlake Village, California at hub101.

This is a public list of programs you should avoid using due to flaws in code that have been reported or programs that have outstanding security. These companies code do not meet our standards of a secure plugin or do meet or exceed our standards.

wpform lite, also known as Contact Form by WPForms version 1.4.5.2 is secure after a non-quicky review, which we recommend you use if you need a WP form plugin.

quick overview of edit flow, shows better security than expected with an area that could use improvement, but over all the project thus far gets an A by us. We consider it safe enough to use.

 

We do not know why   parsedown on github appears to be  allowing rawhtml comments in an area dedicated to block comments. Also most of the parsedown does not apply security automatically. Is this by design? We wouldn’t use this project, but won’t say it isn’t safe enough to use.