This was originally reported to ZAP via BugCrowd.

We rated it as a LOW vulnerability and gave the reporter permission to disclose it, which they have done as CVE-2022-27820.

Edit: GH Autolink ➡CVE-2022-27820

We have rated it as LOW as we expect ZAP users to know about the sites they are testing and to know not to send any sensitive information to those sites when testing them with ZAP.
If testing potentially malicious sites then ZAP users should know to take additional precautions, such as running ZAP in a container environment.
If you disagree with our assessment then please comment on this issue.

We would have no problem with one of the suggested solutions being implemented but do not believe that this should be the default option. ZAP is heavily used in development environments where self signed certificates are common.

Note that ZAP does validate the certificates for the Check For Update functionality to ensure that malcious ZAP updates cannot be downloaded from an untrusted site.

From the original report:

Summary

ZAP proxy does not verify the certificate chain of the HTTPS servers it connects to.
For example, it connects without warning to servers presenting a self-signed certificate, an expired certificate, etc.
This opens up a browser configured to use ZAP as an intercepting proxy to:

1. man-in-the-middle attacks;
2. DNS rebinding attacks (to HTTPS servers configured as default virtual server).

Impact

Man-in-the-middle attack

A user should currently avoid sending sensible information when using a browser through ZAP. In particular, he should avoid connecting using real accounts.

Moreover, the user should avoid using an existing browser profile and always use a dedicated profile in order to avoid getting already existing sessions hijacked by a man-in-the-middle.

DNS rebinding attacks

Moreover, a malicious web site could conduct a DNS rebinding attack on some HTTPS services which are usually not vulnerable to DNS rebinding attacks.

The certificate chain validation usually blocks DNS rebinding against HTTPS sites.
However, as this step is disabled when using ZAP as an intercepting proxy, any HTTPS site which is configured as the default virtual host ends up being vulnerable to DNS rebinding attacks.

The attacker could use the user browser to try to attack such a vulnerable site while hiding behing the IP address of the ZAP user.
For example, he could try to:

• brute force passwords;
• send stored XSS payload;
• send abusive posts, comments, spam, etc.

Another interesting approach would be to attacks HTTPS services hosted in the user internal network, possibly bypassing firewalls, WAFs, etc.

Details

When connecting to a self-signed invalid certificate, ZAP generates a valid generated from its own certificate authority. This certificate is configured as trusted in the browser in order to make the TLS interception work. As a consequence, the browser silently connects to this certificate.

Resolution

Mirroring the status of the original certificate chain

This could be fixed by using the following behaviour by default:

• not generate a certificate signed by ZAP internal CA when the HTTPS server presents an untrusted certificate chain;
• replicate the validity period of the original certificate when generating its own server certificate.

Using this approach, the user would be warned against invalid certificate chains but could choose to ignore the error by using the same procedure he would use without the intercepting proxy.

FortiGate use a similar approach.

Rejecting invalid certificate chains

Another approach is to refuse the connection when the certificate chain is invalid. This approach is simpler to implement but not as convenient for the user who cannot easily the error.

For example, when trying to connect HTTPS site presenting a self-signed expired certificate, mitmproxy presents a certificate
which is accepted by the browser but any HTTP request results in 502 error (Bad Gateway). This HTTP error includes a message
explaining the reason of the error such as:

• Certificate verification error for expired.badssl.com: certificate has expired (errno: 10, depth: 0)
• Certificate verification error for wrong.host.badssl.com: Hostname mismatch (errno: 62, depth: 0)
• Certificate verification error for self-signed.badssl.com: self signed certificate (errno: 18, depth: 0)
• Certificate verification error for untrusted-root.badssl.com: self signed certificate in certificate chain (errno: 19, depth: 1)
• TlsProtocolException("Cannot establish TLS with 192.0.2.42:443 (sni: None): TlsException('Cannot validate certificate hostname without SNI')")