When the zombies began rising from their graves in Montana it had already been over 30 days since IOActive had reported issues with Monroe Electronics DASDECS.
And while it turned out in the end that the actual attacks which caused the false EAS messages to be transmitted relied on the default password never having been changed, this would have been the ideal point to publicize that there was a known issue and that there was a firmware update available, or would soon be to address this and other problems… maybe a mitigation or two in the mean time right?
At a minimum it would have been an ideal time to provide the simple mitigation:
“rm ~/.ssh/authorized_keys”
Unfortunately this never happened, leading to a phenomena I like to call “admin droop”. This is where an administrator, after discovering the details of a published vulnerability, determines that he’s not vulnerable because he doesn’t run the default configuration and everything is working and doesn’t bother to upgrade to the next version.
… it happens…
In the absence of reliable information other outlets such as the FCC provided pretty minimal advice about changing passwords and using firewalls; I simply commented to the media that this was “inadequate” advice.
Eventually, somewhere around April 24 Monroe, with the assistance of CERT begin contacting customers about a firmware fix, we provided a Shodan XML file with a few hundred vulnerable hosts to help track them down. Finally it looked like things were getting fixed but I was somewhat upset that I still had not seen official acknowledgement of the issue from Monroe but on June 13 Monroe finally published this /wp-content/uploads/2013/07/130604-Monroe-Security-PR.pdf
security advisory where it stated “Removal of default SSH keys and a simplified user option to load new SSH keys”, ok its not much of an “announcement” but its something and I know it says April 24, but both the filename and metadata (pdfinfo) point to cough later origins…
Inside the advisory is this wonderful sentence:
“The company notes that most of its users already have obtained this update.”… That sound s like something worth testing!
Then it happened, before I could say “admin droop”…
Found/Vulnerable hosts before we reported the issue: 222
Found hosts After the patch was released, as found by a survey on July 11: 412
|
Version numbers
|
Hosts Found
|
Vulnerable (SSH Key)
|
|
1.8-5a
|
1
|
Yes
|
|
1.8-6
|
2
|
Yes
|
|
2.0-0
|
110
|
Yes
|
|
2.0-0_a01
|
1
|
Yes
|
|
2.0-1
|
68
|
Yes
|
|
2.0-2 (patched)
|
50
|
No
|
unreachable 180
While most users may have “obtained” the update, someone certainly didn’t bother applying it…
Yep… it’s worse now than it was before we reported the issue in January, and everyone thinks everything is just fine. While I’m sure this would still be a problem had a proper security notice been issued.
I can’t say it any better than these awesome folks over at Google http://googleonlinesecurity.blogspot.com/2013/05/disclosure-timeline-for-vulnerabilities.html : “Our standing recommendation is that companies should fix critical vulnerabilities within 60 days — or, if a fix is not possible, they should notify the public about the risk and offer workarounds.”