Security: How to obtain someone’s username/login from the “Gmail for work”?


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 users, that are sending email via gmail servers, but using non-gmail email address as sender (alias). So for example, your gmail address is and you setup alias for 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 ( 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, 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. is the address that you are trying to protect. And you are sending email from

Received: by with SMTP id a64csp423452wmf;
Sat, 26 Apr 2016 05:02:04 -0700 (PDT)
X-Received: by with SMTP id 40mr24542334ior.101.124354452334;
Sat, 16 Apr 2016 05:02:04 -0700 (PDT)
Return-Path: <>
Received: from ( [2607:f9b1:4002:c06::234])
by with ESMTPS id ...

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.

Warning: HostGator leaks your cPanel usernames, script path, and more


Once upon a time the HostGator was a great hosting company – great technical support, great prices, good performance, predictable policy, etc., and positive-thinking CEO who blogs about the company, about fortunes and failures… Fast forward to year 2012. CEO and founder Brent Oxley sells HostGator to EIG. They are famous of “acquiring a large number of smaller web hosting companies” which leads to Web hosting overselling.

From that point everything goes downhill, unfortunately. I am not going to list all the problems their users have. You can find this information using any Search engine. For example, search for: “HostGator and EIG”… and you will find plenty of information about their business practices.

Note and disclaimer. I am not affiliated with any hosting provider. I believe that there exists a way, that you can hide some of the leaked details, bet I am sure, that there is no way to make it work in the reliable way, because, HostGator are constantly changing everything, and constantly consolidating servers, and even moving your server between datacenters located in different physical locations, changing Apache HTTP server to nginx server (breaking changes?), and this all without any notice or warning to its users. And most of the users are uninformed, so you can not expect that they will be able to protect their websites, scripts, assets, etc.

Now about the security issue. When you send email from HostGator, using their Web Mail, or using your Desktop email client or .PHP script, you are always leaking your username. In the case of script, you are also leaking the script name, full path to the script, and also some random domain names and email addresses you have in the same account. Some information is encoded in Base64 format, that can easily be decoded. Below are some examples. YOUR_USERNAME is your leaked username. YOUR_OTHER_DOMAIN is leaked other domain name in the same account, but not related to email address in any way.

Example 1
Received: from localhost ([]:11546
by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85)
(envelope-from )
for; Mon, 1 Dec 2015 11:22:44 -0200
Received: from ([]) by
(Horde Framework) with HTTP; Mon, 1 Dec 2015 11:22:43 +0000
Date: Mon, 1 Dec 2015 11:22:43 +0000
Subject: Testing leak
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [11 13] / [11 13]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: localhost ( []:11343
X-Email-Count: 2
X-Source-Cap: WU9VUl9VU0VSTkFNRTtZT1VSX1VTRVJOQU1FO2dhdG9yMzIxMS5ob3N0Z2F0b3IuY29t

Note, that X-Source-Cap header decoded is:

Example 2
Received: from YOUR_USERNAME by with local (Exim 4.85)
id XXXXXX-XXXXX-XX; Fri, 1 Dec 2015 11:22:27 -0400
Subject: Some text here...
X-PHP-Script: for
X-Mailer: PHP/5.4.45
Content-Type: text/plain; charset=utf-8
Date: Fri, 1 Dec 2015 11:22:27 -0400
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [some random numbers here] / [and there]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source: /opt/php54/bin/php-cgi
X-Source-Args: /opt/php54/bin/php-cgi /home2/username/blah/folder/subfolder/your_script.php
X-Email-Count: 3
X-Source-Cap: WU9VUl9VU0VSTkFNRTtZT1VSX1VTRVJOQU1FO2dhdG9yMzIxMS5ob3N0Z2F0b3IuY29t

Note, that script name is not accessible from the web. It is not publicity known, and is revealed to potential attacker:

I understand, that security by obscurity is not the best security practice, but anyway, revealing internal script names without any real need in nonsense.

As you can see, the headers that was included to track the service abuse, is actually abusing you. And is yet another domain that is in the same account and is leaked too. It is different domain from OTHER domain… so at least two different domains (at random?) are leaked.

And in the second example, the full Linux path to the script is embedded into header:

This script may be your Cron job or other script, and path and script name should not be revealed to email recipient. If they really wanted to track abuse, they could store this all sensitive information in the local DB, and embed only unique ID/key to that information, in case it is later needed.

And to abuse your valuable time even more, they have placed SPAM filters for your outgoing emails with always changing filtering parameters. So you can wonder, why some of your emails are lost somewhere.

Note. This article was written at the time we still used HostGator intensively, both as Shared hosting and as Dedicated servers, but now we have switched away. And believe me, the overselling, security problems and poor support is only the tip of the iceberg, unfortunately.

Did we tried to some these issues with HostGator support. Of course. You can try too. Good luck! :) Usually they reply with, we are sorry, but we can’t do anything because of very high support volume right now.

And almost forgot to mention, that they constantly hijack your 403, 404, 500, and other error pages. They inject their own ads and banners into your page. Maybe at the time, when GeoCities and Angelfire ruled the free web hosting world that was somewhat acceptable, but now in the era of web 2.0?!

Google Drive may be silently renaming your files

Just a friendly warning. If you try to store copy of standard Apache HTTP Server web root, git repository, some Linux directories, etc in the Google Drive, then do not be surprised when Google silently corrupts the filenames by renaming dot (.) to underscore (_). For me this is happening to nix hidden files (begins with a dot), but some of colleagues remember to happen to regular PDFs as well.

Solution. Upload only archived files to the Google Drive. And preferably encrypted (just in case).