Home Tags Symmetric Key

Tag: Symmetric Key

The evolution of (and solution to) ransomware

Contrary to popular belief, ransomware has been around for decades.

The first malware program to lock up people’s files and ask for a ransom was the PC Cyborg Trojan in 1989.
It was created by Harvard-trained evolutionary biologist Dr. Joseph Popp, who was working on several AIDS-related projects at the time. Dr. Popp sent a floppy disk containing a program covering AIDS information, teaching, and testing to tens of thousands of mailing list subscribers.

At startup, a crude EULA warned users they had to pay for the program—and the author reserved the legal right to “ensure termination of your use of the programs ....

These program mechanisms will adversely affect other program applications on microcomputers.” Most people didn’t read the EULA and ran the program without paying for it. After 90 boots, the program crudely encrypted/obfuscated the user’s hard drive data, rendering it inaccessible, and asked for a payment of $189 to be sent to a Panamanian post office box. (Check out a great analysis of the Trojan.) Ransomware evolution Early ransomware used symmetric key encryption, and the cipher algorithm was often poorly constructed.

Encryption experts could frequently break the ransomware easily, and because the symmetric key was the same shared key in every infection, every computer touched by the same ransomware program could be unlocked at once. Eventually, ransomware authors learned to use public key cryptography (where both a private key and a second public key is involved) and started to use popular, well-known, well-tested cipher algorithms.

A different key pair was generated for each infection, which made ransomware a very difficult problem to solve. By the middle 2000s, tough-to-break ransomware was becoming very popular, but the problem of how hackers would collect their money remained. Real money and credit card transactions can be traced. Enter CryptoLocker, the first widespread ransomware program to demand bitcoin payments.

CryptoLocker first appeared in 2013. When matched with randomly generated email addresses and “darknet” pathways, it became almost impossible to catch ransomware hackers. Ransomware writers and distributors are now making tens, if not hundreds of millions, of dollars off their victims. These days ransomware keeps getting more dangerous and targeted. Ransomware programs are now being developed to attack specific types of data, such as database tables, mobile devices, IoT units, and televisions.

This page chronicles all the significant developments from the last year or so. Defeating ransomware First, you need to verify that you’ve actually been hit by ransomware. Less sophisticated programs merely take over your current browser session or computer screen.

They make the same blackmail claims as a more sophisticated ransomware program, but don’t encrypt any files.

All you need to do is reboot the computer and/or use a program like Process Explorer to remove the malicious file. Nothing beats a good backup. Nothing beats a current, offline backup.

The “offline” part is important because many ransomware programs will look for your online backups and render them unusable, too. Get patched. Making sure your system is fully patched is a great way to prevent any malware from infecting your computer.

But also see if they are the real patches from the real vendors. Unfortunately, fake patches often contain ransomware. Don’t get tricked. Don’t let yourself get socially engineered into installing ransomware.
In other words, don’t install anything sent to you in email or offered to you when visiting a website.
If a website says you need to install something, either leave the website and don’t go back—or leave the website and install the software directly from the legitimate vendor’s website. Never let a website install another vendor’s software for you. Use antimalware software. Everyone needs to run at least one antimalware program. Windows comes with Windows Defender, but there are dozens of commercial competitors and some good freebies. Ransomware is malware.

Antimalware software can stop the majority of variants before they hit. Use a whitelisting program. Application control or whitelisting programs stop any unauthorized program from executing.

These programs are probably the best defense against ransomware (besides a good offline backup).

Although many people think application control programs are too cumbersome to use, expect them to become much more accepted as ransomware continues to grow, at least in business computing.

The days of allowing employees to run any program they want are numbered. What to do if you’re locked up If all your critical data is backed up and safe, then you’ll be back in business in a few hours’ time. You’ll still need to reformat/reset/restore your device, however. Luckily, that process gets easier with each new operating system version. Using another safe, uninfected computer, restore your backup.

Apply all critical security patches, restore your data, and resolve never to do what you did that got your device locked up in the first place. If you don’t have a clean backup copy of your critical data and absolutely need the data, you have two options: Find an unlock key or pay the ransomware demand. Using another safe, trusted computer, research as much as you can about the particular ransomware variant you have.

The screen message presented by the ransomware will help you identify the variant. If you’re lucky, your ransomware variant may already have been unlocked. Many antimalware vendors have programs to detect and unlock ransomware (if it recognizes the variant and has the unlock key). Run that program first. It may take an offline scan to get rid of the ransomware.
Several websites also offer unlocking services, free and commercial, for particular ransomware variants. Here’s an example of a ransomware unlocker.

