Thursday, April 23, 2009

Gmail accounts hacked via unpatched hole

By Scott Spanbauer

Exploits allowing hackers to break into Gmail accounts are likely to occur, if they're not already circulating, after security researchers released details of a hole that Google has reportedly declined to patch.

There are steps you can take to reduce the risk of using a webmail account, but it appears that the usual tricks won't solve the Gmail problem until Google fixes the software.

The weakness that researchers say afflicts Gmail, a free e-mail service hosted by Google, belongs to a class of attacks known as cross-site request forgery (CSRF, pronounced "sea surf").

Besides Gmail, CSRF holes affecting YouTube, Netflix, and NYTimes.com have also been found and repaired in the past. CSRF attacks use security flaws in cookies, password requests, and other interactive Web components to intercept communications between your browser and a Web site's server.

The first report of the Gmail problem within security circles was written by Vicente Aguilera Díaz of Internet Security Auditors (ISA) on July 30, 2007. The next day, ISA issued an alert and included a proof of concept illustrating how the exploit could be used to change a Gmail account password.

After more than a year during which, according to ISA, Google was repeatedly contacted privately about the problem researchers publicly released a detailed description of the exploit on March 3, 2009, according to a Secure Computing article.

The magazine quoted an unnamed Google spokesman as saying, "We've been aware of this report for some time, and we do not consider this case to be a significant vulnerability, since a successful exploit would require correctly guessing a user's password within the period that the user is visiting a potential attacker's site."

Considering that an automated attack can test thousands of passwords in a matter of seconds, you might not be very reassured by Google's position. Many PC users select weak passwords that consist of common names or dictionary words, leaving them susceptible to brute-force discovery. And the general release of the CSRF technique makes it easy for hackers to write opportunistic code, if actual exploits aren't already in the wild.

The March 3 public disclosure should not be confused with an earlier Gmail CSRF flaw that was first reported on Jan. 1, 2007. Google repaired that problem by the following day, according to a blog post by software consultant Hari Gottipati.

CSRF attacks — which are also referred to as session-riding — are different from the more-widely known cross-site scripting (XSS) exploits. XSS holes allow a malicious Web site that's open in one browser window to inject JavaScript into another site's page that's open in a separate window or tab. Once the unwanted script is running on a PC, the code can try to collect private data and passwords and transmit them back to the attacker's server.

XSS vulnerabilities have recently been discovered and patched in many browsers and on many sites, including Yahoo Mail and Hotmail as well as Gmail.

Provide some protection for webmail with https

Google, Yahoo, and other Internet services cover themselves by stating that you use the services at your own risk. A major threat of using any webmail service is that a hacker could swipe or guess your password and take over your account.

If your Google account includes such personal information as stored credit card numbers (for Google Shopping, for instance), a contact list, photos, and business or financial documents, having your account hacked could be more than just an inconvenience.

One way for an attacker to steal passwords — especially given the ubiquity of open, unencrypted Wi-Fi networks — is to use software that "sniffs" Internet traffic. If you enter your username and password on a Web page without encryption, your inputs are transmitted as plain text, not just over a Wi-Fi connection but also through every router that happens to be located between you and the service's machine.

Fortunately, the Big Three webmail services — Gmail, Yahoo Mail, and Hotmail — and many other Web sites provide protection for their sign-in sessions using Secure Sockets Layer (SSL) encryption. SSL enables a Web browser to scramble any sign-in data before pumping it out naked across the Internet's plumbing.

To determine whether a site encrypts its sign-in procedure, look in your browser's address bar. The page's URL should begins with https (Hypertext Transfer Protocol over SSL), as shown in Figure 1. Unencrypted pages use the http protocol.

Secure https connection to Gmail
Figure 1. Look for the https protocol in a browser's address bar, which indicates an encrypted connection.

Seeing the https protocol or the well-known "lock" icon in a browser's status bar is no guarantee that a particular site is legitimate, of course. The Anti-Phishing Working Group offers information on how these indicators can be spoofed by hackers as well as some tips to help you avoid scams.

If a sign-in page uses the https protocol, however, it's unlikely that your password will be sent as plain text across the Internet.

Gmail's sea-surf hole can't be closed by SSL

Some reports on the Web, such as an article at Softpedia.com, say using https during your Gmail sessions blocks CSRF attacks on the service.

Unfortunately, that's not the case for this Gmail hole, according to ISA's Aguilera. In an e-mail interview conducted in Aguilera's native Spanish, he said the flaw allows a hacker to take advantage of an encrypted session (the following is my translation from the original language):

* "In this vulnerability, the attacker causes the victim to generate, invisible to the victim, a request to the server (in which request the victim's authenticated session cookie is also transmitted).

"When the server receives the request, it sees that it comes from an authenticated session (the victim's), and thus is unable detect that, in reality, the request was instigated by the attacker.

"In other words, it's as if the victim/user actually created the request to the server, and the fact that the communication is encrypted is unrelated and doesn't prevent the attack."

Using https does prevent traffic sniffing and so-called man-in-the-middle attacks, so you should enable it regardless of whether Gmail's CSRF hole is ever patched.

To benefit from encryption when accessing Gmail, you should configure the service to use SSL by default. To do so, click Settings in the top-right corner of the main Gmail window, select Always use https in the "Browser connection" section at the bottom of the General tab, and click Save Changes.

Using encryption will slow Gmail's performance slightly, but this small price is worth it. The https protocol will encrypt not just your sign-in sessions but also the contents of your e-mails when they're sent between your browser and Google's servers.

POP3 and IMAP protect Gmail, Hotmail, Yahoo Mail

Sadly, Yahoo Mail and Hotmail don't provide a similar Always use https setting. But you can protect these two services' data, and also defeat Gmail's CSRF hole, by using a PC-based e-mail reader and retrieving your messages via the long-established POP3 or IMAP protocols.

When you use a PC-based client like Mozilla Thunderbird to read and send webmail, SSL encryption can prevent eavesdropping. Using IMAP or POP3 also gives you the option to delete sensitive messages that would otherwise remain on the remote server. (I rated Thunderbird and other free e-mail clients in a July 31, 2008, comparative review.)

IMAP and POP3 are supported by the free versions of both Gmail and Hotmail. Yahoo supports POP3, but only in the paid version of Yahoo Mail (U.S. $20 per year).

For instructions on using a PC-based client to retrieve messages from a webmail service, using Hotmail as an example, there's a step-by-step article on the subject at About.com.

Using https when signing in — and encryption when processing your webmail — makes it less likely your password or other personal information will be sniffed. This makes your webmail safer, no matter how long it may take before Google fixes the CSRF hole that has security researchers in a huff.

No comments: