How to Identify Misconfigured and Unauthenticated Management Interfaces
When you imagine a sophisticated cyberattack, often events like zero-day exploits, custom rootkits, criminal organizations, and a knack for social engineering come to mind. However, more often than not, a sophisticated attack is a combination of technical experience, a whole lot of patience, persistence, and a spattering of pure luck. Essentially, finding a needle in the proverbial haystack.
When it comes to computer and network security, a common refrain is that many large and small organizations alike have a hard outer shell and a soft gooey inside. An attacker will have an easier time infiltrating the entirety of a network if they already have a foothold into a company’s trusted security zone.
In August 2021, a hacker obtained and sold a database dump of over 50 million T-Mobile current and prospective customers, as reported in the Wall Street Journal. Even more shocking was that this entire situation could have been avoided with additional proactive monitoring.
Using various techniques, the T-Mobile hacker chipped away at the outer layers of security, and within a week, had worked himself into T-Mobile’s internal networks. However, if it were not for a single unintentionally exposed and unauthenticated router, the outcome of this story may have been drastically different.
As engineers, CISOs, and IT managers, we focus our attention and energy on the potential exposures that, as end-users, we directly interface with (the software running on web servers, the operating system running the webserver, and the authorization and authentication used to access those systems), often forgetting the things between the internet and these public-facing devices.
A network’s most significant weaknesses are the areas with the least visibility and the devices that both time and humans tend to forget. One simple misconfiguration can inadvertently expose a fleet of switches to the internet or leave a router management interface open. A mistake in a firewall rule can expose a set of serially connected out-of-band devices to the global internet or leak sensitive filesystem directories to the world.
Censys set out to determine whether this type of exposure was a rare once-in-a-lifetime find or an indicator of a more significant, unseen problem. Are there large swaths of internet-connected devices with administrative command-line interfaces that were mistakenly configured and deployed without authentication? By delving down these dark corners of the internet, absent from the prying eyes of standard corporate monitoring systems, we can find a world where if you have a general idea of what you are looking for, you may be able to find more than you ever needed to start chipping away at the hard exterior of a supposedly secure and private network.
What is the Issue?
This research aimed to find unauthenticated services that allow users to manage a device remotely via telnet. Such devices could allow an attacker to move laterally into trusted zones within a network, inspect traffic, and potentially modify or bypass security policies.
Typically, when a client connects to a remote telnet-based management service, the server will respond with an informational banner message followed by a login prompt waiting for the client to authenticate. Once authenticated, the server will create an interactive session where the client can issue commands to execute on the device.
By constructing a set of search queries to match telnet banners that do not contain a login prompt but do have indications of a shell prompt towards the end of the banner, one can easily distinguish misconfigured and unauthenticated services from devices with a proper configuration.
Bigquery (Censys enterprise data customers):
SELECT host_identifier.ipv4, svc.port, autonomous_system.asn, autonomous_system.name, location.country_code, SAFE_CONVERT_BYTES_TO_STRING(svc.telnet.banner) AS banner, FROM censys-io.universal_internet_dataset.universal_internet_dataset, UNNEST(services) AS svc WHERE DATE(snapshot_date) = '2021-12-01' AND svc.telnet.banner IS NOT NULL AND svc.service_name = "TELNET" AND NOT REGEXP_CONTAINS(SAFE_CONVERT_BYTES_TO_STRING(svc.telnet.banner), r'(?i).*(user|username|login as|user name|login|password|account).*?[:>]') AND REGEXP_CONTAINS(SAFE_CONVERT_BYTES_TO_STRING(svc.telnet.banner), r'(#|>|\$) ?$')
Search (Censys enterprise search customers):
At the time of writing, Censys found that more than 17,000 internet-connected services exhibited signs of a remotely manageable device that does not require authentication. From routers and switches to root shells and debug consoles, all the way down to esoteric job schedulers, the ability to gain an initial hold into a network is trivial when the doors to the kingdom don’t have locks.
The majority of these unauthenticated services are geographically located in China (with 4,651 services), South Korea (with 2,363 services), and Israel (with 1,816 services), closely followed by the United States with just under 1,700 results.
Additionally, Censys gave each result from this finding an “Estimated Privilege Level,” which indicates the level of access an attacker would have once connected to the device. This level of categorization gives the reader a quick summary of an attacker’s potential lateral movements once connected to the service in question.
|ESTIMATED PRIVILEGE LEVEL||DESCRIPTION||SERVICE COUNT|
|ANONYMOUS||Privilege levels on devices meant to be unauthenticated, such as public route-servers, MUDs, and BBS’s||42|
|ROOT||An administrative privilege level such as configure-mode on a router or an exposed root-shell on a server||5,506|
|USER||Privilege level on a device containing user-level access, such as a router not in configuration mode or a shell prompt signifying a non-UID-zero user||5,115|
|DEBUG||A privilege level intended for debugging a specific feature, usually associated with a limited-access shell||1,460|
|UNKNOWN||A privilege level on a device with shell-like characteristics but not enough information was available to validate||6,300|
Most of the identified services were UNIX-like shells (such as bash, or /bin/sh), or router-like command-line interfaces (such as Cisco IOS and Foundry CLI), both of which were assigned a privilege level of “user” or “root” based on specific patterns found in the banner. For example, if the telnet banner contains the string “bash-1.1#” (a UNIX-like shell), or “(config)#” (a router-like shell in configuration mode), the pound sign would indicate that the access level would be administrative (root), while shells containing a dollar sign would show the service has a more restricted user access level.
Out of the 5,660 services that displayed some form of a UNIX-like shell, 1,282 of them were identified as BusyBox servers. And of those BusyBox servers, 373 of them accepted the connection into an unprivileged (non-root) shell, versus the other 909 that dropped the session straight into a root shell.
Out of 6,987 services categorized as a networking device, Censys found 4,597 of these services to be a router, while only 268 had indicators of a network switch. Censys determined these numbers by classifying the device based on the operating system, along with information found in the telnet banner; for example, this device refers to being a network switch in both the hostname (DC2-DMZ-SW01) and the warning banner for the service:
A few devices would even offer up the passwords to the device in the output of the banner, which is wholly unimportant if the device has no password to start with, such as this networking appliance:
In some cases, when a serially connected physical TTY has been exposed to the internet, previous sessions can be seen in the output of the device’s banner. For example, the banner for this Cisco device displays an active configuration session created by another user who connected to the router via serial. Typically a TTY is not shared across multiple sessions, whereas an internet-accessible serially-connected device will share just one output for all connected sessions (think shared tmux or gnu-screen sessions). Not only can an attacker gain access to these resources, but they can also see what has already been done by other administrators:
What can I do about it?
One of Censys’s primary goals is to help customers identify and remediate common configuration mistakes like this. More often than not, these types of vulnerabilities go undetected and ignored until it’s too late. As corporate networks grow, move, shift, and shrink, a device may be left behind but unlocked, only to be found by a person with ill intent. Censys has a unique outside-in perspective, and our data can quickly assist an operator in finding those rogue devices before they become a bigger problem.
Censys is constantly adding and growing our internal fingerprints and risks to the ASM platform to detect and alert on misconfigurations like this, along with many other security-related indicators.