Tag Archives: Security

Attachments from GitHub’s private issue trackers can be viewed without any authentication

Disclaimer: I disclosed this security issue to GitHub, and they choose to not fix it (We have reviewed your report and determined that this functionality is working as expected). This is undocumented behavior, so I am describing it here. Also, note that I am not asking anyone to hack GitHub nor I am going to do this by myself. All I want is better security and fair playground – everyone should know how safe their files are there at the GitHub.com

Short version: This is security weakness for Private GitHub repositories. I am not talking about public repositories that are available to anyone without entering username or password. Also, source files stored in the Git are safe. However attachments from GitHub’s private issue tracker can be viewed without any authentication or authorization. Not all attachments are at risk. Word, Excel and PDF documents (.doc, .docx, .xls, .pdf) are kept private. Image files .jpg and .png are accessible to anyone – without providing any username or password – even if repository is not shared to anyone, even if you are paying GitHub for enterprise account (Developer, Team, Business). The attacker only need to know the URL of image… and that is disturbing. Also, once uploaded you can not remove the photo, image or blueprint. It stays there forever…

Long version: You are paying from $7 to $21 per user per month to host your Private or Business projects at GitHub (I have tested only $7 account, but my guess is that all of them works the same way). You have read the GitHub Security article (advertisement). You think that they do what they say they do (We know your code is extremely important to you and your business, and we’re very protective of it), but… as every big company does, they fail… and they fail to fix security issues even when they know about them. I don’t know why it happens, but I think that Bounty programs play big role here. They need to give away money to random people to fix their software defects. Sometimes they choose to do nothing, because of high volume of false positives (bug reports) they can not afford security experts to look at every issue submitted.

About security issue:
Create a new Issue for your any private repository.

Screenshot - New issue
Screenshot – New issue

Drag & drop .jpg or .png file into the newly created issue. GitHub immediately creates markup/markdown with embedded image. Notice the path – https://cloud.githubusercontent.com/assets/ (Example URL – https://cloud.githubusercontent.com/assets/8530649/23546842/1265c69c-000a-11e7-9b14-c8c55b243b83.jpg)

Screenshot - New issue attachment
Screenshot – New issue attachment

At this point your private images / photos / blueprints are available publicly – without any authentication or authorization. You don’t even need to post the issue. Your images are already uploaded! Even more alarming fact is, that you can not remove the images / drawings or your blueprints once they are uploaded. There is no delete button. And deleting issue’s comment or even deleting whole GitHub repository does not help. Images are still there.

When deleting GitHub’s private repository, there is no information that some files will be left in the web forever.

Screenshot - Delete this repository
Screenshot – Delete this repository

Even more. They say that “This will permanently delete the repository, wiki, issues, and comments, and remove all collaborator associations. Of course this is not the case. Your issue attachments are kept there forever.

Screenshot - Delete repository warning
Screenshot – Delete repository warning

I can speculate that coding / programming the image cleanup code is more expensive than HDD space nowadays. I have not tested for very long periods. Maybe there are some code that scans comments and removes unused (unlinked) images once a quarter or once a year, but I do not have evidence of a such thing. So the truth is – once uploaded to the GitHub your images are there forever or at least for weeks.

I have tested both .jpg and .png images. They are hosted at https://cloud.githubusercontent.com/ server. They are accessible to anyone. On the other hand – document files like .pdf, .docx, etc. are hosted at https://github.com/YOUR_ACCOUNT_NAME/your-repository/files/your-document.pdf which are kept safe.

And to be fair, here is the GitHub’s view on the issue. They say two things:

  1. The links have UUID / GUID in them (more than 120 bits of entropy), so attacker can not guess them.
  2. Do not share links from private issue tracker to the third parties.

Let me begin with the second point – Do not share links… If you are computer savvy or security oriented, then you may try to not share the link with the third parties. However, in the practice this is not an easy task. First, there are toolbars and browser addons/plugins that grabs all the link for various purposes like virus-checking (private files shared with 3rd parties becasue of the lack of proper authentication). Also not in so long time ago popular Google Toolbar and Alexa Toolbar used such information to index deep web. So your hidden URLs started to appear in the search index. There are countless examples of this happening:

There was some myths and word games with Google and webmaster community, whether Google uses URLs for indexing purposes or not, but one thing is certain – Google Toolbar was sending URLs to Google. So, if you visited your GitHub’s issues page with Google Toolbar enabled, then your URLs was shared with Google, and you can only imagine how the Search gigant used that information. There are some more excuse going on from Matt Cutts. But even one of the brightest minds from Google says – “Security through obscurity is not a great way to keep a url from being crawled”. GitHub, if you do not want to listen to me, may be listen to the Google? According to the Wikipedia “Security through obscurity” was rejected as method of security in 1851, but we are still doing it in 2017.

I see some hands rising – “but… but… GitHub have robots.txt file at the root of https://cloud.githubusercontent.com/
User-agent: Twitterbot
User-agent: *
Disallow: /

But again – so you want that your important files are protected by one text file that is only a recommendation not a law, or you want proper authentication where username and password is required to access your files? The robots.txt file prevents only robots that obey these rules. The text file does not protect from humans or hackers.

And there are countless other ways how can you share links with third parties without your consent. Antivirus / antispyware sends URLs for virus-scanning purposes where sometimes human interaction is required (third party sees your images), as mentioned earlier – the Toolbars, browser addons/extensions, you can send link to misspelled email address and you think that only you and your team have access to the GitHub repository, but sorry… now the person with misspllled email address also have your file.

The first argument about 120 bit entropy and UUID / GUID is also very disturbing. It is clear that person at the GitHub who review the submitted issues have no clue about UUIDs/GUIDs and entropy. I am not here to teach you about all the historical problems with uniqueness, guesability or security. Just read some information from the links provided.

  • How securely unguessable are GUIDs? (Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access))
  • GUIDs are designed to be unique, not random (The GUID generation algorithm was designed for uniqueness. It was not designed for randomness or for unpredictability)
  • UUIDs generally do not meet security requirements (The RFC Section 6 is very clear about this: “Do not assume that UUIDs are hard to guess; they should not be used as security capabilities”)
  • From Wikipedia – Universally unique identifier (Pseudorandom number generation often lacks necessary entropy, and RFC 4122 recommends that when a high-grade source of randomness is not available, that one of the other UUID versions be used instead. Some implementations of version 4 UUIDs do not satisfy this requirement)

Here are some UUID examples. All of them are from GitHub. Maybe not guessable on the spot, maybe enough entropy, but what if they use weak PRNG, or what if some other programmer replaces UUID generating function without any clue that they are improperly used for security? What if they use standard UUID generation alghoritm and are easly predictable?

I hope that GitHub will plug the hole… soon 🙂

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?!