While that's true, the correct way of creating deniable backdoors is to simply write insecure code. The best way to detect something like that is essentially what this article tries to do: a comparative analysis of vulnerability frequency. It doesn't do a great analysis, but it is the correct approach to thinking about the problem.
Why would deniable backdoors be visible in vulnerability frequency? In principle, you only need a single back-door. Perhaps you need to chain some vulnerabilities and build in some redundancy.
According the article, this had 100 vulns, which was signficantly worse than comparable vendors. If we assume that to mean comparable vendors have 50 vulnerabilities, we would have to believe they included 50 vulnerabilities intentionally.
This entire thing reminds me a little bit of the Linux Backdooring Attempt of 2003. A tiny dropped symbol that didn't look like a backdoor and just sloppy at first, but actually...
even better if the insecure code takes advantage of absolutely plausible coding mistakes/language quirks. see e.g. underhanded C contest for very subtle and deniable ways to provide nefarious functionality.
If I was an assigned Chinese official supervising Huawei (like every Chinese business with 50+ employees), would I say, "go write one backdoor?" Nope, I would say, "be sloppy and maybe a few will go undetected."
That’s conspiracy theory logic. The fact that it doesn’t look like a backdoor is evidence that it’s a backdoor? It is impossible to disprove something like that.
Dahua at first ignored ReFirm’s inquiries, then claimed the vulnerability was a simple error that had been fixed in the latest update. But when ReFirm looked through the updated firmware, they still found the same backdoor — just relocated in a different place in the code. (Huawei had done the same thing).
I'm not saying that it is evidence that it is a backdoor. I'm saying that it is indistinguishable, because that's how you would do things if it were a backdoor as well.
The correct way to try to discriminate is to look at how frequent they are, and maybe how they're patched.
No, the logic is not "it doesn't look like a backdoor" but "backdoors and vulnerabilities look very much alike". And given the story of vulnerability being shuffled from place to place instead of removed, the probability of it being deliberate raises. Surely, it can be just gross incompetence, but you don't want grossly incompetent vendor any more than you want a spying one.
If I was told to put a backdoor in my product and make it plausibly deniable, it probably would look like a vulnerability in a very obscure, rarely used and non-documented function.
Yes, there's no real way to know. But then again, is "our products are full of security vulnerabilities" that better than "our products are full of backdoors"? I think being hacked by a random criminal from Moldova is not much better than being watched by a Chinese Army officer from Beijing. You probably want to avoid both.
I agree. I actually spoke with the ReFirm guy ~2 years ago when they first found the Dahua vulns. I don’t see any new data or proof in this report. Also, as I recall the vuln was in a binary called ‘sofia’ or ‘sonia’ that was a modified version of what was possibly the Huawei POc code that shops with the SoC’s. It was unclear if it was really a ‘Huawei’ vuln or a Dahua one.
Might have some minor details wrong, working off memory, would have to check my notes...
