4 ms·

Well, simply storing and hashed version of the pass would be ok. Even an MD5 or a SHA1 would be enough to guarantee at least a "Very Few plus Us" security. Hid

by LukaAl 11y ago

Well, simply storing and hashed version of the pass would be ok. Even an MD5 or a SHA1 would be enough to guarantee at least a "Very Few plus Us" security. Hiding that in the could would be much more difficult. And using PKs would make the attack even easier to spot. And then you have to consider that a "Nobody but Us" backdoor exist only on paper, not in reality. If a key exists and someone knows it, well sooner or later it will be discovered (disgruntled employees, hackers etc). The only safe backdoor is the none backdoor. Now, consider this problem from an attacker that doesn't give a st of your security. He knows that as soon as the backdoor is known (because someone find it in the code, because someone leak the password, because whatever...) the backdoor will be useless most systems. What you do, you design a safe backdoor or you design a backdoor with as little footprint as possible? Obviously, legally sanctioned backdoor have a different set or constraint and making them safe is a requirement. The fact that it is impossible to prove them safe unless some assumptions (that always prove to be wrong, but...) are made, it's a totally different problem.

ghshephard 11y ago
That's a really good question. Why did they store the plaintext instead of a hash? Doesn't feel like the sort of thing an attacker with any sophistication would do. Also doesn't feel like the sort of thing that underwent any code review. I'm starting to wonder about the "intern" theory again.
- brazzledazzle 11y ago
  You're assuming the attackers care if the backdoor is used by others. If a hash would increase the chances of it being found and you don't care if other attackers discover it, only if the vendor does then it's the right choice.
  - ghshephard 11y ago
    I absolutely assume that if the backdoor was placed by a vendor, they would make sure it was a one-way function. I (perhaps incorrectly) assumed that criminals would want to stick in a hash function, given a choice. I think the explanation, that adding a hash function will attract more attention than a simple strcmp is a good one. As is the desire to stick in something that gets by code review. All signs point to this 100% not being Juniper engineering officially adding a back door, and it being a party doing it without authorization.
- LukaAl 11y ago
  Well, there were two different backdoors: - This one could be the work of an intern, maybe a smart one but definitively it doesn't seems very sophisticated (we should look at the code). - The second one, we are not sure it actually existed but just that someone changed the parameters for the PRNG. But if it existed, well, it was a very sophisticated attack. But that's not the point of your question! A string compare with an if is pretty easy to hide in the code. Especially if the string looks like a logging string. I'm pretty sure in a big patch could pass through a quick code review. Calling an HMAC function or hiding it in the auth code that already call the HMAC function is much more complex. Plus it is much more difficult to generate a password, salt couple where both the salt and the HMAC seems legit code. Even for an intelligence agency or an attacker with huge resources, it is difficult to get such result!
- BinaryIdiot 11y ago
  > Why did they store the plaintext instead of a hash? Since we haven't seen the source it's difficult to speculate but I would venture to guess that the less function calls around your backdoor the better. It may look weird putting the code in another place where hash comparisons may be needed but in the place they put it where it's plaintext must have been harder to notice.
rst 11y ago
Apparently, the attackers had a different threat model; they were trying to keep the hash from getting noticed in source code or binary dumps, and thought a hash would stick out more (whether ascii-encoded or as random bits with statistically different properties from what surrounds them). They might also have expected adversaries to be able to invert any hash function accessible in the code -- which is plausible for a nation-state adversary with some hash functions. (If scrypt isn't already there, you don't get to add it; that would really stick out.)

by LukaAl 11y ago

ghshephard 11y ago

That's a really good question. Why did they store the plaintext instead of a hash? Doesn't feel like the sort of thing an attacker with any sophistication would do. Also doesn't feel like the sort of thing that underwent any code review. I'm starting to wonder about the "intern" theory again.

brazzledazzle 11y ago
You're assuming the attackers care if the backdoor is used by others. If a hash would increase the chances of it being found and you don't care if other attackers discover it, only if the vendor does then it's the right choice.
- ghshephard 11y ago
  I absolutely assume that if the backdoor was placed by a vendor, they would make sure it was a one-way function. I (perhaps incorrectly) assumed that criminals would want to stick in a hash function, given a choice. I think the explanation, that adding a hash function will attract more attention than a simple strcmp is a good one. As is the desire to stick in something that gets by code review. All signs point to this 100% not being Juniper engineering officially adding a back door, and it being a party doing it without authorization.
LukaAl 11y ago
Well, there were two different backdoors: - This one could be the work of an intern, maybe a smart one but definitively it doesn't seems very sophisticated (we should look at the code). - The second one, we are not sure it actually existed but just that someone changed the parameters for the PRNG. But if it existed, well, it was a very sophisticated attack. But that's not the point of your question! A string compare with an if is pretty easy to hide in the code. Especially if the string looks like a logging string. I'm pretty sure in a big patch could pass through a quick code review. Calling an HMAC function or hiding it in the auth code that already call the HMAC function is much more complex. Plus it is much more difficult to generate a password, salt couple where both the salt and the HMAC seems legit code. Even for an intelligence agency or an attacker with huge resources, it is difficult to get such result!
BinaryIdiot 11y ago
> Why did they store the plaintext instead of a hash? Since we haven't seen the source it's difficult to speculate but I would venture to guess that the less function calls around your backdoor the better. It may look weird putting the code in another place where hash comparisons may be needed but in the place they put it where it's plaintext must have been harder to notice.

rst 11y ago

Apparently, the attackers had a different threat model; they were trying to keep the hash from getting noticed in source code or binary dumps, and thought a hash would stick out more (whether ascii-encoded or as random bits with statistically different properties from what surrounds them). They might also have expected adversaries to be able to invert any hash function accessible in the code -- which is plausible for a nation-state adversary with some hash functions. (If scrypt isn't already there, you don't get to add it; that would really stick out.)