Also, believe it or not, ransomware distributors will even occasionally apologize and release their own unlocking programs. Lastly, many people choose to pay the ransomware to recover their files. Most experts and companies recommend against paying ransom because it only encourages the ransomware creators and distributors. Yet quite often it works.
It’s your computer and data, so it’s up to you whether to pay the ransom. Be aware that in many cases people have paid up and their files have remained encrypted.

But these cases seem to be in the minority.
If ransomware didn’t unlock files after the money was paid, everyone would learn that—and ransomware attackers would make less money. I hope you never become a ransomware victim.

The odds of infection, unfortunately, are getting worse as ransomware gains popularity and sophistication.

Virtru Debuts Security Encryption Key Server for Cloud Email

New Customer Key Server (CKS) enables organizations to manage their own cryptographic keys for Virtru's cloud email encryption service. Encryption vendor Virtru launched a news service on Nov. 30 that enables its customers to keep encryption keys for c...

Fatal flaws in ten pacemakers make for Denial of Life attacks

Brit/Belgian research team decipher signals and devise wounding wireless attacks A global research team has hacked 10 different types of implantable medical devices and pacemakers finding exploits that could allow wireless remote attackers to kill victims. Eduard Marin and Dave Singelée, researchers with KU Leuven University, Belgium, began examining the pacemakers under black box testing conditions in which they had no prior knowledge or special access to the devices, and used commercial off-the-shelf equipment to break the proprietary communications protocols. From the position of blind attackers the pair managed to hack pacemakers from up to five metres away gaining the ability to deliver fatal shocks and turn of life-saving treatment. The wireless attacks could also breach patient privacy, reading device information disclosing location history, treatments, and current state of health. Singelée told The Register the pair has probed implantable medical device and pacemakers, along with insulin pumps and neurostimulators in a bid to improve security understanding and develop lightweight countermeasures. "So we wanted to see if these wireless attacks would be possible on these newer types of pacemakers, as this would show that there are still security problems almost 10 years after the initial security flaws have been discovered, and because the impact of breaking the long-range wireless communication channel would be much larger as adversaries can be further away from their victim," Singelée says. "We deliberately followed a black-box approach mimicking a less-skilled adversary that has no prior knowledge about the specification of the system. "Using this black-box approach we just listened to the wireless communication channel and reverse-engineered the proprietary communication protocol. And once we knew all the zeros and ones in the message and their meaning, we could impersonate genuine readers and perform replay attacks etcetera." Laboratory setup: A USRP (left) and DAQ with antennas below. Their work is detailed in the On the (in)security of the Latest Generation Implantable Cardiac Defibrillators and How to Secure Them [PDF] authored by Marin and Singelée, KU Leven colleague Bart Preneel, Flavio D. Garcia and Tom Chothia of the University of Birmingham, and cardiologist Rik Willems of University Hospital Gasthuisberg. The team describes in limited detail to protect patients how the wireless communications used to maintain the implantable medical devices can be breached. "Adversaries may eavesdrop the wireless channel to learn sensitive patient information, or even worse, send malicious messages to the implantable medical devices. The consequences of these attacks can be fatal for patients as these messages can contain commands to deliver a shock or to disable a therapy." No physical access to the devices is required to pull off the attacks. The researchers say attackers could install beacons in strategic locations such as train stations and hospitals to infer patient movements, revealing frequented locations, and to infer patient treatment. Attackers could trigger a reprogramming session in order to grab that data. Programming flaws relating to the devices' standby energy saving mode allow denial of service attacks to be performed which will keep units in battery-draining alive states through continuous broadcasting of messages over long-range wireless. This could "drastically reduce" the units' battery life, the team says. The research, like all medical device hacking, has scope limitations that mean mass targeting of pacemakers is not immediately possible. Nor can attacks be extended to many metres. Another happy fact: the gear required isn't cheap. National Instruments sells its URSP-2920 for US$3670 (£2930, A$4972) and USB-6353 for US$2886 (£2724, A$3910). The team tells The Register they have been informed that the compromised vendor has issued a patch, but further details are not known. Medical devices' wireless could be jammed as a stop-gap measure, while the addition of shutdown commands to the devices would best serve long-term fix, as would the inclusion of standard symmetric key authentication. "We want to emphasise that reverse engineering was possible by only using a black-box approach," the team says. "Our results demonstrated that security-by-obscurity is a dangerous design approach that often conceals negligent designs." Medical device hacking has picked up pace in recent years, with much work made through the I Am The Calvary research and activist group. ® Sponsored: Customer Identity and Access Management

New collision attacks against triple-DES, Blowfish break HTTPS sessions

