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|