ROCA: Which Key-Pair Attacks Are Credible?

In the past two weeks, we have seen two big encryption issues arise: key reinstallation attacks, called KRACKs; and “Return of Coppersmith’s Attack,” called ROCA. Many CEOs, CIOs, and CISO/CSOs are asking, as they must, “Are we protected?” and “What’s our exposure?” Security architects are scurrying about to identify reasonable responses that can be presented to anxious executives.

We’ve already looked at KRACKs. How dangerous is ROCA?

Upon reading the Forbes article on ROCA, the first attack (code signatures) did not seem to be that major because operating system certificates typically are not generated on users’ individual machines. “Given a code signing certificate’s public key (which an organization has to publish), an attacker could derive the private key allowing them to sign software impersonating the victim,” said Jake Williams of Rendition InfoSec.

Although Williams’ example is theoretically correct, his statement fails to acknowledge how the major operating system vendors issue certificates. As we shall see from our analysis, only some digitally signed software might suffer from private-key derivation. For several commercial and open-source operating systems, derivation will not be probable, and for others will be impossible.

In case you haven’t read the rest of the analysis, Android is again this week’s security “problem child.”

Android Google Play signing certificates are generated on whatever hardware an application developer happens to own. The key pair are also generated based upon the default Java algorithm in their installation of Java. Surely, some percentage of Android signing certificates use RSA algorithm key pairs smaller than 2,048 bits and are generated from the vulnerable Infineon hardware and software?

It also appears that Apple applications not offered by the Apple Store can be signed with any certificate, including key pairs generated locally. Some small percentage of Apple applications might have key pairs that can be derived via the Infineon chip subject to a ROCA attack.

Because Apple’s Mac OS X doesn’t make use of the Infineon chip for random number generation,[1] we believe the percentage of derivable private keys will be small. Apple development occurs on Apple machines, which use a pseudorandom software algorithm. Only in a corner case would a developer generate the keys outside of Apple’s development system, XCode. Though this is certainly possible, it is not usual, and perhaps quite rare.

Are there other credible attacks? Absolutely. At the current state of key derivation (estimated at 140.8 CPU years), single, targeted derivations are very credible, especially considering adversaries who can afford to apply serious computing time to the derivation.

For attackers who can leverage massive parallel processing or supercomputing resources, the derivation of a targeted private key might be worth the investment. But the attacker first must obtain the public key, which for a number of scenarios will first require gaining a beachhead on the targeted machine.

For attackers who must maximize profits and minimize expenses and investments, key derivation is probably too expensive an operation, unless the return on investment far outweighs the expense of purchasing the computing power and taking the time to perform that single, targeted derivation. This attack occurs one at a time, not as weaponized and global.

Nation-states, cyber armies, and industrial espionage threat actors who aim at specific targets, these are the types of attacks to worry about. For the average consumer who is not a government official, intelligence agency worker, executive, or technical leader of an organization of interest, there is probably little to worry about. Update your firmware (if you can) when it becomes available. But do not change all of your passwords yet again. (Changing passwords provides no protection for this issue.)

If you reuse passwords often, do not construct passwords with lots of character variation, or do not use passphrases, any time is good to change your password strength. The ease of cracking passwords just keeps increasing exponentially. Make your passphrases slow to crack; criminals will move on to easier targets. For those who insist on using poorly constructed passwords, this attack does not decrease your already weak security posture. Weak passwords offer attackers an easy, well-trodden path to success.

For those who are potential targets of a one-off attack powered by significant resources, you should immediately seek a Trusted Platform Module (TPM) firmware update. These users will also need to reprovision the TPM root key pair and any other keys that have been generated by the Infineon chip and its associated random number generator (RNG) library. (More details follow.) Or, potential targets may wish to obtain a different device that is not dependent upon the vulnerable Infineon chip and its RSA key generation library.

For those concerned about McAfee products: McAfee Drive Encryption and McAfee Management of Native Encryption may depend upon an Infineon TPM chip to protect hard disk encryption keys. This not a McAfee vulnerability. Indeed, use of the TPM is a configurable option in McAfee Drive Encryption. If you do not use the “TPM Autoboot” feature, then even if the Infineon chip is present, McAfee Drive Encryption does not use it.

