Hallo JoomlaWunder
Glaube ich nicht, der Formularsatz wird bei der Übergabe ja noch einmal gefiltert und der Haken beeinflusst nur die interne Verarbeitung. Genau genommen ist das im Moment ja auch keine Sicherheitslücke, sondern einfach nur Scripte die die Formulare automatisch ausfüllen und sich dabei geschickt einen Konstruktionsfehler zu Nutze machen. Ausschließen kann man aber letztlich nie etwas. Darum würde ich mir im Moment aber keine Gedanken machen.
Gruß Jan
Moin
Man muss dort an zwei Stellen drehen damit der Haken wirklich verschwindet. Einmal im Formular selbst, und dann noch beim Menüpunkt der das Kontaktformular verknüpft. Wobei der Menüpunkt aber das letzte Wort hat und die Einstellungen im Kontakt selbst übergeht. Nur falls sich jemand wundert warum der Haken bleibt, obwohl man den Kontakt doch geändert hat. 
Gruß Jan
Die Attacken sind extrem agressiv aktuell. Momentan täglich muss ich deswegen Webs sperren.
Kann ich nur bestätigen. Webs deaktivieren ist ein Fass ohne Boden da immer mehr dazukommen.
Nun heult mal nicht rum ihr beiden. So selten wie ihr aus euren Büros herauskommt, würdet ihr bei der Sonne jetzt eh sofort verbrennen und zu Staub zerfallen, wenn ihr einen Schritt vor die Tür wagt. 
Hallo Sebastian
Nein, an der Qualität der Links ändert sich nichts. Nur das Protokoll für die Übertragung wird mit dem "s" für die Verschlüsselung ergänzt. Die Domain und Angabe der Unterseite bleiben prinzipiell ja auch die gleichen.
Gruß Jan
Es geht einfacher. Die Hacks beziehen sich normalerweise nur auf Dateien und maximal zusätzliche erstellten oder veränderten Benutzeraccounts mit Zugang zum Backend. Die Inhalte der Datenbank selbst bleiben eigentlich "verschont".
Du kannst also hergehen und das Joomla mit seinen Komponenten "nachbauen" und dann die "alte" Datenbank damit verknüpfen. Wichtig ist hierbei allerdings, dass du alle wichtigen Zugangsdaten änderst und genau überprüfst wer dort in das Backend kommen kann und ob der Account wirklich diesem Benutzer gehört. Am besten aber auch dort allen Anwendern mit Zugang zum Backend neue Passwörter erstellen und zusenden.
Problematisch ist es halt bei den Dateien, dass man nicht aus Versehen doch eine kompromittierte PHP oder das manipulierte Gif erwischt, mit dem der Hack damals gestartet wurden.
Bei PHP-Dateien ist es klar, die kann man per Filter aussortieren und überhaupt nicht erst anzeigen lassen (Test auf Plausibilität / PHP und JS gehören nicht in ein Image-Verzeichnis).
Bei Bildern kannst du dir diese auf deinen heimischen Rechner übertragen und dort im Verzeichnis als kleine Vorschaubilder anzeigen lassen. Alles was keine Vorschau produziert, wird hierbei mit höchster Wahrscheinlichkeit auch kein Bild sein, sondern z.B. eine PHP-Shell mit bewusst falscher Dateiendung, die später per htaccess ausführbar gemacht werden soll.
Gruß Jan
Hallo Tom
Mit einem Zugang zum FTP (Seite und Logdateien) könnte ich schauen ob dort eventuell Schadcode hinterlegt wurde der nun zu diesem Problemen führt. Bei einem Kunden hatten wir beispielsweise Abfragen zu einem Wordpress drin, die beim vorhandenen Joomla natürlich nicht funktionieren konnten, aber für einen stark verzögerten Seitenaufbau gesorgt haben. Das wäre jetzt noch so eine Idee die bei deinem Problem "passen" könnte.
Grundsätzlich müsste dann aber eigentlich auch deine Kopie bei einem anderen Anbieter langsam laufen, da diese fehlerhaften Anfragen an die Datenbank mit übernommen worden wären.
Gruß Jan
Da kann ich mich Flotte nur anschließen. Gute Karten hat man eigentlich immer dann wenn nach einem Hack nicht mehr viel an einem Projekt gemacht wurden. Dann ist es möglich per Software nach geänderten Dateien zu suchen und diese mit dem Log zu vergleichen So kann man sich von einer Manipulation zur nächsten "hangeln" bis man schließlich beim eigentlich "Hack" und der Schwachstelle im System angekommen ist.
Wurden aber zwischenzeitlich Arbeiten an einer infizierten Seite vorgenommen, am besten noch in Form von irgendwelchen Updates, dann verwischt man die Spuren und es bleiben nur noch zwei Optionen übrig...
1. Backup von einem Zeitpunkt einspielen, an dem die Seite ganz sicher noch nicht infiziert war. Und wenn das nicht möglich ist...
2. Das Projekt "sauber" und von Grund auf mit den gleichen Erweiterungen "nachbauen" und dann die Inhalte manuell übertragen. Am besten von Hand und mit einem Filter der wirklich nur Bilder, PDF und andere "sichere" Dateien übernimmt die nicht betroffen sein können. Macht relativ viel Arbeit, aber man kann recht gut ausschließen das man sich Dateien einhandelt die dort nicht hingehören und die als Hintertür zum System fungieren sollen.
PS: Als eines der wenigen kostenfreie Programm die für die Suche auf einem Server geeignet sind, ist beispielsweise "FileZilla". Dort kann man eine ganze Reihe von Filtern setzen die die Suche auf bestimmte Dateitypen, Zeiträume und Verzeichnisse beschränkt.
Gruß Jan
Ich glaube das der Server so schlecht konfiguriert ist, dass nicht mal Schadcode vernünftig läuft...
Wobei es bei Schadcode manchmal aber auch echte "Perlen" zu finden gibt. Einmal kam mir z.B. ein wirklich gut gemachter Datei-Manager über den Weg, der schlanker und umfangreicher als der eXplorer war. Ich sehe schon Flotte in seinem Joomla-Schadcode-Giftschrank wühlen, um zu schauen was davon auch unter Windows laufen könnte...*g*
Ich würde in diesem Kontext keine langen Diskussionen führen sondern die betroffenen Seiten einfach zu einem anderen Anbieter umziehen. Das ist mit Akeeba Backup schnell erledigt.
Gruß Jan
Naben zusammen
Heutige Erweiterten bringen doch praktisch von allein etwas mit, werden bereits von Plugins oder Modulen ergänzt die sich automatisch mit installieren.
Stell dir vor jemand hat eine Frage zum vermeintlichen Modul, er stellt sich aber heraus das es wahrscheinlich an der Komponente selbst liegt, die Moderatoren sollen verschieben. Dann plötzlich Laufe der Fehlersuche kommt eines der Plugins in Verdacht, also wieder eine Kategorie weiter. Und zum krönenden Abschluss war es dann in Wirklichkeit ein fehlerhaftes Override im Template.
Da blickt spätestens bei der zweiten Wende kein Mensch mehr durch und Bookmarks auf einen Thread kann man auch vergessen. Dann lieber gesammelt unter "Erweiterungen" und das mögliche "Chaos" bewegt sich in sehr engen Grenzen.
Gruß Jan
Hallo SilOrs67
Sorry, hatte überlesen das es sich um eine "externe" Diskussion handelt. Die hier genannten Argumente (plus die aus dem anderen Forum) sollten aber locker ausreichen um deinen Standpunkt entsprechend zu vertreten.
Gruß Jan
Hallo SilOrs67
In dem von Indigo66 verlinkten Beitrag ist eigentlich alles Wichtige gesagt was man zu diesem Thema wissen sollte!? Aber ok, man kann es bestimmt etwas konkreter auf den Punkt bringen.
Viele Anwendern (egal welcher Software) streben bei ihren Bemühungen als ultimatives Ziel an, dass es "läuft", irgendwie. Und genau das ist der ultimative Fehler in Bezug auf Software die direkt am Internet hängt und die Sicherheitsrelevant ist. Denn hier ist das Ziel nicht das es "irgendwie läuft", sondern das es "sicher läuft"!
Damit das gewährleistet ist musst du von der Materie mehr Ahnung haben als die Angreifer die versuchen werden deinen Webserver für ihre Zwecke zu kapern. Und glaub mir, die Kerle sind wirklich clever was das betrifft. Also nicht nur in Hinblick auf den Webserver, sondern ebenso im Zusammenhang mit der Konfiguration insgesamt und möglichen Schwachstellen die sich damit ergeben.
Aber allein schon die Frage ob sich XAMPP für einen Webserver eignet sagt ganz deutlich - und nimm das bitte nicht persönlich - das du von der Materie keinen blassen Schimmer hast. Dies dann gepaart mit einem kleinen Schuss "Uneinsichtigkeit" und der Nachfrage, ob sich nicht vielleicht doch noch jemand meldet der deinem Vorhaben die Absolution erteilen könnte, ist eine bekannte Mischung die schnell zum Hack führt.
Wann wäre denn ein Root-Server etwas für dich? Wenn du Linux nicht nur zufällig von einer Heft-CD kennst, sondern wirklich im Schlaf, allein über eine Shell installierst, pflegst und im allgemeinen administrierst. Ganz ohne Klicki-Bunti oder Maus. Wenn du täglich die aktuellen Security-Newsletter noch schnell vor dem Zubettgehen sichtest und auf mögliche Treffer mit deinem System vergleichst. Wenn du die wichtigsten Textdateien für deine Konfigurationen kennt und weist wo du diese im System findest und wie man sie editiert. Ach ja, und wenn du natürlich masochistisch genug bist mehr Zeit in die Pflege und Aktualität deines Server zu investieren, als in die Seiten die dann darauf laufen. Jepp, dann könntest du mit einem eigenen Server wirklich glücklich werden.
Gruß Jan
Hallo
Dann steige ich hier einfach noch mal ein. Du hattest ja geschrieben das eine Kopie deiner Seite bei dir lokal auf dem Computer läuft. Nimm die mal bitte schau ob sich das Problem bereits auf Joomla und seine Datenbank bezieht oder eventuell doch ein anderer Bestandteil quer schlägt.
Deshalb bitte...
- auf ein Standard-Template von Joomla umschalten.
- alle Module ausblenden und Plugins deaktivieren die zusätzlich installiert wurden.
- Komponenten die in den Seitenaufbau eingreifen könnten bitte ebenfalls abschalten.
- Caches abschalten, SEF in der Joomla Konfiguration deaktiveren und bitte die original htaccess von Joomla selbst aufspielen.
- Browser-Cache löschen und das Projekt neu laden lassen.
Ist der langsame Seitenaufbau dann noch immer vorhanden über Joomla versuchen die Datenbank zu reparieren. Zusätzlich könntest du auch hier den ACL-Manager noch einmal wegen der Assets drüber laufen lassen. Der sollte bei einer lokalten Kopie nicht abbrechen, da der Webserver hier ja aus dem Vollen schöpfen kann.
Ändert sich nichts scheint es wirklich ein größeres Problem zu sein. Lädt die Seite nun aber schnell, kannst du schrittweise die einzelnen Elemente zuschalten und den Fehler damit eingrenzen.
Ich persönlich vermute das hier ein Bestandteil im Hintergrund aktiv ist, der die auszuliefernden Inhalte umsortieren soll und das daraus die vielen Anfragen an die Datenbank resultieren.
Gruß Jan
Hallo zusammen
Jetzt habe ich mir tatsächlich nur für diese Sache hier einen (privaten) Account angelegt. Denn das was hier mit Flottes sachlicher und durchaus berechtigter Frage passiert, liegt quasi auf dem gleichen Niveau wie die Geschichten im Joomlaportal zu seinen schlechtesten Zeiten. Themenschließungen allein aus dem Grund heraus das… (Vorsicht überspitzt!)
a) … unangenehme Themen angesprochen werden.
b) … Verantwortlichen mit entsprechenden Rechten im Forum die Argumente ausgehen.
c) … es eventuell finanzielle Interessen tangiert und man besser keine Risiken eingehen möchte.
d) … man der Meinung ist das letzte Wort für sich zu beanspruchen und weil man es halt „kann“.
Sorry, wenn Ihr etwas besser machen wollt als das Joomlaportal - und daran meine ich mich durchaus zu erinnern - dann seid ihr gerade auf dem besten Weg es zu verfehlen. Und das wäre äußerst schade nach dem klasse Start.
Sachlich betrachtet hat es große Hoster wie 1&1 noch nie interessiert ob eine Community wie die von Joomla Unterstützung gebrauchen konnte. Man nahm (meiner Meinung nach) ganz bewusst alles andere als optimale Einstellungen auf den Servern in Kauf, um letztlich mehr zahlende Kunden auf die Hardware zu bekommen. Denn genau diese Einstellungen haben zu den allseits gern gesehenen Rechte-Problemen bei all jenen Dateien und Verzeichnissen geführt, die von Joomla oder einen anderen CMS erstellt wurden. Denn „optimierte Hoster“ tun eigentlich nichts anderes, als die „richtigen“ Werte zu setzen und damit im Sinne des Kunden auf Gewinn zu verzichten.
Passend dazu habe ich aber noch nie einen Mitarbeiter aus dem 1&1 Support in den Joomla-Foren gesehen, der nennenswert positiv in Erscheinung getreten wäre!? Die „kleinen“ Hoster hingehen, kommen zusammen auf viele 10.000+ Postings in denen wirklich aktiv Fehler gesucht und behoben wurden. Und zwar auch dann, wenn die Hilfesuchenden bei jenen großen Anbietern waren, die heute der Meinung sind, sich einfach ein neues Image kaufen zu können.
Woran man sich jetzt mutmaßlich stört? Allgemein könnte man die ganze Geschichte wohl unter dem Stichwort einer gefühlt fehlenden Loyalität einsortieren. Natürlich sind Events wie der JoomlaDay kostspielig und müssen aus einer ausreichend gefüllten Kasse beglichen werden. Aber deshalb gleich seine Seele zu verkaufen kann wohl kaum Sinn der Sache sein. Denn gleichzeitig mit der erfolgreichen Finanzierung des JoomlaDay spielt man all jene Anbieter an die Wand, die sich über Jahre hinweg konkret mit kostenlosen Support eingebracht und nicht nur die Marketingmaschine angeworfen haben.
Der Logik nach zu urteilen wird der nächste Hauptsponsor wahrscheinlich Artisteer sein und man wird indirekt verkünden das - nach einer ausreichen großen Spende und anschließender Absolution versteht sich - die Software genau genommen doch klasse ist um sich ein Joomla-Template zu erstellen. Klingt jetzt vielleicht furchtbar böse, aber es ist genau das gleiche Schema das bei den Lesern ankommt.
Das es Thomas unumwunden und ehrlich auf den Punkt gebracht hat rechne ich ihm hoch an. Und auch das David ebenso ehrlich versucht hinter den Kulissen sachlich zu vermitteln muss man ganz deutlich hervorheben. Nur ändert es eben nichts daran, dass man im Tausch für das „Joomladay Dinner / Joomla Geburtstagsparty“ anderen Personengruppe langfristig der Hahn zugedreht wird, weil man eben indirekt (und bestimmt nicht einmal gewollt) Partei ergreift. Und ich denke das es im Punkt genau um diese Sache geht.
Kurzer Nachtrag: Mit dem oben geschriebene möchte ich Niemanden persönlich angreifen. Nur aufzeigen das auf den ersten Blick harmlose Entscheidungen deutlich weitere Auswirkungen haben können als man vielleicht im ersten Moment denkt. Also bitte nicht übel nehmen.
Gruß Jan
