Receiving a security disclosure for an old subdomain

After receiving a security disclosure from a security researcher I knew I needed to investigate.

Receiving a security disclosure for an old subdomain

I'm used to receiving security disclosures for some of my clients, as I routinely set up security.txt files for that very reason.  I recently received a security disclosure from a researcher called Gaurang Maheta for a subdomain of my own,, which was confusing because I didn't recall that domain existing.  Time to do some digging...

How did they contact me?

It's probably best to start at the beginning here and describe how the security researcher was able to reach out to me, given there's no contact form on this blog.  You'll see there's a security policy link at the top of this site which in turn links to a security.txt file containing my details.  I really like the concept behind security.txt as it is a great way to make it easy for researchers to reach system owners - read more on the securitytxt website.  I do need to fix my web server config though, as mine isn't in quite the right place.

What were the disclosures?

In total I received three disclosures:

  1. Git repository found
  2. OpenSSH 2.3 < 7.7 is vulnerable to username enumeration
  3. PHP info page disclosure

All of these would need fixing but I was still not convinced the system in question was mine (turns out it wasn't, more on that later) but let's look at each of these in turn.  Each is an information disclosure vulnerability.

Disclosure 1: Git repository found

Git is a version control system used by developers to keep track of source code.  I do use Git, so it wasn't impossible that this vulnerability related to a system of mine but looking at the screenshot from Gaurang, the researcher, I could see the configuration for the repository and that confirmed the system wasn't mine.  I've redacted the details below, but this is essentially what was being presented to anyone browsing to

	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://[email protected]/redacted-user/gift-world.git
	fetch = +refs/heads/*:refs/remotes/origin/*

Exposing this information is far from ideal as it could be used in further attacks (for example, social engineering by pretending to be from BitBucket).  There's potentially other sensitive information that's available inside the .git directory but the researcher has likely avoided looking at that - ethics comes in to play.

Disclosure 2: OpenSSH 2.3 < 7.7 is vulnerable to username enumeration

Username enumeration is the process of working out what users exist on a system.  A vulnerable application, e.g. OpenSSH, might react differently to valid usernames compared to invalid ones, even when the wrong password is used.  In this particular case that was exactly the problem and you can read more about it here (technical).

Disclosure 3: PHP info page disclosure

PHP is a programming language primarily used to produce web applications (the eVitabu management system is written in PHP), and can access a number of external libraries to provide extra features.  A developer can use the following code to see what is supported on their server:


Looking at the screenshot I'd been sent again suggested this was not a server of mine - it's running PHP version 7.0 which is no longer supported.  I'm only running supported versions of PHP.

Screenshot showing the PHP info page, a table of purple and grey listing various information.

So, where does it point?

Having decided this wasn't pointing at a server I owned I still needed to verify if this information was legitimate.  By this point all I'd seen was a handful of screenshots from the researcher, and I'm a "trust but verify" kind of guy.  To determine where was pointing, I turned to nslookup.  We can clearly see it's pointing at an IP address of

>  nslookup

Non-authoritative answer:

Next I wanted to know who owned that IP as it didn't strike me as being one of mine.  whois is a useful tool for looking up IP address owners and this showed me the IP was owned by DigitalOcean (the below output is truncated as it goes on a bit!):

> whois


Found a referral to

% This is the RIPE Database query service.
% The objects are in RPSL format.
% The RIPE Database is subject to Terms and Conditions.
% See

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to ' -'

% Abuse contact for ' -' is '[email protected]'

inetnum: -
netname:        DigitalOcean
descr:          DigitalOcean, LLC
country:        US
org:            ORG-DOI2-RIPE
admin-c:        PT7353-RIPE
tech-c:         PT7353-RIPE
status:         LEGACY
mnt-by:         RIPE-NCC-LEGACY-MNT
mnt-by:         digitalocean
created:        2003-06-26T15:46:32Z
last-modified:  2019-05-01T16:19:07Z
source:         RIPE


Checking DigitalOcean, whose services I do use in places, I do not have a droplet with a public IP of  While it's good to know it's not my vulnerable server I still need to know how it's associated to my domain.

Checking DNS

Looking in my DNS[1] control panel there was indeed an A record[2] for which pointed at as the research implied.  Eventually I recalled I'd set up a temporary test server for my wife to experiment with Big Blue Button teaching software.  The DigitalOcean droplet[3] for it had been deleted long ago but apparently I didn't tidy up the DNS records - sloppy and now rectified.

Viewing the site

Obviously this was done in a safe environment!  One of the first things to note was a certificate warning because there was a certificate name mismatch.  Reviewing the certificate showed the DigitalOcean droplet, now using the IP address I'd once had, likely belonged to a Kenyan gift shop.

Screenshot showing certificate details for the gift shop's website.

Going through the certificate warning presented me with a shopping website:

Screenshot of the Gift World Kenya website, with father's day officers prominently displayed.

Don't go through certificate warnings!

As a rule of thumb, proceeding through a certificate warning is a bad idea - it could mean someone is trying to do something nasty.  Equally it could just mean someone forgot to renew and replace their certificate.  I strongly recommend against proceeding through a certificate warning unless you know what you're doing and can accept the risks.

Legality is a difficult question to answer as there are multiple legal jurisdictions that apply.  Personally, I don't consider a bit of passive probing, for information that's been published publicly, to be an issue.  Indeed, for my own site I don't mind so long as you don't do any damage and you tell me of any problems you find.  For me the cut off point is when you do more than just proof a concept.  Clearly a researcher needs to be able to demonstrate they've found a problem when they report it, but downloading all of someone else's data would be a no no.

Without knowing what techniques the researcher used it's difficult to say.  Also, the shop website owner may not appreciate the attention.  I'm trusting that Gaurang remained inside the law, particularly as their choice to responsibly disclose the issue suggests an ethical viewpoint I can agree with.


Many thanks go to Gaurang Maheta for making me aware of these issues.  While I cannot fix the problems of the Kenyan shop I have cleaned up my stale DNS entry, and checked the others too.

Banner image: Cloud security by GDJ on

[1] DNS is the Domain Name System, and translates the word based addresses we humans use into IP addresses that are used by computers.

[2] DNS is a database of record types.  An A record says "this name points at that IP address".

[3] DigitalOcean calls its virtual machines "droplets", to continue the ocean theme.