The situation is the same for any product that may take advantage of available TPM protections: A service upon which McAfee software is dependent and over which McAfee has no control has a serious vulnerability that affects the security of the machine upon which McAfee builds its protections.

McAfee customers who must protect data from a tightly targeted attack should seek a TPM firmware update immediately and then reprovision their disk encryption keys. (More details follow.) In any event, like other software that makes use of a root-of-trust like the TPM, we depend upon the TPM to ensure and anchor trust on a machine; that is its purpose and a very strong reason to use it. Hence, McAfee Drive Encryption and McAfee Management of Native Encryption are functioning as designed. (McAfee disk encryption products do not support Google Chromebook computers.)

Let’s take a look at how several major operating systems issue code-signing certificates and why these certificates will likely not be vulnerable to ROCA.

To follow the analysis, remember that ROCA works against the Infineon chip’s RNG. Even if a vulnerable Infineon chip is used, if some other RNG is employed then the ROCA attack is not applicable.

Microsoft

Authentic code certificates, which must be used for Windows digital signatures, are issued only by a limited set of approved certificate authority (CA) vendors. We might imagine that one or more of these vendors have support staff issuing certificates on their laptops, but that is not how it is done. Because the CA business is entirely dependent on the trustworthiness of the private key that is used to sign the root certificate, commercial CA must rigorously defend their root private key, and ensure that it is generated with as much entropy as possible.

We have been directly involved in the implementation of four public key infrastructures (PKIs) at three companies and worked with several more. Although none of these was a commercial CA, a couple were for large enterprises.

Root of trust CA and PKI typically do not depend on a user level or even server machines; they depend on hardware security modules (HSM) for generating and protecting keys and cryptographic functions. HSM are purpose-built appliances to perform cryptographic operations. The few HSM vendors tend to be very jealous of their careful and exacting RNGs. Based upon our investigation, the major HSM vendors build RNGs to exacting standards; these tend to be custom—as a differentiator.

It is certainly possible that these HSMs contain Infineon chips. It is also possible that the vulnerable Infineon RNG is used in some capacity in the HSM vendor’s RNG. But, the HSM RNG would have to pass its entropy failures into the vendor’s RNG, and that is unlikely. HSM RNGs receive a lot of testing and, often, independent certification of randomness.

Our educated guess is that commercial HSMs do not suffer from poor entropy because that is what the HSM business is built upon. Of course, without direct testing, Infineon ROCA susceptibility is still a possibility, though we believe a remote one (except perhaps for Infineon’s own HSM offering, Aurix).

It is very unlikely that a commercial CA that is successful enough to be approved by Microsoft would generate keys on anything less than heavy-duty, purpose-built RNGs, likely an HSM that can also adequately protect the private keys to root certificates.

Thus unless one of Microsoft’s approved CAs is blowing smoke (remembering that Microsoft certify each implementation), the likelihood of a vulnerable Infineon chip behind a Microsoft certified CA is small.

Apple

Apple issues its own Apple Store certificates. Apple would be very foolish to use just any hardware under the control of random employees and contractors for Apple Store key generation. Our educated guess is that they also employ a bank of HSMs to generate keys. After all, Apple must protect private keying material like Fort Knox, or their trust pyramid falls like a house of cards.

Outside the Apple Store, anything is possible. But, Apple’s development platform, XCode, makes it easy to generate keys. It would be a corner case that another piece of hardware and another operating system were used to generate a key pair, though this is certainly possible. XCode uses the operating system’s pseudorandom number generator, /dev/random. The device is a software generator. The Infineon ROCA attack is not relevant to XCode-generated keys.[2]

Linux

Linux makes use of OpenPGP. OpenPGP’s algorithms are specified in RFC 4880, which does not include RSA key pairs. Thus PGP signed software cannot be vulnerable.

Android/Google Play

