
EQGRP tools are post-exploitation - jessaustin
http://blog.erratasec.com/2016/08/eqgrp-tools-are-post-exploitation.html
======
wahern

      Some have pointed out that the code in the tools is crappy,
      and they make obvious crypto errors (such as using the same
      initialization vectors). This is nonsense. It's largely
      pentesters, not software developers, creating these tools.
      And they have limited threat models -- encryption is to
      avoid easy detection that they are exfiltrating data, not
      to prevent somebody from looking at the data.
    

Many years ago an engineer asked me for advice. He was being forced to store
login credentials in the firmware so the device could access FTP, SMB, and
other accounts when the only available mechanism was user/password. The device
had no HSM device, and was completely standalone and unattended--using an
administrator-supplied password for decrypting and loading a key on-demand
wasn't an option. Also, most of the management code was implemented in a
regular scripting language, including the code that kicked off the remote
account logins, so even binary obfuscation strategies weren't practical. (You
could bury it through a chain of binary commands, but it only takes one
individual to trace things for it to be useless.)

We both knew there were no good solutions. So I sarcastically told him to just
ROT13 the credentials. The less sarcastic part of my answer was that the best
he could do was to make it more difficult to grep the filesystem or database
with obvious patterns for uncovering credentials. Encrypting the credentials
using a strong cipher was an exercise in futility. Anybody diligent enough to
inspect the source code could immediately locate and decrypt the credentials
regardless of how advanced the cipher or how convoluted the scheme for hiding
the key.

Fast forward nearly a decade later and somebody shows me a YouTube video of a
"security expert" showing his exploits of the firmware. One of the slides he
showed was the ROT13 code, along with a comment the engineer inserted claiming
it was my idea. (This wasn't a junior programmer misunderstanding me. He was
just being a d*ck by literally using ROT13 and preemptively blaming it on me
if anybody criticized the code.)

What really peeved me was that the security researcher and audience acted all
smug about the ROT13, as if simply using AES would have been better. While I
might not have literally used ROT13, there really was no good answer, and I
think it's arguably defensible. Most embedded devices still lack an HSM, and
in the age of VMs and containers that's even less viable than before.

It bugs me that people laughed at the situation, rather than appreciated the
honesty of the programmer, such as it was. That they laughed tells me all I
need to know about their skill, expertise, and experience actually
implementing security systems, and actually dealing with the impossible
solutions that product managers and customers demand.

It also tells me that because they couldn't be bothered to actually think
through the problem and realize that there was no substantially better
solution, they'd make horrible software developers. You can't write solid
software, especially solid security software, if you don't have a habit of
instinctively thinking through all the permutations and possibilities to judge
whether your solution is sound or doomed. And you probably can't be a very
good exploit writer, either, if you're not skillful at that.

It's worth pointing out that in some cases it does make sense to use a strong
cipher, store the credentials in one spot, and store the key in another. For
example, if you're storing the credentials in a network accessible database
where it might be possible for it to accidentally be opened to the world, or
where otherwise the credential store is more susceptible to unintentional
leakage than the key store. That wasn't the type of situation in this case.
Splitting things that way would have just resulted in two files in the same
directory tree rather than one, and there was no reason whatsoever to think
that if one file leaked the other wouldn't also leak simultaneously.

