Ist da was faul oder alles ok?

[Harry P.]

Und wie möchtest Du das konfigurieren?

AMASP oder die eigene "WB Master Site", mit der ich eine WB-Installation vergleichen möchte, könnte ein Modul erhalten, das die aktuellen Versionsnummern aller Module etc. in eine Textdatei schreibt - entweder auf Knopfdruck oder (besser) regelmäßig per Cronjob angestoßen (an die DB selbst kommt man ja site-übergreifend nicht ran). Die URL dieser Datei könnte dann optional in Deinem Versionsmodul angegeben werden und die vorgefundenen Versionsnummern im Vergleich auflisten. Womöglich fabrlich auf Differenzen hinweisen.

[WebBird]

Da würde sich XML anbieten. Aber damit würde ich dem neuen Addons Repository vorgreifen.

[Hans>NULL]

Einen Versionscheck gibt es schon seit "WebsiteBaker v2.6.x"
Module: Check module 'modcheck'
Hab' das Teil auch schon mal in's Forum gepostet (fragt sich jetzt natürlich wo?)
Aus unerfindlichen Gründen ist das Teil aus dem Addons-Bereich verschwunden.
Bräuchte man nur um Rev. erweitern.
Aber es geht natürlich auch mit "Neue Räder braucht das Land"
Gruß, Hans>NUL

[doc]

Hi,

Einen Versionscheck gibt es schon seit "WebsiteBaker v2.6.x". Module: Check module 'modcheck'

Nur dass dieses Modul schon seit 2008 nicht mehr unterstützt, wie u.a. hier zu lesen ist.

Als Modul nur wirklich sinnvoll, wenn es gleichzeitig eine Updatefunktion aus dem Backend heraus anbieten würde. Die zwei Zeilen Datenbankabfrage und Ausgabe in Tabelle dürften WebBird aber nicht wirklich lange aufgehalten haben. Schätze mal unter 15 Minuten, was in etwas der Zeit zum Suchen im Forum und schreiben dieser Post entspricht

Zurück zum Thema / @instantflorian
Eine Liste der "auffälligen" URLs wie bereits mehrfach nachgefragt würde wirklich Aufschluss geben, ob es an WB, an einem WB Modul, oder irgend einem anderen Script auf dem Server lag. Ohne diese Infos ist eine weitere Analyse und Lösung des Problems nicht mit vernünftigem Zeitaufwand zu lösen.

Doc

[WebBird]

Naja, ich habe noch etwas Zeit auf ein halbwegs anständiges Layout aufgewendet, insofern waren es eher 30 Minuten. Ansonsten hast Du recht. Es ging hier aber wirklich nur um "mal eben schnell gucken, was installiert ist"; alles andere hieße, dem Addons Repo vorzugreifen, und ich mach diese Arbeit garantiert nicht doppelt.

[Waldschwein]

Hallo!

Grundsätzlich wäre es evtl. sinnvoll, wenn man die Versionen aller WB-Module (egal ob Core oder nicht) zusammentragt die bekannte Sicherheitsprobleme haben, ich könnte das in mein Sicherheitsscript übernehmen, und das wirft dann eine Meldung aus, dass man unbedingt upgraden sollte. Natürlich später mit neuer Add-ons-Repository dann auch in WB selbst direkt. Mit MD5-Hash Abgleich ist das kein Problem.

Gruß Michael

[instantflorian]

Hallo,

sorry, ich war etwas voreilig und habe bei den Websites, die betroffen waren, schon den FCKEditor geupdated sowie TemplateEdit und (wo vorhanden) ModuleEdit deinstalliert und einige auf 2.8.1 aktualisiert. Wenn es hilft, kann ich jetzt aber Webbirds Modulchecker installieren und das Ergebnis dann irgendwohin mailen (hier ins Forum stellen ist vlt nicht so klug). Wem soll ich die Daten senden?

Grüße
-instantflorian.

[doc]

Hi,

