TheDigitalWay via pixabay
Writing secure code can be challenging, and implementing cryptography correctly in software is just plain hard. Even experienced developers can get tripped up. And if your goal is to swindle people quickly, not to wow them with the quality of your software, there are sure to be serious crypto mistakes in your code.
Malware authors may provide significant lessons in how not to implement cryptography. Such was the upshot of research by Check Point’s Yaniv Balmas and Ben Herzog at the recent Virus Bulletin conference in Denver. Malware authors may be more likely to insert crypto doozies in their code than developers working on legitimate software because they may not care as much about code quality or design, said Balmas and Herzog. These criminals are focused on getting a product that does enough to satisfy their immediate requirements — and no more.
[ Also on InfoWorld: 19 open source GitHub projects for security pros. | Discover how to secure your systems with InfoWorld’s Security newsletter. ]
Here’s a look at the crypto mistakes of recent malware headliners — and how to identify similar missteps in future malware scripts in hopes of cracking their malicious code.
Fuzzy-headed thinking on crypto
Mistakes are inevitable when you have only a “fuzzy understanding of the details” and a very tight time frame. Analyzing the work of malware authors, Balmas and Herzog identified four “anti-patterns,” when it came to implementing encryption, including voodoo programming, cargo cult technique, reinventing the square wheel, and bluffing. Defenders who uncover hints of these categories of mistakes can break the encryption and hinder malware execution, or they can uncover its secrets via reverse-engineering.
“These are basic misunderstandings of how to use cryptographic tools properly, which at best broadcast, ‘I have no idea what I am doing,’ and at worst, catastrophically cripple the malware such that it does not actually do what it set out to do,” Balmas and Herzog wrote.
Professional or amateurish, these malware authors recognize that cryptography is increasingly essential to malware development — in ransomware, to extort money from victims; in hiding communications from the infected device to the command-and-control server; in stealthily evading detection by security tools; and in signing malware as a trusted application. But analysis shows that many appear to have trouble using encryption effectively, to their detriment. Security analysts and network administrators who recognize the main classes of cryptographic errors have a big advantage in foiling ransom demands and thwarting infections.
“Malware authors compose primitives based on gut feeling and superstition; jump with eagerness at opportunities to poorly reinvent the wheel; with equal eagerness, at opportunities to use ready-made code that perfectly solves the wrong problem,” Balmas and Herzog wrote in the conference whitepaper.
No idea what this does, but it looks cool
The authors behind the Zeus banking Trojan and Linux-based ransomware Linux.Encoder fell into the “voodoo programming” trap. Their cryptographic implementation “betrays a deep confusion about the functionality being invoked — what it is, what it does, and why it might fail,” the researchers said.
In the case of Zeus, the authors chose popular stream cipher RC4 to encrypt all Zeus C&C traffic, but added another tweak. They took the already encrypted stream and modified every byte by XORing it with the next byte. While RC4 has its own security weaknesses, the cipher is secure enough to do what Zeus needed, and the tweaked variant was “exactly as secure as plain, vanilla RC4,” the researchers noted.
With Linux.Encoder, the authors seeded the function with the current time stamp to generate its encryption key. When security researchers pointed out that it was really easy to break the ransomware keys, the authors tried generating an AES key by hashing the time stamp eight times.
“Using a hash function eight consecutive times on an input shows a deep misunderstanding of what hash functions are,” the researchers wrote, noting that repeating the function does not yield a better hash. In fact, it could result in “an odd creation that has weaker security properties.”
Copy and paste this code I found
The second class, “cargo cult programming,” refers to copying what looks like a working solution to the problem and pasting that block of code into the program without understanding why or how the code works. Copying code isn’t a big deal — if it was, Stack Overflow wouldn’t exist — but if the programmer doesn’t know what is actually happening in that block, then the programmer doesn’t know whether the code is actually the correct solution.
“[They] might end up using code that performs almost what they had in mind, but not quite,” the researchers wrote, noting that the authors behind the CryptoDefense ransomware fell in this trap.
While most of CryptoDefense’s features — RSA-2048 encryption, payment via bitcoin, communication with C&C servers via Tor — were copied from the original CryptoLocker ransomware, the actual RSA implementation relied on a low-level cryptographic Windows API. The actual code can be found in Microsoft Developer Network documentation, along with the explanation that when a flag is not set correctly, the application saves the private key in local key storage. The CryptoDefense authors didn’t set that flag, so security researchers worked with victims to find the private key on their computers to decrypt the files.
Because the malware authors didn’t thoroughly read the documentation, the defenders were able to save the day.
Cobble together the code
The typical software developer would gladly link to an open source project that handles a necessary task and save the time and effort to write it from scratch. Unfortunately for malware authors, compiling with statically linked third-party code is not always an option, as the extra code can enlarge the resulting executable or make it easier for security tools to detect the malware. Instead of linking, authors tend to improvise and cobble together something that works. The groups behind the Nuclear exploit kit and the ransomware families Petya and DirCrypt attempted to “reinvent the square wheel,” and to everyone else’s benefit, they did so poorly.
“If you believe anything in cryptography is completely straightforward to implement, either you don’t understand cryptography, or it doesn’t understand you,” the researchers wrote.
The widely distributed Nuclear exploit kit obfuscates exploit delivery by using the Diffie-Hellman Key Exchange to encrypt the information passed to the payloads. The variables needed for the key exchange are sent to the server as a JSON file containing strings of hex digits, and the values are parsed and decoded using Base64. However, the researchers noted the implementation was “absurd” as it set the secret key to 0, rendering the whole process useless.
Petra’s authors implemented Salsa20, a lesser-known stream cipher that is considered to be more resistant to attacks than RC4, from scratch. However, three major flaws in Petya’s implementation means the ransomware generates a 512-bit key containing 256 bits of constant and predictable values.
“When your implementation of a cipher cuts its effective key size by half, and the required time for a break by 25 orders of magnitude, it’s time to go sit in the corner and think about what you’ve done,” the researchers said.
DirCrypt didn’t fare much better, as the authors made the common mistake of reusing the same key when encrypting each file with RC4. Key-reuse is an understandable mistake, especially if the person doesn’t have elementary knowledge of how stream ciphers work and how they can fail. However, the group made a bigger mistake by appending the key to the encrypted file. Victims could directly access the key and use it recover portions of locked files and, in some case, recover entire files.
The last category isn’t actually a coding mistake, but rather the malware author’s intentional social engineering shortcut. Ransomware authors, for example, don’t need to create the “impeccable cryptographic design and implementation” when it’s far easier to lie, Check Point’s Balmas and Herzog said. Few victims are going to question the malware’s encryption claims when it comes to retrieving their data.
Similarly, the ransomware Poshcoder originally used AES, instead of either RSA-2048 or RSA-4096 encryption listed on the ransom note. Poshcoder also claims to use strong asymmetric encryption, except AES is a symmetric cipher and is vulnerable to a number of attacks.
The group behind Nemucod believes “would-be adversaries will become light-headed and weak in the knees the moment they hear the phrase ‘RSA-1024,'” the researchers wrote, noting that Nemucod “sets the gold standard for minimal effort.” If the victims are scared enough, they may be less likely to take a closer look at the malware’s capabilities.
Take advantage of the mistakes
Cryptography is hard, and many software developers screw up when trying to implement encryption. Consider that the Open Web Application Security Project’s Top 10 list of web application vulnerabilities identifies only two common cryptographic mistakes that developers can make. It’s no surprise the bad guys are struggling, too.
“Evidence heavily suggests that most malware authors view those tools as wondrous black boxes of black magic, and figure they should be content if they can get the encryption code to run at all,” the researchers wrote.
It’s tempting to pay the ransom or begin restoring from backup right away when files have been locked by ransomware or to assume that there is no way to break open the communications between an infected endpoint and the malware’s C&C servers. Security analysts and IT administrators willing to take the time to look for these common mistakes in the offending malware may be able to change the outcome. Someday, the bad guys will learn how to use encryption properly; until then, the defenders have the edge as they can get around broken implementations and coding errors.