There is now a practical, relatively fast attack on 64-bit block ciphers that lets attackers recover authentication cookies and other credentials from HTTPS-protected sessions, a pair of French researchers said. Legacy ciphers Triple-DES and Blowfish need to go the way of the broken RC4 cipher: Deprecated and disabled everywhere. Dubbed Sweet32, researchers were able to take authentication cookies from HTTPS-protected traffic using triple-DES (3DES) and Blowfish and recover login credentials to be able to access victim accounts, said the researchers, Karthikeyan Bhargavan and Gaëtan Leurent of INRIA in France.

The attack highlights why it is necessary for sites to stop using legacy ciphers and upgrade to modern, more secure ciphers. "We show that a network attacker who can monitor a long-lived Triple-DES HTTPS connection between a web browser and a website can recover secure HTTP cookies by capturing around 785 GB of traffic.
In our proof-of-concept demo, this attack currently takes less than two days, using malicious Javascript to generate traffic," said Bhargavan and Leurent.

They are expected to present the full paper in October at the 23rd ACM Conference on Computer and Communications Security. Sweet32 is a collision attack against triple-DES (3DES) and Blowfish in cipher block chaining (CBC) mode.
In CBC mode, input collisions lead to XOR of two message blocks. When lots of message blocks are encrypted with the same key in this mode, collisions become more likely, which leads to getting the contents of two different message blocks as output.

Attackers can target a victim's authentication cookie by luring them to a malicious site and injecting JavaScript into the victim's browser. JavaScript repeatedly sends HTTP queries to a site the victim is logged into, and each request will include the authentication cookie. The researchers found that if the attackers send at least 232 queries and capture all the requests, they will eventually see a collision and be able to recover the contents of the cookie. "An important requirement for the attack is to send a large number of requests in the same TLS connection.

Therefore, we need to find client and servers that not only negotiate the use of Triple-DES, but also exchange a large number of HTTP request in the same TLS connection (without rekeying).

This is possible using a persistent HTTP connection, as defined in HTTP/1.1 (Keep-Alive). On the client side, all browsers that we tested (Firefox, Chrome, Opera) will reuse a TLS connection as long as the server keeps it open," the researchers said. Blowfish and 3DES are still supported in TLS, IPsec, SSH, and other protocols and well-known sites such as Nasdaq.com and Walmart.com still support these legacy ciphers.

The majority of OpenVPN connections and between 1 percent and 2 percent of the Internet's traffic may be susceptible to Sweet32, the researchers estimated.

The implementation used in OpenSSL is also affected, although the OpenSSL maintainers claimed the attack did not expose a critical weakness. OpenVPN 2.3.12 comes with a warning about Blowfish weaknesses and secure configuration advice for dealing with Sweet32. OpenSSL 1.0.2 and 1.0.1 will move 3DES from the "HIGH" keyword to "MEDIUM" keyword and support it by default, the newer OpenSSL 1.1.0 will no longer compile the cipher as part of the default build.

Administrators wanting to use the legacy cipher in OpenSSL 1.1.0 will need to use the ‘enable-weak-ssl-ciphers' configuration option, and even then, the cipher is allowed only in the ‘MEDIUM' keyword. Major browsers makers are making changes which would prioritize more secure ciphers over 3DES. The techniques and principles used to craft the attack are well-understood in cryptographic circles.

The researchers reduced the complexity and time needed to execute the attack. "While the principles behind this attack are well known, there's always a difference between attacks in principle and attacks in practice. What this paper shows is that we really need to start paying attention to the practice," wrote Matthew Green, cryptography expert and professor at Johns Hopkins University. Just because the attack is possible doesn't mean it is particularly easy to carry out.

For Sweet32, the attacker needs to be able to both monitor traffic passing between the end user and a vulnerable websites and control JavaScript on a webpage loaded by the user's browser.
It would take about 38 hours to collect hundreds of gigabytes of data necessary to decrypt the authentication cookie.

This attack scenario is very much a laboratory scenario, but it's still a good reminder that eventually these attacks will become easier to carry out. Enterprises and developers should treat 3DES and Blowfish in the same way they treat RC4: stop using it.

The complexity of Sweet32 is comparable to recently developed attacks against RC4, the researchers said. Researchers developing more ways to attack RC4 sped up its deprecation. Major web browsers no longer support RC4, and major websites such as Gmail have also entirely deprecated the cipher. Developers should stop using legacy 64-bit block-ciphers altogether.
In the case of Sweet32, that means disabling the Triple DES symmetric key cipher in TLS and retiring Blowfish in OpenVPN.

Ciphers with larger block sizes, such as AES, are immune from Sweet32.
Server administrators can also disable shorter ciphers entirely.

