8

I noticed an unfamiliar device when scanning my local wireless network. It had two open (listening?) TCP ports; TCP/80 (http?) & TCP/443 (https?).

In an effort to identify the unfamiliar device; I exercised some basic banner-grabbing techniques, which provided some strange feedback: 

root@localhost:~# telnet 10.1.1.28 80
Trying 10.1.1.28...
Connected to 10.1.1.28.
Escape character is '^]'.
HEAD / HTTP/1.1
@Q�0�njs-k��`Y���s��N��E2R�S������d���aw��
s�Y�/u"�`QN���I�eRA~W

Connection closed by foreign host.

- - -

root@localhost:~# telnet 10.1.1.28 80
Trying 10.1.1.28...
Connected to 10.1.1.28.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.0 404 Not Found

Connection closed by foreign host.

- - -

root@localhost:~# telnet 10.1.1.28 80
Trying 10.1.1.28...
Connected to 10.1.1.28.
Escape character is '^]'.
HEAD / HTTP/1.1
"�))!���]D�7�ב�����┴�IL&�┬��#�-�zp�,o�������c��D����ל]�h����
                                                                @�.GLMC��2{���

Connection closed by foreign host.

What are these strange responses?
What do they mean?

voices
  • 1,649
  • 7
  • 22
  • 36
  • Aside: your requests are technically invalid; 1.1 requires `Host` especially for abs-path aka origin-form. In general it's safer and easier to use 1.0 when manually connecting e.g. telnet to an HTTP server that tries to comply with standards (not all do). But that is unlikely to explain the extremely-un2616ly behavior you show. – dave_thompson_085 May 07 '16 at 19:07
  • @dave_thompson_085 1.0 had similar results. The output reminds me of an SSL/TLS-encrypted packet, captured in Wireshark. – voices May 07 '16 at 23:23
  • I thought 1.0 was unlikely to help *here*; that was a general reminder (and hence not even a partial answer). SSL/TLS encrypted data, OR handshake data which is not encrypted but is mostly binary, does look like this kind of gibberish, but so does lots of other binary data like PNG, MP4, or gzip -- or just machine code or data. If you have wireshark the hex display may be more informative than the display as characters you show. – dave_thompson_085 May 10 '16 at 12:51
  • @dave_thompson_085 I don't know enough about it to say for sure but I imagine it's fine for simply grabbing service banners. I didn't know that handshake data was binary, but yes I agree; I also thought it looked kind of like when trying to `cat` or `grep` a binary file by accident. – voices May 10 '16 at 13:52

1 Answers1

5

If you insist on talking HTTP through telnet, a proper HTTP server won't answer you before you're sent two consecutive line feeds, effectively ending your request:

GET / HTTP/1.0
<empty line>

If the service starts answering you before sending the empty line, it's not speaking proper HTTP, and may be something else entirely. I'd suggest using a tool like cURL to ensure proper use of protocol. Here's an example:

[root@vostok ~]# curl --dump-header - --silent http://127.0.0.1/
HTTP/1.1 404
Server: nginx
Date: Wed, 11 May 2016 07:16:15 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Last-Modified: Wed, 11 May 2016 07:16:15 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

It may also be a HTTPS service listening on a non-standard port (like port 80, the standard HTTP port). Try the above cURL command with protocol and port explicitly specified in the URL like this: https://127.0.0.1:80/

It may not be HTTP or HTTPS at all, but some other SSL-enabled service. If you want to probe that, you could use OpenSSL to open an SSL-enabled telnet-like connection:

openssl s_client -host 127.0.0.1 -port 443

If it is indeed SSL-enabled, you'll get all sorts of information, including details about the certificate used.

Good hunting! :-)

Saustrup
  • 149
  • 4
  • 1
    Nice answer. This information generally seems to be overlooked in typical banner-grabbing / service-probing articles. – voices May 11 '16 at 07:36