(JSON::ParserError) "{N}: unexpected token at 'alihack<%eval request(\"alihack.com\")%>

I have the website on Ruby on Rails 3.2.11 and Ruby 1.9.3.

What can cause the following error:

(JSON::ParserError) "{N}: unexpected token at 'alihack<%eval request(\"alihack.com\")%>

I have several errors like this in the logs. All of them tries to eval request("alihack.com").

Part of the log file:

"REMOTE_ADDR" => "10.123.66.198",
"REQUEST_METHOD" => "PUT",
"REQUEST_PATH" => "/ali.txt",
"PATH_INFO" => "/ali.txt",
"REQUEST_URI" => "/ali.txt",
"SERVER_PROTOCOL" => "HTTP/1.1",
"HTTP_VERSION" => "HTTP/1.1",
"HTTP_X_REQUEST_START" => "1407690958116",
"HTTP_X_REQUEST_ID" => "47392d63-f113-48ba-bdd4-74492ebe64f6",
"HTTP_X_FORWARDED_PROTO" => "https",
"HTTP_X_FORWARDED_PORT" => "443",
"HTTP_X_FORWARDED_FOR" => "23.27.103.106, 199.27.133.183".

199.27.133.183 - is CLoudFlare IP. "REMOTE_ADDR" => "10.93.15.235" and "10.123.66.198" and others, I think, are fake IPs of proxy.

Here's a link guy has the same issue with his web site from the same ip address(23.27.103.106).

To sum up, the common ip from all errors is 23.27.103.106 and they try to run the script using ruby's eval.

So my questions are: What type of vulnerability they try to find? What to do? Block the ip?

Thank you in advance.

Why it happens?

It seems like an attempt to at least test for, or exploit, a remote code execution vulnerability. Potentially a generic one (targeting a platform other than Rails), or one that existed in earlier versions.

The actual error however stems from the fact that the request is an HTTP PUT with application/json headers, but the body isn't a valid json.

To reproduce this on your dev environment:

curl -D - -X PUT --data "not json" -H "Content-Type: application/json" http://localhost:3000

More details

Rails action_dispatch tries to parse any json requests by passing the body to be decoded

  # lib/action_dispatch/middleware/params_parser.rb

  def parse_formatted_parameters(env)
    ...
    strategy = @parsers[mime_type]
    ...

    case strategy
    when Proc
      ...
    when :json
      data = ActiveSupport::JSON.decode(request.body)
    ...

In this case, it's not a valid JSON, and the error is raised, causing the server to report a 500.

Possible solutions

I'm not entirely sure what's the best strategy to deal with this. There are several possibilities:

1. you can block the IP address using iptables
2. filter (PUT or all) requests to /ali.txt within your nginx or apache configs.
3. use a tool like the rack-attack gem and apply the filter there. (see this rack-attack issue )
4. use the request_exception_handler gem to catch the error and handle it from within Rails (See this SO answer and this github issue)
5. block PUT requests within Rails' routes.rb to all urls but those that are explicitly allowed. It looks like that in this case, the error is raised even before it reaches Rails' routes - so this might not be possible.
6. Use the rack-robustness middleware and catch the json parse error with something like this configuration in config/application.rb
7. Write your own middleware. Something along the lines of the stuff on this post

I'm currently leaning towards options #3, #4 or #6. All of which might come in handy for other types of bots/scanners or other invalid requests that might pop-up in future...

Happy to hear what people think about the various alternative solutions

I saw some weird log entries on my own site [which doesn't use Ruby] and Google took me to this thread. The IP on my entries was different. [120.37.236.161]

After poking around a bit more, here is my mostly speculation/educated guess:

First, in my own logs I saw a reference to http://api.alihack.com/info.txt - checked this link out; looked like an attempt at a PHP injection.

There's also a "register.php" page there - submitting takes you to an "invite.php" page.

Further examination of this domain took me to http://www.alihack.com/2014/07/10/168.aspx (page is in Chinese but Google Translate helped me out here)

I expect this "Black Spider" tool has been modified by script kiddies and is being used as a carpet bomber to attempt to find any sites which are "vulnerable."

It might be prudent to just add an automatic denial of any attempt including the "alihack" substring to your configuration.

I had a similar issue show up in my Rollbar logs, a PUT request to /ali.txt

Best just to block that IP, I only saw one request on my end with this error. The request I received came from France -> http://whois.domaintools.com/37.187.74.201

If you use nginx, add this to your nginx conf file;

deny 23.27.103.106/32;
deny 199.27.133.183/32;

For Rails-3 there is a special workaround-gem: https://github.com/infopark/robust_params_parser