Question posted in
Some documentation to get you started can be found here.

Strange referers in Apache logfiles: empty string and what looks like MySQL code

I’ve read my logfiles into R, and when I look at the referer there are some strange entries:

> logs <- read.table("logfile")
> referer <- data.frame(table(logs$referer))
> head(referer, 2)
Var1              Freq
1                  157
2             - 250290

Apache uses a dash (-) to denote a missing referer. That’s row 2. So what does the empty string (“) in row 1 mean? As I see it, that could only happen if Apache “forgot” to write the referer to the logfile.

Here is one of the 157 entries with an empty referer string (I have anonymized the client ip and my website URL):

173.244.xxx.xxx - - [17/Apr/2018:08:07:46 +0200] "GET /feeds/atom.xml HTTP/1.1" 200 18820 www.my-website.com "" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36; [email protected]" "-"

But the most mysterious referers look like this:

554fcae493e564ee0dc75bdf2ebf94caads|a:2:{s:3:"num";s:280:"*/ union select 1,0x272f2a,3,4,5,6,7,8,0x7b24617364275d3 ...

I have cut off the string at the end (it goes on for quite a bit longer), because I don’t know if it contains sensitive information. I have about 20 visits with referers like this, all from the same client ip, most of them requesting resources that do not exist on my server, such as //user.php and //cm.php.

It seems to me that these are, at least in part, MySQL queries. a:2:{s:3:"num";s:459:" is the beginning of a serialized array. I use this format to store some data from a web form in a MySQL database. But this processing happens serverside and is never sent to the user’s browser. And how does a MySQL query end up as a referer anyway? I can understand that someone might try to enter MySQL code into a webform, but that doesn’t make that part of a referer.

Any explanations would be nice.

Tags:

2

Answers


  1. 0

    This looks like a SQL injection attempt. The logs won’t show if the SQL attempt is successful.

    While this would normally show in a URL field, there’s no reason it couldn’t show up in a HTTP referrer field in your logs.

    Login or Signup to reply.
  2. 0

    This is an attack against internal infrastructure. Many organizations use centralized systems to ingest logs and then use reporting infrastructure to support querying logs. Developers are fairly bad at designing secure systems and the SQL in a Referer field is trying to take advantage of that.

    Attackers can also try to store snippets in Referer fields and then make use of it in other types of attacks.

    So long as you aren’t using poorly crafted software to query logs you should be fine.

    This — https://resources.infosecinstitute.com/sql-injection-http-headers/ — provides some further information.

    Also, as noted in the comment, consider user webreadr to read in web server log files.

    And, upon further review, this appears to be a campaign by an attacker group looking to compromise “Ecshop” content management system (https://github.com/SecWiki/CMS-Hunter/tree/master/Ecshop/ecshop2.x_code_execute). If you are running that you may want to triple check your server.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search