The key pair for Google Play is generated by the Java key tool, which relies on the local Java installation and whatever cryptography provider is installed. (There is a default reference implementation.) Therefore, it is quite likely that a significant number of Android applications have been signed with the key pair generated by the vulnerable chip and potentially less than or equal to 2,048 bits.

To make matters worse, a Google Play certificate is glued to the single application to which it has been issued and is good for 30 years. How does one ensure that a private key will be safe for 30 years? That’s a couple of epochs in computer time, more in web time. Consider the rate of hardware and software change in the last 30 years. Brook threw away all his floppy disks 10 years ago; he hadn’t inserted one for at least seven years before that.

For a lone application developer without access to a properly managed HSM and security infrastructure, how do they protect their Android private key for three years, much less 30? There are many other ways to attack networks and computers beyond deriving the private key from the public key.

Taking in all of our analysis, the likely set of applications that have derivable private keys via a ROCA attack lie within the Android space. Although a faked signature based upon deriving a private key from a public key generated by the Infineon chip is certainly possible, for most operating systems it is not a credible attack due to mitigating factors in the way commercial organizations build trust with their certificate chains.

That does not mean that locally signed software used within an organization or community is not subject to a ROCA attack; the attack is certainly credible outside the realm of most major operating systems’ signing process. But self-signed certificates for signing software offer no more trust then you can place in the person who has signed the software. Caveat emptor; do not trust software from unreliable sources. That is nothing new.

Apple chose not to use the Infineon TPM chip that it had included in early Intel-powered MacBooks. The chip is no longer included. (See references, at end.)

The second attack reported in the Forbes article, impersonating trusted software that is then validated by an Infineon TPM, does seem credible to me. It might be interesting to identify which computers including the Infineon chip use it as a TPM.

Other credible attack scenarios

Of the other potential attacks, the most worrying will be those targeting a single victim. Once having gained a foothold on a device (in some unspecified manner) for which the root of trust or other cryptographic functions depend upon 2,048-bit or smaller RSA keys generated via Infineon’s RSA library, an attacker can steal the public key of the RSA key pair—if the attacker has access to the public key.[3] Offline, with sufficient computing resources, the attacker can derive the private key. At that point, what the attacker can accomplish is dependent upon the functions for which the private key has been used.

If the vulnerable key pair is used as the device startup (“boot”) root of trust, the attacker can insert software into the boot sequence. That might surrender complete control of the victim’s machine.

If the vulnerable key pair have been used to “seal,” that is, protect secrets in the TPM, then those secrets are compromised. For instance, in the case of Microsoft’s BitLocker disk encryption, the disk encryption key could be gained by the attacker.

A TPM attack will depend upon individual use cases and what the attacker hopes to accomplish through the attack. But the attack remains difficult to weaponize, and turn into a general-purpose, automated attack that anyone with the tool could carry out.

First, that attacker must get the public key to the vulnerable RSA key pair. TPM public keys generally remain on the local machine, and are not used across a network, though there are cases for network use of a TPM public key. (Brook has reviewed several such cases, but none of these was with the Infineon TPM.)

Smart card attacks, especially national cards, have been analyzed elsewhere. (See references, at end.) We find no fault in those analyses. Purveyors of smart cards using vulnerable RSA key pairs have been placed on notice to respond, quickly and effectively.

We offer this analysis in the hope that defenders and incident responders will be better able to assess the relative importance of the Infineon RSA RNG vulnerability to key derivation.

Typical consumers will not likely, at least immediately, be a target of this attack. The exploit may never become sufficiently automated to make it useful for broad cybercriminal activity. Those with valuable secrets protected by a vulnerable key pair would be wise to fix or remove the issue.

If a reader feels that they might be a target, then a first line of defense will be to install and maintain endpoint protections such as the latest version of McAfee Endpoint Security (ENS) or similar protections. By keeping attackers from establishing any presence on a machine, most credible attack scenarios cannot achieve the prerequisite first step such that any local, public RSA keys can be obtained.

McAfee Drive Encryption key reprovisioning

