Security researcher Bill Rios reported Monday that a cross-site scripting (XSS) attack against Google Spreadsheet could have exposed all of Google's services. XSS can occur whenever a legitimate site accepts input from the user but does not filter that input properly and could allow the injection of potentially malicious instructions. In this case, however, once an attacker gained access to any xxxx.google.com site, they would have access to other Google services, such as Gmail, Docs, and Code.
In an e-mail to CNET News.com, a Google representative confirmed that the flaw as described by Rios has been fixed. "Google takes the security of our users' information very seriously," said a Google spokesperson. "We worked quickly to address the vulnerability and rolled out a fix before it was reported publicly. We have not received any reports of this vulnerability being exploited."
According to Rios, he was able to use Internet Explorer to change the content type of the HTTP response being returned to the server while using Google Spreadsheets. At issue here is whether or not the browser will ignore the content-type header in certain circumstances. Rios points out that all browsers have the potential to do this under certain circumstances, thus the problem isn't entirely with Google.
In his blog, Rios created a spreadsheet, placing an alert (document.cookie) script string surrounded by HTML tags in the first cell. When that string content is saved and downloaded as a comma-separated value or CSV, the content type should be text/plain. However, since Rios added HTML to the string, Internet Explorer will see that first and render it as HTML instead.
Whenever a victim is lured to this CSV URL, an Alert dialog box will pop up on the attacker's desktop containing the victim's current Google session information. The session cookie would be valid on other Google services used by the victim such as Gmail, Docs, etc.
Rios offers this XSS flaw as a cautionary tale, and recommends that security-minded readers check out a paper by Blake Frantz of Leviathan Security. In "Flirting with MIME types," Frantz found that, while other browsers were also indiscriminate about rendering file types as HTML, IE did so on 696 file types out of 735 tested. To give perspective, the next closest was Opera at 14, with Firefox at 8, and Safari at 7.
In looking for a program to back up his Gmail account, programmer Dustin Brooks found a commercial program that instead copies username and password information, according to a blog on Codinghorror.com.
Over the weekend, Brooks said in an e-mail to CodingHorrror.com that he was looking for a program that would archive his Gmail account onto his local hard drive. He signed up for a program called G-Archiver distributed by Mate Media of Miami, Fla. Brooks says that after installing the program, it didn't do all he was looking for so he decided to reverse engineer the source code using a program called Reflector for .Net.
Inside the source code Brooks found the program author's e-mail address and account password for Gmail. Thinking that was a little strange, Brooks used the hardcoded information to open John Terry's Gmail account. There, Brooks alleges he found 1,777 messages, all of which had username and passwords for people who signed up for the G-Archiver, including his own. In other words, whenever anyone signed up for the program, as Brooks had, a copy of his or her username and password was sent to John Terry's Gmail account.
Hardcoding e-mail addresses isn't new. In a presentation at Black Hat D.C. 2008 a few weeks ago, researchers Nitesh Dhanjani and Billy Rios reported that phishing site creators frequently hardcode e-mail addresses into the code in order to receive copies of the personal information submitted independent of where the Web form is being sent.
Brooks says upon realizing what each of the e-mails contained, he then deleted all the mail and emptied the trash. He then changed the author's password, and reported jterry79@gmail.com's abuse to Google.
On the CodingHorror.com site this morning, Brooks wrote "Granted my actions may have been a little quick and harsh, I was a little upset over the whole deal. I have a lot of personal info in my account along with a stored credit card for Google checkout. I very easily just could have changed my password and been done with it, but I didn't want more people compromising their accounts as well. The only e-mails in this account were usernames/passwords. This wasn't a personal account used for other things."
A number of sites have since removed G-Archiver from their download collection, including CNET Download.com. Attempts to contact Mate Media have so far gone unanswered.
Robert Graham, CEO of Errata Security, who last year found that it's possible to capture someone's session cookie via wireless eavesdropping, now says that even encrypted services such as Google's Gmail can sometimes provide him with a session cookie. This is a departure from his advice last August when he said SSL HTTPS sessions of Gmail should be immune.
Graham, working with David Maynor, created two tools (Ferret and Hamster), which together help him grab session cookies out of thin air, say, at a local hot spot, like an Internet cafe. Session cookies allow you to shop at an e-commerce site, then leave the page and return later without re-entering your password. One doesn't have to decode the user's password to exploit the session cookie, merely possess it.
Graham gave a live demonstration of his sidejack attack on an audience member's Gmail account at last year's Black Hat USA, displaying that person's inbox before a standing-room-only crowd.
Now Graham says that Gmail, in particular, will sometimes connect to a hot spot first via Javascript rather than SSL, and this allows his tool to grab the session cookie and thus read someone else's e-mail. The same could be true with Amazon.com and other Web 2.0 sites.
"In theory, Graham says, "using the HTTPS version of Gmail should protect you by going to https://mail.google.com/mail, but this doesn't work as you think. The JavaScript code uses an XMLHttpRequest object to make HTTP requests in the background. These are also SSL encrypted by default, but they become unencrypted if SSL fails."
Graham provides more details in his blog.
- prev
- 1
- next
