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:

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.

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:

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.