Blog
Insecure Protocols: SMBv1, LLMNR, NTLM, and HTTP
Carol Caley
May 12, 2021
Four years ago today, the WannaCry ransomware variant spread like wildfire, infecting and encrypting over 230,000 computers at public- and private-sector organizations worldwide, and inflicting hundreds of millions, if not billions, of dollars in damage. Less than two short months later, another ransomware attack, NotPetya, again ripped its way through global organizations, temporarily crippling the shipping industry and costing Maersk $300 million alone.
Both attacks exploited the same vulnerabilities in the Microsoft Server Message Block version one (SMBv1) protocol, an exploit known as EternalBlue.
And yet, today, four years after these devastating attacks took place, ExtraHop research found that SMBv1 is still surprisingly common in enterprise environments. Almost 70% had more than 10 devices still running the protocol. And it's not just SMBv1.
Other insecure protocols, including the Link-Local Multicast Name Resolution (LLMNR) protocol and the NT LAN Manager (NTLM) protocol, are still in use. And while not inherently insecure, HTTP, which is deeply problematic when used for transmission of sensitive data, is still widely used in enterprise environments.
A new ExtraHop report provides insight into how common these insecure protocols are within the enterprise, the risks associated with each, and gives recommendations for eliminating these weak points from your environment.
Read on for some highlights, or download the full report.
Common Insecure Protocols
SMBv1
Protocol Snapshot
Introduced: 1983 Deprecated: 2013 Damages associated with protocol: > $1 billion 67% of environments are still running SMBv1
SMB Security Priority #1: Remove SMBv1
SMBv1 (known originally as CIFS) was notoriously buggy, chatty, and difficult to use, and had major security deficiencies. When Microsoft introduced SMBv2 in 2006 they abandoned the CIFS nomenclature altogether. Six years later, in 2012, Microsoft introduced SMBv3, and in 2013 the company officially deprecated SMBv1.
Microsoft actively urged their user community to stop using SMBv1, but with millions of machines using the protocol, many of the warnings, including those from within the Windows Server engineering group, went unheeded. This is why, when EternalBlue and related exploits—known collectively as Eternal(x)—came to light in 2017, SMBv1 was still pervasive in IT environments around the world.
LLMNR
Protocol Snapshot
Introduced: 2007 Deprecated: N/A Damages associated with protocol: Unknown 70% of environments still running LLMNR
What is LLMNR?
Link-Local Multicast Name Resolution (LLMNR) is a protocol that allows name resolution without a DNS server. Essentially, LLMNR is a layer 2 protocol that provides a hostname-to-IP resolution on the basis of a network packet that's transmitted via Port UDP 5355 to the multicast network address (224.0.0.0 through 239.255.255.255). The multicast packet queries all network interfaces looking for any that can self-identify authoritatively as the hostname in the query.
LLMNR was originally created as a workaround to enable name resolution in environments in which DNS servers would be impractical, such as small private networks. LLMNR was created as a way to achieve name resolution without the onerous requirements of DNS. The protocol has been (and still is) used by operating systems, including Microsoft Windows, to identify networked devices like file servers.
LLMNR Security Concerns
While LLMNR provides a DNS-free mechanism for host-name resolution within a local environment, it also provides an avenue of attack for malicious actors. An attacker can use the protocol to trick a victim into revealing user credentials. This is done by leveraging LLMNR to gain access to the user credential hashes, which can then be cracked to reveal actual credentials, especially if older MS password techniques like LANMAN are not disabled.
Though DNS is not without its challenges, it's a far more secure way to accurately identify host names. With that said, DNS should be carefully monitored to ensure that it is not itself being utilized for nefarious purposes.
NTLMv1
Protocol Snapshot
Introduced:1993 Deprecated: 2010 Damages associated with protocol: Unknown 34% of environments still running NTLMv1
What is NTLM?
New Technology LAN Manager (NTLM) is a proprietary Microsoft protocol introduced in 1993 to replace Microsoft LAN Manager (LANMAN). NTLM is part of a cohort of Microsoft security protocols designed to collectively provide authentication, integrity, and confidentiality to users.
NTLM is what is known as a challenge-response protocol used by servers to authenticate clients using password hashes. In its original incarnation NTLMv1 used a fairly simple (and easily compromised) authentication method.
NTLM Security Concerns
Using NTLM for authentication exposes organizations to a number of risks. A skilled attacker can easily intercept NTLM hashes that are equivalent to passwords or crack NTLMv1 passwords offline. A successful exploit against NTLMv1 authentication can enable an attacker to launch machine-in-the-middle (MITM) attacks or take complete control of a domain.
HTTP
Protocol Snapshot
Introduced:1991 Deprecated: N/A Damages associated with protocol: > $1 billion 81% of enterprise environments still use insecure HTTP credentials
HTTP Security Concerns
The original protocol developed in the nineties lacked entirely a way to protect sensitive data—like your credit card number—leaving a massive gap in 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 the communications between clients and servers, preventing people from intercepting and reading your data in flight. It also preserves the integrity of data, helping to prevent it from being broken or corrupted.
While HTTP is not inherently problematic, its use for transmission of sensitive data is definitely a major risk. When plaintext credentials are transmitted over HTTP, those credentials are left exposed, the internet equivalent of shouting passwords across a crowded room, making it trivial for anyone to intercept and steal those credentials.
81% of enterprise environments is a concerningly large percentage. It surfaces the question of whether organizations may be unaware that this is happening in their environment.
Heartbleed
Of course, even HTTPS isn't foolproof. Heartbleed, a serious vulnerability in OpenSSL that first came to light in 2014, is a classic example of how HTTPS can be exploited. Under normal conditions, SSL/TLS encryption protects information—such as logins and credit card numbers—being transmitted over the internet. The Heartbleed vulnerability inadvertently exposed the memory of systems protected by OpenSSL, compromising the secret keys used to encrypt the traffic and giving attackers access to users names, passwords, and other sensitive information.
Because HTTP or HTTPS are often used to transmit user input from websites and web applications, the protocols are sometimes abused to transmit malicious content from the public internet into a private environment. For example, an attacker using the SQL injection tactic sends SQL statements hidden in HTTP headers or other user-manipulatable fields in the HTTP protocol. The encryption used by HTTPS can actually make it more challenging to detect SQL injection attacks.
Even with vulnerabilities like Heartbleed, HTTPS is still far more secure than HTTP for transmission of sensitive information.
Quick Links:
Discover more
