54

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.

Igor Markelov
  • 798
  • 2
  • 8
  • 16
  • 4
    Getting this too. Any ideas? I guess it's a good thing that we actually see it. – Ponny Aug 15 '14 at 12:17
  • 1
    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 Aug 22 '14 at 03:31
  • I'm also getting those requests from a couple of days ago from a different IP address – Aitherios Sep 19 '14 at 13:33

4 Answers4

65

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

Community
  • 1
  • 1
gingerlime
  • 5,206
  • 4
  • 37
  • 66
  • 1
    The right answer depends on how you want to handle it. It's not an application-specific concern, so writing code or middleware into your app to deal with this is probably wrong. (That is, if you were running several apps on the same server, you would want all of them protected against this attack.) So this would probably go on `iptables` on your load balancer, or something similar, and I prefer solutions [1] and [2] for that reason. – John Feminella Aug 31 '14 at 14:18
  • Thanks John. I see where you're coming from. It's true that other solutions are more application-specific. On the other hand, solutions [1] and [2] are very attack-specific. i.e. any other request with malformed JSON to a different URL or from a different IP won't be covered by those... Whereas rescuing from any JSON ParseError and logging it would. – gingerlime Aug 31 '14 at 15:43
  • 3
    If you want to use rack-attack you might need this for rails: https://github.com/kickstarter/rack-attack/issues/99 – 2called-chaos Oct 24 '14 at 17:26
10

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.

CRZ
  • 126
  • 4
  • This is definitely ERB syntax `<%eval request(\"alihack.com\")%>` so it seems they must be going after Rails vulnerabilities too. – excid3 Aug 21 '14 at 02:16
  • 1
    "It might be prudent to just add an automatic denial of any attempt including the "alihack" substring to your configuration." ⇒ This is almost certainly a terrible idea. See, e.g., **[the Scunthorpe problem](http://en.wikipedia.org/wiki/Scunthorpe_problem)**. – John Feminella Aug 22 '14 at 04:18
  • hey @JohnFeminella! nice bumping into you :) I totally agree it's a bad idea. I'm curious about your thoughts / opinion about the possible alternatives I suggested on my [answer](http://stackoverflow.com/a/25487047/305019). – gingerlime Aug 30 '14 at 08:56
2

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;
James
  • 2,284
  • 1
  • 20
  • 29
0

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

Kostia
  • 150
  • 4