Pass the hash attack
ysillam opened this issue · 3 comments
Hello,
I noticed that the 3 components of the hashed string are pasted one after the other.
I imagined that someone without the knowledge of the shared key would be able to insert an information into the DNS :
-
Query that the attacker sees -
IP 111.111.111.111 - https://MY_API_ID.execute-api.us-west-2.amazonaws.com/prod?mode=set&hostname=host1.dyn.example.com&hash=96772404892f24ada64bbc4b92a0949b25ccc703270b1f6a51602a1059815535 -
Query that the attacker is able to execute -
IP 111.111.111.11 - https://MY_API_ID.execute-api.us-west-2.amazonaws.com/prod?mode=set&hostname=1host1.dyn.example.com&hash=96772404892f24ada64bbc4b92a0949b25ccc703270b1f6a51602a1059815535
I admit that is very unlikely, but I thought it was worth mentioning.
In order to prevent this case, I would suggest to reorder the 3 components this way : $IP$shared_secret$hostname
Best Regards,
Yohann Sillam
Hey Yohann,
Thanks for your interest in the project.
I'm aware that the system could susceptible to a replay attack. Under TLS, this would require a MITM as well.
I have thoughts on fixing that by adding a timestamp to the hash.
The fact that the IP is part of the hash means that the attacker could only set the IP to the same one included in the hash.
I'm not clear on how re-ordering the elements of the hash would change the security of the system.
Forgive me if I'm missing something, and thanks in advance for your thoughts on this.
Best,
Sean
"Thanks for your interest in the project."
It is a pleasure
"The fact that the IP is part of the hash means that the attacker could only set the IP to the same one included in the hash."
The attacker can add an IP that is not the same one because of the organization of the strings before the hashing process.
Indeed, in my example above :
"111.111.111.11" is different from 111.111.111.111".
sha1(111.111.111.111hostXXX) = sha1(111.111.111.111hostXXX)
A reordering (or adding of a separator) would prevent this scenario from happening
Yohann
Hostname 1host.net will cause the Lambda to fail as no DynamoDB record is present with that key. The attacker doesn't have access to DynamoDB threfore cannot add an arbitrary hostname in the DNS.