As a software engineer for DiliTrust, I think software security as a primary feature for any kind of product or software. Every time we heard a story about any kind of security flaw, we take it seriously: how is that possible? Am we directly or indirectly impacted?
Well, I guess I wasn’t yet prepared for my last discovery.
Since I got my first home automation device: a Philips Hue set, I really like the idea of handling devices remotely, or locally from my phone or even my voice. That’s why I also bought some sensor devices from Elgato, to track temperature, humidity and air quality all around my flat.
Every device I ever choose was HomeKit compatible, and I never intended to use any of my devices remotely. I do not have any concentrator to make HomeKit available from anywhere, and I feel confident that my devices are pretty much secure. I suppose, maybe wrongly, that Apple do impose some rules to make the device secure, and also make sure that their own implementation of HomeKit is quite secure.
I know that HomeKit already had some security flaw in the past, and may have some in the future, but I’m pretty sure Apple will always correct them.
I adopted Newton in June 2016, and he’s adorable… well… most of the time. But since we’ve got him neutralized, he became trapped in gluttony. Incapable of getting himself regulated with food, we had a pretty bad time trying him not to eat more food that he needs.
In that context, I got seduced by an automatic feeder like we can find on Amazon. The trademark HoneyGuaridan was getting very good reception and comments from many users, and their last model, the HoneyGuaridan S25 was very seducing!
Indeed, it was one of the only models that allowed me to program 10 meals or more a day! Perfect to make my cat more regulated about food. Last tinkle in my ear: The device was getting setted and triggered with a smartphone, it was a complete IoT device!
I received the device about three weeks ago, and my cat adopted it very quickly!
Newton, claiming for food
Despite a buggy application, the machine works very well, and my cat gets less obsessed about food.
Plus, the setup workflow made me fairly confident: I had to create an account, and then it seemed like we’re authenticated all the time within the app.
But still, with some very nasty bugs, the app gave a very bad user experience, and I decided to reverse-engineer their API to make my own application, with less features, but also less UI bugs!
I used Burp Community Edition as an HTTP proxy to catch every requests sent by the application ; and find out how they’re built.
The application communicate with many differents servers:
fr.dev.alnpet.com, but also
126.96.36.199 to send some report data over a security layer.
us1.dev.alnpet.com does not have any security layer, and make data transmit without TLS or SSL. It means that it’s vulnerable to man-in-the-middle attacks, and that the password used for signin and login is sent with no encryption at all, making any attacker able to intercept it, and read it!
But another intercepted request I got tinkled my mind: I was not able to see any authentication cookie, representing my current session, and declaring the permission to perform a feed request, or any modification on my device schedule.
I immediately tried it with
curl: Just using my machine unique ID and the url, BIM, my cat got a new meal, right from my command line interface, and without any session created.
This is crazy. At this moment, I realize that barely anyone could empty my feeder from anywhere in the world and/or make my cat obese!
My first reaction to that discovery was to remove the Wi-Fi settings from the machine, making sure it’s not anymore Internet connected. Of course I tried the magic request to prove that my machine was offline, and therefore more secure.
But that solution made the machine unusable: impossible to change the schedule or trigger a meal from my phone anymore. So I decided to continue the reverse engineering of my machine in order to implement my own secure API to use it! (crazy right?)
That allowed me to look the way my cat feeder was communicating with the outside world.
I found out that the only address it was communicating with was
188.8.131.52 corresponds to alnpet.net. I do recognize the feeder on this website, but It’s a more advanced one, with a camera, and more advanced feature. Hum, weird. And the preorder link bring to KickStarter homepage. Oh boy, what am I getting myself into? I do not know what link there is between HoneyGuaridan and Alnpet. Are they even the same?
Well, let say that this IP has been banned from my Raspberry Pi
iptables -A INPUT -s 184.108.40.206 -j DROP iptables -A FORWARD -s 220.127.116.11 -j DROP iptables -A OUTPUT -s 18.104.22.168 -j DROP
That make sure my machine is still offline, while connected to my Raspberry. The next step would be to imitate this server to make my machine thinks it’s communicating with Alnpet API, despite it would be mine.
For now, I’m still at the reverse engineering phase in order to understand how I can communicate with my device. It’s not the easiest part; let hope I succeed.
And lesson learned: I will always challenge any new device that connect to my network from now on.
Am I getting a little bit paranoid? Yes I am!