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

Question

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.

Getting this too. Any ideas? I guess it's a good thing that we actually see it. — Ponny
I'm getting this as well from a different IP address. It comes alongside other very suspicious requests like ones to path="/admin/fckeditor/editor/filemanager/connectors/php/upload.php" I think it's just someone running some attack tool on a ton of domains — JKillian
I'm also getting those requests from a couple of days ago from a different IP address — Aitherios

gingerlime gingerlime · Accepted Answer · 2014-08-25T13:30:24

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:

you can block the IP address using iptables
filter (PUT or all) requests to /ali.txt within your nginx or apache configs.
use a tool like the rack-attack gem and apply the filter there. (see this rack-attack issue )
use the request_exception_handler gem to catch the error and handle it from within Rails (See this SO answer and this github issue)
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.
Use the rack-robustness middleware and catch the json parse error with something like this configuration in config/application.rb
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