CONTACT US
forrester wave report 2023

Forrester rates Corelight a strong performer

GET THE REPORT

ad-nav-crowdstrike

Corelight now powers CrowdStrike solutions and services

READ MORE

ad-images-nav_0013_IDS

Alerts, meet evidence.

LEARN MORE ABOUT OUR IDS SOLUTION

ad-images-nav_white-paper

5 Ways Corelight Data Helps Investigators Win

READ WHITE PAPER

glossary-icon

10 Considerations for Implementing an XDR Strategy

READ NOW

ad-images-nav_0006_Blog

Don't trust. Verify with evidence

READ BLOG

ad-nav-NDR-for-dummies

NDR for Dummies

GET THE WHITE PAPER

video

The Power of Open-Source Tools for Network Detection and Response

WATCH THE WEBCAST

ad-nav-ESG

The Evolving Role of NDR

DOWNLOAD THE REPORT

ad-images-nav_0006_Blog

Detecting 5 Current APTs without heavy lifting

READ BLOG

g2-medal-best-support-ndr-winter-2024

Network Detection and Response

SUPPORT OVERVIEW

 

Focus Terrapin patching efforts with Zeek

In this blog, we will demonstrate how Zeek’s metadata approach can help focus patching efforts related to the recent SSH “Terrapin” attack. One of the interesting aspects to bear in mind as you read this is that Zeek provides visibility of the vulnerable elements of this encrypted protocol, and thus serves as a reminder that network monitoring is still very much relevant, even in a heavily encrypted world. For those not familiar with Zeek, it is a network security monitoring platform that is foundational to Corelight’s network evidence.

The “Terrapin” attack

The SSH Terrapin attack was discovered by researchers at the Ruhr University Bochum. The attack scenario is more than a little nuanced, given that an attacker is required to have a Machine-In-The-Middle at the TCP/IP layer between an SSH client and server. This nuance aside, since the elements that give rise to the vulnerability are quite widespread (they are said to appear in up to 11 million publicly facing SSH servers), it is well worth understanding the extent of the vulnerability in your organization.

Without going into too much detail (you can read more here), the essence of the attack involves the use of a certain combination of vulnerable algorithms that are involved in the initiation of an SSH session. This combination of protocols, together with the attacker using their Machine-In-The-Middle vantage point to alter and truncate these initiation messages, allows for a “downgrade attack,” making the SSH connection insecure. The attack involves three separate CVEs: CVE-2023-48795, CVE-2023-46445, and CVE-2023-46446.

As referenced in the report, the strict key exchange protocol, or “strict kex” has a mitigation effect, however another nuance of this attack is that both client and server need to support and offer the strict kex protocols for this mitigation to be successful, so this needs to be examined in the context of individual client-server connections.

The combinations of algorithms that give rise to an SSH server being potentially vulnerable are:

Encryption Algorithm Message Authentication Is strict kex used?
chacha20-poly1305@openssh.com any kex-strict-s-v00@openssh.com NOT present
Anything with “-cbc Anything with “-etm@openssh.com kex-strict-s-v00@openssh.com NOT present

The above is for SSH servers. SSH clients have the same set of vulnerable protocols, except the client uses kex-strict-c-v00@openssh.com instead of kex-strict-s-v00@openssh.com.

Finding the extent of the problem:

Mitigating the vulnerability requires patching both client and server SSH software, or making a configuration change to disable the vulnerable protocols. The biggest problems facing any organization of size is determining:

  • The extent of use of the protocol in question, both in server and client form.
  • The identification and ongoing monitoring of endpoints that require patching or mitigation.

This problem is exacerbated due to the ubiquitous and critical nature of SSH. Having this information readily available can save a vast amount of time and resources, as efforts are focused only on impacted systems.

Put another way, one could well imagine a CSO asking.

  • Do we even have this problem? And if so, how widespread is it for us?
  • How do we best direct our efforts?
  • How do we track/audit the success of our mitigations and monitor them over time?
  • Has anyone exploited this already? If yes, what happened next?

