Unsecure protocols: SMBv1, LLMNR, NTLM and HTTP

Four years ago, the WannaCry ransomware variant spread like wildfire, infecting and encrypting more than 230,000 computers in public and private sector organizations around the world, and inflicting hundreds of millions, if not more billion dollars in damage. Less than two months later, another ransomware attack, NotPetya, broke into global organizations again, temporarily crippling the shipping industry and costing Maersk $ 300 million alone.

Both attacks exploited the same vulnerabilities in Microsoft Server Message Block protocol version 1 (SMBv1), an exploit known as EternalBlue.

And yet, today, four years after these devastating attacks, ExtraHop research has revealed that SMBv1 is still surprisingly prevalent in corporate environments. Almost 70% had more than 10 devices still running the protocol. And it’s not just SMBv1.

Other insecure protocols, including Link-Local Multicast Name Resolution (LLMNR) and NT LAN Manager (NTLM), are still in use. And while not inherently insecure, HTTP, which is deeply problematic when used for the transmission of sensitive data, is still widely used in corporate environments.

A new ExtraHop report provides insight into the frequency of these insecure protocols within the organization, the risks associated with each, and provides recommendations for eliminating these weak points from your environment.

Read on for some highlights, or download the full report.

Common unsecured protocols

SMBv1

Protocol snapshot

Introduced: 1983

Obsolete: 2013

Protocol damage:> $ 1 billion (67% of environments are still running SMBv1)

Do you want to see the data? Check out the insecure protocols infographic.

SMB Security Priority # 1: Remove SMBv1

SMBv1 (originally known as CIFS) was notoriously buggy, chatty, and difficult to use, and had major security flaws. When Microsoft introduced SMBv2 in 2006, they completely abandoned the CIFS nomenclature. Six years later, in 2012, Microsoft released SMBv3, and in 2013, the company officially discontinued SMBv1.

Microsoft has urged its user community to stop using SMBv1, but with millions of machines using the protocol, many warnings, including those from the Windows Server engineering group, have gone unheeded. That’s why, when EternalBlue and related exploits – known collectively as Eternal (x) – appeared in 2017, SMBv1 was still ubiquitous in computing environments around the world.

LLMNR

Protocol snapshot

Introduced: 2007

Obsolete: N / A

Protocol related damage: unknown (70% of environments still running LLMNR)

What is LLMNR?

LLMNR is a protocol that allows name resolution without a DNS server. Essentially, LLMNR is a Layer 2 protocol that provides hostname-to-IP resolution based on a network packet transmitted through UDP port 5355 to the multicast network address (224.0.0.0 to 239.255.255.255) . The multicast packet queries all network interfaces for those that can authoritatively self-identify as the host name in the request.

LLMNR was originally created as a workaround to allow name resolution in environments where DNS servers would not be practical, such as small private networks. LLMNR was created to achieve name resolution without the onerous DNS requirements. The protocol has been (and still is) used by operating systems, including Microsoft Windows, to identify networked devices such as file servers.

LLMNR Security Issues

While LLMNR provides a DNS-less mechanism for host name resolution in an on-premises environment, it also provides an attack route for malicious actors. An attacker can use the protocol to trick a victim into revealing user credentials. This is done by taking advantage of LLMNR to access hashes of user credentials, which can then be hacked to reveal actual credentials, especially if older MS password techniques such as LANMAN are not disabled.

While DNS is not without its challenges, it is a much more secure way to accurately identify hostnames. That said, DNS should be carefully monitored to ensure that it is not itself being used for nefarious purposes.

Learn more about how SUNBURST attackers used DNS.

NTLMv1

Protocol snapshot

Introduced: 1993

Obsolete: 2010

Protocol related damage: unknown (34% of environments still running NTLMv1)

What is NTLM?

NTLM is a proprietary Microsoft protocol introduced in 1993 to replace Microsoft LAN Manager (LAN MAN). NTLM is one of a cohort of Microsoft security protocols designed to collectively provide authentication, integrity, and privacy to users.

NTLM is a so-called challenge-response protocol used by servers to authenticate clients using password hashes. In its original incarnation, NTLMv1 used a fairly straightforward (and easily compromised) authentication method.

NTLM security issues

Using NTLM for authentication exposes organizations to a number of risks. An experienced attacker can easily intercept NTLM hashes equivalent to passwords or decrypt NTLMv1 passwords offline. A successful exploit against NTLMv1 authentication can allow an attacker to launch machine-in-the-middle (MITM) attacks or take complete control of a domain.

HTTP

Protocol snapshot

Introduced: 1991

Obsolete: N / A

Protocol damage:> $ 1 billion (81% of enterprise environments still use insecure HTTP credentials)

HTTP security issues

The original protocol developed in the 90s completely lacked a way to protect sensitive data, like your credit card number, leaving a huge gap HTTP Security. In 1995, four years after the introduction of HTTP, its more secure version, HTTPS, arrived on the scene. Unlike HTTP, HTTPS uses TLS to encrypt communications between clients and servers, preventing people from intercepting and reading your data in flight. It also preserves data integrity, helping to prevent it from being broken or corrupted.

While HTTP is not inherently problematic, its use for the transmission of sensitive data is certainly a major risk. When unencrypted credentials are transmitted over HTTP, that information is left exposed, the Internet equivalent of shouting passwords in a crowded room, making it easy for anyone to intercept and steal this information from. identification.

Needless to say, 81% of enterprise environments is a relatively high percentage. It raises the question of whether organizations can ignore that this is happening in their environment.

Read the report to learn more about identifying unsafe protocols running in your environment.

Heartbleed

Of course, even HTTPS is not foolproof. Heartbleed, a serious vulnerability in OpenSSL that first appeared in 2014, is a classic example of how HTTPS can be exploited. Under normal conditions, SSL / TLS encryption protects information, such as connections and credit card numbers, transmitted over the Internet. The Heartbleed vulnerability inadvertently exposed the memory of systems protected by OpenSSL, compromising secret keys used to encrypt traffic and giving attackers access to usernames, passwords and other sensitive information.

Because HTTP or HTTPS is often used to transmit user input from websites and web applications, the protocols are sometimes abused to transmit malicious content from the public Internet in a private environment. . For example, an attacker using the SQL injection tactic sends SQL statements hidden in HTTP headers or other user-manipulable fields in the HTTP protocol. The encryption used by HTTPS can actually make it harder to detect SQL injection attacks.

Even with vulnerabilities like Heartbleed, HTTPS is still much more secure than HTTP for transmitting sensitive information.

Learn more in the full report.

Quick links: