Hacking Google's HVAC Systems
cylance.com
cylance.com
Original ICS-CERT Advisory: http://ics-cert.us-cert.gov/advisories/ICSA-12-228-01
(Edit: Disclaimer, I work for Cylance.)
Let me quickly clarify that I'm not anti-Windows, it was just a double-take to see it used as a workstation for security research like this (though I'm using the word 'research' lightly). Strange article all around, lots of it caught my eye.
“We’re not going to say Niagara is secure”
What I find most worrisome about this is that it can enable attackers to access internal video feeds. Seems like an excellent vector to grab someone's credentials.
Also, ironically, one of the people mentioned in the WaPo article who discovered these vulnerabilities used to work for Google.
edit: Aaron's reading comprehension is evidently VERY LOW today ;)
> (We don’t know what this button does… and we were afraid to test it :-))
How do you hack HVACs and not know what an after hours button does?
(it extends operation of the system so if you're working after hours, you won't freeze/boil to death, without wasting energy running the HVAC out of hours when no-one is there.)
Note that it doesn't matter whether Google is cool with your actions, after the fact. What matters is whether the local prosecutor is cool with your actions, or whether he needs an extra easy slamdunk conviction.
Kids: do not do this at home.
In a situation like this, I'm going to guess that "facilities" was run as a fiefdom and its network presence was obfuscated from infosec staff. Or in the worst case, infosec was told to leave it alone...
When you consider these system have complete control over many environments - signal distribution, HVAC, occupancy sensing, motor control for things such as dropping 3 tonne screens from roofs, even occasionally extending to physical access control - this is a very scary thought.
You certainly see lots of examples of lawsuits over changing numbers in URLs, so you'd figure downloading configuration info from a machine and then reversing a password would definitely provide grounds for a suit.
Nice to see Google not overreact here.
He worked there for almost 3 years: http://www.linkedin.com/pub/billy-rios/3/a7a/5b1
Before that, he was recognized for "ongoing and sustained contribution to the security of Google's applications": http://www.google.com/about/appsecurity/hall-of-fame/archive...
http://www.google.com/about/appsecurity/reward-program/
(I work for Google.)
When I was at Google Sydney a few years ago for an internship, the AC died prompting an interesting response. The server temps were rising to unsafe levels and the AC wasn't expected to come back in time. The MacGyver solution was to buy portable AC units and pump the heat into the coder's workspace. That was a distinctly unpleasant afternoon =]
If the machines weren't important for production or productivity I'm certain they'd save us the hassle and shut them down. If nothing else, abuse of this office's AC system could severely impact the productivity of the office and spring dozens of people into action.
Whilst not under the usual purview of the rewards program, I'd still think it's noteworthy of recognition.
The aircon was clearly over capacity then, and there were portable air conditioners scattered around the floor I was on, with flexible ducting feeding up to the return ducts in the ceiling.
I assume they've fixed that by now, I know they've gone through at least on remodel since.
For example, we don't want physical security or the police second-guessing the intent of someone trying to sneak into one of our buildings - so we set a very clear scope for the program, pragmatically focusing on our user-facing applications and excluding things such as attacks on our facilities and corporate infrastructure. It's a broad exclusion, but it's hard to come up with something finer-grained yet clear enough.
In the same vein, we ask researches that they don't go after any systems unless it's perfectly clear that the application is owned and operated by us - for example, because it's in an IP range registered to us. Again, while this may be more limiting than we'd like, it protects the community against overly litigious parties if the system proves to belong to somebody else.
In several unusually serious cases, we have made case-by-case exceptions and have paid external researchers for nominally non-qualifying bugs; but it's a tricky balance, and we use this power very cautiously.
Source: I authored a good chunk of the current rules for Google VRP ;-)
However, this case is different. While it was absolutely an attack on Google's infrastructure, it was discovered through a vulnerable external web service. Even though the control panel application is not a Google product, it stores user passwords in clear text as decoding it seems to be trivially simple. At the very least, Google should be responsible for picking third party vendors that store passwords using one-way hashes ;).
If you ask me, this should be one of those special cases!
There are millions of rarely updated devices... printers, security systems, fire alarms, cameras, etc... the list goes on and on.
That's a pretty bold assumption :)
http://internetcensus2012.bitbucket.org/paper.html
They ran their own botnet to map the internet, and then discovered other malware already running on insecure home routers.
Did Google write this software? If not, it's kind of like writing "Google locks vulnerable to lock picks". Well yeah, just like every other pin tumbler lock ever made.