Helpful (?) Tips from the CIA hacker school

The new data leak on WikiLeaks contains tips on how you need and how not to write exploits.

The data posted on WikiLeaks , contains thousands of files belonging to the group of developers of the CIA (Engineering Development Group, EDG). This organization from the CIA Cyber ​​Intelligence Center is responsible for creating tools for hacking digital devices around the world - to achieve the goals of the CIA. Leaked documents from the server used to track and document projects.



Many of these documents are not classified - there, for example, you can find instructions from Lockheed Martin and other manufacturers. Most of them are classified as “secret”, including such harmless things as the manual for beginners in Microsoft Visual Studio - it seems to be the favorite tool of the EDG division of the Applied Engineering Department (AED). Also there you can find some components for creating memes and animated gifs from the Trigan manga series.



A small part of the documents is “top secret”. The section with these documents is marked as “special data” (Special Intelligence, SI) and NOFORN (do not distribute outside the country). From the first group, consisting of more than 1000 documents, only two paragraphs are classified at this level. This data describes the details of how the cryptographic functions of the tools of the CIA network division tools should work and how the CIA gets and prepares phones for use in its exploit lab.

')

The damage caused by the documents for the most part is not that they tell about the CIA's capabilities in hacking and network espionage. The problem is how detailed these documents describe the technical specifications, rules and other details of the work of teams developing hacking tools. Now, after examining the documents, any person can find out how EDG uses techniques peeped in other people's malicious programs to write their own, and what, according to the CIA, should and should not be done when developing attacks and espionage tools. In other words, the details of the professional work of the scouts from the hacking teams leaked from the CIA server.



However, most of these details look like a beginners malware instruction. Some comments made by the CIA developers in 2013 tell us how far these rules are lagging behind. Many of these technologies are no longer secret.



To demonstrate this, we commented on some excerpts from the secrets of malware development from AED. Many of these rules apply to the development of any computer security application. Most of them are connected with the difficulty of researching these applications - so that the enemy team is more difficult to determine and understand how the malware works. Among some banal things about the rules of writing code, there are such:

1. Do not leave business cards

Developers were advised not to do anything that would allow the enemy to determine where the tool, bookmark, or malware came from.



"Do not leave time and date stamps, such as compiler, linker, builder time, access time, etc., corresponding to the working time in the US (from 8 am to 6 pm Eastern time)." Such artifacts are often used by analysts to identify as part of the process of determining the country of origin of the malware.



Developers are advised to use UTC time for all time-dependent operations. This will ensure a coherent work and the absence of hints at any particular time zone.



"Delete all debug information, manifests [from Microsoft Visual C ++], build paths, developers' names from the final binary file assembly." Such things can also be used to establish authorship. For the same reasons, documents persuade developers to "not leave data in binaries indicating their involvement in the development or use of this tool by the CIA, the US government, or their partner companies."



One of the main security warnings is encountered: “Do not store data containing terminology of the CIA or the US government, department names, code names of operations or other terminology in the binary.”



There is another warning that you should not use in the development of tools - obscene language. “Do not use obscene words in a binary. Such words or hacking terms can lead to overly thorough checks of a binary file. ”

2. Do not disturb the victim’s computer

Then the developers are warned about the mistakes of beginners, facilitating the reverse-engineering tools. The first rule of the Malicious Club is not to disrupt the victim’s computer, so as not to draw unnecessary attention to the presence of malware.