This would affect a small number of users who are still relying on older hardware and software. There is no need to wait till the attackers are easy and cheap to execute to get rid of weak and vulnerable cryptographic ciphers. Just as there is a concerted effort to ditch RC4, other 64-bit ciphers also need to go.

HTTPS and OpenVPN face new attack that can decrypt secret cookies

Enlarge / From an upcoming paper laying out a new attack against 64-bit block ciphers used by HTTPS and OpenVPN.Karthikeyan Bhargavan and Gaëtan Leurent reader comments 10 Share this story Researchers have devised a new attack that can decrypt secret session cookies from about 1 percent of the Internet's HTTPS traffic and could affect about 600 of the Internet's most visited sites, including nasdaq.com, walmart.com, match.com, and ebay.in. The attack isn't particularly easy to carry out because it requires an attacker to have the ability to monitor traffic passing between the end user and one of the vulnerable websites and to also control JavaScript on a webpage loaded by the user's browser.

The latter must be done either by actively manipulating an HTTP response on the wire or by hosting a malicious website that the user is tricked into visiting.

The JavaScript then spends the next 38 hours collecting about 785GB worth of data to decrypt the cookie, which allows the attacker to log into the visitor's account from another browser.

A related attack against OpenVPN requires 18 hours and 705GB of data to recover a 16-byte authentication token. Impractical no more Despite the difficulty in carrying out the attack, the researchers said it works in their laboratory and should be taken seriously.

They are calling on developers to stop using legacy 64-bit block-ciphers.

For transport layer security, the protocol websites use to create encrypted HTTPS connections, that means disabling the Triple DES symmetric key cipher, while for OpenVPN it requires retiring a symmetric key cipher known as Blowfish.

Ciphers with larger block sizes, such as AES, are immune to the attack. "It is well-known in the cryptographic community that a short block size makes a block cipher vulnerable to birthday attacks, even if the[re] are no cryptographic attacks against the block cipher itself," the researchers wrote in a blog post explaining the attacks. "We observe that such attacks have now become practical for the common usage of 64-bit block ciphers in popular protocols like TLS and OpenVPN." A birthday attack is a type of cryptographic exploit that is based on the mathematical principle known as the birthday paradox.
It holds that in a room of 23 randomly selected people, there is a 50-percent chance two of them will share the same birthday, and there's a 99.9 percent chance when the number is increased to 70 people.

The same principle can be used by cryptographers to find so-called collisions, in which the output of two chunks of encrypted text is the same.

Collisions, in turn, easily return the plaintext.

By collecting hundreds of gigabytes worth of HTTPS or VPN data and carefully analyzing it, the attackers are able to recover the sensitive cookie. In response to the new attack, which the researchers have dubbed Sweet32, OpenVPN developers on Tuesday released a new version of the program that actively discourages the use of 64-bit ciphers. OpenSSL maintainers, meanwhile, said in a blog post that they plan to disable Triple DES in version 1.1.0, which they expect to release on Thursday.
In versions 1.0.2 and 1.0.1, they downgraded Triple DES from the "high" to "medium," a change that increases the chances that safer ciphers are used to encrypt data traveling between servers and end users.

The precise cipher choice is made dynamically and is based on a menu of options supported by both parties. While stripping Triple DES out of all versions would be the safest course, it also would leave some people unable to browse certain HTTPS sites altogether. “A matter of good hygiene” "When you have a large installed base, it is hard to move forward in a way that will please everyone," Rich Salz, a senior architect at Akamai Technologies and a member of the OpenSSL developer team, wrote. "Leaving triple-DES in 'DEFAULT' for 1.0.x and removing it from 1.1.0 is admittedly a compromise. We hope the changes above make sense, and even if you disagree and you run a server, you can explicitly protect your users through configuration." Browser makers are also in the process of making changes that prioritize safer ciphers over Triple DES. The Sweet32 attack will be presented in October at the 23rd ACM Conference on Computer and Communications Security. While the time and data-collection requirements present a significant barrier, it works as described on sites that support Triple DES and allow long-lived HTTPS connections.

As of May, about 600 websites in the Alexa 100,000 were identified, including those mentioned at the beginning of this article. Karthikeyan Bhargavan and Gaëtan Leurent—the researchers behind Sweet32—estimate that about 1 percent of the Internet's HTTPS traffic is vulnerable. OpenSSL team member Viktor Dukhovni summed things up well in an e-mail. "We're not making a fuss about the 3DES issue, and rating it 'LOW," Dukhovni wrote. "The 3DES issue is of little practical consequence at this time.
It is just a matter of good hygiene to start saying goodbye to 3DES."