Whatever these happen it's 50/50 either an internal debugging feature used when designing the device or intended as a way for customer support to more easily help people.
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.
> Whatever these happen it's 50/50 either an internal debugging feature used when designing the device or intended as a way for customer support to more easily help people.
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.
> a way for customer support to more easily help people
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.
I have done this accidentally at least once - we shipped a full-stack app, and telemetry started lighting up that on certain older phones and browsers (no points for guessing which brand and browser), the release version didn't load. The minifier did something in the release build that it didn't like.
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..
Whatever these happen it's 50/50 either an internal debugging feature used when designing the device or intended as a way for customer support to more easily help people.
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...
> Whatever these happen it's 50/50 either an internal debugging feature used when designing the device or intended as a way for customer support to more easily help people.
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.
> a way for customer support to more easily help people
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.
> So most consumer devices have either a "reset to defaults" feature or a hidden support password.
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.
I have done this accidentally at least once - we shipped a full-stack app, and telemetry started lighting up that on certain older phones and browsers (no points for guessing which brand and browser), the release version didn't load. The minifier did something in the release build that it didn't like.
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..
and "accidentally" they forgot to disable it when releasing
Wouldn't be the first nor the last time someone is asked to ship something and it gets rushed through for reasons XYZ...
This being said makes the situation for an attacker awfully convenient...
Believe it or not, shit happens in the software business.
I know this from personal experience.
Enemy of the state:
- What did you think was going on?
Jack Black: Oh, I thought it was an STO.
- STO?
Jack Black: Standard Training Op.