A few of the more uninformed, but more vocal, readers (less than .2 percent of those who read the story, by the way) howled in protest. Google Analytics does nothing more than aggregate page visitors, they argued. Surely, there’s no way it could give someone outside the Obama camp access to one of the more popular websites in the .gov domain.
To use Google Analytics, webmasters call up a javascript file hosted by Google called urchin.js. Google engineers wrote the program and they control what it does. It is granted precisely the same read and write privileges on Change.gov’s administration page as a piece of code written inhouse. “By referring to javascript that’s hosted elsewhere, you’re basically at the mercy of that other organization, which is in this case Google, to not do evil with it,” says David Campbell, a security consultant and a leader of the Open Web Application Security Project (http://www.owasp.org/) (OWASP). “By Change.gov pointing to javascript from somewhere else, that vulnerability is there.”
Campbell and three other website security experts interviewed for this story say it would be trivial for anyone with control of the urchin.js file to hijack authentication cookies or other session variables used to validate users accessing the Change.gov administration page.
Dinis Cruz, an OWASP board member and director of advanced technologies for source code assessment firm Ounce Labs, says such exploits could prove especially effective if combined with attacks on browsers or network infrastructure. “If that urchin.js can be controlled by somebody with malicious intent (and with the latest DNS exploits (http://www.theregister.co.uk/2008/08/06/kaminsky_black_hat/) they don’t even need to control the google server), then the content of those Obama sites could be manipulated,” he writes in an email to The Register. Besides using a rogue urchin.js to steal session cookies or sniff data typed into forms, Cruz envisions other, more exotic attacks, among them one called a cross site script proxy, which essentially causes the attacker to control a user’s login session. “If I wanted a backdoor into the website, this would be one of the best ways to do it,” Cruz says. “It would allow somebody who knew about this to drop a payload in a way that almost wouldn’t be detected.”
Where the four disagree is how easy it would be for Obama insiders or others to identify a plot as sinister as a rogue urchin.js that steals session details from Change.gov. Because the code would be pushed to anyone using Google Analytics, the malicious payload would surely be noticed by millions of people and quickly reported, Campbell says.
Cruz, along with Jeremiah Grossman, CTO of White Hat Security, a firm that does web application security assessments, isn’t so sure. That’s because execution of the urchin file is automatic and seamless, and there is no easy way to view its source code. “It will probably change regularly to fix bugs and add features and I don’t think anybody notices.”
The real question should be: Why is the future President of the United States building a .gov website that makes such a scenario possible?
Ask 10 security auditors if it’s a good idea to put any third-party company’s javascript on an administrative panel to a website where security is paramount and they’ll all say no.
(We reached out again to Blue State Digital (http://www.bluestatedigital.com/), the firm that built the content management system for Change.gov, but they turned down our request for an interview. The company still hasn’t said whether the system has been audited by an outside security firm.)
“They’re creating additional vulnerability surface and there’s no clear business case for why they’re doing it,” says Campbell.
http://www.theregister.co.uk/2008/11/22/google_analytics_as_security_risk/