3

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?

  • Where's this question from? A link would be great. – Neil Smithline Nov 4 '15 at 5: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 4 '15 at 7:55
10

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.

  • 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. – dr01 Nov 4 '15 at 9:21
  • 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 4 '15 at 10:02
  • 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 5 '15 at 8:17
  • 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 5 '15 at 8: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 6 '15 at 6:57
3

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.

  • 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 5 '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 5 '15 at 16:26
  • I comment on unclear questions and provide answers on misguided ones (like this). – u2702 Nov 5 '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.

  • 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 6 '15 at 6: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 9 '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 9 '15 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.