Photo: freeimages.com
Short version: Gmail leaks your username. Always! To get username/login information for Google Apps user (paid Work/Business account) you need one email message. Just look at the Return-Path header. Fortunately, you do not know password yet, but combined with other weaknesses (like password reuse) this is not a problem. Determining if someone is using Google Apps for Work (Business) is trivial. And this method works in 100% cases. Even administrators can not hide their administrator’s username.
Long version: Some time ago when doing security audit / consulting I found a small security hole in the Google’s Gmail for work (previously Gmail for Business). Of course, as a responsible citizen, I notified Google’s security team with the info that their popular web email client has the security problem. They responded timely and very polite, asked a couple of questions, and to my surprise said, that this is not a security issue and they are not going to fix it.
Normally, I would agree that knowing your login name is not a problem. However, in the real world in the computer systems that are in use by millions of people these “normally” rules does not apply anymore. When password reuse happens, where brute-force password guessing is reality, in the world where lazy admins live, etc. One more thing is – the IT security is not a simple thing. It is more like layers of various pieces that are put together in the right combination by making reasonable good security. By revealing your username – one of the two credentials, you are eliminating one piece of that security layer. And this is absolutely unnecessary. Whatever Google wanted there, it can be achieved in many different ways without compromising that one small piece of security.
Also, I must note, that this weakness is documented by Google. This is not something rare or unique, when software author describes some feature in the documentation, and when later the scope of the feature is changed, the Vulnerability appears. I suspect that something similar happened there.
I suspect that this feature was originally implemented for regular @gmail.com users, that are sending email via gmail servers, but using non-gmail email address as sender (alias). So for example, your gmail address is personal.email@gmail.com and you setup alias for personal.email@example.com. In the original gmail this feature makes perfect sense. If you are too spammy then any administrator in any organization can look at your email headers (Return-Path) and determine your real email address (personal.email@gmail.com) or block it altogether, without any action needed from Google’s team. They offer free service, and do not need to spend money on support team. But by revealing your personal.email@gmail.com, it also reveals your gmail login. But again, this is fine – free service, everyone already know, that your email address is login name, and have turned on 2-factor auth, etc.
But it does not make any sense for Business email, where email address and alias are on the same server. There should be an option to disable this Return-Path thing, or better, it is disabled automatically when Admin have configured alias domain on the same Google server. I would somewhat understand that Return-Path is added in Business email when the alias resides on non-google servers. But why on the Earth the header is added when both domains resides on one Google email account and the email is send from the same account?
One more problem is that users of the Google’s paid email service are not aware of the issue. One tech savvy admin would think, that by creating the alias different from the administrator username would somehow protect the admin’s real email address, and by assuming that no one knows that address, would fall as victim in the phishing attack in the email form, where email looks like from Google support, because she thinks that only Google knows this hidden admin email address. She have not revealed this email address to anyone except Google. Think about it. If she receives email to that address, it must be Genuine – from Goolge.
This is how the Return-Path header looks. ADMIN-USERNAME@example.com is the address that you are trying to protect. And you are sending email from john@example.com
Delivered-To: something@example.com
Received: by 10.128.17.7 with SMTP id a64csp423452wmf;
Sat, 26 Apr 2016 05:02:04 -0700 (PDT)
X-Received: by 10.17.107.18 with SMTP id 40mr24542334ior.101.124354452334;
Sat, 16 Apr 2016 05:02:04 -0700 (PDT)
Return-Path: <ADMIN-USERNAME@example.com>
Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com. [2607:f9b1:4002:c06::234])
by mx.google.com with ESMTPS id ...
From: john@example.com
...
And again, if you have not enabled two factor authentication, do it now. Do it for the every service that support it (Google, Dropbox, Amazon, Twitter, etc.).
And if you still think that revealing usernames is somewhat acceptable, try to educate yourself by reading other peoples opinions. For example here – Disclose to user if account exists? And by the way, the Wikipedia article about Phishing begins with the sentence: “Phishing is the attempt to obtain sensitive information such as usernames…”
P.S. And by coincidence today we have vulnerability from the same category in the Microsoft’s Live service – Microsoft Live Account Credentials Leaking From Windows 8 And Above.
