[SECURITY] Releases are published insecurely
Closed this issue · 4 comments
CWE-829: Inclusion of Functionality from Untrusted Control Sphere
CWE-494: Download of Code Without Integrity Check
The build files indicate that this project is uploading artifacts over HTTP instead of HTTPS. Any of these artifacts could have been MITM to maliciously compromise them and infect the build artifacts that were produced. Additionally, if any of these JARs or other dependencies were compromised, any developers using these could continue to be infected past updating to fix this.
This vulnerability has a CVSS v3.0 Base Score of 8.1/10
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
This isn't just theoretical
POC code has existed since 2014 to maliciously compromise a JAR file inflight.
See:
- https://max.computer/blog/how-to-take-over-the-computer-of-any-java-or-clojure-or-scala-developer/
- https://github.com/mveytsman/dilettante
MITM Attacks Increasingly Common
See:
- https://serverfault.com/a/153065
- https://security.stackexchange.com/a/12050
- Comcast continues to inject its own code into websites you visit (over HTTP)
These Vulnerabilities are Considered "Out Of Scope" by the PayPal Security Team
I originally reported this vulnerability privately to the PayPal bug bounty program but it was determined to be "Out Of Scope" by the HackerOne team that pre-filters these reports.
If this is considered a security vulnerability, I'd advise the PayPal team to communicate this to the HackerOne team.
Here is the link to my original report:
https://hackerone.com/reports/504119
Source Locations
Insecure Download
https://github.com/paypal/gimel/blob/33192730edd6741ef459fba98b84e20d4f3ff980/pom.xml#L42-L58
WARNING! If any of these builds are using a shared or re-used ~/.gradle
or ~/.m2
cache between builds and any of these downloads were maliciously compromised, the compromised jar may remain inside of cache directory and continue to be used in the future.
Insecure Upload
Passwords in this upload are being sent in plaintext and should be considered compromised!
Lines 70 to 73 in 248163c
Fix and Public Disclosure
At a minimum, all of these code locations where artifacts are uploaded insecurely needs to be fixed. Previous releases should be rebuilt with the fix applied. The checksum of the released artifacts and artifacts built in a trusted environment should be made. If the checksums match, you can be certain that they weren't compromised.
If the checksums don't match, indicating a compromised artifact, CVE numbers need to be issued for the potentially malicious artifacts.
The ability to check if checksums match assume that these projects have reproducible builds.
@mach6 Will you be auditing previous releases?
Also, can you communicate this vulnerability to the PayPal security team? It got bounced by the HackerOne team who pre-filters reports.
@mach6 Would you like me to file for the CVE number? Or can you? I've got a lot on my plate, so if you can do so, that would be good.
Ping!