Open baptx opened 6 years ago
I agree that this is a potential security issue, but the chances of it being exploited are really low. Don't take me wrong, we should fix it, but there are still other more important issues.
If we know someone using w3af on the same network, it would be a serious problem. I understand there are other issues but I think security should be a priority. Is there a bug bounty program for vulnerabilities like for OWASP ZAP? (https://bugcrowd.com/owaspzap) By the way, I opened another issue and it would be good if someone can confirm the problem or has a solution: https://github.com/andresriancho/w3af/issues/16304
I still believe that this is a low-medium priority issue. If you believe it is more important than that, which is totally acceptable and understandable, please feel free to send a pull request to fix the problem.
We don't have a bug bounty.
My solution was to remove w3af/core/controllers/daemons/proxy/ca
folder and create a symlink with command ln -s /home/username/.mitmproxy/ w3af/w3af/core/controllers/daemons/proxy/ca
to use the CA certificate from mitmproxy (I read this tool is used by w3af so I think there is no problem using the same certificate).
Should I create a pull request deleting the ca folder? (the documentation should be updated also to tell we should create a symlink to .mitmproxy folder or create the certificate manually)
Your solution is great but requires ~/.mitmproxy/
to exist, which might or might not be available when the w3af user wants to run the proxy: it is created by mitmproxy, w3af uses mitmproxy, but... when exactly does mitmproxy create that directory and files?
Since we don't know the answer to that question, and the answer might change, I recommend that w3af creates the ~/.w3af/ca/
directory and uses that.
The only place where the CA directory is referenced is:
https://github.com/andresriancho/w3af/blob/master/w3af/core/controllers/daemons/proxy/proxy.py#L80
So, the ideal fix would:
@andresriancho Since there is still no fix for this issue, I think removing the certificates in w3af/core/controllers/daemons/proxy/ca/
from the repository is safer than distributing the software with a backdoor. People will just have to create a symlink or a certificate manually, which can be explained in the README file (until someone develops an automated solution like discussed above). I think security should be a priority over the convenience, especially for a security software where people should be serious about security.
I noticed a difference between mitmproxy and w3af CA certificate which could be a security issue.
The documentation of mitmproxy says "For security reasons, the mitmproxy CA is generated uniquely on the first start and is not shared between mitmproxy installations on different devices" (http://docs.mitmproxy.org/en/latest/certinstall.html). When using mitmproxy and visiting mitm.it to install the CA certificate, it also says: "Other mitmproxy users cannot intercept your connection. This page is served by your local mitmproxy instance. The certificate you are about to install has been uniquely generated on mitmproxy's first run and is not shared between mitmproxy installations."
But the documentation of w3af says "To avoid certificate errors in your browser it’s recommended that you add the CA certificate stored at /w3af/core/controllers/daemons/proxy/ca/ to your browser’s list of trusted CAs" (http://docs.w3af.org/en/latest/ca-config.html). The CA certificate is shared by every users and located here: https://github.com/andresriancho/w3af/tree/master/w3af/core/controllers/daemons/proxy/ca
This would mean that every w3af user are at risk of being a man-in-the-middle victim of other w3af users because they use the same CA certificate. The attacker would not even need to physically access the victim's machine with ARP spoofing.
Can you confirm this security issue?