Drive Encryption is affected only if the TPM Autoboot policy is in use. McAfee Drive Encryption customers wishing to update an Infineon TPM should follow these steps:

  • Change the TPM Autoboot policy to Non-TPM Autoboot (or use Temporary Autoboot).
  • Update the Infineon TPM firmware provided by your hardware vendor.
  • Clear the TPM.
  • Reprovision the TPM with new keys.
  • Re-enable the TPM autoboot policy.

See the McAfee Service Portal for updates and detailed information.

Brook Schoenfield is Principal Engineer, Product Security Architecture and Jonathan Oulds is Senior Software Development Engineer and Product Security Champion Lead. They thank Joani Wilkinson, Senior Technical Support Engineer, for her assistance with this analysis.

References

https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx

https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man4/random.4.html

https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html#//apple_ref/doc/uid/TP40012582-CH31-SW41

https://developer.apple.com/support/code-signing/

https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html#//apple_ref/doc/uid/TP40012582-CH31-SW1

https://en.wikipedia.org/wiki/Pretty_Good_Privacy

RFC 4880 (November 2007)

RFC 4880bis in 2014

https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update

https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/

Notes

[1] First-generation MacBooks included an Infineon TPM but did not use it. See http://www.osxbook.com/book/bonus/chapter10/tpm/.

[2] Pseudorandom number generators have plenty of cryptographic problems, which is why HSM vendors build high-entropy RNG.

[3] TPM key use cases are largely confined to the machine upon which they are used, which implies that the attacker has gained a foothold on the machine to get the public key.

The post ROCA: Which Key-Pair Attacks Are Credible? appeared first on McAfee Blogs.

KRACKs Against Wi-Fi Serious But Not End of the World

On October 12, researcher Mathy Vanhoef announced a set of Wi-Fi attacks that he named KRACKs, for key reinstallation attacks. These attack scenarios are against the WPA2 authentication and encryption key establishment portions of the most recent set of protocols. The technique is through key reinstallation.

The attack can potentially allow attackers to send attacker controlled data to your Wi-Fi connected device. In some situations, the attacker can break the built in Wi-Fi protocol’s encryption to reveal users’ Wi-Fi messages to the attacker.

However key reinstallation depends on either working with the inherent timing of a Wi-Fi during a discreet, somewhat rare (in computer terms) exchange or the technique depends upon the attacker forcing the vulnerable exchange through some method (see below for examples). Both of these scenarios take a bit of attacker effort, perhaps more effort than using any one of the existing methods for attacking users over Wi-Fi?

For this reason, while KRACKs is a serious issue that should be fixed as soon as possible (see below), our collective digital lives probably won’t experience a tectonic shift due to Wi-Fi key reinstallation attacks.

Please read on for a technical analysis of the issue.

“… because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.”

–Mathy Vanhoef, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

The highlighted text above is Vanhoef’s, not mine.

Depending upon which key establishment exchange is attacked, as Vanhoef notes, injection of messages might be the result. But, for some exchanges, decryption might also be possible.

For typical Wi-Fi traffic exchange, AES-CCMP is used between the client (user) and the access point (AP, the Wi-Fi router). Decryption using KRACKs is not thought to be possible. But decryption is not the only thing to worry about.

An attacker might craft a message that contains malware, or at least, a “dropper,” a small program that when run will attempt to install malware. Having received the dropper, even though the message may make no sense to the receiving program, the dropper is still retained in memory or temporary, perhaps even permanent, storage by the receiving computer. The attacker then has to figure out some way to run the dropper—in attack parlance, to detonate the exploit that has been set up through the Wi-Fi message forgery.

“Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged.“

–Mathy Vanhoef, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

Packet forgery is worse, as the receiver may consider that the data is legitimate, making it easier for an attacker to have the receiver accept unexpected data items, influencing the course of an exchange and establish a basis upon which to conduct follow-on, next-step exploits.

In my opinion KRACKs are a serious problem to which the wise will wish to respond.

