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

Question

Le site web est sous Ruby on Rails 3.2.11 et Ruby 1.9.3.

Qu'est-ce qui peut causer l'erreur suivante :

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

J'ai plusieurs erreurs comme celle-ci dans les journaux. Elles essaient toutes d'évaluer la requête (\"alihack.com\").

Partie du fichier journal :

"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 - est l'IP de CLoudFlare. "REMOTE_ADDR" => "10.93.15.235" et "10.123.66.198" et d'autres, je pense, sont de fausses IP de proxy.

Voici un lien a le même problème avec son site web à partir de la même adresse IP (23.27.103.106).

Pour résumer, l'IP commune à toutes les erreurs est 23.27.103.106 et elles essaient d'exécuter le script en utilisant l'eval de ruby.

Donc mes questions sont : Quel type de vulnérabilité essaient-ils de trouver ? Que faire ? Bloquer l'IP ?

Merci d'avance.

Answer 1

Pourquoi cela arrive-t-il ?

Cela ressemble à une tentative de tester ou d'exploiter une vulnérabilité d'exécution de code à distance. Potentiellement une vulnérabilité générique (visant une plateforme autre que Rails), ou une vulnérabilité qui existait dans des versions antérieures.

L'erreur réelle provient toutefois du fait que la demande est une HTTP PUT con application/json les en-têtes, mais le corps n'est pas un json valide.

Pour reproduire ceci sur votre environnement de développement :

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

Plus de détails

Rails action_dispatch essaie de parser toutes les requêtes json en passant le corps à décoder.

  # 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)
    ...

Dans ce cas, il ne s'agit pas d'un JSON valide, et l'erreur est soulevée, entraînant l'envoi d'un message 500 au serveur.

Solutions possibles

Je ne suis pas tout à fait sûr de la meilleure stratégie à adopter pour faire face à cette situation. Il y a plusieurs possibilités :

1. vous pouvez bloquer l'adresse IP en utilisant iptables
2. filtre ( PUT ou toutes) les demandes à /ali.txt au sein de votre nginx o apache configs.
3. utiliser un outil comme le rack-attack gemme et y appliquer le filtre
4. utiliser le request_exception_handler afin d'attraper l'erreur et de la gérer depuis Rails (voir cette réponse SO y ce problème github )
5. bloc PUT dans l'environnement de Rails routes.rb à toutes les urls sauf celles qui sont explicitement autorisées. Il semble que dans ce cas, l'erreur soit levée avant même d'atteindre les routes de Rails, ce qui n'est pas forcément possible.
6. Utilisez le rack-robustness et attraper l'erreur de parse json avec quelque chose comme cette configuration en config/application.rb
7. Écrivez votre propre intergiciel. Quelque chose du genre de ce qui se trouve sur ce poste

Je penche actuellement pour les options n°3, n°4 ou n°6. Toutes ces options pourraient s'avérer utiles pour d'autres types de bots/scanners ou d'autres demandes invalides qui pourraient apparaître à l'avenir...

Je suis heureux d'entendre ce que les gens pensent des différentes solutions alternatives.

Answer 2

J'ai vu des entrées de journal étranges sur mon propre site [qui n'utilise pas Ruby] et Google m'a conduit à ce fil de discussion. L'IP sur mes entrées était différente. [120.37.236.161]

Après avoir fouillé un peu plus, voici mes spéculations et mes suppositions :

Tout d'abord, dans mes propres journaux, j'ai vu une référence à http://api.alihack.com/info.txt - J'ai vérifié ce lien ; ça ressemble à une tentative d'injection de PHP.

Il y a aussi une page "register.php" - la soumission vous amène à une page "invite.php".

Un examen plus approfondi de ce domaine m'a conduit à http://www.alihack.com/2014/07/10/168.aspx (la page est en chinois mais Google Translate m'a aidé ici)

Je suppose que cet outil "Black Spider" a été modifié par des script et qu'il est utilisé comme un tapis de bombes pour tenter de trouver tous les sites qui sont "vulnérables".

Il pourrait être prudent d'ajouter à votre configuration un refus automatique de toute tentative incluant la sous-chaîne "alihack".

Answer 3

Un problème similaire est apparu dans les journaux de Rollbar, une requête PUT vers /ali.txt.

Le mieux est de bloquer cette IP, je n'ai vu qu'une seule demande de mon côté avec cette erreur. La demande que j'ai reçue venait de France -> http://whois.domaintools.com/37.187.74.201

Si vous utilisez nginx, ajoutez ceci à votre fichier de conf nginx ;

deny 23.27.103.106/32;
deny 199.27.133.183/32;