Shodan is a really useful tool for, well, all sorts of research. Not only can you quickly determine what the public-facing security impact of a new vulnerability is going to be, you can find all sorts of control systems attached to the Internet that shouldn’t be. Searching for random control-systems related terms sometimes even steers a researchers towards new and interesting equipment to test.
John Matherly, who runs Shodan, is constantly tweaking settings and adding features (and new scan types) to help the security community. [On a personal level I can’t thank him enough for teaching me all of the tricks that I’m writing about here].
Two of the recent changes made ended up being really helpful for finding some of the most vulnerable ICS systems: telnet options searching and bannerless telnet searching. The latter of these is only available to folks who pay for API access, but it opens up some rather interesting critical infrastructure to locatability.
Way back in 2012 we did Project Basecamp. The ‘Biggest Loser’ of Project Basecamp, purely on the number of red ‘X’ security failures, was General Electric’s D20ME RTU. (I should mention that GE has made strides in improving the line with the release of their D20MX, but the D20ME line will remain forever vulnerable). Back then, I really wanted to be able to search for the D20 on Shodan but couldn’t. This was because the D20 only supports Telnet, and it supports it in a way that Shodan didn’t support. Until now.
Telnet: It’s not just text
One of the common misconceptions of the Telnet protocol is that it just shuffles textual data back and forth. This isn’t true. Telnet supports a number of terminal formatting features, many of which are entirely optional for both the client and the server to support. The Telnet RFC contains the main protocol standard, which is extended upon by the ‘Options’ RFC. Options themselves are defined in numerous followon RFCs (ah, to have been part of IETF in the 80s!).
The most useful for device identification are the Telnet handshake options. When you first connect to a system’s Telnet port, the Telnet server will send a series of options that server /wants/ to use, what options it /will allow/ the client to use, and what options it /will not/ use, and what options the client /shouldn’t/ use. In response, the client is expected to do the same thing. These are called WILL/DO/WON’T/DON’T options. There is a lengthy list of fancy features that Telnet servers and clients support.
The ‘problem’ with scouring the internet for some devices, such as the aforementioned D20 (many Schweitzer Engineering relays have the same ‘problem’) is that they don’t send any kind of welcome banner, or their welcome banner is completely user-configurable and often changed during setup. In the case of GE and some SEL products, they simply spit out a few Telnet options and then wait for the end user to interact with the system. Usually pressing Enter will suffice. In the case of GE, pressing enter will display a fully customizable banner defined by the end user. In the case of SEL, pressing enter will display a level-1 command prompt (‘=‘).
Shodan plays things safe, and never sends a carriage return, or any other characters, to Telnet hosts. I suppose that someone could construe that data transmission as an attack, so Shodan refrains.
Telnet Option Searching
Fortunately, Shodan now saves the Telnet options in a searchable way. John actually wrote about this back in February. The interesting thing about those options is that there are a *lot* of them. Many of these small embedded systems made by ICS manufacturers have home-brew Telnet servers, so the options that they support are a bit like snowflakes. Even among the equipment that we have in our lab, different devices, and even different firmware releases of the same device, will spit out different Telnet options.
We can use this to our advantage.
Due to the sensitivity of the equipment, and the criticality of their vulns, we shall not post our device Telnet options list. I will say that there are far too many substation-level controllers hanging on the Internet for comfort.
As with all of our internal scans, Digital Bond Labs tries a lot of techniques to get in touch with the actual asset owner to get these systems removed. We are happy that we can now search for more devices in our attempt to reduce internet harm.
Sample Searches
As an example of finding something that is incredibly selective, Shodan search for telnet.will:echo telnet.wont:tm . You will find an incredibly specialized RS232 to Ethernet adapter, which appears to be the only device in the world that supports this particular pair of Telnet options upon connection.
Unfortunately the main Shodan results will not return bannerless searching: that is, devices which spit out Telnet options and nothing else. For that, you will need paid API access — the syntax of the searching doesn’t change, though.
Shodan uses the ARPA standard Telnet option codes, available in arpa/telnet.h. Remove ‘TELOPT_’ from the option name to make it a Shodan-searchable option.
image by pasukaru76