Reflection Attack in an Authentication Protocol
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.
Description
A mutual authentication protocol requires each party to respond to a random challenge by the other party by encrypting it with a pre-shared key. Often, however, such protocols employ the same pre-shared key for communication with a number of different entities. A malicious user or an attacker can easily compromise this protocol without possessing the correct key by employing a reflection attack on the protocol.
Reflection attacks capitalize on mutual authentication schemes in order to trick the target into revealing the secret shared between it and another valid user. In a basic mutual-authentication scheme, a secret is known to both the valid user and the server; this allows them to authenticate. In order that they may verify this shared secret without sending it plainly over the wire, they utilize a Diffie-Hellman-style scheme in which they each pick a value, then request the hash of that value as keyed by the shared secret. In a reflection attack, the attacker claims to be a valid user and requests the hash of a random value from the server. When the server returns this value and requests its own value to be hashed, the attacker opens another connection to the server. This time, the hash requested by the attacker is the value which the server requested in the first connection. When the server returns this hashed value, it is used in the first connection, authenticating the attacker successfully as the impersonated valid user.
Demonstrations
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
Example One
The following example demonstrates the weakness.
unsigned char *simple_digest(char *alg,char *buf,unsigned int len, int *olen) {
const EVP_MD *m;
EVP_MD_CTX ctx;
unsigned char *ret;
OpenSSL_add_all_digests();
if (!(m = EVP_get_digestbyname(alg))) return NULL;
if (!(ret = (unsigned char*)malloc(EVP_MAX_MD_SIZE))) return NULL;
EVP_DigestInit(&ctx, m);
EVP_DigestUpdate(&ctx,buf,len);
EVP_DigestFinal(&ctx,ret,olen);
return ret;
}
unsigned char *generate_password_and_cmd(char *password_and_cmd) {
simple_digest("sha1",password,strlen(password_and_cmd)
...
);
}String command = new String("some cmd to execute & the password") MessageDigest encer = MessageDigest.getInstance("SHA");
encer.update(command.getBytes("UTF-8"));
byte[] digest = encer.digest();See Also
Weaknesses in this category are related to access control.
Weaknesses in this category are related to authentication components of a system. Frequently these deal with the ability to verify that an entity is indeed who it clai...
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is i...
This view (slice) covers all the elements in CWE.
CWE entries in this view have maintenance notes. Maintenance notes are an indicator that an entry might change significantly in future versions. This view was created...
This view contains a selection of weaknesses that represent the variety of weaknesses that are captured in CWE, at a level of abstraction that is likely to be useful t...
Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.