The article doesn't disclose the value of "sys.rzadmin.password", but this writeup from 2022 does:
https://boschko.ca/tenda_ac1200_router/
Spoiler: it's "rzadmin". And it looks like there are a bunch of other goodies in the firmware, too.
https://boschko.ca/tenda_ac1200_router/
Spoiler: it's "rzadmin". And it looks like there are a bunch of other goodies in the firmware, too.
This being said makes the situation for an attacker awfully convenient...
I know this from personal experience.
- What did you think was going on?
Jack Black: Oh, I thought it was an STO.
- STO?
Jack Black: Standard Training Op.
So after a quick test, it was decided to deploy the debug version of just the frontend as a bandaid. Next day we saw we managed to deploy the debug version of the backend with admin stuff like this as well..
I remember when a backdoor was discovered in the most popular brand of keylogging devices[0], likely added there in case someone forgot their password and reached out to support.
[0] https://old.reddit.com/r/cybersecurity/comments/jw6k5v/backd...
This is my guess. People don't like it when a device they have turns into a brick of e-waste because they can't remember their password. So most consumer devices have either a "reset to defaults" feature or a hidden support password. Even enterprise routers and switches often have this.
One of those is sensible, and one is not. Put a recessed "hold to reset" button on the device, problem solved, no backdoor required or desired.
The problem with this is, everyone who builds an intentional backdoor will also claim that it's this.
Sufficiently advanced ignorance is indistinguishable from malice, and sometimes needs to be treated as if it were malice.
I think sufficiently explained by incompetence over malice applies here. Some nefarious three letter agency having a backdoor like this is pretty pointless anyway.
Unless you’ve enabled remote management you can’t even get to this backdoor from a physical network perspective.
And then you change some router settings which really aren’t a magical access point into your devices in your home. My PC isn’t just going to magically allow you to browse the file system just because a malicious actor got on my local network. They can’t intercept anything moving over TLS.
Not saying it’s good to have that kind of access, but I think at the scale of “typical home network of consumer devices” the utility and blast radius is pretty limited. Go ahead and launch a DDOS attack on my printer and use up my ink cartridges, I guess.
I think we could stop reflexively defaulting to “incompetence” when the end result just as easily resembles a deliberate exploit. Plausible deniability is an extremely effective cover when it’s smartly applied.
I’m not disputing any of your specific technical points; my cynicism is thematic. Even when I try to muzzle it, it tends to get through. The parent comment, though short, is dense with implications about cheap gear, opaque firmware, exposure surfaces I think deserve more sustained attention.
* A quick, generic, maybe sub-ideal list to harden my point.
“Never attribute to malice that which is adequately explained by stupidity.”
It's really a matter of context. Security people tend to only be involved when things are already nefarious where as boring old normal people like us see get to see the mundane everyday mistakes so not just the nefarious bits.
It's possible the backdoor is deliberate, I have no idea in this particular case, but the more likely situation, absent more information, is that someone who is earning a middling wage just added the "feature" and didn't think about the security implications because no one cares about computer security.
I work heavily with security-conscious clients where vulnerabilities would be catastrophic. And we are talking high profile clients that are juicy target for attacks.
My experience is still that the vast majority of vulnerabilities are accidental rather than due to malice.
And when I say “vast”, I mean the so heavily slanted in favour of “unintended” that it’s not even comparable.
> It's really a matter of context. Security people tend to only be involved when things are already nefarious
I’m guessing you’ve not worked with many “security people”?
You’d be surprised how much of their day-to-day is mundane.
I know their day to day is just as mundane as the rest of ours it's their "Step 1" approach that i've seen to be entirely different. I assume it's probably a software bug, they assume it's an exploit.
They're not mutually exclusive.
I suspect you and the security team are arguing the same thing but with different terminology.
When vulnerabilities (which, in the vast majority of cases, are accidental) are published, or when static analysis tools review code, you'll get a description and a severity score. That description will broadly describe how, if possible, that vulnerability can be exploited.
Working for an in-house security team basically just means you're a risk assessor. And the way you assess risks is to look at the potential consequences of those risks. Which means looking at how bugs can be exploited.
But none of this means those vulnerabilities were placed in the code intentionally and with malice. It just means that someone else who is malicious could, theoretically, exploit those vulnerabilities. And if the risk of that is greater than the risk appetite of the business (as will typically be the case), then they'll feedback to you that there is an exploitable vulnerability that you need to patch.
Looking at the IT security landscape we see every layer, every product category if not every product itself riddled with issues at one point or another. At the same time the incentives to put those security issues in are huge, and we know attackers work systematic, creative and persistent to introduce those weak points.
Security is hard and many bugs certainly happen due to mistakes, but I wouldn't assume that all of those security mishaps stem from an endless series of blunders from "stupid" programmers.
So I would go with “Never attribute to ignorance that which is adequately explained by malice.”
The saying doesn’t mean that all vulnerabilities are blunders. It means we shouldn’t automatically assume vulnerabilities are nefarious.
If closer inspection proves beyond reasonable doubt that it was placed there deliberately and maliciously then that’s different.
But the point is most vulnerabilities are blunders so it’s better to assume that until proven otherwise.
1. You can generally get a feel for the intent by the developers reputation.
2. Look at the code that changed as part of the same commits. Eg was the vulnerable code included as part of the same commits as an unrelated change elsewhere in the codebase? If the latter then that’s hugely suspicious.
3. How is that vulnerability encoded? Eg is a bug parsing logic that was discovered via fuzzing? Or is it obfuscated code? Clearly the latter demonstrates intent.
4. What’s the nature of the vulnerability? Is it simply a dumb unhandled bounds or allocation error in C? Or is there an entire path of code that opens network ports? The latter also demonstrates intent.
5. How did the authors behind the vulnerable code react to the big report? Did they rush a patch out? Write more robust tests? Work with the community? Was there any transparency? Or was the issue quietly brushed over? This is least reliable indicator but it does demonstrate trustworthiness.
With these and other indicators you can build a body of evidence that can make an argument for or against a particular vulnerability being malicious. And while I do agree that in some cases it isn’t going to be clear cut, in most cases the evidence, or lack of, will be enough to justify an opinion.
The key part of my earlier statement being “beyond reasonable doubt”. Ie I’m not talking about a mathematical proof here.
I think it's true to some extent that a lot of the backdoors really are just stupidity, like debugging tools put into prod for convenience. Rather than suggesting that it is genuine malice, maybe the right thing to say is that for security, it doesn't matter whether or not it is malice for most purposes. If it did, it would give more incentive to do as much as possible to disguise malicious backdoors as mistakes.
Plausible deniability is important.
A lot of the stuff I worked on already had glaring issues like that without me having to add it..
So in English it would be like "dcadmin". Maybe they outsourced it to someone doing "gute Deutsche Wertarbeit", or it's a leftover from some agency having had their fun, or smoke&mirrors from whomever for whichever reasons.