“Do not perform operations that can cause the computer to stop responding to user requests (bursts of CPU usage, screen flicker, freeze, etc.,” the document says.



“Do not perform disk operations that may cause the computer to stop responding to user requests or give a signal to the system administrator.” The last thing you need in this situation is if someone looks at the system inspector and finds out that the Notepad.exe program is running out all the resources of the CPU, the network and the I / O of the drive.



“Set the maximum size and number of files to be recorded.” This, for example, will prevent the computer's drive from filling up, after which the risk of computer inspection is increased by a specialist from the support service.



For the same reason, the document recommends: “Do not create crashdump and coredump files, do not call the blue screen, the pop-up dialogs of Dr Watson and other artifacts in case of a program crash.” Error messages work in both directions - they will be useful both to developers and program researchers. AED developers are advised to specifically drop their programs to make sure that they do not show themselves in this case.





These manuals are as modern as this IBM System / 370 mainframe.

3. Use encryption

Another feature of the invisible work is the encryption of the data used by the tool; in memory, on disk, on the network. One of the documents contains the following tips:



"Protect with obfuscation or encryption all string data and settings directly related to the operation of the tool." Someone who studies the settings file or the executable file in the editor should not be able to figure out what your tool does and where it sends its data only on the basis of textual data. Developers are encouraged to write code that decrypts only the information required at the moment, and remove it from memory immediately after use. "Do not rely on the fact that the operating system will do this at the end of the program."



“Do not write data to disk in plain text”, this can quickly lead to uncomfortable situations. “Encrypt all the data written to disk” and “use safe mashing [overwrite data with zeros] when deleting data from disk”. Files deleted this way cannot be restored.



“Use end-to-end encryption for all network communications” - after all, passive collection of unencrypted data leaving the network will ruin everything.



Use standard Internet protocols so that your communications merge with other network traffic - and not your own protocol, trying to pass for something else. Incorrectly implemented protocols will look like the wrong traffic on a network monitor such as Wireshark, which may attract attention.



Do not rely solely on SSL / TLS for data security "- because SSL proxies are vulnerable to the MitM attack. This went sideways even for the safest messaging applications.



“Use variable size and random times to send [jitter] network messages. Do not send predictable packets of fixed size and time to send. Clean up network connections correctly. Do not reserve residual compounds. ” In short, changing the size and time of sending messages will help your tool to advertise its presence less.

4. Do not facilitate the work of the research team of the enemy

In the matter of creating tools for espionage, a lazy programmer is a bad programmer. The recommendations speak of various aspects of programming hygiene that are designed to protect against untidy actions that can uncover CIA operations.



“Remove the debug system output from the final build” - because there is nothing more convenient for a third party trying to figure out what the program is doing than the debugging tools it leaves.



"Do not call explicitly and do not import functions that do not correspond to the explicit purpose of the program." In other words, if you are pretending to be a notepad.exe program, it should not trigger processes that notepad.exe would not cause — this can be suspicious and make it easier for you to recognize the true purpose of your program using static analysis.



“Do not export functions with obvious names; if work is required to export, use an ordinary or non-suspicious name. ” Since the code like "__declspec (dllimport) void DoVeryBadThings ()" can attract the attention of the analyst.

"Do not read, write or cache data on a disk without need." Enthusiasm records can leave traces.



Do not exceed the required size: “take reasonable efforts to minimize the size of all the binaries intended for downloading to the victim’s computer (without the use of packers or compression). The ideal binary of a full-featured tool should not be more than 150 KB. "



"Do not allow the possibility of a retransmission of data over the network." This means that the connection between the program and the managing server must depend on the date and time so that it is impossible to record the traffic and send it to the instrument in an attempt to figure out what it is doing.

5. Check the reaction of antivirus software

Everything worked in development



Some of the recommendations contained in the documents of the CIA, refers to the products of "PSP / AV" - "personal security products", products for personal security. This name has already been found in the documents of the CIA, published by hackers Shadowbrokers.



Part of the AED development cycle, according to the documents, includes extensive testing in a virtual DART environment. This system was created in Lockheed Martin based on VMware and several programs for automatic testing and deployment. But such an environment will not always be ideal for comprehensive testing of programs developed in AED, especially in terms of checking for their detection by antivirus.



As a result, the developer needs to customize tests using real products - and not just free ones. “Do not assume that a free PSP is identical to a paid one,” the document warns. "Check for paid versions whenever possible."



In addition, for reliability, these tests should be performed on recently updated antivirus software, since their manufacturers regularly send new data to customers. “Check out how to work with a PSP with a working (or recently operated) Internet connection,” the document says. He also warns: “a balance must be struck between the benefit and the risk, which must be carefully weighed. It is well known that antiviruses download examples of the investigated programs. ”



In other words, testing a tool while the Internet connection is working may result in the tool being tested being uploaded to the antivirus vendor’s threats library - and maybe then shared with a threat prevention platform like VirusTotal. This can make the tool useless.

Outdated data

It is not known how carefully the developers of the CIA adhered to the recommendations of the leaked document - in particular, because they themselves understood how these recommendations were outdated. In 2013, two system users wrote about this in the comments section: “Many of the intelligence tips on this page are incorrect.” Another added: "To be honest, all this is likely to be outdated." It is not known how long these recommendations were updated.



Four years later, some of the recommendations were even more expired. This is mainly due to the development of malware detection tools, including those built into the OS. But it also played a role that the techniques used by the authors of malicious programs that work without government support, have surpassed all these tips. Of course, with the help of the CIA or without it, there are no guarantees that all programmers use modern techniques.