wake-up-neo.com

(JSON :: ParserError) "{N}: unerwartetes Token bei 'alihack <% eval request (\" alihack.com ")%>

Ich habe die Website zu Ruby on Rails 3.2.11 und Ruby 1.9.3. 

Was kann folgenden Fehler verursachen:

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

Ich habe mehrere Fehler wie diese in den Protokollen. Alle versuchen, die Anfrage zu bewerten ("alihack.com"). 

Teil der Protokolldatei:

"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 - ist CLoudFlare IP . "REMOTE_ADDR" => "10.93.15.235" und "10.123.66.198" und andere, ich denke, sind gefälschte IPs des Proxy.

Hier ist ein Link guy hat das gleiche Problem mit seiner Website von derselben IP-Adresse (23.27.103.106).

Zusammenfassend ist die allgemeine IP aller Fehler 23.27.103.106 und sie versuchen, das Skript mit Rubys Eval auszuführen.

Meine Fragen lauten also: Welche Art von Schwachstelle versuchen sie zu finden? Was tun? IP blockieren?

Danke im Voraus.

53
Igor Markelov

Warum passiert es?

Es scheint ein Versuch zu sein, eine Sicherheitsanfälligkeit bezüglich Remotecodeausführung zu testen oder auszunutzen. Möglicherweise eine generische Plattform (zielt auf eine andere Plattform als Rails) oder eine, die in früheren Versionen vorhanden war.

Der eigentliche Fehler rührt jedoch von der Tatsache her, dass die Anforderung ein HTTP PUT mit application/json-Kopfzeilen ist, der Body jedoch kein gültiger Json ist.

So reproduzieren Sie dies in Ihrer Entwicklungsumgebung:

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

Mehr Details

Rails action_dispatch versucht, alle Json-Anforderungen zu analysieren, indem der zu decodierende Körper übergeben wird

  # 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 diesem Fall handelt es sich nicht um einen gültigen JSON, und der Fehler wird ausgelöst, wodurch der Server eine 500 meldet.

Mögliche Lösungen

Ich bin nicht ganz sicher, was die beste Strategie ist, um damit umzugehen. Es gibt mehrere Möglichkeiten:

  1. sie können die IP-Adresse mit iptables blockieren.
  2. filtern (PUT oder alle) Anforderungen an /ALi.txt in Ihrer nginx- oder Apache-Konfiguration.
  3. verwende ein Werkzeug wie den rack-attack gem und wende den Filter dort an. (Siehe dieses Rack-Angriff Problem )
  4. verwenden Sie den Edelstein request_exception_handler , um den Fehler abzufangen und innerhalb von Rails zu behandeln (Siehe this SO answer und this github issue )
  5. blockieren Sie PUT-Anforderungen in Rails 'routes.rb an alle URLs, die jedoch explizit zulässig sind. Es sieht so aus, als würde der Fehler in diesem Fall bereits ausgelöst, bevor er die Routen von Rails erreicht - dies ist möglicherweise nicht möglich.
  6. Verwenden Sie die rack-robustness Middleware und fangen Sie den Json-Parser-Fehler mit etwas wie dieser Konfiguration in config/application.rb ab.
  7. Schreiben Sie Ihre eigene Middleware. Etwas in der Richtung des Zeugs auf diesem Beitrag

Ich neige derzeit zu Optionen # 3, # 4 oder # 6. All dies könnte sich für andere Arten von Bots/Scannern oder andere ungültige Anfragen als nützlich erweisen, die in der Zukunft auftauchen könnten ...

Freut mich zu hören, was die Leute über die verschiedenen alternativen Lösungen denken

65
gingerlime

Ich habe einige seltsame Protokolleinträge auf meiner eigenen Site gesehen (die Ruby nicht verwendet) und Google brachte mich zu diesem Thread. Die IP auf meinen Einträgen war anders. [120.37.236.161]

Nachdem ich ein bisschen mehr herumgestöbert habe, hier meine meist spekulierte/gebildete Vermutung:

Zuerst sah ich in meinen eigenen Protokollen einen Verweis auf http://api.alihack.com/info.txt - diesen Link ausgecheckt; sah aus wie ein Versuch einer PHP -Injektion.

Dort gibt es auch eine "register.php" -Seite - das Senden bringt Sie zu einer "invite.php" -Seite.

Weitere Prüfung dieser Domain führte mich zu http://www.alihack.com/2014/07/10/168.aspx (Seite ist auf Chinesisch, aber Google Translate hat mir hier geholfen)

Ich gehe davon aus, dass dieses "Black Spider" -Tool von Scriptkiddies modifiziert wurde und als Teppichbomber verwendet wird, um zu versuchen, Websites zu finden, die "anfällig" sind.

Es kann ratsam sein, eine automatische Ablehnung jedes Versuchs, einschließlich des "alihack" -Substrings, zu Ihrer Konfiguration hinzuzufügen.

10
CRZ

Ich hatte ein ähnliches Problem in meinen Rollbar-Protokollen, eine PUT-Anforderung an /ALi.txt

Am besten nur um diese IP zu blockieren, ich sah an meinem Ende nur eine Anfrage mit diesem Fehler. Die Anfrage, die ich erhielt, kam aus Frankreich -> http://whois.domaintools.com/37.187.74.201

Wenn Sie Nginx verwenden, fügen Sie dies Ihrer Nginx-Conf-Datei hinzu.

deny 23.27.103.106/32;
deny 199.27.133.183/32;
2
Jamsi

Für Rails-3 gibt es einen speziellen Workaround-Edelstein: https://github.com/infopark/robust_params_parser

0
Kostia