A few clients received the following e-mail:

My name is Charles Bourasseau, and I'm an independent IT security expert.
I have found a security issue on your website http://example.org.

I was able to access a lot of files that contain sensitive data.
I attached a screenshot of the files I found to this email.

I would be happy to give you the method I used to access these files in order to let you fix it.
Do you have a bug bounty program or offer financial rewards for security advice?

Please forward this email to the right person, if you are not responsible for the security of the website.

This email is personal and in no way related to any of my employers.

Best Regards,
Charles Bourasseau

The screenshot included a listing of the root directory of the website, which had one non-standard directory specific to the client, so it was a rather good hint that he had access to privileged information. I am always skeptic of such emails, usually scams, borderline extortion, but in any case the screenshot did provide sufficient proof to investigate.

The client website runs Drupal 6. My first reaction was to check whether all modules were up to date (against a Drupal 6 LTS vendor such as mydropwizard). They were. So either this was an unknown vulnerability or a server configuration error (which seemed unlikely, we run a pretty standard stack based on Aegir). However, it was even more unlikely that this was an unknown Drupal vulnerability, since such an attacker would gain more (credibility and reputation) from reporting the issue to the Drupal security team. So either a server configuration error, or some old third-party library lurking around?

I had a look at the web server logs for suspicious “POSTs” (or anything else than a GET), since many rootkits tend to upload malicious code this way, which would then allow him to do a directory listing. I didn’t find anything suspicious. Looking at “GET” requests manually would have been like searching for a needle in a haystack.

Talking with friends, I was offered to test using Warden by Delve Labs. I was skeptic because most scanners find a ton of false-positives and are rarely of much value unless you run out of date software. However, it could probably find server configuration errors. A few clicks and about an hour later, Warden discovered that the https://example.org/.git/ directory was returning an “Access denied” (403) error, which is suspicious.

I then grepped my access logs for “.git” references and found results that seemed credible.

[16/Nov/2016:13:17:42 +0000] "GET /.git/HEAD HTTP/1.1" 200 378 "-" "git/1.9.1"

Facepalm: I didn’t realize git over https was this simple. Git requests the index file and from there it can clone the repository over regular http. The .htaccess of Drupal 7 on Apache blocs this by default, but Drupal 6 does not.

I was able to clone the git repository used to manage the website using plain https:

git clone https://example.org/.git/

This was a lead, but a website can have many security issues (nothing is bullet-proof!). How to be certain that this was the issue he found? Going back to the screenshot that was sent, I then noticed that the file listing in the screenshot did include one of the client’s custom directories, but it did not include two files that were not part of the git repository. Therefore it was pretty clear that the attacker didn’t have access to the disk, only to the git data. The git repository didn’t contain anything of value, so this was clearly an extortion scam.

For those into victim blaming: 1- yes, Drupal 6 is really ancient, it’s not really up to me (the clients are in the process of being upgraded). 2- I use Git mostly to simplify syncing various code platforms and tracking patches (pending to be merged upstream), nothing of value.

Other lessons learned

It’s good to have a disclosure policy that’s more explicit of what people can expect when they report a vulnerability. It’s a good way to keep the trolls away. Sophos is a good example of “give us 30 days to fix it or you can go public about it”, CERT is another good one. Zendesk on Hackerone is a good example if you can pay for bounties (if you’re big enough, you may want to consider it). For most organizations, it’s probably better to have a disclosure policy, but not a bounty policy. Bounties will attract trolls.

If you’re like this guy, who maybe had good intentions when reporting this issue: be up front about the issue when reporting it, how you discovered it and why it’s sensitive. If you really are an expert, I might want to work with you. Tell me more about your background and what kind of services you provide. I want to make sure that if I respond, I won’t be feeding a troll. I have seen so many bogus security reports (of people clearly looking to prey and make a quick buck), you don’t want to look like them.

Thanks

Hat tip to Delve Labs for helping out with the issue. While it can scan individual sites, Warden does much more, such as auto-discovering assets and re-evaluate risks through regular scans. If you’re hosting a bunch of junk managed (or forgotten) by various subcontractors, definitely have a look. It’s also ridiculously easy to use.

Update

Jon @ Megaphone Technology Consulting proposes on his blog a neat short snippet to monitor this issue with Icinga2.