Smart Security Research Diaries: Defending the Internet of Things.

18th of January, 2026 - The day started with some network troubleshooting and system administration as we forgot to bring our wi-fi router that was earlier acting as a gateway. But yeah, after scratching our heads we were finally able to use one of our laptops as the gateway which really helped us capture all the data frames via Wireshark. Today, our main goal was to get Remote Code Execution on our target. Last time we found a Buffer-Overlfow based Denial-of-Service vulnerability which was obviously not a very critical one, so we decided to expand our horizon this time.

Starting off with the threat model I prepared, I tried to reproduce CVE-2023-41184 on our target. The CVE suggested that an attacker can supply a very high value for the ActiveCells parameter accepted by CreateRules and ModifyRules API endpoints.The firmware doesn’t validate the length of user-input data and assigns a fixed-length buffer on the stack. An attacker can then easily overflow and corrupt the memory, overwrite return addresses, and even control execution flow. This results in the return address being overwritten, which is in the control of the attacker, ultimately leading to RCE. Our goal was very straight-forward. I created the following curl request-:

curl -k -X POST https://10.42.0.153:443/   #Target IP along with port

Content-Type: application/json

{
  "method": "CreateRules",
  "params": {
    "ActiveCells": "9854738642935830928302945700432938423675834239432"
  }
 
}

for which I received the following output-:

{"error_code":-40209}

Now before getting confused and start talking about the error, I first did a bit of celebration as I was one step closer. The ActiveCells parameter, yes, it was an 'ACTUAL' recognised parameter that was being accepted by the API endpoints and was reachable. If CreateRules didn't exist, we'd see something like an HTTP 404 or method not found or in the worst case, a no response. But hey, I got a response, yeah I know it was an error, but a response is a response.

What does error_code: -40209 mean?

There was no official documentation talking about this error code. Because of that, I had almost no other option left than to use AI. Based on our condition, the error came most probably because the parameters were invalid or some required fields were missing. As soon as I read this, I thought of using BurpSuite to intercept some requests and see what data exactly is the server expecting us to send it. But soon after reading the documentation clearly, I got to know that this vulnerability was fixed in firmware 1.3.6 Build 230426 Rel.48373n and our target was updated to the latest firmware. This was when I interpreted that the vulnerability was already fixed and because of that, I was receiving this error code as the developers might have initiated some user-input validation. So we just dropped the work there and moved-on.

The next thing we did was jumping on to another vulnerability which was CVE-2021-4045. The vulnerability was with the camera's uhttpd server. The attacker could send a crafted request to the camera's server injecting a reverse shell command ultimately giving us a Remote Code Execution.

Firstly I checked whether the vulnerability was patched or not and obviously it was patched, it's quite old from 2021 anyways! But still I thought of giving it a try and after some active reconnaissance, I realised that the server neither had any input field nor any web interface, so the reverse shell which I created was actually of no use, like where are we going to inject it? We ended the research with some burgers and coke. While discussing about the outcomes, we concluded that, "KNOWING WHAT DOES NOT WORK IS AS EQUALLY IMPORTANT AS KNOWING WHAT DOES!". Because of this, we ended up with a positive vibe and more enthusiasm to work on the targets.

Stay tuned for more insights and learnings from our research.