5 ms·

I'm having a hard time understanding how this could happen too. It would have to be that looking up the root account enabled it, maybe users go dormant or some

I'm having a hard time understanding how this could happen too. It would have to be that looking up the root account enabled it, maybe users go dormant or something, and this was a way to readd them? then once it was enabled it defaulted to a blank password, but you would think that it needs sudo to enable root in the first place.

pishpash 9y ago
Not only enabled it but actually set an empty-string password. Usually the stored hash for a disabled account is not in the hash space, so it was either overwritten, or root account password was actually empty string out of the factory. That and the enabling of the account both point to debug code accidentally left in (or intentional backdoor by the disgruntled).
inetknght 9y ago
Login screen is probably already running as root in the first place, so it already had permission to enable shell/GUI access
skygazer 9y ago
Blank password is not necessary. Any password provided on initial attempt WILL BECOME the root password. Blank is being circulated simply because that's what was discovered first. Edit: Which also means it's possible to "secure" a vulnerable (unexploited) machine simply by attempting to log in as root with a long random password.
- cherimoya 9y ago
  So by my logic - if you tried this exploit and it failed the first time, then worked the second time: No one else has tried it before you. Otherwise it would either have worked the first time (if you guessed the same pass) or not worked at all (if the first time it was tried a different pass was used). Or is this not a permanent password set?
  - FabHK 9y ago
    If that's true (and certainly sounds plausible from what is known so far), that's a very valuable heuristic.
  - skygazer 9y ago
    Well, I suppose if someone had exploited your system with this, they could probably install some remote access tool, and then disable the root account and unset the password, and remove all evidence they were there. But, if you don't have Screen Sharing or Remote Management enabled and exposed to the WAN, you're probably safe unless someone untrusted had physical access. It's hard to know how long this vulnerability was "known." The initial report on Nov 13th looks second hand, so it may have been circulating earlier.

pishpash 9y ago

Not only enabled it but actually set an empty-string password. Usually the stored hash for a disabled account is not in the hash space, so it was either overwritten, or root account password was actually empty string out of the factory. That and the enabling of the account both point to debug code accidentally left in (or intentional backdoor by the disgruntled).

inetknght 9y ago

Login screen is probably already running as root in the first place, so it already had permission to enable shell/GUI access

skygazer 9y ago

Blank password is not necessary. Any password provided on initial attempt WILL BECOME the root password. Blank is being circulated simply because that's what was discovered first. Edit: Which also means it's possible to "secure" a vulnerable (unexploited) machine simply by attempting to log in as root with a long random password.

cherimoya 9y ago
So by my logic - if you tried this exploit and it failed the first time, then worked the second time: No one else has tried it before you. Otherwise it would either have worked the first time (if you guessed the same pass) or not worked at all (if the first time it was tried a different pass was used). Or is this not a permanent password set?
- FabHK 9y ago
  If that's true (and certainly sounds plausible from what is known so far), that's a very valuable heuristic.
- skygazer 9y ago
  Well, I suppose if someone had exploited your system with this, they could probably install some remote access tool, and then disable the root account and unset the password, and remove all evidence they were there. But, if you don't have Screen Sharing or Remote Management enabled and exposed to the WAN, you're probably safe unless someone untrusted had physical access. It's hard to know how long this vulnerability was "known." The initial report on Nov 13th looks second hand, so it may have been circulating earlier.