The essential problem with Wi-Fi is that it is free to intercept. Radio waves travel over the air, which, as we all know, is a shared medium. One need not “plug in” to capture Wi-Fi (or any radio-carried) packets. One simply must craft a receiver strong enough to “hear,” that is, receive the transmissions of interest.

But although certainly serious, are KRACKs the end of the known digital universe? I think not.

First, the attacker has to be present and alert to the four-way, WPA2 handshake. If this has already passed successfully, the attacker’s key reinstallation is no longer possible. The handshake must be interjected at exchange #3, which will require some precision. Or, the attacker must force the key exchange.

One could, I imagine, write an attack that would identify all WPA2 handshake exchanges within range, and inject the attacker’s message #3 to each handshake to deliver some sort of follow-on exploit. This would be a shotgun approach, and might on large, perhaps relatively open networks have potential attacker benefits.[1]

Supplicants (as Wi-Fi clients are called) do not constantly handshake. The handshake interchange takes place upon authentication and reauthentication, and in some networks upon shifting from one AP to another when the client changes location (a “hand-off”). These are discreet triggers, not a constant flow of handshake message #3. Johnny or Janie attacker has to be ready and set up in anticipation of message #3. That is, right after message #3 goes by, attacker’s #3 must be sent. Once the completed handshake message #4 goes by, I believe that the attack opportunity closes.

I fear that the timing part might be tricky for the average criminal attacker. It would be much easier to employ readily available Wi-Fi sniffing tools to capture sufficient traffic to allow the attacker to crack weak Wi-Fi passwords.

There are well-understood methods for forcing Wi-Fi authentication (see DEAUTH, below). Since these methods can be used to reveal the password for the network or the user, using one of these may be a more productive attack?

There are other methods for obtaining a Wi-Fi password, as well: The password must be stored somewhere on each connecting device or the user would need to reenter the password upon every connection/reconnection. Any attack that gives attacker access to privileged information kept by any device’s operating system can be used to gain locally stored secrets like Wi-Fi passwords.

Wi-Fi password theft (whether WPA-Enterprise or WPA-Personal) through Wi-Fi deauthentication, “DEAUTH,” has been around for some time; numerous tools make the attack relatively trivial and straightforward.

Nation-state attackers may have access to banks of supercomputers or massive parallel processing systems that they can apply for rapid password cracking of even complex passwords. A targeted nation-state–sponsored Wi-Fi password-cracking attack is difficult to entirely prevent with today’s technologies. There are likely other adversaries with access to sufficient resources to crack complex passwords in a reasonable amount of time, as well.[2]

Obviously, as Vanhoef suggests, as soon as your operating system or Wi-Fi client vendor offers an update to this issue, patch it quickly. Problem, hopefully, solved. Please see https://www.krackattacks.com for updates from security vendors that are working with the discoverer. Question your vendor. If your vendor does not respond, pressure them; that’s my suggestion.

Other actions that organizations can couple with good Wi-Fi hygiene are to use good traffic and event analysis tools, such as modern Security Information Event Management (SIEM) software, network ingress and egress capture for anomaly analysis, and perhaps ingress/egress gateways that prevent many types of attack and forms of traffic.

“One can use VPN, SSH2 tunnels, etc., to ensure some safety from ARP poisoning attacks. Mathy Vanhoef also uses an SSL stripper that depends on badly configured web servers. Make sure your TLS implementation is correct!”

– Carric Dooley, Global Lead, Foundstone Consulting Services

Organization Wi-Fi hygiene includes rapidly removing rogue access points, Wi-Fi authentication based upon the organization’s central authentication mechanism (thus do not employ a WPA password), strong password construction rules, and certificates issued to each Wi-Fi client without which access to Wi-Fi will be denied. Add Wi-Fi event logs to SIEM collection and analysis. Find out whether organization access points generate an event on key reinstallation. This is a fairly rare event. If above-normal events are being generated, your Wi-Fi may be suffering from a KRACK.

