EP-01-001 HTTP: Lacking Admin-Interface Security allows CSRF and DOS (Cure53)

[htuch]

From Cure53 Pentest-Report Envoy Proxy 02.2018 report:

It was noticed quite early in the assessment that the Envoy’s Admin Interface, normally
reachable under http://localhost:9901, is highly insecure. This is because it completely
fails to follow modern security standards. There is actual authentication (although per
default the instance is only reachable locally), no HTTP security headers are in place
and CSRF tokens are not deployed. The last point is especially dangerous because all
administrative operations can be carried out by simple GET requests. Therefore luring
an internal administrator onto websites that embed the code like the following will signify
changes to the entire global configuration.

Example HTML (disable logging):
<img src="http://localhost:9901/logging?admin=off">

Example HTML (shutdown the server):
<img src="http://localhost:9901/quitquitquit">

Besides having a mass-impact in terms of modifications, the attacker may even turn off
the server. Both these high-impact action may occur without the administrator noticing
for certain. Although the Envoy team has expressed their awareness of the bad security
premises of its Web Interface, it is still necessary to highlight the importance of relevant
fixes. It is recommended to offer additional authentication, e.g. similar to the Apache’s
digest-auth mechanism. Furthermore, CSRF tokens should be urgently implemented, for
example by utilizing X-CSRF-TOKEN headers on each authenticated request.

[htuch]

It's the assessment of the Envoy product security team that this is not an elevated security risk justifying following https://github.com/envoyproxy/envoy/blob/master/SECURITY_RELEASE_PROCESS.md.

The admin console is known to not have any authentication or HTTP security, and must be secured in any reasonable deployment from untrusted networks. There is a reasonable consideration that if direct access via the browser is granted to an admin (rather than confining to programatic use via curl etc. inside a trusted network), that CSRF is something we'd like to mitigate as an incremental improvement. We advise users to be wary of this concern until such mitigations are in place.

One such mitigation might be to force all side effecting operations to be POSTs, which would avoid the example provided above, but is still vulnerable to forms + Javascript execution. We probably should adopt CSRF tokens if we are offering a first class web interface (rather than API, which has different authentication mechanisms). We have a longer term discussion occurring in #2763 on how to improve security of the admin console, including the browser vs. API discussion. CC: @jmarantz

[htuch]

@mattklein123 would one reasonable thing to do in the short term is add more explicit documentation on the admin console trust model and dangers?

[mattklein123]

@htuch yes. I will do this and will assign this to myself for inclusion in 1.6.0. I would suggest that we track long-term admin security in the other tracking issue.