Wenn es hilft, kann ich jetzt aber Webbirds Modulchecker installieren und das Ergebnis dann irgendwohin mailen.

Macht wohl keine grossen Sinn mehr, da die "kritischen" Module bereits upgedatet wurden.

Wem soll ich die Daten senden?

Denke das habe ich bereits zwei- oder dreimal geschrieben (Form, PM ...).

Auch schon mindestens zwei oder dreimal gepostet war die Bitte Deinen Provider zu kontaktieren und nach den betroffenen URLs zu fragen. Scheint aber das hast Du nicht vor. Ohne diese Info dürfte jede weitere Post hier ziemlich überflüssig sein ...

Doc

[instantflorian]

Hallo doc,

1. ich musste erstmal Schadensbegrenzung betreiben und dafür sorgen, dass nicht noch mehr passiert. Ich finde es nicht fair, mir jetzt daraus einen Strick zu drehen.
2. Die betroffenen Websites sind bei Goneo gehostet, und so wie ich den Service von denen kenne, ist es sowieso sinnlos, dort irgendwelche Anfragen zu stellen.
3. Deinen Hinweis, ans devteam zu pehemmen, hatte ich in der Tat überlesen. Das Sicherheitsfragenfo rmular auf der WB-Website finde ich abschreckend, und zudem besteht dort nicht die Möglichkeit, Anhänge mitzusenden.

-if.

[doc]

Hi,

ch musste erstmal Schadensbegrenzung betreiben und dafür sorgen, dass nicht noch mehr passiert

Ne kurze Post á la "Antwort kommt später" wäre trotzdem super gewesen. Und was Deine Anspielung mit nem Strick drehen soll verstehe ich nicht wirklich. Denke es wurden genug und ausführliche Hilfestellungen hier gegeben (59 Posts), Dein Problem scheint ja auch bereits gelöst.

Die betroffenen Websites sind bei Goneo gehostet, und so wie ich den Service von denen kenne, ist es sowieso sinnlos, dort irgendwelche Anfragen zu stellen.

Schade, die Info hätte man gebraucht, um WB als "mögliche" Ursache auszuschliessen. Denke den Thread kann man dann hiermit schliessen.

Doc

[Waldschwein]

Hallo!

Das Sicherheitsfragenfo rmular auf der WB-Website finde ich abschreckend, und zudem besteht dort nicht die Möglichkeit, Anhänge mitzusenden.

Also ich habe das Formular einmal grundsätzlich unverändert vom damals noch aktiven Security Team (also von FrankH) übernommen - ich denke der wusste schon, was er da tut.
Aber was genau meinst du mit abschreckend? Das Design oder die Fragen?  Beides lässt sich schon lösen - die Frage natürlich nur in Zusammenarbeit mit jemand vom Team, der sich damit auskennt.
Anhänge mitsenden sind bloß ein paar Klicks - kein Problem, das war nur im Ursprünglichen nicht vorgesehen. Aber evtl. wäre hier Kontakt mit FrankH sinnvoll, oder halt sonst jemand, der sich dafür verantwortlich fühlt.

Gruß Michael

[derschutzhund]

Hallo,

also das modulelist habe ich installiert und es läuft. Jetzt ist wirklich die Frage wie erzeuge ich einen kompletten Ausdruck bzw. wohin dann damit.
Ich habe den Eindruck, dass meine beiden HPs so offen wie ein Scheunentor sind!
Sie sind bei verschiedenen Providern und beim einen (bei 1und1) das ich vor zwei Tagen bereinigt habe sind heute schon wieder Einträge vorhanden!

und zwar in
include: codepress, jscalender, Yui,

modules: code, fckeditor, gdpics, htmlarea, imageflow, lightbox, lightbox2, output_filter, post_its, slideshow, slideshow2gal, smoothgallery, wrapper

Grüße Wolfgang

Hi,

Einen Versionscheck gibt es schon seit "WebsiteBaker v2.6.x". Module: Check module 'modcheck'

Nur dass dieses Modul schon seit 2008 nicht mehr unterstützt, wie u.a. hier zu lesen ist.

Als Modul nur wirklich sinnvoll, wenn es gleichzeitig eine Updatefunktion aus dem Backend heraus anbieten würde. Die zwei Zeilen Datenbankabfrage und Ausgabe in Tabelle dürften WebBird aber nicht wirklich lange aufgehalten haben. Schätze mal unter 15 Minuten, was in etwas der Zeit zum Suchen im Forum und schreiben dieser Post entspricht

Zurück zum Thema / @instantflorian
Eine Liste der "auffälligen" URLs wie bereits mehrfach nachgefragt würde wirklich Aufschluss geben, ob es an WB, an einem WB Modul, oder irgend einem anderen Script auf dem Server lag. Ohne diese Infos ist eine weitere Analyse und Lösung des Problems nicht mit vernünftigem Zeitaufwand zu lösen.

Doc

[instantflorian]

@Michael: Das "abschreckend" beim Kontaktformular nehme ich zurück. War etwas voreilig bzw. bezog sich auf den Umfang der abgefragten Informationen, was ohne die modulelist wirklich schwierig geworden wäre.

Möglicherweise its mein Problem erstmal gelöst, weil ich FCKE geupdated und TemplateEdit entfernt habe und auch alle weitere Module, die gar nicht zum Einsatz kommen, runtergeschmissen habe (PageCloner usw.). Das - nämlich die Anzahl der installierten Module so weit wie möglich zu reduzieren - sowie bei den betroffenen Websites das FTP- und, wichtig, das Datenbankpasswort zu ändern, hilft hoffentlich erstmal, bis ich alle Seiten auf 2.8.1 migriert habe.

-if.

[wollinche]

Entschuldigt bitte wenn ich hier nun einfach so reinplatze.
Ich habe dieses Thema mit interesse gelesen, aber ...

solange wie @derschutzhund nicht seinen komplette Webspace LÖSCHT inclusive der Datenbank
hat er nie Ruhe vor den "Eindringlingen" !!!

Das was du installiert wurde ist gut gemacht, gut versteckt, und immer wieder verfügbar für die "Herren des Servers", die jederzeit wieder die Kontrolle übernehmen können.

Solche Shell-Scripte lassen sich nicht löschen, wer das glaubt - glaubt auch an den Klapperstorch *böse_grins*

Das einzige was bleibt ist das "Einfallstor" eindeutig zu localisieren und dann abzustellen.

PS: solche Scripte werden, zu 99%, über url-Injection oder mysql-Injection, installiert, da würde ich mein Hauptaugenmerk drauf richten.

Nochmals, entschuldigung für mein Einmischen *nett_grins*

[doc]

Hi,

solange wie @derschutzhund nicht seinen komplette Webspace LÖSCHT inclusive der Datenbank
hat er nie Ruhe vor den "Eindringlingen" !!!

Yepp, mit WB 2.8.1 Dateien hochladen oder neue Module aufspielen ist es nicht getan. Das sollte auch aus diesem Thread hervorgehen. Habe auch ne PM an instantflorian verschickt.

Der Inhalt war in etwa:
 + Komplettsicherung aller Dateien und Ordner (FTP), sowie Datenbank (phpMyAdmin)
 + löschen aller Dateien und Verzeichnisse ausser /pages, /media, dem Frontendtemplate und der config.php
 + überprüfen aller verbliebenen Dateien auf Schadcode (die /pages/xxx.php haben ja nur 3-4 Zeilen Code)
 + den Dump der MySQL DB auf verdächtige Einträge überprüfen (ist ne Textdatei)
 + frische WB 2.8.1 Installationsdateie n per FTP hochladen (ausser config.php, /install)
 + "geprüfte" DB Backup zurückspielen (phpMyAdmin)
 + WB upgrade script ausführen und danach löschen
 + alle FTP, MySQL und WB Zugangsdaten ändern (Passwort + Benutzernamen)
 + ein Komplettbackup der neuen und hoffentlich sauberen Installation erstellen (lokale Kopie)

Doc

[Waldschwein]

Hallo,

also das modulelist habe ich installiert und es läuft. Jetzt ist wirklich die Frage wie erzeuge ich einen kompletten Ausdruck bzw. wohin dann damit.
Ich habe den Eindruck, dass meine beiden HPs so offen wie ein Scheunentor sind!
Sie sind bei verschiedenen Providern und beim einen (bei 1und1) das ich vor zwei Tagen bereinigt habe sind heute schon wieder Einträge vorhanden!

und zwar in
include: codepress, jscalender, Yui,

modules: code, fckeditor, gdpics, htmlarea, imageflow, lightbox, lightbox2, output_filter, post_its, slideshow, slideshow2gal, smoothgallery, wrapper

Grüße Wolfgang

Hallo!

[Edit: Siehe Docs Beitrag]

CodePress, YUI und JSCalendar verwundert mich, weil YUI gar keine Möglichkeit bietet (ich bezweifle stark die anderen), irgendeinen Einfall zu erzeugen - aber ich lehne mich einmal weit aus dem Fenster und stelle eine Vermutung auf: Alles liegt im /include Ordner, also wird der Hacker davon ausgehen, dass wichtige Informationen in diesem Ordner liegen, und daher auch sein "Allmächtiges" Script dort platzieren.

Ich weiß, dass man es grundsätzlich nicht gerne sieht, sich um Sicherheitsfragen bei WB zu kümmern (ja, schon wieder so blöde Anschuldigungen, aber es ist einfach so). Aber ich würde einmal versuchen, Luisehahne und DarkViper zu kontaktieren (siehe Teamübersicht), oder sonst jemand vom Dev-Team, der sich bereit erklärt dazu. Die beiden genannten kennen sowohl den 2.8er Code (daher grundsätzlich auch den 2.7er) und sind auch aktiv momentan dran.
Allerdings muss in naher Zukunft eine vernünftige Lösung für 2.8.x her zwecks Sicherheit, Form hin oder her.

Gruß Michael

[derschutzhund]

Hallo wollinche,

du scheinst Ahnung zu haben (im Gegensatz zu mir) aber was soll das bringen, alles neu einzugeben, wenn man nicht weiss, wo das Tor ist???

Wenn die Datenbank mit mySQL gesichert und nachher wieder hochgeladen wird bringt das doch auch nicht viel wenn da der Schädling eingebaut ist oder?

Ich könnte mir die Datenbank ruhig ansehen, würde nix bringen weil ich keine Ahnung davon habe!
Daher könnte ich sie nicht bereinigen!

Das Ende vom Lied wird sein, dass ich alle Infos und alles andere ganz neu eingeben muss und das ist eine extreme Arbeit!
Das müsste ich dann für meine priv. Seite und für meine Schulseite machen!

Wolfgang
 

Entschuldigt bitte wenn ich hier nun einfach so reinplatze.
Ich habe dieses Thema mit interesse gelesen, aber ...

solange wie @derschutzhund nicht seinen komplette Webspace LÖSCHT inclusive der Datenbank
hat er nie Ruhe vor den "Eindringlingen" !!!

Das was du installiert wurde ist gut gemacht, gut versteckt, und immer wieder verfügbar für die "Herren des Servers", die jederzeit wieder die Kontrolle übernehmen können.

Solche Shell-Scripte lassen sich nicht löschen, wer das glaubt - glaubt auch an den Klapperstorch *böse_grins*

Das einzige was bleibt ist das "Einfallstor" eindeutig zu localisieren und dann abzustellen.

PS: solche Scripte werden, zu 99%, über url-Injection oder mysql-Injection, installiert, da würde ich mein Hauptaugenmerk drauf richten.

Nochmals, entschuldigung für mein Einmischen *nett_grins*

[Waldschwein]

Hallo!

Mache doch das was Doc gesagt hat, dabei gehen wenige Informationen verloren, wenn /pages und /media nicht befallen sind (kann man ja schnell durchchecken, dann das machen was doc sagt) auch gar keine. In der Datenbank wird sich eher selten Schadcode einnisten, und die kann man ja weiterhin benutzen, da ist ja alles drinnen.
Aber egal, Doc hat das gut zusammengefasst, besser als ich es kann. 

Gruß Michael

[WebBird]

Ich könnte mir die Datenbank ruhig ansehen, würde nix bringen weil ich keine Ahnung davon habe!
Daher könnte ich sie nicht bereinigen!

Doch. Der DB-Dump ist im reinen Textformat. Dort müßtest Du einfach nach seltsamem "Line Noise" suchen, so wie er in Deinem Einstiegsposting gequotet ist.

Folge der Anleitung von doc. Wichtig ist vor allem die Änderung _sämtlicher_ Kennwörter. _Natürlich_ solltest Du versuchen, die Schwachstelle zu finden, aber ohne Hilfe des Providers kannst Du da lange suchen. 1und1 ist normalerweise technisch recht fit, und bei Goneo - bohren, bohren, bohren. Die reden doch von ihrer großen "Sicherheits-Offensive", dann sollen sie sich gefälligst auch ein bißchen Mühe geben. Damit würde ich argumentieren und nicht nachgeben, bis sie endlich die Schnute aufmachen. Und wenn sie es nicht tun - sofort kündigen! So einen Provider kannst Du dann nicht gebrauchen!

[wollinche]

du scheinst Ahnung zu haben

Mit Sicherheit nicht mehr als die hier anwesenden.

aber was soll das bringen, alles neu einzugeben, wenn man nicht weiss, wo das Tor ist

Das ist das Problem.
Hier ist es gut zu wissen das Sicherheit nicht isoliert betrachtet werden darf.
Ich behaupte es gibt 4 Sicherheitsrelevant e Dinge (über die ein Angreifer reinkommt)
1.) die Sicherheit auf dem eigenen PC (Ohne Trojner/Keylogger, der die  Daten an seinen Herrn versendet)
2.) das CMS als solches mit unsicheren Funtionen/Scripten
3) die verwendeten Module
4) die Sicherheitseinstell ungen Konfiguration des Servers / Provider

Für 1) bist du selber zuständig und kannst prüfen

Für 2) und 3) bist du auf die Sorgfalt der Programmierer angewiesen.
Kein System ist 100% sicher, niemals. Es ist immer ein Wettlauf zwischen Programmieren und Hackern.
Und da niemand weiß was und wo alle in den CMS-Files geändert wurde bleibt hier nur löschen und das System neu aufspielen, auf keinem Fall alte Files auf dem Server belasssen.

Die von  @doc angesprochenen Dateien in /pages müssen vor dem zurückspielen sehr sorgfältig geprüft werden auf veränderungen.
Und dabei auf immer bis zum Ende der Datei Scrollen und im Editor den automatischen Zeilenumbruch einstellen und bis zur linken Fensterkante nachsehen.
(Das sind auch zu tricks etwas in Daten zu verstecken)

Dann die Mysql-Dumps prüfen, auch dazu wurden dir schon alle Hinweise gegeben.
(Wobei das zwischenschalten eines localen Servers (Xampp) ein gutes Hilfsmittel ist.

Und als letztes zu 4). WEnn der Provider dir die ZUgriff-Log nicht liefern kann oder will, kündigen und einen anderen Provider suchen der bessseren Suport und Hilfestellung bietet (im Idealfall kostenlos - die gibt es, kosten aber ein klein wenig mehr, aber sie sind ihr Geld wert)

Ansonsten halte dich an die Beschreibung von @doc, damit solltest du klatkommen.
Viel Glück.

