4

I came across a test where the instructions were to circle all the correct answers. I'm looking for an explanation to the answer for this question:

Question: a replay attack is a threat against
Answers: 1) confidentiality 2) integrity 3) availability
Correct: 2) integrity
Explanation: attacker is faking the authentication process which is a level of indirection

First of all, is there a clear cut answer or is it more of an art interpreting the rules of CIA? Second, isn't the data being stolen and nothing is getting written to? Does it count as a write, just falsely authenticating to a system?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Celeritas
  • 10,039
  • 22
  • 77
  • 144
  • Where's this question from? A link would be great. – Neil Smithline Nov 04 '15 at 05:52
  • The question does not state that the replay attack provides access to information which has a confidentiality requirement, therefore the only conclusion that can be drawn is that there is a threat against the integrity of whatever system is in place that the replay is circumventing. – R15 Nov 04 '15 at 07:55

3 Answers3

12

A replay attack is an attack where you record a legitimate transaction and then replay it at a later date.

It is not an attack on confidentiality because the attacker isn't learning any new information: he has the same data than what he recorded in the first place. it might lead to an unauthorized access but that is a different issue.

It is not an attack on availability because the target system will still be functioning normally (again, unless the replay attack opens up the way for a different kind of exploit).

It is, however, a breach of the system integrity because it allowed an unauthorized transaction.

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 4
    In addition to Stephane's good answer, note that the attacker *might not even know* the content of the replayed message, which could be encrypted. So this is not a confidentiality breach. In this case, of course, the attacker won't know which effect his attack will have, but he might want to do so as a DoS. – dr_ Nov 04 '15 at 09:21
  • I still don't see it pertaining to integrity. From [here](http://security.blogoverflow.com/2012/08/confidentiality-integrity-availability-the-three-components-of-the-cia-triad/) "Integrity of information refers to protecting information from being modified by unauthorized parties.". in this situation no data is being modified. – Celeritas Nov 04 '15 at 09:56
  • 1
    @Celeritas In this case, it's new, unauthorized data that is being added. That counts as "modification" as far as the global dataset is concerned – Stephane Nov 04 '15 at 10:02
  • @celeritas at a minimum, the access log has been manipulated – Neil Smithline Nov 04 '15 at 15:18
  • @Stephane what data is being added? – Celeritas Nov 05 '15 at 01:11
  • 2
    @Celeritas The replayed data. Imagine that we have a fund transfer system: A signed, encrypted packet sent to a bank say "give 10€ from Bob to Alice". If Alice records the packet and send it again to the bank, she performs a replay attack: adding new, fraudulent transactions to the system. – Stephane Nov 05 '15 at 08:17
  • @Stephane I guess in that sense it would be integrity, but I thought replay attacks usually replay the authentication process (when I first learned about them I was given the example of replaying the same signal a garage door opener gave out to break into the garage). – Celeritas Nov 05 '15 at 08:19
  • 2
    No: a replay attack is any attack where you replay the content of a previous, legitimate transaction. Replaying authentication is a common type of replay attack but it is in no way the only one. – Stephane Nov 05 '15 at 08:21
  • 1
    @Celeritas, we cannot know the side effect of any particular operation. Even a seemingly innocuous message that queries a bank account for a balance, where the entire exchange is encrypted still presents a problem. What if the user is only allowed 10 queries/day? Nine replays and the user can no longer check a balance. From your definition above "...protecting information from being modified by unauthorized parties" we need to protect the user's "daily balance query limit" from modification by Ralph the Replayer. – Andrew Philips Nov 06 '15 at 06:57
4

The question is usually a distraction and a rat-hole. CI & A are goals for properties that system designers aim for. A replay is a type of attack. Assuming that there is a perfect mapping between attacks and goals gets people tied up in knots.

In threat modeling, people often try to categorize attacks they've discovered according to STRIDE, and get caught up in questions like this. (STRIDE is a mnemonic for violations of AINCAA, a super-set of CIA.) The question I encourage them to ask is "what good does it do to categorize in that way?" and I've never in a decade of teaching threat modeling heard a good answer.