None of the foregoing measures will directly prevent key reinstallation attacks. Reasonable security practices do make gaining access to Wi-Fi more difficult, which will prevent or slow other Wi-Fi attacks. Plus, physical security ought to pay attention to anyone sitting in the parking lot with a Wi-Fi antenna pointing at a campus building. But that was just as true before KRACKs were discovered.

For home users, use a complex password on your home Wi-Fi. Make cracking your password difficult. Remember, you usually must enter the password only once for each client device.

Maintain multiple Wi-Fi networks (probably, multiple access points), each with different passwords: one for work or other sensitive use; and another for smart TVs and the like and other potentially vulnerable devices such as Internet of Things devices—isolate those from your network shares, printers, and other sensitive data and trusted devices. Install a third Wi-Fi for your guests. That network should be set up so that each session is isolated from the others; all your guests need is to get to the internet. Each SSID network must have a separate, highly varied password: numbers, lowercase, uppercase, symbols. Make it a long passphrase that resists dictionary attacks.

Wi-Fi routers are a commodity; I do not suggest spending a great deal of money. How much speed do your occasional guests really need? Few Internet connections are as fast as even bottom-tier home Wi-Fi. Most of your visitors probably do not need access to your sensitive data, yes? Should your kids have their own Wi-Fi so that their indiscretions do not become yours?

Multiple Wi-Fi networks will help to slow and perhaps confound KRACKs cybercriminals. “Which network should I focus on?” You increase the reconnaissance the attacker must perform to promulgate a successful attack. Maybe they will move on to simpler home network.

If you happen to notice someone sitting in a car in your neighborhood with an open laptop, be suspicious. If they have what looks like an antenna, maybe let law enforcement know.

Basic digital security practices can perhaps help. For instance, use a VPN even over Wi-Fi. Treat Wi-Fi, particularly, publicly available Wi-Fi as an untrustable network. Be cognizant of where the Wi-Fi exists. WPA2 is vulnerable to decryption, so don’t trust airports, hotels, cafes, anywhere where the implementers and maintainers of the network are unknown.

Users of some Android and Linux clients should be aware that an additional implementation error allows an attacker immediate access to the decryption of client and access point Wi-Fi traffic. Remember, all those smart TVs, smart scales, home automation centers, and thermostats are usually nothing more than specialized versions of Linux. Hence, each may be vulnerable. On the other hand, if these are segregated onto a separate, insecure Wi-Fi, at least attackers will not have readily gained your more sensitive network and devices. While waiting for a patch for your vulnerable Android device, perhaps it makes sense to put it on the untrusted home Wi-Fi as a precaution.

You may have noticed that I did not suggest changing the home Wi-Fi passwords. Doing so will not prevent this attack. Still, the harder your WPA2 password is to crack, the more likely common cybercriminals will move on to easier pickings.

As is often the case in these serious issues, reasonable security practices may help. At the same time, failure to patch quickly leaves one vulnerable for as long as it takes to patch. I try to remember that attackers will become ever more facile with these methods and what they can do with them. They will build tools, which, if these have value, will then become ever more widespread. It is a race between attacker capability and patching. To delay deploying patches is typically a dance with increasing risk of exploitation. In the meantime, the traffic from this attack will be anomalous. Watch for it, if you can.

Many thanks to Carric Dooley of Foundstone Professional Services for his help with this analysis.

 

[1] “When a client joins a network, it […] will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. […] Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.”

[2] My LinkedIn password was among those stolen during the 2011 LinkedIn breach. A research team attempted to crack passwords. After three months, they cracked something like 75% of the passwords. However, my highly varied, but merely six-character password was never cracked. Although today’s cracking is factors more sophisticated and rapid, a varied nondictionary password still slows the process  considerably.

The post KRACKs Against Wi-Fi Serious But Not End of the World appeared first on McAfee Blogs.

NoMoreRansom – One year on!

One year on.  It is fair to say that the No More Ransom project not only exceeded our expectations, but simply blew these initial expectations out of the water.  A collaboration between six partners (McAfee, EC3, Dutch Police, Kaspersky Lab, AWS and Barracuda) has now grown to include more than 100 partners across the public and private sector.  We often hear people talk about Public-Private Partnerships, but here is a true example of that commitment in action.

