The application uses a hashing algorithm that has been established by researchers to be unsafe for protecting sensitive data with today's technology.
Recommendation
Cryptography is hard. There are lots of little mistakes you can make in your cryptosystem that can leak information, or worse - but choosing a known unsafe hashing algorithm can be a big mistake. This is why we wanted to alert you to the presence of a hashing algorithm being used that doesn't meet our standards.
Obviously, there are lots of times when a hashing algorithm like MD5 or SHA-1 is used in a way that doesn't represent realistic risk to your organization. However, if you find yourself needing to switch hashing algorithms, doing it in the code is very easy; data migration is a much bigger problem. Here's code that gets a MD5 digester, which is considered BROKEN by today's standards because it's not nearly as collision-resistant as once thought:
The following code retrieves a SHA-256 cipher, which is considered MUCH STRONGER for many reasons (including a 256-bit hash, which is less likely to fall victim to a birthday attack):
MessageDigest safeDigester = MessageDigest.getInstance("SHA-256"); // Safe!
Attacks against unsafe digests are more than theoretical; undirected collisions can be found on an average laptop in a few seconds. Directed collisions can be generated with relatively modest resources. That being said, all practical attacks would seem to require cryptographers of rare quality and the resources of a mid-large sized organization. Therefore, you should carefully decide how likely you are to face such an attack when estimating the severity of this issue. There is a common saying in cryptography (attributed to the NSA), "Attacks always get better; they never get worse." Make your cryptographic design accordingly!
Vulnerability ID: W9L9-S2IR-UHPP-PO7F
Application Name: Petclinic-Quicky
Vulnerability Link: https://apptwo.contrastsecurity.com/Contrast/static/ng/index.html#/6119fcd6-5a74-48e8-aff8-092520138ef3/applications/e92a7ce4-04a0-470f-b5fe-cd1e6017801b/vulns/W9L9-S2IR-UHPP-PO7F
What Happened?
The code:
com.zaxxer.hikari.util.DriverDataSource#getConnection(), line 136
...obtained a handle to the hashing algorithm seen here, which is considered insecure:
digest = java.security.MessageDigest.getInstance("MD5")
What's the risk?
The application uses a hashing algorithm that has been established by researchers to be unsafe for protecting sensitive data with today's technology.
Recommendation
Cryptography is hard. There are lots of little mistakes you can make in your cryptosystem that can leak information, or worse - but choosing a known unsafe hashing algorithm can be a big mistake. This is why we wanted to alert you to the presence of a hashing algorithm being used that doesn't meet our standards.
Obviously, there are lots of times when a hashing algorithm like MD5 or SHA-1 is used in a way that doesn't represent realistic risk to your organization. However, if you find yourself needing to switch hashing algorithms, doing it in the code is very easy; data migration is a much bigger problem. Here's code that gets a MD5 digester, which is considered BROKEN by today's standards because it's not nearly as collision-resistant as once thought:
The following code retrieves a SHA-256 cipher, which is considered MUCH STRONGER for many reasons (including a 256-bit hash, which is less likely to fall victim to a birthday attack): MessageDigest safeDigester = MessageDigest.getInstance("SHA-256"); // Safe!
Attacks against unsafe digests are more than theoretical; undirected collisions can be found on an average laptop in a few seconds. Directed collisions can be generated with relatively modest resources. That being said, all practical attacks would seem to require cryptographers of rare quality and the resources of a mid-large sized organization. Therefore, you should carefully decide how likely you are to face such an attack when estimating the severity of this issue. There is a common saying in cryptography (attributed to the NSA), "Attacks always get better; they never get worse." Make your cryptographic design accordingly!
First Event
Last Event
HTTP Request
(No HTTP Request)
References
https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet