• Herzlich willkommen im "neuen" DSLR-Forum!

    Wir hoffen, dass Euch das neue Design und die neuen Features gefallen und Ihr Euch schnell zurechtfindet.
    Wir werden wohl alle etwas Zeit brauchen, um uns in die neue Umgebung einzuleben. Auch für uns ist das alles neu.

    Euer DSLR-Forum-Team

  • In eigener Sache!

    Liebe Mitglieder, liebe Besucher und Gäste
    ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
    Bitte hier weiterlesen ...

  • DSLR-Forum Fotowettbewerb neu erfunden!
    Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
    und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
    Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
    Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen.
  • Neuer Partner: AkkuShop.de
    Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
  • Neuer Gutscheincode unseres Partners Schutzfolien24:
    DSLR-Forum2024
    Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
    Der Code ist für alle Geräteklassen gültig.
  • Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
    Thema: "Sprichwörtlich"
    Nur noch bis zum 30.04.2024 23:59!
    Jeder darf abstimmen!
    Zur Abstimmung und Bewertung hier lang
WERBUNG

Forum schon wieder verseucht ?

Status
Für weitere Antworten geschlossen.
Was mich gerade wundert:
Heute Morgen hat mein Avast angeschlagen und mich nicht mal mehr in's Forum gelassen.
Gestern hat er nicht gemeckert, obwohl der Iframe da war.
Gab`s vielleicht mit dem letzten Definitionsupdate eine Erkennung für dubiose iFrames?

Hätte auch noch 'ne Frage:
Weiß einer von euch, ob unser Freund aus 'ner Sandbox ausbrechen kann?
 
Zuletzt bearbeitet:
Thunderclap schrieb:
Die Ziel-URL wird offenbar täglich geändert... ist ja auch trivial, da ein dynDNS-Hoster genutzt wird...
Zum Vergrößern anklicken....

Bedeutet das nicht, dass der gestern diskutierte Hosts- Eintrag bzw. das Sperren der Adresse im Router auch täglich zu aktualisieren ist?

Wenn ja, dann wäre es hilfreich, den entsprechenden Eintrag hier zu veröffentlich.

Danke und Gruß
ewm
 
Die heutige Warnung ist ja wohl ein schlechter Scherz. Wenn das Forum dauerhaft verseucht ist, und keiner weiß, wie das gehen soll, gehört es so lange vom Netz, bis das Problem behoben ist.
Das ist ein Armutszeugnis für einen professionellen Betreiber.
 
Blur schrieb:
Naja, man könnte ja auch manuell eine Seite hinlegen.

Reden wir eigentlich über diesen Cache?
Zum Vergrößern anklicken....

Wir reden soweit ich vestanden habe vom Template-Cache, der eben nicht optional ist...
(warum beim datastore-cache 777 vorgeschlagen wird ist mir aber rätelhaft)

BTM schrieb:
Was mich gerade wundert:
Heute Morgen hat mein Avast angeschlagen und mich nicht mal mehr in's Forum gelassen.
Gestern hat er nicht gemeckert, obwohl der Iframe da war.
Gab`s vielleicht mit dem letzten Definitionsupdate eine Erkennung für dubiose iFrames?
Zum Vergrößern anklicken....

Jepp... ist mir auch aufgefallen!
Sobald der IFrame da ist blockt Avast seit gestern den kompletten Zugriff aufs Forum (y)
 
Zuletzt bearbeitet:
Thunderclap schrieb:
Ich bin gespannt wie du das Forum per Script in den Wartungszustand versetzt... vBulletin bietet hierzu keinerlei API...

Hab auch schon recherchiert...
Zum Vergrößern anklicken....

warum willst du das tun? :)

du setzt es einmal in den wartungezustand um ein frisches kompilat der templates zu erzeugen und das wars. diese kompilierten template files sind es die wir auf der benutzerseite zugesandt bekommen, und die brauchen sich auch nicht mehr zu aendern. wenn du dir diese files kopierst oder zumindest die wichtigen davon, dann hast du einen stand den du jeder zeit drueberkopieren kannst wenn etwas nicht stimmt. du hast auch eine vergleichsbasis um zu ueberpruefen ob etwas nicht stimmt. tag und nacht. das forum waere lediglich fuer wenige sekunden kompromitiert - was immer noch schlimm ist, aber zuminest hat man etwas zeit zum durchatmen und kann jetzt nach der eigentlichen luecke suchen.

nocheinmal anders ausgedrueckt:

1. forum manuell in den wartungszustand versetzen, dieser schritt ist nur einmal noetig und muss nicht automatisiert werden
2. man lösche alles manuell im cache ordner
3. man erneuert die templates im acp, dass er die kompiliert und neue files in den chache schreibt
4. jetzt kopiert man den kompletten cache in einen sicheren ordner
5. geschrieben werden muss ein kleines script dass den zustand des cache ordners überwacht, die anzahl der files und die check-summen anhand der files im backup ordner
6. sollte irgendwas nicht stimmen, soll das script sofort alles noetige austauschen. wenn möglich auch infos in log files ablegen, zb. änderungsdatum, etc.
7. ab in die cron-tab mit dem script, jede minute einmal laufen lassen, besser alle 30 sekunden - frisst ja nicht viel cpu sowas.
 
Zuletzt bearbeitet:
Fruchtzwergemutta schrieb:
Wo liegt der Template-Cache hierarchisch auf dem Server? Ist er per Web erreichbar? Wenn ja, reicht ein HTTP PUT aus, um die Dateien entsprechend zu manipulieren...
Zum Vergrößern anklicken....

Ach bitte... Red nicht über Dinge von denen du keine Ahnung hast :grumble:

Bitte ein proof of concept, wie du per PUT eine Datei manpulierst...

PUT überträgt Daten an den HTTP-Service, nicht aufs Dateisystem!
 
paulhenschel schrieb:
wenn du dir diese files kopierst oder zumindest die wichtigen davon, dann hast du einen stand den du jeder zeit drueberkopieren kannst wenn etwas nicht stimmt. du hast auch eine vergleichsbasis um zu ueberpruefen ob etwas nicht stimmt.
Zum Vergrößern anklicken....

Wenn du den Thread verfolgt hättest, wüsstest du, dass das einfach überschreiben aus irgend einem Grund nicht ausreicht und keine Datei ein Anzeichen einer Manipulation aufweist...

Was auch immer da am werkeln ist, es tut es nicht im Filesystem... zumindest nicht sichtbar (Rootkit?)
 
Thunderclap schrieb:
Ach bitte... Red nicht über Dinge von denen du keine Ahnung hast :grumble:
Zum Vergrößern anklicken....

Mach ich doch. Vielleicht solltest Du mal von etwas reden, wovon Du Ahnung hast.

PUT überträgt Daten an den HTTP-Service, nicht aufs Dateisystem!
Zum Vergrößern anklicken....

Nein, das macht nur POST. Hier mal die Spezifikation für PUT:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.
 
Thunderclap schrieb:
Wenn du den Thread verfolgt hättest, wüsstest du, dass das einfach überschreiben aus irgend einem Grund nicht ausreicht und keine Datei ein Anzeichen einer Manipulation aufweist...
Zum Vergrößern anklicken....

Da der Schadcode in der Datei drin ist, wurde sie auch manipuliert, klingt logisch, ist auch so. Die Admins tauschen die Dateien auch ständig aus, d.h. das Modifikationsdatum ändert sich ständig. Es gibt lediglich keine Einträge im FTP-Log. Im HTTP-Log hat bestimmt noch niemand geschaut, bzw. niemand der Ahnung hat.
 
Fruchtzwergemutta schrieb:
In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.
Zum Vergrößern anklicken....

Und wo steht da jetzt irgendetwas von einem möglichen Zugriff aufs Dateisystem? :rolleyes:
Sorry, aber ich arbeite seit Jahren mit diversen Webservern (als Entwickler als auch als Admin - und das nicht als Hobby wie hier so einige andere...).... und nein, man kann bei KEINEM Server einfach per Put auf ein beliebiges File schreiben! Nicht mal wenn die Files auf 777 stehen...
Ein Put erzeugt nur einen Request-String im HTTP-Header, den der Server verarbeiten muss. Existiert kein Script dass den Put entgegennimmt, passiert gar nichts (ausser einer entsprechenden Fehlermeldung - je nach Config)

