Listen to this Post
The AUSF (Authentication Server Function) component of the free5GC 5G core network implements two primary authentication procedures: 5G-AKA and EAP-AKA’. In the 5G-AKA flow, the AUSF receives a RES (response) value from the UE via the AMF, and compares it with the expected XRES value stored in the AUSF’s context. This comparison is performed using the Go function strings.EqualFold(). This function is designed for case-insensitive string equality, not for cryptographic constant-time operations. It iterates through the characters and returns as soon as it finds a mismatch, causing a timing variation that depends on the position of the first differing character. More critically, the AUSF logs both the received RES and the expected XRES at INFO level immediately before the comparison, exposing sensitive authentication material. For the EAP-AKA’ flow, the AUSF computes an expected MAC (XMAC) and compares it to the received AT_MAC using bytes.Equal(). This function also lacks constant-time guarantees. If the MAC check passes, the AUSF then compares the received RES with the expected XRES using a simple `==` string comparison, which is similarly vulnerable to timing side channels. The correct Go primitive for these operations is crypto/subtle.ConstantTimeCompare(), which executes in constant time regardless of input values. While static analysis confirms the non-constant-time comparisons and logging issues, practical remote exploitation over HTTP/SBI is challenging. Lab tests over loopback HTTP showed that the comparator-level timing signal (in nanoseconds) is dwarfed by HTTP noise (in microseconds). The logging issue, however, is directly and easily exploitable by anyone with access to AUSF logs. This vulnerability was confirmed on free5GC AUSF version v1.4.4 and the current main branch as of May 2026.
DailyCVE Form:
Platform: free5GC AUSF
Version: v1.4.4
Vulnerability: Timing/Logging
Severity: Medium
date: 2026-05-26
Prediction: 2026-06-15
What Undercode Say:
Check for the vulnerable code in the AUSF processor
grep -n "strings.EqualFold" internal/sbi/processor/ue_authentication.go
grep -n "bytes.Equal" internal/sbi/processor/ue_authentication.go
grep -n "XRES" internal/sbi/processor/ue_authentication.go
Example of a vulnerable code snippet found in the analysis:
logger.Auth5gAkaLog.Infof("res: %x\nXres: %x\n", updateConfirmationData.ResStar, ausfCurrentContext.XresStar)
if strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) { ... }
Example of the EAP-AKA' vulnerability:
if !bytes.Equal(MAC, XMAC) { ... }
else if XRES == RES { ... }
A simple Go microbenchmark to demonstrate the timing difference in bytes.Equal()
The benchmark showed a monotonic increase in time as more leading bytes matched.
The median delta from N=0 to N=15 matching bytes was ~0.31 ns.
Exploit:
The timing side channel is not practically exploitable over HTTP/SBI in standard network conditions due to high noise levels. The lab could not distinguish the comparator signal from HTTP latency variations. However, the logging of XRES at INFO level is a direct information disclosure. An attacker with access to AUSF logs can read the plaintext expected response value for authentication attempts. This could be leveraged to bypass authentication if the attacker can also intercept or influence the authentication context.
Protection:
- Remove all logging of authentication materials (XRES, RES, XRES, RES, K_aut, AT_MAC) from INFO logs. Log only metadata like authentication context ID or redacted SUPI/SUCI.
2. Replace all non-constant-time comparisons with `crypto/subtle.ConstantTimeCompare()`.
- Normalize inputs before comparison: decode hex-encoded strings to byte slices, validate lengths, and then compare.
- Add unit tests to ensure no authentication secrets are logged.
- Consider reducing redundant UDM notifications to minimize coarse timing differences between success and failure paths.
Example remediation code:
// 5G-AKA remediation
resStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)
xresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)
if err1 == nil && err2 == nil &&
len(resStar) == len(xresStar) &&
subtle.ConstantTimeCompare(resStar, xresStar) == 1 {
// success
} else {
// failure
}
// EAP-AKA' MAC remediation
if len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {
eapOK = false
}
// EAP-AKA' XRES remediation
res, err1 := hex.DecodeString(RES)
xres, err2 := hex.DecodeString(XRES)
if err1 == nil && err2 == nil &&
len(res) == len(xres) &&
subtle.ConstantTimeCompare(res, xres) == 1 {
// success
}
Impact:
- Sensitive Value in Logs: The 5G-AKA path logs the XRES value. This exposes critical authentication material to anyone with access to AUSF logs, including operators, SIEM systems, or compromised processes. An attacker could use this to authenticate as a valid subscriber.
- Timing Side Channel: The non-constant-time comparisons are a cryptographic weakness. Although not practically exploitable over HTTP in this analysis, the risk is elevated in low-noise environments (e.g., local network, shared CPU, kernel tracing). An attacker with such access could potentially recover secret values by measuring timing differences.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
