SNHACK Attack: How Hackers Could Turn Your Smart Pet Feeder into an All-You-Can-Eat Buffet

Recently a Smart Pet Feeder landed in my home. Out of curiosity, I have decided to check how secure this IoT device is and also extended this “research” to another brand and model. So far, I have checked the following ones that were purchased on Amazon and got some interesting results. ??

The DUT (Devices Under Test)

As you can see from the images above the DUTs are the so-called BALIMO LENA and the PETLIBRO remotely-controlled IoT Pet Feeders. Both have an embedded camera, speaker and microphone.

Looking closely at the PETLIBRO packaging we can already notice the presence of a FCC ID.

Looking at the FCC database we can clearly see its internal PCB: https://fcc.report/FCC-ID/2A3DE-PLAF203 and therefore we can already see what SoC is installed (i.e. a classic Anyka used in many IoT Cameras) and potential pins for UART and JTAG!

The Mobile Apps

Both DUTs do rely on mobile apps for controlling them remotely: BALIMO relies on the official TUYA App called SmartLife (which has remained out of my scope for now), meanwhile the PETLIBRO relies in its PETLIBRO and PETLIBRO LITE apps.

Since my investigation was more focused on the hardware side… I did not spend any time looking at the APKs nor the cloud APIs (which usually are still an interested target to check. Just saying ??). However, out of curiosity I did ran a quick scan with MobSF and here you can see the results… Overall no big red flags…

Hardware Teardown

Now that I got some ideas of what to expect from the hardware side… I have started the teardown of the DUTs.

Both devices mount an Anyka SoC (System on Chip). To be precise a AK3918EN080 which is a known SoC usually installed on consumer IoT Cameras. On Github there are plenty of repositories were fellow hackers played with it. ??????

The Bad, The Good amp; The Ugly

Now the questions are two:

1)????? Where the firmware is stored? (we will see later on is in the SPI Flash)

2)????? Is there an UART interface enabled?

Looking at the images above we can clearly see the presence of interesting pins, marked with the usual UART values (i.e. RT, TX, GNS, in the case of PETLIBRO).

The next step was to grab the #BRUSCHETTABOARD (https://github.com/whid-injector/BRUSCHETTA-board ) & #PIZZABITE (https://github.com/whid-injector/PIZZAbite ) and check if there is the UART console enabled.

To my un-surprise… in both DUTs I was able to get the usual UART console running at the standard 115200 bps. However, I was welcomed by a restricted console asking to login with user/pass. At this point I could have used multiple approaches to get into… but I preferred for the faster one… dump the SPI > Extract Firmware > steal the root’s shadow hash > crack it with hashcat > profit. (I followed this approach also because the device has Telnet open on port 23/TCP open by default. ??)

At this point, I just needed to use again #BRUSCHETTABOARD with Flashrom to dump the SPI flash memory and use binwalk to check/extract it. The images below are self-explanatory.

In the case of BALIMO, I opted to use the SOP8 clip and dump the firmware directly from the PCB. Instead for the PETLIBRO I decided to physically remove the SPI and read it with #BRUSCHETTABOARD and a SOP8-to-DIP8 Socket.

In both cases, I was successfully able to dump their firmware and exctract the contents with Binwalk. As usual, for this kind of consumer IoT devices, I was presented with a classic squasfs/jffs filesystems structure that were easily parsed/extracted by Binwalk. So far so good.

Automated Firmware Analysis

Since I had access to the firmware, but not much interest in a full bug-hunt I quickly ran EMBA and Bugprove to get a grasp of the security of these two DUTs… and the results were not a surprise… usual IoT consumer devices where security is not the first (and not even a second) priority…

One interesting feature of Bugprove is the 0day detection/hunting feature… which actually found some interesting findings automatically (that should be manually checked, time permitting).

Firmware Analysis

With the extracted firmware at my disposal, I was able to look for some low hanging fruits. Here a quick self-explanatory overview.

As you see there are plenty of stored credentials, Tuya cloud token, Wifi settings, etc… but what I was looking for primarly was the root’s shadow hash: root:kRVZynxtm9Jac:0:0:99999:7:::

