ghsa-h362-m8f2-5x7c
Vulnerability from github
Impact
User passwords are stored in the database using the rather outdated and cryptographically insecure MD5 hash algorithm. Furthermore, the hashes are salted using the username instead of a random salt, causing hashes for users with the same username and password to collide which is problematic especially for popular users like the default admin
user.
This essentially means that for an attacker, it might be feasible to reconstruct a user's password given access to these hashes.
Note that attackers needing access to the hashes means that they must gain access to the database in which these are stored first to be able to start cracking the passwords.
Patches
The problem is addressed in Opencast 8.1 which now uses the modern and much stronger bcrypt password hashing algorithm for storing passwords. Note, that old hashes remain MD5 until the password is updated.
For a list of users whose password hashes are stored using MD5, take a look at the /user-utils/users/md5.json
REST endpoint.
Workarounds
There is no workaround.
References
For more information
If you have any questions or comments about this advisory:
- Open an issue in opencast/opencast
- For security-relevant information, email us at security@opencast.org
{ "affected": [ { "package": { "ecosystem": "Maven", "name": "org.opencastproject:opencast-common-jpa-impl" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "7.6" } ], "type": "ECOSYSTEM" } ] }, { "package": { "ecosystem": "Maven", "name": "org.opencastproject:opencast-common-jpa-impl" }, "ranges": [ { "events": [ { "introduced": "8.0" }, { "fixed": "8.1" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2020-5229" ], "database_specific": { "cwe_ids": [ "CWE-327" ], "github_reviewed": true, "github_reviewed_at": "2020-01-30T19:59:06Z", "nvd_published_at": null, "severity": "LOW" }, "details": "### Impact\n\nUser passwords are stored in the database using the rather outdated and cryptographically insecure MD5 hash algorithm. Furthermore, the hashes are salted using the username instead of a random salt, causing hashes for users with the same username and password to collide which is problematic especially for popular users like the default `admin` user.\n\nThis essentially means that for an attacker, it might be feasible to reconstruct a user\u0027s password given access to these hashes.\n\nNote that attackers needing access to the hashes means that they must gain access to the database in which these are stored first to be able to start cracking the passwords.\n\n\n### Patches\n\nThe problem is addressed in Opencast 8.1 which now uses the modern and much stronger bcrypt password hashing algorithm for storing passwords. Note, that old hashes remain MD5 until the password is updated.\n\nFor a list of users whose password hashes are stored using MD5, take a look at the `/user-utils/users/md5.json` REST endpoint.\n\n\n### Workarounds\n\nThere is no workaround.\n\n### References\n\n- [MD5 (Wikipedia)](https://en.wikipedia.org/wiki/MD5)\n- [bcrypt (Wikipedia)](https://en.wikipedia.org/wiki/Bcrypt)\n- [How weak is MD5 as a password hashing function?](https://security.stackexchange.com/q/52461)\n\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [opencast/opencast](https://github.com/opencast/opencast/issues)\n- For security-relevant information, email us at security@opencast.org", "id": "GHSA-h362-m8f2-5x7c", "modified": "2021-01-08T20:31:50Z", "published": "2020-01-30T21:21:58Z", "references": [ { "type": "WEB", "url": "https://github.com/opencast/opencast/security/advisories/GHSA-h362-m8f2-5x7c" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5229" }, { "type": "WEB", "url": "https://github.com/opencast/opencast/commit/32bfbe5f78e214e2d589f92050228b91d704758e" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N", "type": "CVSS_V3" } ], "summary": "Password Hashing: Do not use MD5" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.