This is exactly where Zeek can help, and how to leverage it forms the basis for the rest of this blog. Let’s now look at how Zeek can help identify the presence of these potentially vulnerable SSH installations.

Enter Zeek and the HASSH package

The “HASSH” Zeek package (contributed to the Zeek community by Salesforce) provides a means of fingerprinting SSH clients and servers. These fingerprints are constructed from algorithms that are exchanged directly after the initial TCP three-way handshake, in the form of clear-text packets. The exchange is contained in "SSH_MSG_KEXINIT" messages—an integral part of the setup of the final encrypted SSH channel. The fingerprints themselves are derived from string representations of 1) Key Exchange, 2) Encryption, 3) Message Authentication and 4) Compression algorithms. These include the very same algorithms that give rise to the Terrapin attack, so the HASSH package provides historic, continuous, auditable visibility into this metadata directly in your SIEM.

As an example, here we see the four components of the hasshServerAlgorithms field that HASSH adds to the ssh.log. This was created from a PCAP of a vulnerable SSH server and was provided by the Terrapin authors (tip o’ the hat!). The algorithms related to Terrapin are highlighted in blue and red. In this case, given that this server uses chacha20-poly1305@openssh.com it is potentially vulnerable and should be addressed.

Function Component of hasshServerAlgorithms field in ssh.log
Key Exchange methods curve25519-sha256,curve25519-sha256@libssh.org,curve448-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,ecdh-sha2-1.3.132.0.10,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256@ssh.com,diffie-hellman-group14-sha1,rsa2048-sha256,ext-info-s
Encryption chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
Message Authentication umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha256-2@ssh.com,hmac-sha224@ssh.com,hmac-sha256@ssh.com,hmac-sha384@ssh.com,hmac-sha512@ssh.com;zlib@openssh.com,none
Compression zlib@openssh.com,none

The HASSH package builds these four component strings and further concatenates them together with a delimiter of “;” and adds it to ssh.log as hasshServerAlgorithms. Similarly the SSH client has its own set of hasshAlgorithms.

Servers and clients offering the vulnerable combination of algorithms can readily be searched in SIEM, as this example from within CrowdStrike LogScale shows.


// SSH Servers potentially vulnerable to Terrapin attack
    #path=ssh
    (hasshServerAlgorithms=/chacha20-poly1305/ OR         
    hasshServerAlgorithms=/-cbc[^;]+;.+-etm@openssh\.com/) 
    | groupby([server,id.resp_h])
    

Stepping through the components of this search:

#path=ssh
Refers to all logs parsed by Zeek’s SSH analyzer.

hasshServerAlgorithms=/chacha20-poly1305/
A regular expression that searches for the first vulnerable condition: where chacha20-poly1305 is offered as the encryption algorithm.

hasshServerAlgorithms=/-cbc[^;]+;.+-etm@openssh\.com/)
A regular expression that searches for the second vulnerable condition: where 1) a supported encryption algorithm is any of the “-cbc” algorithms AND the 2) a supported message authentication algorithm is any of the “etm@openssh.com” algorithms. Note the “;” characters in this regular expression relate to the delimiters between the four components of the hasshServerAlgorithms string.

In searching data from our Corelight Lab’s realtime at-scale Polaris Program, we are able to back up the Terrapin researcher’s observation that this vulnerability is widespread, as a sample of potentially vulnerable server and client strings shows:

image1

 

image2

 

Zeek’s metadata approach can turn a seemingly unwieldy task of tracking down vulnerable systems into a three-minute SIEM rule search-writing exercise—a search that can then be used to track and audit the progress of patching efforts over time.

Start patching today, and look for evidence of existing compromise. Learn more about Zeek data and how to counter encrypted threats with Corelight’s Encrypted Traffic Collection.

Recent Posts