SSL Requests sent to port 80 (request for help/input)

Published: 2012-09-06
Last Updated: 2012-09-06 23:37:12 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

A while ago, a reader submitted some odd looking web log entries like the following:

 

default 10.5.0.48 - - [06/Sep/2012:23:11:36 +0000] "\x16\x03" 200 15 "-" "-"
default 10.5.0.48 - - [06/Sep/2012:23:12:26 +0000] "\x16\x03" 200 15 "-" "-"

 

After some experimenting, we figured out that these are SSL connection attempts that are directed at a non-SSL server. These log entries are common if your web server is misconfigured, and the SSL module is not enabled on port 443. But in this case, the log entries showed up on a web server listening on port 80.

To "force" an https request on port 80, you have to add the port explicitly to the URL. For example the log entries above, I created using the command:

wget https://webserver:80/index.html

The bytes "\x16\x03" are the first two payload bytes transmitted for the connection (a \x00 is the third byte, which terminates the string as far as the server is concerned). The server may actually still respond with a default error page. The server I used was configured to respond with a "200" code for any request (to make URL brute forcing harder).

The Wireshark analysis of course doesn't make much sense here:

However, luckily we can use Wireshark's "decode as" feature to make more sense of the packet. If we ask Wireshark to decode this traffic as SSL, we do get a perfectly fine Client Hello packet:

The "0x16" byte indicates that this is a "Handshake" and the "0x03" tells us that we are dealing with SSL 3.0. So now we can do a bit fingerprinting on these requests.

Here is a sample from today's ISC log:

\t\xe2)\x18\x12\xbc\xcc\x04U\xbf\xddj\xc4\xf9q\x163\xa0\x90
\xc4]\xd6\x1cg\x90\xc1\xf2\xe9\x9a\x1e\xba\v\xca2N\x92\x1a\xd0
\xb2\xf28i\xe5{A\x16`\xc2\x01\xa1\x84\xd4_\xfe%\x93\x92\xf8\xb1
\xb7\x85\x15\x05\xdc\xae\xde\x9d\xbb'\x05\x8e\x11\x17\xb9\xdf\xee|%\xd19\xf3\x9b\xeb
\xb9\xa4\x03{\xea\x88\xf4\x88\x87\xfb\x17\xc5\x07\x9c\xc5{\xaa?{\xc7]v\xcf
\x04c\x98\xbf\x87+in
\x83\x91w\xe2\x13\x85\xae,qs\xdb\xbe\xd78\xa4\xed\xbf\
\xd2\xa2 *\xcaUV\xd7\x0e\xab\xaa\x91A\x13\xf7E\xaf\x01\xc1\x9e\xbf\xd3
\x99\xd2\xad\x1b5\xcc\x85\xef\xaa\r:9\xdc>p\xdf\xfb\xb8\xb6\xd1Pj4\x04\xb1\
\x1f\xe4\xbet\xec\x0c\xcc>\xf3\
Avg\xdc\x94\xd5\xd9\bO\x18y+\xcd\xb0
\xd1\xaf\x855\xeb\xb4\x19/3\xa8\xab\x15ZNZU9>=\x0e\x87\xb8\xa0\xe2\x12
\x16\x03
\x16\x03

(I shortened some lines a bit to avoid page width problems)

Based on our analysis above, on the last two appear to be SSL requests. The others, appear to be "something else". Can you identify them? Telnet doesn't cause any additional characters to show in the log (I suspected telnet's terminal negotiation, but was not able to trigger the characters ). Have you seen similar entries in your logs? Haven't seen anything with SSH either. The SSH client first waits for the "banner" from the server before sending anything (I may have to wait longer).

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

3 comment(s)
ISC StormCast for Thursday, September 6th 2012 http://isc.sans.edu/podcastdetail.html?id=2782

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives