33 ms·

It was a matter of time before it leaked. If you're going to put a back door in, at least make sure only you can use it (Nobody But Us). Why didn't they use a k

by jdiez17 11y ago

It was a matter of time before it leaked. If you're going to put a back door in, at least make sure only you can use it (Nobody But Us). Why didn't they use a keypair?

_jomo 11y ago
My guess is a hardcoded public key would be easier to find in code and/or binaries, whereas this cryptic password was quite challenging.
- jdiez17 11y ago
  That's what I thought as well, but it might have been worth the effort to obfuscate it. I mean, they must've known it was going to leak sooner or later, leaving a lot of vulnerable boxes behind.
  - dogma1138 11y ago
    It is obfuscated in a way that will still avoid detection during static code analysis and casual code review. This looks like debug or logging string builder which no one would give it a second look while glancing over it. Hashes and binary blobs will look out of place, same thing goes for intentionally obfuscated secure string builder. When you put in a back door the best one will always be the shortest possible complicating it will only increase the likelihood of it being detected. The sign of a true high level adversary isn't overly complicated and obfuscated software but one which is remarkably simple and elegant whilst still achieving the desired functionality. Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality.
    - psykovsky 11y ago
      >>> Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality. spies, you mean? The NSA, that is
      - dogma1138 11y ago
        No, your run of the mill malware and back doors which are implemented by people without much real trade craft experience that like to show off being smarter than anyone else - cyber criminals. Spies rarely are egotistical and never are flashy, James Bond is pretty much the most anti-spy as one can get :)
    - jdiez17 11y ago
      I agree that functionality and simplicity is very important, but having the password in plaintext is just sloppy. LukaAI suggested using a hashed password. Surely that would have been much better at containing the fallout.
      - sk5t 11y ago
        Embedding the hash into the program would stick out somewhat more than this camouflaged printf-like format.
        deleted 11y ago
        [deleted]
      - dogma1138 11y ago
        A hashed password means that you have to implement the entire hashing mechanism to evaluate it that will take a huge amount of code compared to a single string compare. The hash string value will also be detected by most common static analysis rules which look for hashes and strings that look like passwords in the code. The beauty of this hack is that even if you are looking for hard coded credentials you are likely not to find them as that PW string will not trigger any reasonable regex which will look for a clear text passwords (or a hashed one for that matter).
        jdiez17 11y ago
        You wouldn't have to implement sha1(), I bet it's already there. It'd be the same as calling strcmp; the difficulty is hiding the hash (although it probably wouldn't be the only "magic number" in their code), but given enough time and creativity you could come up with a clever solution. For example, you could check one byte of the hash at a time in different parts of the auth function.
        dogma1138 11y ago
        You would have to implement it somewhere which means you'll either "import" it which will add it to the assembly or have to call functions / services which handle SHA1. One of the common techniques in static code analysis is to cross reference function calls against a desired state and to flag any undocumented links which again increases the likelihood of your backdoor being detected.
    - sophacles 11y ago
      From a very practical standpoint - obfuscation and complexity also makes it more likely that the code will be broken in the future. Not broken like "discovered and disclosed" but broken like: "it doesn't work any more". I mean - it's not like the unit tests are going to contain check_backdoor_works() (etc). So the simpler and more straight forward you can get your backdoor snuck in - the longer you can know it will remain, and keep working.
  - jarfil 11y ago
    Who is "they"? I doubt it was Juniper who put this in, and whoever did it, I doubt he cared about how many people would abuse it once it got out.
    - MichaelGG 11y ago
      Such kind of work is almost certainly within reach of wealthy individuals, let alone companies. As the KGB showed, it doesn't cost much to turn people. Decades-long spies operated in the CIA and FBI for very little money, despite only doing it for the money.
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.
baby 11y ago
That's why I don't think it was the NSA. They only seem to be using NOBUS kind of trojans.

by jdiez17 11y ago

It was a matter of time before it leaked. If you're going to put a back door in, at least make sure only you can use it (Nobody But Us). Why didn't they use a keypair?

_jomo 11y ago

My guess is a hardcoded public key would be easier to find in code and/or binaries, whereas this cryptic password was quite challenging.

jdiez17 11y ago
That's what I thought as well, but it might have been worth the effort to obfuscate it. I mean, they must've known it was going to leak sooner or later, leaving a lot of vulnerable boxes behind.
- dogma1138 11y ago
  It is obfuscated in a way that will still avoid detection during static code analysis and casual code review. This looks like debug or logging string builder which no one would give it a second look while glancing over it. Hashes and binary blobs will look out of place, same thing goes for intentionally obfuscated secure string builder. When you put in a back door the best one will always be the shortest possible complicating it will only increase the likelihood of it being detected. The sign of a true high level adversary isn't overly complicated and obfuscated software but one which is remarkably simple and elegant whilst still achieving the desired functionality. Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality.
  - psykovsky 11y ago
    >>> Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality. spies, you mean? The NSA, that is
    - dogma1138 11y ago
      No, your run of the mill malware and back doors which are implemented by people without much real trade craft experience that like to show off being smarter than anyone else - cyber criminals. Spies rarely are egotistical and never are flashy, James Bond is pretty much the most anti-spy as one can get :)
  - jdiez17 11y ago
    I agree that functionality and simplicity is very important, but having the password in plaintext is just sloppy. LukaAI suggested using a hashed password. Surely that would have been much better at containing the fallout.
    - sk5t 11y ago
      Embedding the hash into the program would stick out somewhat more than this camouflaged printf-like format.
      - deleted 11y ago
        [deleted]
    - dogma1138 11y ago
      A hashed password means that you have to implement the entire hashing mechanism to evaluate it that will take a huge amount of code compared to a single string compare. The hash string value will also be detected by most common static analysis rules which look for hashes and strings that look like passwords in the code. The beauty of this hack is that even if you are looking for hard coded credentials you are likely not to find them as that PW string will not trigger any reasonable regex which will look for a clear text passwords (or a hashed one for that matter).
      - jdiez17 11y ago
        You wouldn't have to implement sha1(), I bet it's already there. It'd be the same as calling strcmp; the difficulty is hiding the hash (although it probably wouldn't be the only "magic number" in their code), but given enough time and creativity you could come up with a clever solution. For example, you could check one byte of the hash at a time in different parts of the auth function.
        dogma1138 11y ago
        You would have to implement it somewhere which means you'll either "import" it which will add it to the assembly or have to call functions / services which handle SHA1. One of the common techniques in static code analysis is to cross reference function calls against a desired state and to flag any undocumented links which again increases the likelihood of your backdoor being detected.
  - sophacles 11y ago
    From a very practical standpoint - obfuscation and complexity also makes it more likely that the code will be broken in the future. Not broken like "discovered and disclosed" but broken like: "it doesn't work any more". I mean - it's not like the unit tests are going to contain check_backdoor_works() (etc). So the simpler and more straight forward you can get your backdoor snuck in - the longer you can know it will remain, and keep working.
- jarfil 11y ago
  Who is "they"? I doubt it was Juniper who put this in, and whoever did it, I doubt he cared about how many people would abuse it once it got out.
  - MichaelGG 11y ago
    Such kind of work is almost certainly within reach of wealthy individuals, let alone companies. As the KGB showed, it doesn't cost much to turn people. Decades-long spies operated in the CIA and FBI for very little money, despite only doing it for the money.

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.

baby 11y ago

That's why I don't think it was the NSA. They only seem to be using NOBUS kind of trojans.