4

I'm getting below error requests with status code 200 (OK) to below paths:

[06/Feb/2013:07:41:38 +1100] "\x80w\x01\x03\x01" 200 550 "-" "-"
[05/Feb/2013:10:52:22 +1100] "\x80g\x01\x03\x01" 200 550 "-" "-"

I'm getting spam abuse now. Is my server compromised?

1
  • 2
    More details required. What do you mean by "spam abuse"? Are you receiving spam? Is your server receiving spam? Is your server sending spam? Are you receiving complaints that your server is sending spam? Do you have any reason to think that those Apache log entries are a compromise or in any way related to the spam? – Ladadadada Feb 7 '13 at 8:51
14

These byte sequences in your logs look like the beginning of SSL version 2 client hello packets, and result from some HTTPS clients connecting to a port where your web server expects plain HTTP, not HTTPS. Your web server tries to interpret the start of SSL handshake as the HTTP request method.

So you have two problems here:

  1. Someone tries to talk HTTPS to a port on which your web server expects HTTP. This may be a misconfiguration of your server (e.g., you added a Listen 443 directive, but did not enable HTTPS correctly), or just the result of port scans from dumb robots which try HTTPS on nonstandard ports. Or this may be caused by a client misconfiguration (something like https://example.com:80/ could result in such behavior).
  2. Your server for some reason replies with status code 200 to requests with a bogus method. While Apache itself should not handle such unknown methods, PHP by default accepts everything and passes the request to the script. Together with some rewrite rules which cause request for nonexistent files to be passed to index.php (commonly used to get “clean URLs”) and scripts which do not check $_SERVER['REQUEST_METHOD'] this could result in the behavior you see here.

And if the clients sending those requests are controlled by you, then you have a third problem — those clients are using the obsolete and insecure SSL v2 protocol (they advertise support for SSL version 3.1, which is actually TLS 1.0, but would accept SSL v2 responses from the server, so they are vulnerable to a protocol downgrade attack due to missing integrity protection for handshake in SSL v2).

3

Yes, the garbage one seems to come from https requests to an http server.

The HNAP1 requests look like an automated attack against a whole slew of routers.

If it's hitting an Apache install you're fine.

If it's hitting any sort of cable/DSL router it's quite possibly hosed. You should reset it and update the firmware to the latest version. The exploit could allow a hacker into your inner network, but I really doubt the automated attack goes that far. Fortunately, it would seem that it can only change the password and settings, so a reset will undo it, though it will just happen again if you don't update to a fixed firmware. More permanent exploits that involve overwriting the firmware would be device-specific.

0

I am constantly finding that request method paired with a GET /HNAP1/ HTTP/1.1 which makes me suspect the \x80w\x01\x03\x01 sequence may be related to a vulnerability in one of the home automation systems.

74.203.xx.xx - - [13/Dec/2013:19:01:25 -0800] "\x80w\x01\x03\x01" 405 997 "-" "-"
74.203.xx.xx - admin [13/Dec/2013:19:01:25 -0800] "GET /HNAP1/ HTTP/1.1" 301 579 "http://.../" "Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20011224"
74.203.xx.xx - - [13/Dec/2013:19:04:43 -0800] "\x80w\x01\x03\x01" 405 997 "-" "-"
74.203.xx.xx - admin [13/Dec/2013:19:04:44 -0800] "GET /HNAP1/ HTTP/1.1" 301 581 "http://.../" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.