Am I affected?
Description
Use of a One-Way Hash with a Predictable Salt vulnerability in team-alembic AshAuthentication allows readers of the audit store to recover the client IP addresses that the audit log add-on's :hash privacy mode is meant to pseudonymise.
AshAuthentication.AddOn.AuditLog.IpPrivacy.hash_ip/1 computes a single unkeyed :crypto.hash(:sha256, salt <> ip) and truncates the result to 16 hexadecimal characters. The salt is read from the :audit_log_ip_salt or :secret application config keys, and falls back to the constant "default-salt-change-in-production" published in the library source when neither is set, with nothing warning that the default is in use. The IPv4 space is only 2^32 values and SHA-256 is fast, so the whole hash table is precomputable and every stored value maps back to its source address. Truncating to 16 characters does not help, and even a configured salt leaves the hash cheap enough to enumerate once it leaks.
This issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Weaknesses & attack patterns
Weakness
CWE-760
·
Use of a One-Way Hash with a Predictable Salt
in catalog →
MITRE ↗
Attack patterns
CAPEC-112
·
Brute Force
MITRE ↗
Affected — Hex / ash_authentication Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / team-alembic/ash_authentication Repository ↗
modules · source files · routines
Configurations
Only applications that enable the audit_log add-on and set its ip_privacy mode to :hash store the affected value. Other modes (:none, :truncate, :exclude) do not reach hash_ip/1.
The complete break additionally requires the default salt, that is neither :audit_log_ip_salt nor :secret configured under the :ash_authentication application. This is the out-of-the-box state: no warning or error is raised when the hardcoded salt is in use.
References
Credits
CVSS breakdown
CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N