Here, I noticed immediately an interesting thing… BOTH targets (i..e supposedly being from TWO different vendors, using different mobile apps and having a different main PCB… share the same root hash! ??????

With that hash in my hands, I quickly fired hashcat and left it running all night… the day after I was welcomed by a lovely result. The root password: AK2040jk? ??

Now with this important piece of information we can check with Nmap if Telnet is open (i.e. which was also confirmed being enabled with the command “telnetd &” contained in the fw’s file /etc/init.d/rcS).

At this stage of my investigation, it was proved that both DUTs can be reached from LAN and access as root through telnet. A legit question at this point would be… What about Internet? Well, we will see later on this article that Shodan can help us figure this out. ??

At this point is clear that both vendors and products could be easily hacked remotely and become part of a IoT botnet in pure Mirai style. But again, this was not the goal for the moment.

The SNHACK ATTACK explained

Now that we have two ways to interact with the DUTs (i.e. both UART and telnet) we can start playing around with the live console. My goal, at this point, was to figure out a way to trigger remotely the feeder servo motor in order to overfeed the victims’ pet (i.e. reason why I called this article SNHACK ATTACK) ??.

The initial approach was to hunt for some GPIOs that at-rest are set to a 0 value and when the user triggers the feed routine it will change to value of1 and thus enable the servo motor.

During the investigation I also started checking the main ELFs involved (i.e. ak_tuya_ipc, feedwatchdog, etc.) with Ghidra and IDA but I ended up wasting too much time and eventually focused on another strategy: checking for logs or debug information.

I first started deploying a cross-compiled version of tcpdump on the DUT and then tried to dump some packets while triggering the feeding function through the mobile app.

As you see the network dump was not very useful, lot of encrypted traffic encapsulated into UDP stream and lot of TLS traffic, both going to the Tuya Cloud infrastructure. As I already mentioned, I intentionally avoided dealing with Tuya cloud and APIs because only this topic would take days and days of checks and I am a lazy and busy hacker nowadays, so I will leave to some of you the pleasure of playing with this. ??

While looking around dmesg logs, uboot logs and the debug information printed on screen through UART while triggering the feeding function… I noticed the following debug data:

It seems that the servo motor is NOT controlled through GPIOs but through a serial connection (note: at this point I could also have checked the PCB to understand if there was involved an external driver connected through serial connection on the SoC… but at the end I didn’t need to).

At this point, the challenge was to understand what was the device name related with this serial connection… cross-checking the list in /dev/ together with the U-boot logs… I quickly realized that two serial ports exist: /dev/ttySAK0 (i.e. our UART serial console) and /dev/ttySAK1.

The next step was to replay those packets to that serial connection and hope ??

#Magic command for triggering 1 time the BALIMO feeder servo motor

echo -en "\xff\xff\x01\x01\x00" > /dev/ttySAK1

#Magic command for triggering 1 time the PETLIBRO feeder servo motor

echo -en "\x55\xaa\x03\x01\x00\x01\x01\x05" > /dev/ttySAK1

This was enough for a PoC. However, if I will have time, I will reverse engineer the serial protocol to forge the correct packet to trigger an max feeding action. For now, I am ok with this. For the overfeeding attack I just need to sending the same packet in loop and I reach the same goal.

Real Case Scenarios

Arrived at this point, I was enough satisfied to stop hacking these DUTs… mark these IoT Pet Feeder as total crap from a security standpoint… when I started wondering if someone ever got hacked through them and if there are exposed devices on Internet…

This is what I found…

1)????? On Reddit some PETLIBRO owners reported being hacked ??

2)????? A quick search on Shodan return couple of hundreds of potential DUTs online… after a quick check it was confirmed some of them being exactly the same devices… ??

Conclusions

Am I done? Of course not. There are plenty of entry points and attack vectors to check. I will drop here a list of things I would probably check once I will have more spare time. Maybe some readers will take over and play around with this funny NotSoSecure Pet Feeders! Happy Hacking Folks! ??????

·???????? Tuya DB decryption

·???????? Tuya APIs

·???????? Extract Video Stream

·???????? Extract Audio Stream

·???????? Inject Audio

?

WANNA BECOME A CERTIFIED HARDWARE HACKER?

The Offensive Hardware Hacking Training is a Self-Paced training including Videos, a printed Workbook and a cool Hardware Hacking Kit. And... you get everything shipped home Worldwide! For more info: https://www.whid.ninja