GMail Messages are Vulnerable to Interception

[freeandfun1]

GMail Messages are Vulnerable to Interception

If you use GMail, like I do, you might wanna know this....

The Discovery

It all started about 3 days ago when MrYowler and I were working on a mailing list script to send out a batch of newsletters for a free hacker-friendly shell service we operate. We made the decision to keep it simple; a Perl script based upon the Net::SMTP CPAN module. Being the Perl guru that MrYowler is (shut up! people will start having expectations of me! ;-P), he had one whipped up in about 20 minutes. In the course of testing the script, we cranked out 10 newsletters to our GMail inboxes. We were a little shocked with that happened next.

MrYowler opened up his mailbox, and noticed the email had arrived just fine. He clicked on the subject line, and as expected, the message showed correctly. However, when he clicked the "Show options" link, the "Reply To" field in the email header that GMail displayed contained what appeared to be HTML code! Upon further inspection, we realized that it was the message body of another person's HTML-formatted email message.

The Research

Wondering if something had happened during the message transmission, we viewed the message source via GMail's "Show original" link. In the source, we did not see any of the HTML code that GMail was showing us. No HTML at all, as we did not even use it in our newsletter. It appeared as a regular run-of-the-mill plain text message.

We became curious as to what had gone wrong, and whether it was an error in the script, or in the GMail messaging system. We examined the the output of our Perl script, and discovered that it was not transmitting the "From" header (in the message body) correctly - the trailing ">" character was missing in the address area.

Where it should have been "From:<[email protected]>", we had "From:<[email protected]".

This, apparently, was enough to get GMail to provide us with some portion of someone else's messages.

We speculate that there is a subroutine which determines where the "From" address component of a message, ends - and that this subroutine relies upon the closing ">" bracket to distinguish this end. When unable to find this character prior to a carriage return, it simply continues to read past the end of the allocated buffer for this component, until it either encounters this character in whatever data happens to be there, or until some upper buffer size limit is reached. We remain unsure of that buffer size limit, and whether, in fact, one exists.

We propose that the correct solution to this problem, might be to also search for non-displayable data, such as carriage returns, in this area, and to terminate the field on this basis. Alternatively, if the size of the field is determined separately, when allocated; that information could be retained, as a criterion for failure conditions, when the field is parsed.

It is possible that a large buffer area is being allocated, and then being populated only partially. This being the case (if so), then the data that we are seeing is what was left in memory, after the last time that this memory area was returned to the memory manager, and this error does not represent a buffer overflow, but rather, a poorly-managed boundary condition in the GMail server-side software.

Regardless of the specific failure, the result is a compromise of the privacy of communications over GMail. As demonstrated in the examples (below), message content and address information are easily - if somewhat randomly - available to unintended recipients. Usually, this only permits an attacker to examine recently-arrived spam in random user's inboxes - but (as noted in one example) message content does occasionally become more interesting.

The Conclusions

We do realize that GMail is an invitation-only service, in a beta-test state of development. Nevertheless, many people rely upon GMail heavily, and many more people are forced to communicate with GMail users, because of this reliance. These people should expect their communications to be vulnerable to interception, at least until GMail corrects the issue. And the appearance of this issue, at the user level, probably indicates a failure in GMail's code review and/or quality assurance standards, which may result in other, similar errors. We did not explore GMail for additional such errors, but based upon the nature of this one, we are confident that such exploration would bear interesting fruit. (Note to GMail's development teams: we are available for hire! Cheaply! ;-P)

So... If you are a regular GMail user - or someone that corresponds with one - you might want to either rethink the privacy of your communications, or perhaps make some noise with the folks at Google's email service. And don't forget to tell them that MrYowler and I need jobs... ;-P (Note that we are using a GMail address, so any job offers are probably not going to be well-kept secrets... ;-P)

Abstract

GMail messages are vulnerable to interception. An attacker has only to transmit malformed test messages to himself, and information left over in memory, from previous messages destined for other people, will appear with the test messages, in the attacker's inbox. Sometimes, this information may include usernames and passwords... Do you use GMail? Are you communications private? Should they be? Well, here's what we figured out about the issue, that may or may not help you - or perhaps GMail, if anyone can get ahold of their developers, to tell them about it.

 

[waltky]

Granny don't use Gmail, `cause she don't want folks googlin' at her...

Gmail Hack: 5 Million Passwords Get Posted on Russian Forum
Sep 11, 2014 — Nearly 5 million Google user names and passwords were posted on a Russian Bitcoin forum this week. Though the passwords have since been removed, the information could have been public long enough to allow hackers access to Gmail and other services using a Google login.

Other email systems have also suffered public user data leaks on Russian Internet services, though some of the data has been reported as outdated. Google is not admitting a recent hack, and reports are claiming that the posted login information had been gathered over years, from phishing exploits. The security issue will most likely impact users who have retained the same password for extended periods of time – and those who use the same login information on multiple systems.

Several media outlets that reported the leak directed readers to isleaked.com, a purported email breach verification system. Blogger James Watt claims the site may in fact be a “honey pot” – a hacker trap to gather personal login information from unknowing users. “All of the news articles are telling people to go to isleaked.com to check their addresses," Watt wrote on his blog. "However, I don’t think any of the media has vetted this website and could possibly be sending millions of people to a website run by people harvesting email addresses for spam or other hacking activities. It’s even possible that isleaked.com is run by the very people who leaked the passwords in the first place. Why do I think this? Because isleaked.com was registered on the 8th, 2 days before the story broke anywhere else.”

Rather than trust an online tool to determine if your account information was posted in the Russian leak or not, you can simply try to login to your Google account as usual. If your account was on the list, Google will redirect your login to a password reset system in order for you to regain access to your account.

With ongoing concerns from frequent private data hacks, security experts are advising consumers abide by these precautions:

See also:

Justice Dept. seeks new tool against data fraud
Sep 12,`14: WASHINGTON (AP) -- Working to combat an increasingly lucrative crime that crosses national boundaries, Justice Department officials are pressing for a new law to help them prosecute criminals overseas who traffic in stolen credit cards.

Authorities say the current law is too weak because it allows people in other countries to avoid prosecution if they buy and sell stolen card data entirely outside the United States. The Justice Department is asking Congress to amend the law to make it illegal for an international criminal to possess, buy or sell a stolen credit card issued by a U.S. bank no matter where in the world the transaction occurs.

Though prosecutors do have existing tools and have brought international cybertheft cases in the past year, the Justice Department says a new law is needed at a time when criminals operating largely in Eastern Europe are able to gobble up millions of stolen credit card numbers and commit widespread fraud in a matter of mouse clicks. Companies and banks, too, have been stung by faraway hackers who have siphoned away personal information. "It's a very simple fix, and it makes perfect sense to fix it," Assistant Attorney General Leslie Caldwell, the Justice Department's criminal division chief, said in an interview. "This is a huge law enforcement issue when it's our financial institutions and our citizens' credit card data that's being stolen ... by overseas people who never set foot in the United States."

The problem, though certainly not new, has evolved to the point that "a lot of these folks who are trafficking in these devices are overseas," Caldwell said. The issue is more than hypothetical, Caldwell told a Senate subcommittee, as law enforcement agencies have identified criminals in other nations who are selling large quantities of stolen credit cards without passing the business through the U.S.

Officials say the crime is facilitated by online marketplaces where participants, cloaked in the anonymity of the Internet and trading data with the ease of eBay commodities, advertise, buy and sell credit card information stolen in data breaches. The credit cards are valued at different prices, generally depending on the balance, and swapped on web forums that often operate in foreign languages and are primarily hosted in non-U.S. countries.

MORE