""DO NOT have "dirty words" (see dirty word list - TBD) in the binary.
Rationale: Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.""
I'm not even kidding. I've found so much bad code over the years through searching for profanity. It's actually a bit embarrassing to be honest.
From the NOD crypto document, the following advice is given:
> (S//NF) Tools should perform key exchange exactly once per connection. Many algorithms have
weaknesses during key exchange and the volume of data expected during a given connection does
not meet the threshold where a re-key is required.
xiii To reiterate, re-keying is not recommended.
With the footnote:
> xiii (S//NF) The exact nature of which algorithms are weak at this stage is highly classified. In the absence
of those facts this guidance is still relevant; the utility inherent in re-keying derives from minimizing key
exposure when performing bulk encryption of large amounts of data. Even the most data-intensive NOD
operations involve several fewer orders of magnitude of data per session key. Consequently, re-keying
introduces unnecessary complexity (and therefore opportunities for bugs or other unexpected behavior)
without delivering value in return.
Which key exchange algorithms have key exchange vulnerabilities when keys are frequently exchanged, I wonder.
It would be really interesting if that kind of technical detail leaked. With all of these leaks, I've never heard of a technical / mathematical document discussing the actual encryption algorithms leaking.
Makes me wonder if either
- This whole leak is a "fake" or at least no big deal for the TLAs (because there is not much surprizing inside)
and / or:
- Most encryption is broken in a fundamental way. I would never be able find out, because the four or five influential security experts I know and trust, and who tell me it is safe, are bought by the TLAs. Who knows, maybe all PGP does effectively is to mark my mails as really really interesting. "They" can trivially decrypt them, and then they employ thousands of analysts who just do parallel construction on everything they find out (so they don't leak their exploit).
A boring but more likely explanation is that the juicier the information, the more heavily protected it is. Fewer people know, writing it down is more strongly discouraged, more paranoid procedures are used to prevent leaks, etc.
DO explicitly remove sensitive data (encryption keys, raw collection data,
shellcode, uploaded modules, etc) from memory as soon as the data is no
longer needed in plain-text form. DO NOT RELY ON THE OPERATING SYSTEM TO DO
THIS UPON TERMINATION OF EXECUTION.
DO NOT explicitly import/call functions that is not consistent with a tool's
overt functionality
DO NOT perform operations that will cause the target computer to be
unresponsive to the user
DO make all reasonable efforts to minimize binary file size for all binaries
that will be uploaded to a remote target
DO provide a means to completely "uninstall"/"remove" implants, function
hooks, injected threads, dropped files, registry keys, services, forked
processes, etc whenever possible.
DO use end-to-end encryption for all network communications. NEVER use
networking protocols which break the end-to-end principle with respect to
encryption of payloads.
DO NOT break compliance of an RFC protocol that is being used as a blending
layer.
DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of
3rd party code that may implicitly write/cache data to disk.
DO NOT use hard-coded filenames or filepaths when writing files to disk.
This must be configurable at deployment time by the operator.
It's remarkable how many of these guidelines are just good software development guidelines and have nothing to do with malware, necessarily.
It's funny when you think about it. Many of these guidelines are there to prevent the program from being detected; in other words, it's to give the impression that it's not there.
You would think that good software which performs background tasks should be just as discreet, and follow similar guidelines: do your task, don't bother the user too much, definitely try not to block UI when the user is doing another thing. But a lot of software definitely does not. The classical example is AV software, but a lot of mobile applications are very guilty too. There is so much software that fails so hard at being efficient at background tasks...
It used to be even more prevalent about 10-15 years ago, but I suspect that it has a lot more to do with increased computational capabilities than to higher quality software.
> DO NOT solely rely on SSL/TLS to secure data in transit.
Rationale: Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol.
In the CIA's use case (data exfiltration), this rationale is likely due to target organizations using a firewall which utilizes TLS interception to capture and inspect data, requiring the computer or mobile device to have a custom trusted root CA added in order to properly send traffic through their firewall box.
So the issue would be that TLS is going to be useless for protecting any data that is being exfiltrated, as the firewall box would obviously perform it's DLP duties and block their exfiltration attempt. Custom additional cryptography or added obfuscation makes sense in this case because they only need to get past the automated inspection, not an actual human. The data has already been sent to the LP by the time anyone has a chance to crack the additional layer of crypto/obfuscation and see the data.
See the bottom of the page where he talks about the link to their internal (previously top secret) CIA crypto standards, which is probably one of the few cryptos that is actually any good (most of it was done with the NSA and just talks about which protocols are secure).
No, the plot of Sneakers is at the end the NSA thinks they're the only ones who can break the CIA's encryption but really the only one who can do it is Robert Redford!
Postscript: Redford of course then goes ahead and basically announces it to the NSA by stealing all the Republican party's money (and someone else - can't remember) and donating it to causes like Greenpeace and Amnesty International.
How easy is it for automated tools to spot encryption routines in a binary? If my notepad replacement had call to encryption algorithms in it I'd be a bit surprised...
This is equivalent to asking, "How good are virus scanners?"
Many crypto routines have identifiable constants but there are myriad ways to obfuscate code too so I'm not sure there's an answer other than: It depends on how hard they're trying to avoid you and how hard you're trying to find them.
The presence of AES instructions would be easy just from static analysis. Also loops of shifts and xors that are accumulating, etc. You could easily map the structure of various encryption algorithms into a static analysis tool. (I feel like the dynamic analysis proposed below about watching outputs being random is clever, but much more difficult).
Statistically, any routine which results in randomized output from non-random input (and especially if it is repeatably deterministic) would be a good candidate.
"This malware has consistent US EST timestamps, so it's probably not the CIA since the CIA knows to change timestamps. Probably some Iran masquerading as a US malware."
> Asymmetric cryptography must not be used directly for bulk encryption. It must only be used to
negotiate or exchange secrets used for symmetric encryption and for digital signatures and their
verification.
Isn't it great? Now every low level malware author in the world will start to follow adhere these tips, and the US has once again shot themselves massively in the foot, and fucked over the whole world in the process...
These tips are not very new or novel. Even low-level malware already follows some of them, although they likely do not care as much about attribution for example.
I'm not even kidding. I've found so much bad code over the years through searching for profanity. It's actually a bit embarrassing to be honest.