19.5.3 Replay attacks
As the name suggests, in a replay attack, Mallory reuses or replays information – typically, a message – that she recorded during a previous protocol run. Mallory can replay the message to the same communication party – for instance, sending Alice a message that was originally sent by Alice herself – or to some different communication party – for instance, sending Alice a message that was originally sent by Bob. Despite the original message being authenticated by means of a MAC or a digital signature, the replayed message might still be accepted by Alice as authentic. Replay attacks therefore threaten message authenticity.
The equivalent of a replay attack on persistently stored files is a restore attack where Mallory replaces one or more files on Alice’s machine with their earlier versions. This might be very dangerous if the files contain configuration data, especially the configuration of network-facing software such as a web server or a firewall. In a restore attack, Mallory can ingest a configuration that is known to be vulnerable – for example, due to a vulnerable software package the web server relies on – and, thus, introduce a weakness she can later on exploit.
The working principle of a replay attack is illustrated in Figure 19.11. Alice and Bob use a keyed hash function hk – effectively, a MAC – to protect the integrity and authenticity of their messages. If no time stamp or nonce (such as a random number or a counter) is used as part of the input for calculating the MAC, Mallory can store the message D,h(D) and, later on, replay it.
Figure 19.11: Working principle of a replay attack
Now, imagine that Alice is a controller of an automated gate, and the message D,h(D) opens the gate. In our example, it is sufficient for Mallory to capture the message once, when Bob opens the gate. From then on, Mallory can always open the gate by replaying D,h(D). Importantly, this does not require any cryptanalysis and so the attack would work even if the underlying keyed hash function is cryptographically strong.
The reason why a replay attack works in the preceding example is the missing verification of messages’ timeliness or freshness. In other words, because no time stamp, nonce, or other means of contextualization are used, Alice has no way to verify that D,h(D) was not previously sent.
A practical example of a replay attack is so-called cookie hijacking. Because HTTP is a stateless protocol, cookies were traditionally the only – and they are still the prevailing – option for persistently storing data on the client.
Persistent cookies are stored on the client’s hard drive as long as their expiry date is valid and are frequently used for user identification. A typical example is the case of consecutive visits to a web application.
Web browsers store cookies in known file system locations and in known formats. Thus, if Mallory obtains access to Bob’s computer or is able to eavesdrop on the communication between Bob and the web server, she can steal Bob’s cookie for some web application, replay a message (URL, cookie), and gain access to that URL as Bob – possibly triggering some action if the web application has a RESTful API.
As an example, assume a web application offers detailed weather information under https://www.weather.xyz for payment. Assume further the application uses cookies containing a data item userID to identify users. If the application processes HTTP requests to https://www.weather.xyz without additionally authenticating the user, Mallory can perform the HTTP requests as Bob if she obtains Bob’s cookie.
Leave a Reply