Because of this commitment from all the partners, this initiative has resulted in the successful decryption of more than 28,000 computers.  Let us put that into context, for zero cost, victims of ransomware who do not have to be customers of any security provider can get their data back for nothing.  They don’t have to fill in a survey, enter their email address, provide their credit card details, in fact they don’t even have to worry about obfuscating their IP address.  For the first time, there is another option.  No longer are victims faced with the option of a) lose my data or b) pay criminals.

So thank you to all of our partners, thank you to those of you that tweeted, blogged about it.  This site has been successful, in fact so successful that we even have ransomware named after us.

Of course, the Queen of England gets a boat named after her, we get ransomware!  Well that’s okay, because it shows that as the tens of millions of dollars we have prevented going into the hands of criminals, they have taken notice.

We will not stop, in fact, we need more partners, more decryption tools, and more successes.   The message of #DontPay seems to be working (as we witnessed with WannaCry and nPetya), and we will continue in our efforts to hurt the bottom line of criminals.

 

The post NoMoreRansom – One year on! appeared first on McAfee Blogs.

Petya More Effective at Destruction Than as Ransomware

At the beginning of the recent Petya malware campaign, the world was quick to exclaim this attack was ransomware. Now, with time to analyze the facts and make comparisons to other ransomware campaigns, this Petya attack does not look so much like ransomware. To back up this claim, let’s examine three other well-known ransomware campaigns: Cerber, Locky, and WannaCry.

Generally, the goal of ransomware is financial gain. For a ransomware family to make money in the long term, it must be able to both encrypt and decrypt files. These steps ensure that once payment is sent, data can be recovered. Otherwise, victims will learn that payments are worthless and the ransomware industry’s reputation will suffer, along with the loss in revenue for the criminal. Cerber, Locky, and WannaCry all had methods for decrypting files after encryption. Unlike Cerber and Locky, however, WannaCry lacked victim identification, which left most victims with encrypted disks even after payment. The recent Petya campaign does not include the capability to decrypt files due to changes in the key and victim ID, with or without payment. The word is spreading, and we can expect more and more victims to stop paying the ransom. In a financially motivated campaign, this significantly reduces the ransomware’s effectiveness. Thus, the orchestrators of this campaign appear to be either short sighted or not financially motivated.

What other indicators do we have of the attackers’ motivation? The behavior of malware can also help us infer intent of the authors. Let’s look at some key behaviors of the new campaign. Namely, the way it finds new hosts; the files it chooses to encrypt; its stealth tactics; and its ransom-note injunction with the method for collecting payment.

When Petya seeks new hosts it first checks to see if it is installed on a domain controller. If it is, it looks for the DHCP server service to understand the local network. Using this information, it then scans only the local network. If not on a domain controller, it uses an address resolution protocol (ARP) scan technique to discover the local network. See our previous post for more technical details.

In contrast, WannaCry generates random IP addresses to attempt to attack potential targets, not limited to the local network, allowing it to spread across the Internet. Cerber and Locky do not have a built-in spreading mechanism; they mostly use combinations of botnets and email spam or other social engineering techniques to infect users. If money is the motivation, as it is with traditional ransomware, the larger the spread across the Internet the better. Local spreading of the malware is more likely to cripple or sabotage a specific organization and less likely to spread across organizations. In this case, however, Petya also started to spread globally. One or more targets in the Ukraine were the first to be attacked. The infections spread from there. We believe that the Petya attackers did not intend to reach so broad an audience during the initial attack, yet still caused a lot of collateral damage.

The core function of ransomware is to encrypt files. Arguably the more files that are encrypted, the more effective the ransomware is. Encrypted files are the motivation for victims to pay ransoms. Most ransomware limits that files it encrypts based on file extension to ensure the victim’s system is still functional and the victim can pay the ransom.

