My first vulnerability submission(s)

I’ve never previously submitted a vulnerability report to a provider. In the past I’ve acted on a few where I’ve run bug bounties for clients’ websites, but never from the ‘ethical hacker’ side.

This week has been rather different, though.

Currently I’m testing several managed WordPress hosts; many, in fact. I already use four (I know, right!) and I want to consolidate to one, for a variety of reasons. Therefore, I’ve been signing up for and trying out as many managed WordPress hosts that I consider worthy of my and my clients’ sites, because to me it’s important (i.e. business-critical). We’re talking premium, premium managed WordPress hosts.

Now, I am a security-focussed techie but I’m not a hacker (in the sense of making a living searching for vulnerabilities, ethically or not, other than as part of my normal IT security defence strategies).

However, this week I discovered noticed three, one each at three separate hosts.

Number 1:

• 8/11/2020: Contacted Chat Support advising I may have found a vuln
• 8/11/2020: Chat responded advising they’d “be in touch”
• 8/11/2020: I asked if they run a bug bounty
• 8/11/2020: Chat advised no bug bounty program but is setting one up
• 8/11/2020: Chat advised they’d have Manager or Lead Developer email me
• 8/12/2020: Contacted Chat requesting an update
• 8/12/2020: Chat advised Development Team will be in touch
• 8/12/2020: Chat advised they do have a bug bounty program
• 8/12/2020: Located bug bounty program. Domain not in program
• 8/12/2020: Advised Chat unable to submit report via bug bounty program
• 8/13/2020: Chat asked me how I was getting on submitting report
• 8/13/2020: Repeated unable to submit via bug bounty for multiple reasons
• 8/13/2020: Chat advised Head of Development will email me
• 8/13/2020: Later, Head of Development emailed me. I reported the vuln to him
• 8/13/2020: HoD replied and advised “We are aware of that oddity. It’s something the current dev/product team inherited from past teams.” … “I totally agree however that it’s still an issue to [redacted].” … “As I’m sure you can imagine this will be easy to fix. I’ll run it by our product team tomorrow to see if they have any prefered way to get this changed”.
• 8/14/2020: Looking forward to an update

Number 2:

• 8/11/2020: Contacted Chat Support advising I may have found a vulnerability
• 8/11/2020: Asked if host ran a bug bounty – reply, no
• 8/11/2020: Chat provided appropriate email address for vulnerability report
• 8/11/2020: Emailed details of vulnerability
• 8/11/2020: Within an hour, reply received from host’s Head of Product, “… All this said, I totally agree with you. You will see [redacted] going away quite soon.”
• 8/14/2020: Looking forward to hearing they’ve resolved the issue, hopefully as quickly as they responded.

Number 3:

Not yet submitted. Not yet convinced myself it’s actually a vulnerability, therefore need to think some more.

One week, three managed WordPress hosts. Two definite vulnerabilities identified and reported (one more possible). Both of those reported advised me they agree and they’re fixing them.

Of course, responsible disclosure prevents me from naming the hosts or the vulnerabilities for 90 days, to allow the providers to fix. I’ll respect that because it’s the right thing to do.

In conclusion, a good result (except the lengths needed to actually report number 1). There are also two more hosts I intend to sign up to and trial. To be frank, I’m not expecting any issues with them.

Finally, you can find a high-level of that which I do normally, at jamesbliss.com

Update 8/15/2020: It has only just occurred to me that I didn’t check if either host (above) publishes a security.txt page under the /.well-known/ directory.

I have now checked. They don’t. Both returned:

“Oops! That page can’t be found.”

Purposely I didn’t screenshot the 404s, as it would have immediately given away the hosts in question.

For more info on “security.txt” see: securitytxt.org, IETF, WikiPedia, Troy Hunt & Scott Helm)

Also…