Stephane's analysis is good; a replay attack is a violation of integrity, and that can help you decide you need authentication controls in the protocol or system. However, you can get that answer in many easier ways.

Adam Shostack
  • 2,659
  • 1
  • 10
  • 12
  • I'm not sure this answers the question. It is a great (and perhaps necessary) comment, but not an answer (you merely echo Stephane's words). – schroeder Nov 05 '15 at 16:21
  • So I'm not a stackexchange expert--when it's a bad question, is the right thing to add a comment rather than an answer? – Adam Shostack Nov 05 '15 at 16:26
  • I comment on unclear questions and provide answers on misguided ones (like this). – u2702 Nov 05 '15 at 21:51
1

The key defining factor of a replay attack is that the replay'd message is treated as legitimate traffic and has some effect. Simply being able to replay a transaction isn't enough - it has to also look like regular traffic.

For example, say you have a programmable wireless car-key. You have to type your password into both the key and at some point the car, lets say.

If the password is sent to the car in plaintext, it is both vulnerable to confidentiality AND integrity attacks (your third criteria, availability, would be if you could jam/block the car-key or not).

So say you encrypt the password with SHA9000, and send that to the car. Eavedroppers can no longer see/decrypt your password and it's no longer vulnerable to confidentiality attacks, but since your password hashes the same way every time it can simply be replayed.

Now imagine that you don't encrypt the password, but you do send the password plus the current time of day. Now communications are no longer confidential, but they are protected from 'dumb' replay attacks. I say dumb, because the attacker knowing the protocol could easily replicate it knowing the password, so we haven't got true integrity protection yet, but its a step in the right direction. Unlike confidentiality attacks, integrity attacks have a much broader spectrum of vulnerability. It's often not all or nothing, but somewhere in between. Certain kinds of packets maybe, or perhaps "60% of the time it's vulnerable every time" if it's PRNG related... it used to be a bit of a cat-and-mouse game with protocols having all sorts of weird checksums, etc, to ensure it was a legitimate device sending them, but attackers would eventually learn and dupe the protocol... early security jobs mainly focused on communication integrity.

Then the wide-spread adoption of encryption changed all that, because everything wrapped in a layer of encryption carries the authenticity of the encryption too.

For example, in our car-key example, if you concatenate the password and the time of day together into a single string, and encrypt that, you can get integrity and confidentiality in one.

J.J
  • 775
  • 1
  • 4
  • 6
  • 1
    JJ, this is a good explanation. Just to clarify, a hashed password is not "encrypted" even though people use that terminology, as it cannot be "decrypted" in the cryptographic sense. It's hashed, it becomes a verifier, etc. Also, just encrypting the msg isn't enough. It also requires a separate integrity protection unit. In a well designed algorithm, there would be two keys, one for encryption and one for hashing (MAC(msg,key)). Using the same key for both opens up a two-pronged attack. Embedding the hash inside the encrypted message also has some issues (I cannot currently remember why). – Andrew Philips Nov 06 '15 at 06:43
  • 1
    All good points, and you're right I shouldn't be so lazy with my terminology - particularly when explaining things to newcomers looking to learn the basics. In my example the integrity protection unit was the time-of-day, assuming the key and the car were synced. Of course, in real life scenarios this wouldn't happen because they would come out of sync (you have no idea how many times i've been locked out of AWS servers because my gemalto 2-factor auth. drifted too far) and time can be duped, so proper algorithms like the one you described should be used :) But as a demo i think it's OK – J.J Nov 09 '15 at 15:11
  • 1
    Yup, TOD, the bane of all real world security applications. TOD just creates all sorts of problems from the illusion of a secure PRNG seeding to protocol sync issues. Notable sync pains from the past: DCE setup (in the 90's) and RSA Token keys. – Andrew Philips Nov 09 '15 at 15:29