Receiving a security disclosure for an old subdomain
After receiving a security disclosure from a security researcher I knew I needed to investigate.
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, jules.jonsdocs.org.uk, 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:
- Git repository found
- OpenSSH 2.3 < 7.7 is vulnerable to username enumeration
- 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 https://jules.jonsdocs.org.uk/.git/config.
[core]
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:
<?php
phpinfo();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.
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 jules.jonsdocs.org.uk was pointing, I turned to nslookup. We can clearly see it's pointing at an IP address of 167.172.62.49.
> nslookup jules.jonsdocs.org.uk
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: jules.jonsdocs.org.uk
Address: 167.172.62.49Next 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 167.172.62.49
...
Found a referral to whois.ripe.net.
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '167.172.0.0 - 167.172.255.255'
% Abuse contact for '167.172.0.0 - 167.172.255.255' is '[email protected]'
inetnum: 167.172.0.0 - 167.172.255.255
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 167.172.62.49. 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 jules.jonsdocs.org.uk which pointed at 167.172.62.49 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.
Going through the certificate warning presented me with a shopping website:
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.
Is it legal?
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.
Acknowledgements
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 OpenClipart.org.
[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.