Daily Archives: August 12, 2019

Extended Validation Certificates are (Really, Really) Dead

Extended Validation Certificates are (Really, Really) Dead

Almost one year ago now, I declared extended validation certificates dead. The entity name had just been removed from Safari on iOS, it was about to be removed from Safari on Mojave and there were indications that Chrome would remove it from the desktop in the future (they already weren't displaying it on mobile clients). The only proponents of EV seemed to be those selling it or those who didn't understand how reliance on the absence of a positive visual indicator was simply never a good idea in the first place.

The writing might have been on the wall a year ago, but the death warrant is now well and truly inked with both Chrome and Firefox killing it stone cold dead. Here's the Google announcement:

On HTTPS websites using EV certificates, Chrome currently displays an EV badge to the left of the URL bar. Starting in Version 77, Chrome will move this UI to Page Info, which is accessed by clicking the lock icon.

And here's the Firefox announcement:

In desktop Firefox 70, we intend to remove Extended Validation (EV) indicators from the identity block (the left hand side of the URL bar which is used to display security / privacy information).

Chrome 77 is currently scheduled to ship on September 10 and Firefox 70 on October 22. With both browsers auto-updating for most people, we're about 10 weeks out from no more EV and the vast majority of web users no longer seeing something they didn't even know was there to begin with! Oh sure, you can still drill down into the certificate and see the entity name, but who's really going to do that? You and I, perhaps, but we're not exactly in the meat of the browser demographics.

I will admit to some amusement in watching all this play out, partly because the ludicrous claims about EV efficacy really come crashing down when it's no longer visible to the end user. But also partly because of comments along the lines of "Google is pushing the EV changes into the spec". Google wasn't pushing anything into a spec, no more so than Apple was last year and Mozilla is now, they were all simply adapting their own UIs to better service their customers and they've all arrived at the same conclusion: remove the EV entity name. But it's the reasons why they're doing this that I find particularly interesting, for example in the Chrome announcement:

Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection.

That absolutely nails it - users aren't going to change their behaviour when they see a DV padlock rather than an EV entity name. This is precisely what Mozilla called out in their announcement:

The effectiveness of EV has been called into question numerous times over the last few years, there are serious doubts whether users notice the absence of positive security indicators and proof of concepts have been pitting EV against domains for phishing.

In fact, Mozilla went even further and referenced the great work that Ian Carroll did when he registered a colliding entity name and got an EV cert for it:

More recently, it has been shown that EV certificates with colliding entity names can be generated by choosing a different jurisdiction. 18 months have passed since then and no changes that address this problem have been identified.

All Ian had to do was spend $100 registering "Stripe Inc" in a different US state to the payment processor you'd normally associate the name with then another $77 on the EV cert and less than hour later, he had this newsworthy result:

Extended Validation Certificates are (Really, Really) Dead

He did this perfectly legally and in a fashion compliant with the baseline requirements yet shortly thereafter, Comodo CA (now Sectigo) revoked the certificate. They later apologised and blamed the decision on "A Comodo CA employee who is not a member of senior management". Apple knew this was a problem when they killed off the EV entity name last year:

Apple said that this changes was based on research and customer input. “Org name is not tied to users intended destination the same way that the domain name is”

So now I'm curious - how long will take the CAs selling EV to adjust their marketing to align with reality? For example, Sectigo is going to need to kill off most of their EV description:

Extended Validation Certificates are (Really, Really) Dead

Half their "visible trust indicators" go too which leaves them with an identical set of bullet points to DV:

Extended Validation Certificates are (Really, Really) Dead

But hey, you still get to put a logo on the page! 🤦‍♂️

Let's not just single out Sectigo though, DigiCert will also need to significantly revise their marketing paraphernalia:

Extended Validation Certificates are (Really, Really) Dead

I'm assuming the bit about brand refers to the entity name in EV as it doesn't appear against OV or DV on that page. Oh - and just for reference, DigiCert refused to issue Ian a certificate for Stripe due to "risk factors". What risk factors? Well...

It's time for re-sellers to clean up their act too, for example The SSL Store:

Extended Validation Certificates are (Really, Really) Dead

I chose to leave the entire browser window in this screen grab to highlight the irony of "The SSL Store" having an EV cert issued to "Rapid Web Services". Remember one of Apple's complaints - "Org name is not tied to users intended destination" - yeah...

Actually, The SSL Store provides many great opportunities for reflection on the EV craziness that was (it's pretty safe to use the past tense now). Their piece on how EV provides "tremendous value" is clearly now on the nose and is full of great zingers such as how important it is to be able to differentiate PayPal.com from FakePayPal.com. Why a great zinger? Because PayPal themselves decided that didn't matter back in September last year. And since that entire piece was in response to me writing about just how useless EV was even back then, let's pick it apart even further, for example:

The value of an EV certificate is clear. It is the ability to know more than your browser can assert through connecting to a hostname, parsing a certificate file, and verifying an encryption key.

Ouch - that didn't age well!

EV is now really, really dead. The claims that were made about it have been thoroughly debunked and the entire premise on which it was sold is about to disappear. So what does it mean for people who paid good money for EV certs that now won't look any different to DV? I know precisely what I'd do if I was sold something that didn't perform as advertised and became indistinguishable from free alternatives...

Making authentication even easier with FIDO2-based local user verification for Google Accounts


Passwords, combined with Google's automated protections, help secure billions of users around the world. But, new security technologies are surpassing passwords in terms of both strength and convenience. With this in mind, we are happy to announce that you can verify your identity by using your fingerprint or screen lock instead of a password when visiting certain Google services. The feature is available today on Pixel devices and coming to all Android 7+ devices over the next few days.



Simpler authentication experience when viewing your saved password for a website on passwords.google.com


These enhancements are built using the FIDO2 standards, W3C WebAuthn and FIDO CTAP, and are designed to provide simpler and more secure authentication experiences. They are a result of years of collaboration between Google and many other organizations in the FIDO Alliance and the W3C.

An important benefit of using FIDO2 versus interacting with the native fingerprint APIs on Android is that these biometric capabilities are now, for the first time, available on the web, allowing the same credentials be used by both native apps and web services. This means that a user only has to register their fingerprint with a service once and then the fingerprint will work for both the native application and the web service.

Note that your fingerprint is never sent to Google’s servers - it is securely stored on your device, and only a cryptographic proof that you’ve correctly scanned it is sent to Google’s servers. This is a fundamental part of the FIDO2 design.

Here is how it works

Google is using the FIDO2 capability on Android to register a platform-bound FIDO credential. We remember the credential for that specific Android device. Now, when the user visits a compatible service, such as passwords.google.com, we issue a WebAuthn “Get” call, passing in the credentialId that we got when creating the credential. The result is a valid FIDO2 signature.


High-level architecture of using fingerprint or screen lock on Android devices to verify a user’s identity without a password

Please follow the instructions below if you’d like to try it out.
Prerequisites
  • Phone is running Android 7.0 (Nougat) or later
  • Your personal Google Account is added to your Android device
  • Valid screen lock is set up on your Android device
To try it
  • Open the Chrome app on your Android device
  • Navigate to https://passwords.google.com
  • Choose a site to view or manage a saved password
  • Follow the instructions to confirm that it’s you trying signing in
You can find more detailed instructions here.

For additional security
Remember, Google's automated defenses securely block the overwhelming majority of sign-in attempts even if an attacker has your username or password. Further, you can protect your accounts with two-step verification (2SV), including Titan Security Keys and Android phone’s built-in security key.

Both security keys and local user verification based on biometrics use the FIDO2 standards. However, these two protections address different use cases. Security keys are used for bootstrapping a new device as a second factor as part of 2SV in order to make sure it’s the right owner of the account accessing it. Local user verification based on biometrics comes after bootstrapping a device and can be used for re-authentication during step-up flows to verify the identity of the already signed-in user.

What’s next
This new capability marks another step on our journey to making authentication safer and easier for everyone to use. As we continue to embrace the FIDO2 standard, you will start seeing more places where local alternatives to passwords are accepted as an authentication mechanism for Google and Google Cloud services. Check out this presentation to get an early glimpse of the use cases that we are working to enable next.

McAfee AMSI Integration Protects Against Malicious Scripts

Following on from the McAfee Protects against suspicious email attachments blog, this blog describes how the AMSI (Antimalware Scan Interface) is used within the various McAfee Endpoint products. The AMSI scanner within McAfee ENS 10.6 has already detected over 650,000 pieces of Malware since the start of 2019. This blog will help show you how to enable it, and explain why it should be enabled, by highlighting some of the malware we are able to detect with it.

ENS 10.6 and Above

The AMSI scanner will scan scripts once they have been executed. This enables the scanner to de-obfuscate the script and scan it using DAT content. This is useful as the original scripts can be heavily obfuscated and are difficult to generically detect, as shown in the image below:

Figure 1 – Obfuscated VBS script being de-obfuscated with AMSI

Enable the Scanner

By default, the AMSI scanner is set to observe mode. This means that the scanner is running but it will not block any detected scripts; instead it will appear in the ENS log and event viewer as show below:

Figure 2 – Would Block in the Event log

To actively block the detected threats, you need to de-select the following option in the ENS settings:

Figure 3 – How to enable Blocking

Once this has been done, the event log will show that the malicious script has now been blocked:

Figure 4 – Action Blocked in Event Log

In the Wild

Since January 2019, we have observed over 650,000 detections and this is shown in the IP Geo Map below:

Figure 5 – Geo Map of all AMSI detection since January 2019

We are now able to block some of the most prevalent threats with AMSI. These include PowerMiner, Fileless MimiKatz and JS downloader families such as JS/Nemucod.

The section below describes how these families operate, and their infection spread across the globe.

PowerMiner

The PowerMiner malware is a cryptocurrency malware whose purpose is to infect as many machines as possible to mine Monero currency. The initial infection vector is via phishing emails which contain a batch file. Once executed, this batch file will download a malicious PowerShell script which will then begin the infection process.

The infection flow is shown in the graph below:

Figure 6 – Infection flow of PowerMiner

With the AMSI scanner, we can detect the malicious PowerShell script and stop the infection from occurring. The Geo IP Map below shows how this malware has spread across the globe:

Figure 7 – Geo Map of PS/PowerMiner!ams  detection since January 2019

McAfee Detects PowerMiner as PS/PowerMiner!ams.a.

Fileless Mimikatz

Mimikatz is a tool which enables the extraction of passwords from the Windows LSASS. Mimikatz was previously used as a standalone tool, however malicious scripts have been created which download Mimikatz into memory and then execute it without it ever being downloaded to the local disk. An example of a fileless Mimikatz script is shown below (note: this can be heavily obfuscated):

Figure 8 – Fileless Mimikatz PowerShell script

The Geo IP Map below shows how fileless Mimikatz has spread across the globe:

Figure 9 – Geo IP Map of PS/Mimikatz detection since January 2019

McAfee can detect this malicious script as PS/Mimikatz.a, PS/Mimikatz.b, PS/Mimikatz.c.

JS/Downloader

JS downloaders are usually spread via email. The purpose of these JavaScript files is to download further payloads such as ransomware, password stealers and backdoors to further exploit the compromised machine. The infection chain is shown below, as well as an example phishing email:

Figure 10 – Infection flow of Js/Downloader

Figure 11 – Example phishing email distributing JS/Downloader

Below is the IP Geo Map of AMSI JS/Downloader detections since January 2019:

Figure 12 – Geo Map of AMSI-FAJ detection since January 2019

The AMSI scanner detects this threat as AMSI-FAJ.

MVISION Endpoint and ENS 10.7

MVISION Endpoint and ENS 10.7 (Not currently released) will use Real Protect Machine Learning to detect PowerShell AMSI generated content.

This is done by extracting features from the AMSI buffers and running these against the ML classifier to decide if the script is malicious or not. An example of this is shown below:

 

Thanks to this detection technique, MVISION EndPoint can detect Zero-Day PowerShell threats.

Conclusion

We hope that this blog has helped highlight why enabling AMSI is important and how it will help keep your environments safe.

We recommend our customers who are using ENS 10.6 on a Windows 10 environment enable AMSI in ‘Block’ mode so that when a malicious script is detected it will be terminated. This will protect Endpoints from the threats mentioned in this blog, as well as countless others.

Customers using MVISION EndPoint are protected by default and do not need to enable ‘Block’ mode.

We also recommend reading McAfee Protects against suspicious email attachments which will help protect you against malware being spread via email, such as the JS/Downloaders described in this blog.

All testing was performed with the V3 DAT package 3637.0 which contains the latest AMSI Signatures. Signatures are being added to the V3 DAT package daily, so we recommend our customers always use the latest ones.

The post McAfee AMSI Integration Protects Against Malicious Scripts appeared first on McAfee Blogs.

SSH In Nutshell : A protocol for secured network communication

Estimated reading time: 4 minutes

Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. A widely used Transport Layer Protocol, SSH is used to secure connections between clients and servers. SSH was basically designed as a replacement for conventional Telnet and for unsecured remote shell protocols such as the Berkeley rlogin, rsh, and rexec protocols. These protocols send critical information, such as passwords, in plain text format, and are susceptible to interception and disclosure using methods like packet analysis or deep packet inspection. The encryption used by SSH provides confidentiality and integrity of data over an unsecured network, such as the Internet.

                                         Fig. 1: SSH Protocol Stack

How Does SSH Work?

The SSH protocol employs a client-server model for authentication and encryption of data transferred between them.

Negotiating Encryption for the Session

  • Version Exchange: When a TCP connection is made by a client, the server responds with the protocol versions it supports. If the client can match one of the acceptable protocol versions, the connection continues.
  • Key Exchange Initialization: To kick off the key exchange, both sides send a SSH_MSG_KEX_INIT message to each other, with a list of cryptographic primitives they support with their preference. These primitives are basic building blocks, used to perform key exchange and bulk data encryption. The following table (Tab.1) shows some examples of cryptographic primitives.
                                                                                          Tab.1: Cryptographic Primitives

 

  • Diffie-Hellman Initialization: The key exchange begins by the client, generating an ephemeral key pair (private and associated public key) and sending its public key to the server in a, SSH_MSG_KEX_ECDH_INIT message (Fig. 2). The server checks the authorized_keys file of the account that the client is attempting to log into for the key ID. If strict key checking is enabled, and key is not found to be correct, the connection is rejected by the server thereby safeguarding the server from connecting with unknown clients. The key pair created will only be used during the key exchange and disposed afterwards. So, for an attacker it is extremely difficult to steal a private key while passively recording encrypted traffic. This property is called forward secrecy.
                                                   Fig. 2 Generation of the key exchange initialization message

 

  • Diffie-Hellman Reply: On receiving SSH_MSG_KEX_ECDH_INIT message, server generates its own ephemeral key pair. The shared secret key K is generated by server, with its own key pair and client’s public key. After successful generation of shared secret an exchange hash H is generated (Fig. 3). The exchange hash is signed by server to generate its signature HS (Fig. 4).
                                                                 Fig. 3: Generation of the exchange hash H

 

The exchange hash and its signature serve several purposes:

•  The signature or verification loop, of the exchange hash and its signature enables the client to verify whether the server has ownership of the host private key. If yes, the client is connected to the correct server.

• A faster handshake is achieved by signing the exchange hash instead of input to exchange hash.

                                                                  Fig. 4: Generation of the ECDH KEX reply

 

The exchange hash is generated by taking the hash (either SHA256, SHA384 or SHA512, as per the key exchange algorithm) of the following fields:

• Magics M

• Server host public key (or certificate) HPub

• Client public key A

• Server public key B

• Shared secret K

Magics consists of client version, server version, clients SSH_MSG_KEXINIT message and server SSH_MSG_KEXINIT message. With this information in hand, the SSH_MSG_KEX_ECDH_REPLY message can be constructed by the server from the following:

ephemeral public key of the server B,

the host public key of the server HPub,

and the signature on the exchange hash HS.

After SSH_MSG_KEX_ECDH_REPLY is received by client, the client can calculate the secret K and the exchange hash H.

The client extracts the host public key (or certificate) from SSH_MSG_KEX_ECDH_REPLY and verifies the signature of exchange hash HS, hence proving the ownership of the host private key.

In order to prevent Man-in-the-Middle (MITM) attacks, after the signature is validated, the host public key (or certificate) retrieved is checked against a local database of the trusted hosts; if this key (or certificate) is not trusted the connection is terminated.

If you have ever seen a message like below (Fig. 5), it means that the key presented is not in your local database of known hosts.

                                                                          Fig. 5: Prompt for Authentication of Server

Authenticating the User’s Access to the Server

The next stage involves authenticating the user and deciding access. There are various mechanisms for authentication but which mechanism to use depends upon what purpose the server is configured for.

The simplest is password authentication, but this is highly not recommended due to complexities and automated password breaking scripts.

The most popular and recommended alternative is the use of SSH key pairs. SSH key pairs are asymmetric keys. The public key is used to encrypt data that can only be decrypted with the private key. The public key can be freely shared, because, although it can encrypt for the private key, there is no method of deriving the private key from the public key.

Summary

SSH provides a secured encrypted channel for configuration of remote servers, established by agreed cryptographic primitives, and user authentication by symmetric key pairs.

The following diagram shows various stages of SSH handshake in establishing a secured channel that uses a password authentication mechanism.

                                                      Fig. 6: Stages of SSH Handshaking with user Password Authentication

The post SSH In Nutshell : A protocol for secured network communication appeared first on Seqrite Blog.