Sensitive Information Disclosure via /certificates route

[pduldig-at-tw]

Summary

Kong provides the /certificates route via the Admin interface. The GET method produces a json output that contains an json encoded PEM files containing the certificate and private keys, and their associated Virtual Host FQDN(s).

This is an sensitive information disclosure condition, as I would argue that the raw key material should NEVER be visible via GET /certificates. One could make a case for the certificate (public keys), for verifying the correct certificate in place for a host -- but the private keys -- not so much.

By default, the admin interface is open and unauthenticated, and ships with HTTP port enabled. This should be considered 'insecure by default', and there are instances of kong online (some with production certificates) that have compromised their key material via an open admin interface.

Additionally, it is never a good thing to transmit private key material over HTTP. It is easy for an administrator to inadvertently disclose their private key material to a global passive HTTP observer. I suspect more than one Kong admin has 'handed their keys over' by accessing this route via HTTP.

Regarding the POST to the /certificates route; It is not advised that this be done over internet bound HTTP for the same reason, but local HTTP may be acceptable (ie: http://localhost:adminport). I feel the documentation should disclose the risks to the administrator, who may be uploading the certificate material remotely.

I understand that the administrative interface should be secured, but removing this attribute of the JSON is a simple, easy to fix, disclosure issue that manifests because of the lack of admin authentication by default.

Steps To Reproduce

(admin):

1. Install Kong 0.11
2. Install a cert with PUT to /certificates route (any random internet jerk):
3. Issue a GET to /certificates
4. Steal your private keys

[p0pr0ck5]

Hi @pduldig-at-tw,

Thanks for the input. I would say this falls into the same vein as https://github.com/Kong/kong/issues/1237 (and, more legacy, https://github.com/Kong/kong/issues/385). Some good material there worth chewing on regarding how we handle sensitive information.

Regarding documentation warnings, the docs for Kong are open source and available at https://github.com/Kong/getkong.org. Would you consider a PR warning about plaintext transmission of sensitive data? We can review it further over there. Thanks!

[pduldig-at-tw]

Hi p0prock5,

Thank you for the references to the other disclosure issues. I feel that the database backed storage/encryption is a seperate issue (more of a best practises concern), where as in this situation there are actual Kong servers online with inadequate admin api protection that have exposed their private keys.

I would consider this a high severity vulnerability, and it may be worth obtaining a CVE so that users can be informed. I strongly recommend this be fixed ASAP and a new release issued that does not have this private key disclosure issue. In #385 The API disclosure issue was raised Jul 8, 2015 and it would appear that every release including latest has this vulnerability. You can apply for a CVE here: https://iwantacve.org/

Regarding the docs, I will log a PR with some additional wording.

[p0pr0ck5]

Thanks. I don't think a CVE here is warranted. If we had indicated that private key data would not be presented to a client, and we inadvertently leaked that data, I would consider otherwise, but no part of our documentation or design paradigm indicates this. Reference: https://getkong.org/docs/0.11.x/admin-api/#certificate-object. I will also note we do have documentation regarding best practices for securing the Admin API: https://getkong.org/docs/0.11.x/secure-admin-api/.

To note, I do not think we should be complicit here; you have a valid point. But I don't believe it warrants a CVE, and I would strongly hesitate to call this a "vulnerability". From our perspective, obscuring such data is not part of our threat model here; we strong encourage users to adopt a holistic, defense-in-depth approach to securing Kong installations and the Admin API. Again, I want to emphasize that I'm not arguing that there's no room for improvement. We are indeed aware of the implications here. At it's core, the Admin API transparently represents the objects stored in the Kong config.

[pduldig-at-tw]

Thank for acknowledging the issue but I want to stress that this design is leaking private keys 'in the wild'.

The following shodan scan reveals there are (today) 712 exposed HTTP admin interfaces. How many of them are leaking their private keys?

https://www.shodan.io/search?query=kong+port%3A8001

A CVE revealing this issue would help inform folks that have an insecure configuration. As the product is shipping insecure by default, (and the number of results found online), I feel this needs to be addressed.

[p0pr0ck5]

@pduldig-at-tw we don't think this warrants a CVE assignment request. Ultimately, it's the responsibility of the user to secure the Admin API- we explicitly call this out in the documentation. And in cases where the Admin API is publicly accessible, the presence of TLS wouldn't help. Our posture here is, if the Admin API is accessible, it is assumed that the client has full authority to access and configure Kong entities. Likewise, stripping the private key data from the Admin API response could be considered a more secure posture in some cases, but would break functionality elsewhere (consider a UI integration in which TLS cert/key pairs could be defined and edited). Again, the model that we assume here is that of transparency.

With respect to Kong shipping as "insecure by default", there is certainly some room for improvement. We could disable plaintext connection handling by default, but this then requires uses to configure a valid TLS cert/key, or requires an unsigned certificate is used, and force the user to click-through security warnings, just as part of the 'getting started' process (and I wouldn't ever want to design software that encourages such bad practices and psychology). Neither approach provides an intuitive introduction to the software. Certainly, an intuitive introduction is not enough, I agree; the proper approach is to provide a robust environment in which to secure the application, and encourage holistic best-practices through documentation and community engagement.

To address the concern of exposed Admin API interfaces: quite simply, there's nothing we can do about this. We can encourage users to secure their installations, and provide guidance in doing so (and we do: https://getkong.org/docs/0.11.x/secure-admin-api), but ultimately it is up to the user to limit access to any sensitive application interface. In cases where a user's threat model assumes that any given element of Kong configuration is sensitive and should not be exposed to the Internet at large, a sane approach to securing Kong requires that multiple layers of defensive posturing be adopted. This includes network, session, and application-layer security controls be put in place. Again, we can advise on this, offer our suggestions and recommendations, and engage in discussion with the community, but the final responsibility for securing software installations lies with the end user.

Moving forward, I do agree that there are ways to improve how Kong handle sensitive data; as noted, the above issues are trackers for these discussions, and in the future we may consider configuring what and how database entities are exposed over the Admin API. Again, please reference the links I left above for previous discussions and anchor points for such issues. We would gladly welcome your feedback and any code contributions you would like to make.

Given the above, I will be closing this issue. Thank you for the discussion. Please feel free to continue to reach out to us and the community via Gitter or the mailing list (https://groups.google.com/forum/#!forum/konglayer); such forums are the appropriate place for the kind of lengthy discussion that these contexts deserve. Github, as we note, is not the appropriate forum; we reserve Github issues for actual bugs and problems running Kong. Thank you for your understanding, and thank you again for the discussion! We are always encouraged to hear from the community.