[1] "[...] it turns out the error was caused due to buggy code and nothing I was or wasn't doing wrong." - if the code is so obviously buggy and the backdoor part isn't obviously a bug, the developers are probably just being sloppy, not malicious (bad or rushed development).
I think it can go the other way in a couple of cases though:
A) WD (by a government) or its staff (by WD management) were ordered to put in the backdoor, but didn't agree with doing so, thus made it obvious in the hopes that it would be found.
B) A backdoor that is found but written off as sloppy development is less damaging than a bug that if found and analysed looks deliberate (because bad development practices are hardly new for hardware manufacturers). _Potentially_ makes exploiting it less risky as well - if it's an obvious or known thing, the attacker could be anyone. If it's a subtle, undisclosed bug (that hasn't been used against many targets), that suggests, to some extent, the involvement of whomever could arrange for the bug to be placed there.
It probably isn't deliberate, but that possibility certainly isn't excluded either, so I'd be cautious about treating this as a hard and fast rule.
Wow. Don't think I've had a comment with negative points on HN before. Curious as to why the downvotes. I was attempting to point out that I did not consider what I said in the original comment to be a hard and fast rule.
Is the objection that the way I said it was too disrespectful (no offense was intended, hence the :-) )? Disagreeing with the original statement (it might have downvotes too, but maybe more upvotes are hiding that)? Too obvious? Something else?
If you feel compelled to put a smiley face after a sentence to make it more agreeable, it's a sign that you were uncomfortable with the tone of the sentence. Adding a smiley just comes across as passive aggressive or condescending. Just rewrite the original sentence so that you're comfortable with the tone, and omit the smiley.
Having identified a backdoor in a major product myself, the eventual meeting with product managers led to a clear and frank discussion about the cause. That being, it was there because it was expected only "certified" engineers would know about it.
The initial view was a hotfix that just changed the hardcoded password, because senior management felt lightning would not strike twice.
I found the password (actually, it used an s/key generator[0]) by similar means to this write up. It didn't matter if I "found" it again because at this point I was in direct contact with them and considered "trusted". The principle that someone else could just as easily find it gets back to the lighting striking twice argument, and was refuted for a long time. Eventually they agreed to change behavior but it took a while.
The timeline on the below link only refers to one specific incident, the time discussing this in principle went for roughly 11 months, and left me extremely disillusioned with the concept of responsible disclosure.
By the same token, if there's little accountability on the project, one might intentionally leave a debugging mechanism in for dubious purposes because they feel they have deniability if/when it's found. "Oh sorry, just a debugging thing I accidentally forgot."
It's just a rule of thumb, not an absolute. I tend to believe most developers are just doing a job (good or bad), and not out to get someone. So to me it's a numbers game where one explanation seems much more likely.
It's not that difficult to put in something much more subtle and still have deniability if the intent was malicious.
I think you give these guys way too much credit. It's more likely some clueless PM simply asked a clueless junior developer to add a backdoor and due to lack of good processes nobody ever reviewed that commit (assuming those guys even use version control).
If a recent CS great doesn't have common sense, they chose the wrong career path. That individual would probably be equally bad in other industries though.
Ah, yes; the Russian defense. I know it well. How did it go?
"The hard-coded backdoor that was found can't be a hard-coded backdoor, because Western Digital would never be so crass and incompetent as to put a hard-coded backdoor hidden in such a way that a security researcher would find it and attribute it to them."
How can one argue against such flawless logic when it even has an aphorism to describe it?
The keyword in the rule of thumb known as Occam's razor is neither that the explanations be simple or complex, but that they be adequate to a knowledgeable person, and that given two (or more) highly adequate explanations -- one simple and one (or more) complex -- that the complex ones be cut in favor of the simplest one.
The original statement was "Never attribute to stupidity alone that which is adequately explained by both stupidity and malice."
It seems to me that both are adequate explanations. One explanation requires one factor (stupidity), and the other two factors (stupidity and malice). The one factor explanation would seem to be the simpler of the two explanations.
It seems to me the original statement reverses the logic of Occam's razor by preferring the more complex example. I think my point still stands. The original statement makes as much sense as trying to reverse Occam's razor.
If someone actually wanted to implant a "secret" backdoor it would be disguised as a subtle bug and/or obfuscated in some way.
"Never attribute to malice that which is adequately explained by stupidity." Hanlon's Razor - https://en.wikipedia.org/wiki/Hanlon%27s_razor
[1] "[...] it turns out the error was caused due to buggy code and nothing I was or wasn't doing wrong." - if the code is so obviously buggy and the backdoor part isn't obviously a bug, the developers are probably just being sloppy, not malicious (bad or rushed development).