6 C
Tuesday, November 21, 2017
Home Tags Stream Cipher

Tag: Stream Cipher

A month before Apple is expected to enforce stricter security requirements for app communications in iOS, enterprise developers don’t seem ready to embrace them, a new study shows. The study was performed by security firm Appthority on the most common 200 apps installed on iOS devices in enterprise environments.

The researchers looked at how well these apps conform to Apple’s App Transport Security (ATS) requirements. ATS was first introduced and was enabled by default in iOS 9.
It forces all apps to communicate with Internet servers using encrypted HTTPS (HTTP over SSL/TLS) connections and ensures that only industry-standard encryption protocols and ciphers without known weaknesses are used.

For example, SSL version 3 is not allowed and neither is the RC4 stream cipher, due to known vulnerabilities. Before ATS, app developers implemented HTTPS using third-party frameworks, but configuring SSL/TLS properly is hard so implementation errors were common.

These weakened the protection that the protocol is supposed to provide against traffic snooping and other man-in-the-middle attacks. Currently iOS provides a method for apps to opt out of ATS entirely or to use it only for specific connections, but Apple wants to change that.

At its Worldwide Developers’ Conference in June, the company announced that it will require all apps published on the App Store to turn on ATS by the end of this year. The requirement won’t be enforced at the OS level, but through the App Store review process. Using some of the ATS exceptions will still be possible, but developers will have to provide a “reasonable justification” for using them if they want their apps to be approved. During their study, the Appthority researchers found that 97 percent of the analyzed apps—193 out of 200—used exceptions and other settings that weakened the default ATS configuration. “Among the top 200 iOS apps that we analyzed, 166 apps (83 percent) bypass at least some ATS requirements by setting ‘NSAllowsArbitraryLoads’ attribute to ‘true’ in their Info.plist files,” the Appthority researchers said in their report. “However, not all of them bypass ATS requirements for all network connections.

For instance, a company can still support ATS requirements for network connections with its domain, while allowing ATS to bypass all other connections.” Among the apps that didn’t use HTTPS for all of their connections were popular ones like Facebook, Twitter, LinkedIn, Facebook Messenger, Skype, Viber, WhatsApp, Fox News, CNN, BBC, Netflix, ESPN, Hulu, Pandora, Amazon Cloud Player, Word, Excel, PowerPoint, and OneNote, but also utility apps like Flashlight, QR code readers and games. While it could be argued that some connections don’t need HTTPS because they aren’t used to transfer sensitive data, the Appthority researchers found 10 applications that did send device IDs, email addresses, physical addresses, zip codes, geolocation information and even passwords or secret keys over unencrypted HTTP links. There are many reasons why developers can’t turn on ATS for all connections and are likely to request ATS exceptions during the app review process.

For example, many apps don’t talk only to their developers’ servers, but also to third-party advertising, market research, analytics and image or video hosting services.

The use of HTTPS on these external services are out of app developers’ control. ATS provides fine-grained exceptions like “NSAllowsArbitraryLoadsInMedia,” which can, for example, be used to allow the streaming of video or audio content over HTTP, while encrypting all other connections. However, based on Appthority’s analysis, it seems that so far developers have preferred using the more generic “NSAllowsArbitraryLoads” which disables ATS for all connections, when dealing with such problems. The company didn’t find any app that used the “NSAllowsArbitraryLoadsInMedia” or the “NSAllowsArbitraryLoadsInWebContent” attributes to limit the scope of ATS exceptions.
It hopes that Apple’s new requirements will change that. Many apps that do use ATS disable some of its security features.

For example, none of the apps analyzed by Appthority used Certificate Transparency, which is available in ATS. Furthermore, seven of them disabled SSL certificate validation and 46 didn’t use certificate pinning.

Thirty-eight apps disabled Forward Secrecy and eight apps set the allowed TLS protocol version to 1.0 or 1.1, even though the secure default in ATS is TLS 1.2. “We still expect iOS apps with unencrypted data in enterprise environments, even after January 1,” the Appthority researchers said. “When Apple approves such apps for the App Store, there will still be the security risks associated with unencrypted data for some connections, so it’s important for enterprises to have visibility into and management of the risks related to apps with those exceptions.”
A*STAR Singapore shows how easy it is The crypto scheme applied to second generation (2G) mobile phone data can be hacked within seconds, security researchers have demonstrated. The work by researchers from the Agency for Science, Technology and Research (A*STAR), Singapore shows that breaking the A5/1 stream cipher used by 2G is possible using commodity hardware. Security experts have known the A5/1 was breakable since 2009, so what the Singapore team has done is illustrate the ease with which this is now possible, re-emphasizing the need to update remaining 2G-based mobile communications networks. "GSM uses an encryption scheme called the A5/1 stream cipher to protect data," said Jiqiang Lu from the A*STAR Institute for Infocomm Research. "A5/1 uses a 64-bit secret key and a complex key-stream generator to make it resistant to elementary attacks such as exhaustive key searches and dictionary attacks." Weaknesses in the ageing A5/1 cipher, combined with the improved performance of number-crunching hardware, have rendered the crypto system crackable. The approach adopted by the Singapore-based researchers is more sophisticated than a vanilla brute force (try every possible combination) attack.

By harnessing two security weaknesses, the boffins were able to compute a look-up table using commodity hardware in 55 days.

Armed with this 984GB rainbow table, determining the secret key used to encrypt communications is possible in as little as nine seconds. "We used a rainbow table, which is constructed iteratively offline as a set of chains relating the secret key to the cipher output," Lu explained, phys.org reports. "When an output is received during an attack, the attacker identifies the relevant chain in the rainbow table and regenerates it, which gives a result that is very likely to be the secret key of the cipher." The researchers used a cracking rig made up of a general-purpose graphics processing unit computer with three NVIDIA GeForce GTX 690 cards, costing about $15K. More details of the research can be found in a white paper entitled Time–Memory Trade-Off Attack on the GSM A5/1 Stream Cipher Using Commodity GPGPU in the journal Applied Cryptography and Network Security. ®
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. 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 rand() 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. Fake it 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. This was the case with Nemucod, a JavaScript Trojan that recently transformed into ransomware, which claimed to encrypt files with RSA-1024 encryption when it was actually using a simple rotating XOR cipher. Nemucod also displays the ransom note before the files are actually encrypted, so if the victim’s antivirus or security tools were vigilant enough to prevent the malware from downloading the encryption components, the files remain intact. 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. Related articles