Tag Archives: Security

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

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 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: <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.

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 helo=gator3211.hostgator.com)
by gator3211.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85)
(envelope-from )
for email2@example.com; Mon, 1 Dec 2015 11:22:44 -0200
Received: from ([]) by YOUR_OTHER_DOMAIN.hostgator.com
(Horde Framework) with HTTP; Mon, 1 Dec 2015 11:22:43 +0000
Date: Mon, 1 Dec 2015 11:22:43 +0000
Message-ID: XXXXXXXX@YOUR_OTHER_DOMAIN.hostgator.com
From: email@example.com
To: email2@example.com
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 - gator3211.hostgator.com
X-AntiAbuse: Original Domain - YOUR_ANOTHER_DOMAIN.com
X-AntiAbuse: Originator/Caller UID/GID - [11 13] / [11 13]
X-AntiAbuse: Sender Address Domain - YET_ANOTHER_DOMAIN.com
X-BWhitelist: no
X-Source-Sender: localhost (gator3211.hostgator.com) []:11343
X-Source-Auth: email@example.com
X-Email-Count: 2
X-Source-Cap: WU9VUl9VU0VSTkFNRTtZT1VSX1VTRVJOQU1FO2dhdG9yMzIxMS5ob3N0Z2F0b3IuY29t

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

Example 2
Received: from YOUR_USERNAME by gator3211.hostgator.com with local (Exim 4.85)
(envelope-from YOUR_USERNAME@gator3211.hostgator.com)
id XXXXXX-XXXXX-XX; Fri, 1 Dec 2015 11:22:27 -0400
To: email@example.com
Subject: Some text here...
X-PHP-Script: subdomain.example.com/folder/subfolder/your_script.php for
From: email2@example.com
Reply-To: email2@example.com
X-Mailer: PHP/5.4.45
Content-Type: text/plain; charset=utf-8
Message-Id: XXXXXX-XXXXX-XX@gator3211.hostgator.com
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 - gator3211.hostgator.com
X-AntiAbuse: Original Domain - YOUR_ANOTHER_DOMAIN.com
X-AntiAbuse: Originator/Caller UID/GID - [some random numbers here] / [and there]
X-AntiAbuse: Sender Address Domain - gator3211.hostgator.com
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-Source-Dir: example.org:/web/internal_dir/
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 YOUR_ANOTHER_DOMAIN.com 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?!

WordPress still insecure by design

Some major WordPress design flaws have led to widespread attacks on our and your servers. The only hope is reasonably long and strong passwords or WordPress security plugins.

The first flaw. By default WordPress have enabled “feature”, when you visit your blog with author query string appended, it nicely reveals your usernames. For example, if you have:


just add


and default WordPress installation redirects you to the:


In you need next valid username, change 1 to 2:


The second flaw. WordPress have two separate login error messages:

ERROR: Invalid username


ERROR: The password you entered for the username admin is incorrect.

So basically, you can check if particular username is valid.

The third flaw. Many users use .htaccess to secure the wp-admin directory, but WordPress coders decided to include public accessible script in the admin folder. So securing admin folder breaks your site in many ways. Of course you can write more advanced .htaccess rules, but it is not excuse for including public script in the admin folder.

Both front-end and back-end Ajax requests use admin-ajax.php

Forth flaw. Allow hackers to iterate hundreds of usernames/passwords in the single web request (system.multicall), and do it via public accessible script, that is not hidden behind wp-admin folder. Just brilliant! By the way, flaw is still not fixed, and even if you have not so popular site, you will still see your log files full of password guessing requests from different IP addresses: - - [13/Oct/2015:17:26:55 -0400] "POST /xmlrpc.php HTTP/1.0" 200 561 "-" "-"

Note, that IP is given as an example.

Read more about this system.multicall thing here: Brute Force Amplification Attacks Against WordPress XMLRPC

The fifth flow (and not the last). If you have some flaws / vulnerabilities, please share them in comments. Of course only publicly known ones. If you have newly discovered flaw, use proper disclosure channels.