RACH Replay Attack

[cueltschey]

Random Access Channel Request Replay Attack

Implementation (UE):

• Capture the RACH requests of other UEs
• Replay these requests later to confuse the RAN

Mitigation (UE and gNB):

• add identifiers to RACH requests like timestamps or identifiers

Attack Metrics:

• Disconnected UEs
• Channel quality reduction
• gNB crash / malfunction

[cueltschey]

A Replay Attack on the Random Access Channel (RACH) in cellular networks involves an adversary capturing legitimate RACH requests from UEs (User Equipment) and retransmitting them at a later time. This attack aims to confuse the network by reintroducing previously valid requests, potentially leading to resource allocation issues, unauthorized access, or denial of service. Since the RACH procedure is a critical part of the initial connection process in LTE and 5G networks, the replayed messages can disrupt normal operations, causing delays or failures in establishing connections. The attack exploits the lack of unique identifiers or timestamps in the RACH requests, allowing the adversary to interfere with the network by replaying captured messages without being detected.

To perform a Replay Attack on RACH in srsRAN, we can use a tool like srsUE to first capture a legitimate RACH request. This can be done by running srsUE and monitoring the RACH preambles sent during the connection process. Once a RACH request is captured, we can modify the srsUE or use a separate script to retransmit the captured RACH message at different intervals. Set up srsGNB to act as the base station and observe the handling of these replayed RACH requests. By analyzing the network's response, We can determine how vulnerable it is to replay attacks and evaluate the effectiveness of potential countermeasures, such as implementing unique identifiers or timestamp-based validation in the RACH process.