PS: Wenn die v***-Conection ihre Finger im Spiel hat waren es Profis. Im Log müßte für den Angriff immer 2 bis 4 gleichzeitig aufrufe (von unterschiedlichen Domainen) innerhalb von 2,3, Sekunden eingetragen sein. Das ist deren übliche Masche.
Etwas mehr Sicherheit gegen diese Art Angriffe bietet ein Server wo: allow_url_fopen deaktiviert ist.
(Das machen die Provider nicht gerne da oft Code von anderen Servern erwünscht ist z.B. RSS-Feeds)

[Waldschwein]

Hallo1

Ich wollte nur anmerken, dass ich einmal die Seite geprüft habe, sowohl gemerkt habe, dass Schadcode in JS vorhanden ist als auch, dass einige XSS-Einfallslöcher auf der Seite vorhanden sind.
Aber mehr Informationen will ich hier nicht geben, wenn es unbedingt sein soll, dann soll sich derjenige am Besten direkt an derschutzhund wenden, der hat von mir alles was ich herausfinden konnte bekommen.

Gruß Michael

[doc]

Hi,

Die von  @doc angesprochenen Dateien in /pages müssen vor dem zurückspielen sehr sorgfältig geprüft werden auf veränderungen.

Da die Dateien im /pages Ordner immer gleich aufgebaut sind, sollte eine Überprüfung recht einfach sein (3-4 Zeilen PHP Code).

Auch der Hinweis ALLE nicht zu WB gehörenden Dateien zu löschen (Ordner, Unterordner und Dateien) sollte befolgt werden. Eine eingeschleuste .htaccess in einem recht tiefen Unterordner könnte z.B. auch andere Dateien wie z.b. .txt über den PHP Parser schicken. Man kann auch in GIF Dateien PHP Code einschleusen. Wird das Bild dann in bild.gif.php umbenannt oder über .htaccess an den PHP Parser geschickt, wird der sonst nicht sichtbare PHP Code ausgeführt.

Sprich ist das System erstmal komprommitiert, könnte der/die Hacker überall weiteren Schadcode versteckt haben. Mit nem simplen Update von Modulen oder WB Dateien ist es dann in aller Regel nicht getan. Aber das dürfte ja alles bekannt sein.

Doc

[derschutzhund]

Hallo Michael,

inzwischen habe ich folgendes gemacht:
1. meinen PC komplett mit avast 5 prof getestet und was gefunden wurde gelöscht
2. alle Dateien auf den PC gesichert
3. die Datenbank (*.sql) auf den PC gesichert
4. mit FreeCommander sowohl den Link selbst als auch das Script das den Link einträgt gesucht und gelöscht
5. die Datenbank durch gesehen und nichts gefunden
6. KundenPasswort geändert
7. FTP-PAsswort geändert
8. die Daten wieder auf den Space geladen

Der Linke wird aber immer noch im ie8 unten angezeigt!!!

Wo befindet sich das Teil jetzt noch?

Grüße Wolfgang

Hallo!

Mache doch das was Doc gesagt hat, dabei gehen wenige Informationen verloren, wenn /pages und /media nicht befallen sind (kann man ja schnell durchchecken, dann das machen was doc sagt) auch gar keine. In der Datenbank wird sich eher selten Schadcode einnisten, und die kann man ja weiterhin benutzen, da ist ja alles drinnen.
Aber egal, Doc hat das gut zusammengefasst, besser als ich es kann. 

Gruß Michael

[wollinche]

8. die Daten wieder auf den Space geladen

Der Linke wird aber immer noch im ie8 unten angezeigt!!!

Wo befindet sich das Teil jetzt noch?

So wird das niemals was. So wird die Seite immer infiziert bleiben.
ES darf niemals etwas vom Core / Moddule / CMS-SYstem zurückgespielt werden, den in den Dateien findest du nicht alles dazu gibt es zu viele Tricks etwas zu verstecken.

Ich klicke mich nun aus, du willst keinen Rat, du willst deinen Kopf durchsetzen und das führt nicht zu einer sauberen Installation.
*mitleidig_grins*