In the preceding table, we compare the number of file types encrypted by the different ransomware families. A variant of Petya from nearly one year ago listed 228 extensions for encryption. These numbers show a large amount of coverage and the motivation to withhold as many files as possible without crippling the system. The recent Petya campaign targets only 65 file types and significantly reduces the time it takes for victims’ files to be fully encrypted. Although there can be reasons for speedy encryption, the actors sacrificed potentially important files, which cannot be used as leverage to entice victims to pay the ransomware.

When Cerber, Locky, WannaCry and previous Petya variants encrypt a file, they add their own extension to the file. This shows the user that the file is still there, but no longer in the usual format. The current Petya does not add an extension to a file after encryption. The users remain unaware of encryption or even which files are encrypted. They may not know if an important file they rarely access is indeed on the list of files they can no longer access. Instead of rebooting immediately, Petya restarts the system after an hour, allowing the malware some time to attack the network before anyone notices. Its priorities are to infect as many machines as possible instead of getting a ransom from a particular victim.

How do we explain Petya’s attacks against the master boot record and master file table? These render the entire system unusable. In this case why does encrypting files matter? The attack on the boot record and file table are similar to the behavior of the previous version of Petya, but there is one important difference. In research reported by Hasherezade, the new Petya destroys the Salsa20 cipher key by erasing it from the disk. In previous versions of Petya, the key is backed up in the victim’s ID before being erased—allowing for the recovery of the disk.  Hasherezade also shows that the victim’s ID is generated before the random Salsa20 key is made, proving there is no relationship between the Salsa20 key and the victim’s ID. A reboot is required for this overwrite to take effect and supports the priorities we have mentioned. This difference in priorities implies the attackers are looking for pure destruction—closer in behavior to campaigns like Shamoon rather than ransomware such as Cerber, Locky, and WannaCry.

Before infection                                                After infection

 

Before                                                             After

Another distinct characteristic of the new Petya is that it attempts to cover its tracks. This variant has code to delete Windows event logs to make it harder for researchers to discover what it does. This secrecy is not present in major ransomware families such as Cerber, Locky, or WannaCry. Ransomware by nature is not stealthy; it needs to be seen by the user. It must be visible for the attackers to get paid. It is not uncommon to see antimalware evasion techniques in ransomware, but Petya’s cleanup at the end of the infection does not provide any coverage against antimalware products. Removing Windows logs does not match the normal steps of ransomware.

For ransomware to be financially effective, it needs a mechanism to collect payments. Cerber, Locky, and WannaCry use the TOR network in conjunction with a Bitcoin wallet. If the ransom is not sent within a certain time, the cost increases. This ticking clock pushes the user to pay as quickly as possible, a common social engineering technique. The use of TOR also makes the malware difficult to track. Petya uses a Bitcoin wallet but provides an email address to contact. It does not set a time limit or threaten to increase the cost. Effectively, it removes proven techniques used in the past to increase profits. Although email can be difficult to track, it provides more clues for law enforcement to follow than a TOR web page. A financially motivated attacker will try to force a user to pay as soon as possible, as we have seen in other ransomware campaigns.

The attacks that began on June 27 by the new Petya campaign are no doubt malicious and caused serious damage. In the rush to find solutions and combat this new threat, is it possible the world miscategorized this new threat? Our analysis comparing Petya to previous ransomware families supports the idea that this attack was not ransomware but was intended to maximize destruction. The attackers decisions regarding propagation suggest they may have had a certain group or groups in mind as targets. The security industry has seen many examples of campaigns intended to destroy systems, such as Shamoon and Shamoon 2.

Unfortunately, we expect to see more targeted acts of destruction in the future. The industry has also been knee deep in numerous new ransomware families and variants during the last two years. However, two major recent families seem to break the ransomware mold: to a lesser extent, WannaCry, which has more ransomware capabilities, and, to a greater extent, the new Petya variant, which appears to be significantly more interested in destruction than money. (We expressed our suspicions about WannaCry in “Is WannaCry Really Ransomware?”) For malware like this, demanding a ransom may be a red herring, merely a distraction to hide its true intentions.

The post Petya More Effective at Destruction Than as Ransomware appeared first on McAfee Blogs.