Two days after researchers exposed aNational Security Agency-tied hacking group that operated in secret for more than a decade, CIA hackers convened an online discussion aimed at preventing the same kind of unwelcome attention. The thread, according to a document WikiLeaks published Tuesday, was titled \"What did Equation do wrong, and how can we avoid doing the same?\" <\/p>\n
Equation Group eventually came to light because of a handful of errors its members made over the years. One was the widespread use of a distinctive encryption function that used the RC5 cipher with negative programming constantsrather than with the positive constants favored by most developers. The nonstandard practice made it easier to identify Equation Group tools. Another mistake: failing to scrub variable names, developer account names, and similar fingerprints left in various pieces of Equation Group malware. A third error was the failure to renew some of the domain name registrations Equation Group-infected computers reported to. When Kaspersky Lab obtained the addresses, the researchers were shocked to find some machines infected by a malware platform abandoned more than 10 years earlier were still connecting to it. <\/p>\n
It was this intrigue that set the stage for the online discussion about how CIA hackers could avoid the same pitfalls. <\/p>\n
\"As for what 'Equation' did wrong... All their tools shared code,\" one user, who like all the others was identified only by a unique identifier WikiLeaks used in place of a username, concluded on February 18, 2015, two days after the Kaspersky Lab findings were published. \"The custom RC5 was everywhere. The techniques for positive ID (hashing) was used in the same way in multiple tools across generations.\" <\/p>\n
The person continued:\"The shared code appears to be the largest single factor is [sic] allowing [Kaspersky Lab] to tie all these tools together. The acquisition and use of C&C domains was probably number 2 on the list, and I'm sure the [CIA's computer operations group] infrastructure people are paying attention to this.\" <\/p>\n
The person also suggested peers avoid using non-standard crypto functions, avoid using custom names in code, and scrub code clean of any PDB database information provided by Microsoft's Visual Studio debugger feature. The person wrote: <\/p>\n
1. I would argue using custom crypto is always a mistake for two reasons. First, for the obvious problem described in the report. It makes your code look strange on deep RE inspection. Second, a custom routine greatly increases the odds you implemented the algorithm incorrectly and end up with a much weaker encryption scheme than intended. <\/p>\n
2. Named kernel objects in general provide an easy signature for detection because it's usually a unique name. Using the same name in multiple tools is catastrophic. <\/p>\n
3. This is PDB string, right? The PDB path should ALWAYS be stripped (I speak from experience. Ask me about Blackstone some time.). For Visual Studio user mode stuff, the \/DEBUG linker switch should NOT be used. For drivers, it's a bit harder to avoid it, but a post-build step using binplace will strip the path information. <\/p>\n
4. For other strings generally, yeah, search the binary for them. Don't use internal tool names in your code. It's less of a problem if leave-behind code doesn't have any exploit code in it. <\/p>\n
The person went on to say, \"The 'custom' crypto is more of [an] NSA falling to its own internal policies\/standards which came about in response to prior problems. The problems included misconfigured crypto implementations that were corrected by using a single, optimized library. <\/p>\n
\"Unfortunately, this implementation used the pre-computed negative versions of constants instead of the positive constants in the reference implementation,\" the person wrote. \"I think this is something we need to really watch and not standardize our selves into the same problem.\" <\/p>\n
Other suggestions included the use, when possible, of publicly available crypto libraries, such as Microsoft Encryption Libraries, OpenSSL, and PolarSSL; creating a warning that would be displayed when unique names are embedded in the final binary file; and using a tool that would scan binaries for any usernames used on the local network. <\/p>\n
The thread is part of a cache of 8,761 documents and files that WikiLeaks said were \"obtained from an isolated, high-security network situated inside the CIA's Center for Cyber Intelligence in Langley, Virginia.\" The discussion provides a fly-on-the-wall account of some of the reactions to what must have been one of the more embarrassing exposures of NSA hacking. It wouldn't be surprising if members of NSA hacking units are having discussions of their own speculating on the cause of Tuesday's leak. <\/p>\n
<\/p>\n
Originally posted here:<\/p>\n
After NSA hacking expos, CIA staffers asked where Equation ... - Ars Technica<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Two days after researchers exposed aNational Security Agency-tied hacking group that operated in secret for more than a decade, CIA hackers convened an online discussion aimed at preventing the same kind of unwelcome attention. The thread, according to a document WikiLeaks published Tuesday, was titled \"What did Equation do wrong, and how can we avoid doing the same?\" Equation Group eventually came to light because of a handful of errors its members made over the years. One was the widespread use of a distinctive encryption function that used the RC5 cipher with negative programming constantsrather than with the positive constants favored by most developers. Continue reading