Salt Typhoon and the Power of Encryption Protocols

Communications networks become compromised in many ways. Compromise can take the form of a threat actor sniffing traffic on the local network, taking malicious actions on Wi-Fi networks, or stealing credentials via websites. While organizations can take steps to defend networks they control, in most cases, traffic will at some point pass through a network they cannot control. Furthermore, local networks might become compromised without IT teams realizing it. While organizations generally cannot control or protect third-party networks, they can protect their own traffic, and that’s where encryption comes in.

Many types of encryption exist that can address different goals, and they offer varying levels of protection based on use case. While most organizations understand that they should use encryption, many might be unaware of the unencrypted communication methods or of the limitations of the type of encryption they are using. The most relevant types of encryption for combating interception-type attacks are in-transit encryption and end-to-end encryption (E2EE).

In-transit encryption

In-transit encryption provides protection from interception as the data passes over networks between users and the service being used. Notably, in-transit encryption does not provide protection from access to the data by intermediate servers or the service provider. For example, a file shared with another individual via Google Drive™ storage or another cloud-hosting provider would be encrypted in transit between the service provider and the user via hypertext transfer protocol secure (HTTPS), but service providers might still be able to access it. Some examples of in-transit encryption include:

• HTTPS for web traffic
• Session initiation protocol (SIP) with transport layer security (TLS) and secure real-time transport protocol (SRTP) for voice over internet protocol (VoIP) calls
• Non-E2EE chats on most social media platforms and instant messaging applications

E2EE

E2EE is like in-transit encryption, and in-transit encryption is a component of E2EE. The key difference with E2EE is that the data is encrypted and decrypted at the device level of the sender and the recipient. With E2EE, no one has access to the data other than the sender and recipient, not even the service provider. E2EE can be considered as the next step beyond in-transit encryption that provides a higher level of protection from interception or access outside of the network and devices. Some examples of E2EE include:

• Z and real-time transport protocol (ZRTP), a protocol for end-to-end encryption in VoIP calls
• E2EE email providers, such as Proton Mail
• Pretty good privacy (PGP) encryption for emails
• Signal private messenger

How these encryption methodologies come into play varies depending on what sort of communications organizations conduct. Following is an illustration of how data travels with unencrypted, in-transit, and E2EE methodologies.

Most organizations conduct some level of business via cellular networks. Whether they do so with phone calls with clients, cellular hotspots, or short message service (SMS) as multifactor authentication (MFA), sensitive organizational data is transmitted daily via cellular networks.

While modern cellular protocols encrypt the data in transit between the cellular device and the cellular tower, once the data is transmitted on the cellular provider’s network, that encryption is no longer in place. Phone calls, SMS texts, and any unencrypted internet traffic are readable to adversaries able to snoop the traffic on its way across the sender’s or receiver’s cellular network provider. Threat actors who are able to intercept this traffic can listen to phone calls and read the contents of text messages, potentially revealing sensitive information such as MFA codes, business information, and financial information.

To combat such interception, organizations can use end-to-end encrypted communication methods when exchanging any sensitive information. Some examples of end-to-end encrypted communication methods for cellular networks include Apple iMessage^®, Google^™ Messages, Signal, and WhatsApp, all of which (except iMessage) use the same underlying protocol.

Computer networks

Many unencrypted protocols have been in widespread use over the years. Due to legacy or poorly configured equipment, many of these protocols are still in use on networks today. Network administrators are often unaware of the extent of unencrypted communication that occurs on their networks. Organizations should review network traffic, either via firewall logs or a traffic-capture tool, such as Wireshark placed in the proper positions to collect broad amounts of traffic, to identify which unencrypted protocols are in use on their networks. While each organization will identify different protocols, following is a breakdown of some of the more common ones.

Unencrypted DNS. Devices use domain name system (DNS) requests to translate human-readable webpage addresses into IP addresses, such as 159.246.55.10. Every time a user browses the internet or an application makes a connection based on a domain name, DNS is used. Plain DNS (UDP port 53) is quite common; however, it presents several different security risks. It’s unencrypted, so its contents are vulnerable to interception and modification. Using plain DNS is akin to calling a secret number to send a scrambled message but circling the number in a public phone book first. Threat actors snooping on the network can monitor browsing activity to inform further attacks or modify DNS responses to redirect users to malicious sites. Encrypted DNS protocols, such as DNS over HTTPS (DoH) or DNS over TLS (DoT), address these issues by providing encryption in both the request and response. While some minor differences exist between these protocols, they both offer similar security for most use cases and organizations can choose either protocol. Switching to these protocols can help protect against collection of browsing data and redirection to malicious sites containing malware or phishing pages.

