What is the best way to achieve success?

Whenever I ask people what it takes to be successful. The only answer I get is hard work. Everyone knows that hard work makes a person successful. But no one knows how to do hard work. It's like you…

Smartphone

独家优惠奖金 100% 高达 1 BTC + 180 免费旋转




The worst things I found hacking a cheap IoT Smart Light

In the last article we reverse engineered a significant part of the smartlight’s internals.
We’re now going to take a higher-level point of view and have a look at the applications developed by iHomma.

First of all, let’s read the description; isn’t there something weird?

Why would I need to allow this app to discover Bluetooth Low Energy devices if this application only supports WiFi smart lights?!

I don’t want to jump to conclusions, but that’s definitely a very interesting way to introduce your application, iHomma.

Apk files (like jar, docx, xlsx and probably many others) actually are zip archives (you probably noticed the usage of zipalign if you ever signed apk files).

Which means that we can unzip this archive like any other zipfile :

We now have some of the original application’s files but we still need to decompile the java sources.

Decompiled code, whether if it was compiled from C, C++, Java, Rust, Golang or any other compiled language is very different from the code originally written by the developer(s).

Most functions, methods, variables and files names are replaced by placeholders since they are usually lost during the compilation process.

In most cases an Android application’s decompiled code will look like this :

To make sense out of decompiled code with many unknown data, I have a macroscopic to microscopic approach :

After spending the last two days going through 134 files (roughly 32428 lines of code), here are the most interesting things I discovered about this application :

They litteraly are the same, each of these apps share 99% of the same codebase.

It’s just there and does not seems to be used as far as I know.

I cannot be 100% confident it can not be exploited or remotely enabled/activated though.

I could not read all of the application’s code : a few classes could not be decompiled successfuly and there is a libjellyfish-lib.so C++ library used, which seemed only used to forge serial packets from what I noticed going through it with radare, but x86 asm isn’t nearly as explicit as decompiled Java and I can’t afford to spend 4 days reversing this library.

Am I the only one scared about this? Oh and it’s not over —

Do you want more? Because there’s more!

The application creates a lamp.db file, in which is stored information about your smart devices and about your WiFi, including its SSID and passphrase in cleartext.

lamp.db’s file tables

As a reminder, the lamp uses the ESP smart config protocol, which means that our SSID and passphrase are already stored in the lamp’s internal memory!

Such sensitive information should not be stored (especially in plaintext) unless it is absolutely necessary and in the case of iHomma HCS, it really could have been avoided.

According to the documentation given with the smart light, it has only two modes : the “pairing” mode (with a red light) and the “normal” mode, when your lamp has successfully paired and you can change its color.

Well, there is a third, undocumented mode referenced in the app’s code!

If you turn the smart light on and off 4 times in a few seconds span, it is going to display a bright green light.

It can receive commands from devices connected to this network and totally use its own self-broadcasted WiFi.

What’s the passphrase, you might ask?

I found it, hardcoded in an (unused) Android activity and gave the variable a fitting name when I rewrote this part of the code :

Is this real life, is this just fantasy?

Yep, Every iHomma device, turned off and on 4 times will directly be accessible with the passphrase “12345678”.

Even worse, some users using an old version of the application might have paired their smart light this way and still use this passphrase.

Most exploitation scenarios require physical access to the smartlight, and the feature seems to have been deprecated (on the app at least), but such a weak hardcoded passphrase and the possibility that some users might still use this mode is definitely a security concern.

But what I can guess, looking at the application’s permissions, screenshots and descriptions is that all of these apps probably share the same colossal codebase and the same issues.

As I said, I tried to only share with you the most interesting and most concerning things I discovered in this application.

I also chose not to share some information I hope I will be able to disclose in a safe manner later.

As you’ve seen, the software and hardware we analyzed in these articles present at least a few very problematic security issues (no encryption/authentication whatsoever, permissions are very dangerously handled, sensitive data is stored and logged).

I’d like to moderate my remarks and try to guess what went wrong with this IoT device :

First of all, I do not think these devices and apps were designed with malicious intents. Poor security and design choices were made, but I can’t say they were intended.

They seem to have written a huge codebase using all of the SDKs and librairies they wanted to interact with and just changed the main activities and side-menu content for each new app, maybe because of time or money constraints.

All of these elements induced performance, permissions and security issues.

The first risk concerns the device itself, as long as you can reach the smart light’s port 8080, that’s all you need to control it.

For instance, you can just log on a coffee’s WiFi network and just start playing with their smart devices it they are connected to the same network.

iHomma’s applications are a very interesting exploit area : they have all of the permissions needed to be used as a backdoor, steal personal information or spy on their users, they aren’t updated often and their code is messy enough for the chances of it being vulnerable to be high.

Also, since they mostly are the same, chances are that if you find an exploit for iHomma’s apps, it will work for iGlo and Prolight’s software.

SSIDs and networks passphrases are both stored in the application’s local database and inside the device’s memory.

Don’t throw your smart lights away before you properly destroyed their ESP8266 chip!

First of all, avoid buying and using products that are “too cheap to be true”. Unfortunately cuts on hardware and development costs often also means huge risk of security vulnerabilities.

Know the manufacturers you trust and always be suspicious about anything that is going to be plugged to your home or company network.

If you can, consider setting all of your IoT devices in their own Local Area Network with no possible access to the Wide Area Network. You’ll avoid plenty of future problems.

If you can’t, check that UPnP is disabled on your router, that none of your device is set as a DMZ and that you don’t have any useless NAT/PAT rules configured.

It’s not because an application is not malicious that it isn’t dangerous. If your smart light’s application asks the permission to answer and make phone calls or record audio and video, it’s a major red flag.

If you own the same iHomma smartlight that we talked about, you can download the open source Android client I wrote and read the code before you use it :

I’m going to contribute as much as I can on this and try to offer a safe and open alternative to the official clients, you can also contribute on Github by opening Issues and Pull Request!

If a device have at some point been connected to your private network, it might contain private data.

Always try to destroy your old device’s chips before throwing them away. Maybe it won’t make your data absolutely impossible to recover, but it surely will make it much harder to recover.

That’s all for me, I’m finally going to stop being obsessed by a stupid light!

Thanks for reading, take care.

Peace out.

Add a comment

Related posts:

Helpful questions for better product discovery

The goal is to learn not to prove that the product works — Marty Caga “Inspired: How to Create Tech Products Customers Love“ Here’s a simple framework to help product discovery, provide better…

Do People Really Need or Want an Alternative Payment Network at the Point of Sale and Why?

We recently ran a poll among Twitter followers, asking people to explain what makes them interested in paying with crypto (implied, using a decentralized payment network) at the point of sale. The…

Carbon Free Shipping by 2050?

Shipping industry has increasingly been bombarded with ever increasing demands to protect the environment. I could go on how shipping is already by far the most carbon efficient mode of transport…