Wenn irgendein Server das direkte Schreiben aufs FS ermöglichen würde, wären schon 90% aller Webseiten defaced - wenn man bedenkt wie viele Forensysteme, Galerien, etc auf Files angewiesen sind, die auf 777 stehen...:ugly:
 
Zuletzt bearbeitet:
Thunderclap schrieb:
Wenn du den Thread verfolgt hättest, wüsstest du, dass das einfach überschreiben aus irgend einem Grund nicht ausreicht und keine Datei ein Anzeichen einer Manipulation aufweist...

Was auch immer da am werkeln ist, es tut es nicht im Filesystem... zumindest nicht sichtbar (Rootkit?)
Zum Vergrößern anklicken....

scorpio tut es mit einem click im acp. dieser refresh tut nichts anderes als die files im cache ordner zu ueberschreiben - und laut scorpio ist danach die gefahr vorerst gebannt, auch ohne, dass er nur eine aenderung vornimmt. wenn das wirklich funktioniert muss es im cache sein. gestern hat ers doch schon wieder getan, ein neuer kompilierungsvorgang, weg war der virus. nochmal, die funktion im acp ueberschreibt lediglich den cache mit den frisch kompilierten templates-er macht lauffaehige php dateien daraus.

im filesystem nach der reinen virus-url oder dem iframe zu suchen ist eh nicht so gut, schau nur wie sie ihr js zeug verschluesselt haben, die sind doch nicht doof. wenn ich der hacker waere wuerde ich diese sache natuerlich verschluesselt in die phps im cache einfuegen und die generieren dort erst den string den hier jeder sieht. die templates selbst und den vb-php code lasse ich natuerlich unberuehrt. aber dort, im cache, muss es eine aenderung geben. wenn scorpio nach einer attacke den kompletten ordner mal packt bevor er im acp den refresh macht, dann kann man ohne weiteres mal schauen wie sies machen. und ich vermute auch das vorgeschlagene script wuerde funktionieren und das forum absichern.
 
Zuletzt bearbeitet:
Thunderclap schrieb:
Und wo steht da jetzt irgendetwas von einem möglichen Zugriff aufs Dateisystem?
Zum Vergrößern anklicken....

Genau da wo Du es zitiert hast:

the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource

Da stehts! Nochmal auf deutsch für Dich: der Browser kennt die URI und der Server MUSS NICHT die Anfrage zu einer anderen Resource schicken.

Hier nochmal mit Beispiel-HTTP-Anfragen (schau bei PUT):
http://www.html-world.de/program/http_3.php

In den meisten Fällen sind solche Funktionen im Webserver ausgeschalten, aber das heisst nicht, dass es nicht geht.
 
Mal rein interessehalber:
Benutzt ihr "mod_cache"?
Wenn ja könnte dort das Einfallstor liegen.
Dann muss der Angreifer die original Dateien nicht anfassen.

Oder ist irgend eine andere Software aktiv zwischen Server und User?
z.B. Apache Traffic Server, oder sonst irgendetwas das cached?

Grüße,
Bjoern
 
Ah, okay, nginx - ich hätte vllt doch erst mal schauen sollen was ihr benutzt anstelle vom quasi default Apache auszugehen :D

nginx kenn ich leider so gut wie gar nicht... :(

Nichts desto trotz hört sich das alles an als ob der Angreifer im Cache rumspielt. :mad:
 
paulhenschel schrieb:
scorpio tut es mit einem click im acp. dieser refresh tut nichts anderes als die files im cache ordner zu ueberschreiben - und laut scorpio ist danach die gefahr vorerst gebannt, auch ohne, dass er nur eine aenderung vornimmt.
Zum Vergrößern anklicken....

Bis gestern morgen ging das, ja... mittlerweile nicht mehr... Die Angriffe haben sich geändert. (daher der lange Befall über Nacht... Die bisherigen Methoden hab nicht gewirkt)
 
Status
Für weitere Antworten geschlossen.
WERBUNG
Zurück
Oben Unten