HTTP. While HTTP is less common in everyday web browsing than it used to be, many organizations still commonly use HTTP for IT consoles and intranet sites. In addition to the technical risks of credentials theft and data tampering in transit, organizations must consider behavioral risks. When users can repeatedly bypass browser security warnings, they become conditioned to ignore them. This behavior makes it easier for attackers using techniques like DNS cache poisoning or Evil Twin attacks to succeed, as they can rely on users overlooking critical warning signs. Using HTTP on external websites, while less common, also poses risks of interception or modification of credentials or data. Luckily, the risks posed by internal use of HTTP are easily remedied by switching to HTTPS for all company-hosted websites. Not-for-profit organizations, such as Let’s Encrypt operated by the Internet Security Research Group, provide easy, cost-effective methods for organizations to create certificates. For external websites using HTTP, organizations can configure rules on their firewall to either block HTTP or redirect all HTTP requests to HTTPS. Taking these steps can greatly increase the security of web communications.

Unencrypted FTP. File transfer protocol (FTP) is a common protocol used for transferring files across networks. However, by default, FTP traffic is not encrypted, which leaves credentials and the data being transferred vulnerable to interception or modification. Several alternative protocols exist to transfer files securely over networks. FTP secure (FTPS) is built on the FTP protocol and encrypts FTP traffic using TLS. Secure Shell FTP (SSH FTP) is another popular protocol, built off SSH, that similarly encrypts traffic. Switching to these protocols can help protect credentials and data from being stolen or malicious data from being injected during transfers.

VoIP. Today, traditional landlines are uncommon in business environments, and most businesses use VoIP for communication. However, many older VoIP protocols contained no security precautions to protect against interception of data, and more recent VoIP protocols vary in the level of security offered. Legacy SIP and RTP, which are still widely used, are commonly found in desktop VoIP phones and softphone applications, but they use no encryption for signaling or audio streams, which allows attackers to sniff traffic to monitor numbers called, redirect phone calls, and play back audio streams of full conversations. Alternatives, such as SRTP, ZRTP, SIP over TLS, and RTP over TLS, can be used to encrypt VoIP communications. If self-hosting a VoIP solution, organizations can configure their private branch exchange. If using an external provider, organizations will need to discuss with their provider what protocols are in use and whether any hardening is available.

Telnet and SSH. While less common today, telnet previously was a popular remote administration tool. It can be used to transmit credentials and commands in plaintext, and as such, it is vulnerable to interception. Telnet has become less common, but it can still be found on some internet of things (IoT) devices and similar products. Organizations should identify any use of telnet on their networks, and, if possible, upgrade to modern SSH. For IoT devices without the capability of using SSH, organizations need to make sure the credentials used for telnet are not used anywhere else in the environment. They should also implement specific firewall rules limiting who can use telnet to access the device. While SSH is a massive upgrade, not all forms of SSH are equal. SSH v1 allowed support for very weak encryption algorithms, such as data encryption standard, which left it vulnerable to interception. Organizations should determine whether they are using SSH v2 and an up-to-date version of the SSH client or server for all devices where SSH is in use.

SMB. IBM originally introduced the server message block (SMB) protocol SMBv1 in the 1980s to support file sharing and network communication. Microsoft further developed it in the 1990s, released SMBv2 in 2006, and continues to maintain it, with the most recent version being SMBv3.1.1. In 2014, Microsoft deprecated SMBv1, and by 2017, it removed it from modern operating systems. Despite this decision, SMBv1 still appears on many internal networks, which is a concern because it lacks encryption and contains known vulnerabilities. In most cases, moving to the more secure SMBv2 or SMBv3 protocols is a straightforward configuration update.

Encryption protocols: Good for business

Why do encryption protocols matter? For one, organizations cannot – and should not – trust external networks. While responsibility for maintaining the network might end at the demarcation point, organizations’ responsibility to secure their data does not.

For another, encryption protocols strengthen security on internal networks. Organizations should take the time to evaluate the software they use and identify any unencrypted communications. Once they have identified these, they can take steps to upgrade to secure, effective encryption for all business functions. By doing so, organizations can protect their networks and their data – wherever it travels.