Pagerduty website insecurity

I work for a potential Pagerduty customer and am performing my IT security due-diligence on the company and services, and I see that Pagerdury does not monitor for nor correct insecure configurations on their websites and public servers. For example, expired certificates. Can someone from Pagerduty reply as to why this is and what you intend to do about it, please?

COLLECTION TARGET PORT CERTIFICATE AUTHORITY START DATE EXPIRATION DATE
54.227.252.125 443 DigiCert Inc Mar 22, 2016 12:00:00 am Mar 27, 2017 1:00:00 pm
23.21.199.182 443 GeoTrust Inc. Sep 20, 2015 8:18:50 am Sep 22, 2018 7:51:37 pm
54.235.249.128 443 DigiCert Inc Mar 22, 2016 12:00:00 am Mar 27, 2017 1:00:00 pm
23.23.109.49 443 GeoTrust Inc. Feb 14, 2016 5:21:09 am Feb 16, 2019 5:17:23 pm
54.225.222.194 443 DigiCert Inc Jun 21, 2016 12:00:00 am Jun 28, 2017 1:00:00 pm
54.197.254.249 443 GeoTrust Inc. Feb 14, 2016 5:21:09 am Feb 16, 2019 5:17:23 pm
54.225.239.129 443 GeoTrust Inc. Feb 14, 2016 5:21:09 am Feb 16, 2019 5:17:23 pm
54.225.182.165 443 DigiCert Inc Jun 21, 2016 12:00:00 am Jun 28, 2017 1:00:00 pm
23.23.153.154 443 GeoTrust Inc. Sep 20, 2015 8:18:50 am Sep 22, 2018 7:51:37 pm
23.23.143.96 443 GeoTrust Inc. Sep 20, 2015 8:18:50 am Sep 22, 2018 7:51:37 pm
50.16.250.166 443 DigiCert Inc Mar 22, 2016 12:00:00 am Mar 27, 2017 1:00:00 pm

All are easily discovered and tested using the likes of sslscan.

I’ll be watching to see how long it takes for these to be resolved and if future weaknesses go unaddressed.

Hello @kenord,

The IP addresses in the above list are not in use by PagerDuty. They correspond to Heroku app hosts that have been removed from use for some time.

The TLS servers running on them do however happen to be using old certificates with which they were previously configured, even though they aren’t in use. For all hosts that we do currently use, we have monitoring in place to detect expired certificates and warn us about impending expirations.

We do not consider the certificate configuration on these hosts to carry any significant risk because, since they have long been absent from our DNS records, no clients would be connecting to PagerDuty through them.

Thank you for your response. However, should someone manage to take over those systems then they will have access to certificates and private keys that will allow clients to initiate HTTPS sessions if the users choose to ignore security warnings, and we all know that users are very willing to ignore security warnings. It is your responsibility to ensure that assets owned by PagerDuty are not allowed on unauthorised systems no matter what their status is. Allowing these certificates to operate on systems which you have abandoned is very poor security indeed. You should be in contact with whoever is hosting the systems and requesting their immediate termination or removal of the certificate instead of ignoring the problem. I will be recommending to my organisation that we do not use PagerDuty due to your poor response and lack of understanding of security best practice and risk remediation.

Hello @kenord,

To respond and provide a bit more detail here:

However, should someone manage to take over those systems then they will have access to certificates and private keys that will allow clients to initiate HTTPS sessions if the users choose to ignore security warnings, and we all know that users are very willing to ignore security warnings.

We use different server keys for distinct certificates. What that means for this attack scenario is that after the attacker (1) gains access to Heroku and a server’s certificate/private key, (2) manages to poison or hijack DNS:

  • Any given private server key corresponds only to an expired certificate and may not be used with any valid certificates currently in use on PagerDuty systems, so they would be limited to using the expired certificate.
  • Because *.pagerduty.com uses preloaded HSTS, the attacker is dependent on the users disabling hard safeguards that, in all modern browsers, require non-trivial effort from the end user to circumvent. In Chrome (for instance) a user couldn’t just click “advanced” and then “proceed to mycompany.pagerduty.com (unsafe)” but would be met with the error message: You cannot visit mycompany.pagerduty.com right now because the website uses HSTS. (See screen shot below for an example of what this would look like)
  • The certificate in question on any of the above servers would be valid only for specific subdomains; there are no wildcard certificates hosted on any of them. Hence, none would be valid for any given PagerDuty account’s subdomain, but only (ignoring the fact they’re expired) valid for the original special-purpose subdomains that they were used for.

It is your responsibility to ensure that assets owned by PagerDuty are not allowed on unauthorised systems no matter what their status is.

These systems are actually still within PagerDuty’s administrative control, and so the same internal security policies that dictate how other production systems are accessed and managed apply also to them. In this sense they are still “authorized” systems, though not in use.

I hope that provides sufficient clarity as to our risk classification for this issue. For what it’s worth, we do intend to remove the expired certificates from the unused hosts, however that work is not currently a priority as we consider the issue low risk.

For any future security issue reports, please follow our responsible disclosure policy. Thank you!