Hallo Elwood,
die Sache ist erledigt. Manuell bin ich nicht an das Ziel gekommen und alle gelesenen Anleitungen im Web gehen nicht mit 4.3.2 konform. Die Lösung war Advanced Google Analytics. In der ZIP-Datei ist auch die Version für 4.x enthalten. Das Problem saß wie so oft vor dem Rechner. 
Danke Euch nochmals.
Wolfgang
Hallo Elwood,
die Seite ist nun in der entsprechenden Domain www. ds-transportservice.de online. Will nun Google Analytics einbinden. Da habe ich beider Version 4.3.2 echt ein Problem. Wohin mit dem Code? Wollte kein Plugin einbinden. Wenn es nicht anders geht, dann welches?
Gruß
Wolfgang
Hallo Elwood, muss ich mir anschauen. M. E. habe ich den doch genommen. Kannst du da 3 Sätze mehr sagen? Was OSM anbelangt kann ich noch nichts zu sagen. Mit externen Plugins bin ich immer sehr vorsichtig.
Gruß
Wolfgang
Hallo Elwood,
herzlichen Dank dir 
. Der Ansatz war der richtige. Hatte den Kategorie Blog noch nie benutzt. Kämpfe noch mit der Sortierung. Dann passt es! Schau mir später noch OSM von Astrid an (Astrid Günther ? )
Seite ist online!
Gruß
Wolfgang
Sortierung auch erledigt!
Gruß
Wolfgang
Hallo Elwood,
ok, ich mach das dann mal. Seite ist online: ita-testdrive.de. Ist sozusagen Halbfertigungserzeugnis 
Gruß
Wolfgang
Zunächst Euch ein freundliches Hallo!
War lange nicht hier (lasst mich rechnen) - müsste 9 Jahre her sein. Joomla ist jung und ich inzwischen alt 
. Wie der Teufel es will, muss ich doch nochmals eine neue Seite aufsetzen. Zu Beginn hat es etwas geholpert, aber inzwischen geht es wieder flott von der Hand. Bei CSS bin ich allerdings mehr am Lesen wie am Schreiben. Aber zur Sache:
Ich möchte möglichst ohne externe Erweiterungen auskommen. Das erspart erfahrungsgemäß viel Arbeit beim Update, welches ich über die Jahre in der 3er Version ja häufig noch machen musste. Aufgelegt habe ich jetzt die Version 4.3.2 mit dem Cassiopeia Template. Nun habe ich einige kurze Fragen:
So viel geschrieben und hoffe Ihr lasst den alten Mann nicht hängen 
Gruß
Wolfgang
Hallo Euch,
Das Problem von Wolfgang ist gelöst
Chris gebührt ein ganz großes Dankeschön. Ohne Chris seiner Hilfe wäre das nicht zu machen gewesen. Es ist mit Sicherheit keine Werbung, aber bei Chris ist man gut aufgehoben. Kompetent, schnell und zuverlässig.
Nochmals Dank Euch allen. Ich bleibe dem Forum sicher treu!
Gruß und jetzt mal schon frohe Festtage
Wolfgang
Hallo,
Das sind einfache Brut Force Versuche, denen man mittels eines Verzeichnisschutzes (htaccess) in /administrator entgegnen kann. Das ist äußerst effektiv, und schont die Serverlast.
Nur zur Info: Seite ist in professionellen Händen und das ist gut so! Man darf sich nicht scheuen zuzugeben, dass man die eigenen Grenzen erreicht hat. Das ist gut so und konsequent! Es wird dazu sicher noch ein Info geben. 
Gruß
Wolfgang
Hallo Euch,
Gar nicht ungewöhnlich über einen so langen Zeitraum.
Aber nicht, wenn der einzige Zugang zum System der Admin-Bereich ist. Es folgen ein paar Tage später 3 Fehlanmeldungen in der Minute und das über Stunden. Des weiteren weiß ich, wann ich mich in etwa angemeldet habe. Natürlich kommt es vor, dass ich mich auch einmal irre und ein falsches PW verwende. Bleibt immer noch die Frage nach der Beschränkung der maximalen Fehlanmeldungen und eines Sicherheits-Logins. Naja, ich denke am Montag sind wir schlauer 
Gruß
Euch
Hallo David,
...und das ist beim Thema Sicherheit schlicht unakzeptabel.
Das sehe ich auch so und bin beruhigt, wenn Ihr so denkt! Danke!
Gruß
Wolfgang
Hallo Euch allen zu später Stunde!
Hat meiner Meinung nach nichts mit einem Hack zu tun, sondern eher mit einem Spambot etc. Wenn da was gelöscht wurde, wurde das vermutlich durch das Easybook bereinigt. Ich glaube Viktor hatte da was verbaut damit nicht jeder Müll erscheint. Hab mit dem Easybook aber auch schon ewig nichts mehr gemacht, da Gästebücher out sind.
Da hast Du komplett Recht, denn ich bin fündig geworden nach Auswertung der "error.php", die die Anmeldungen protokolliert. Ich denke, es ist ein klassischer und erfolgreicher Wörterbuchangriff auf den Admin-Account. Der Angriff erfolgte über mehrere Tage. Das Protokoll füllt eng beschrieben 1921 A4-Seiten und besteht aus 63.374 Einträgen. Begonnen hat es am 2.7.2014. Die Anmeldeversuche fanden faktisch im Minutentakt statt.
2014-02-07T19:54:02+00:00 INFO joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
2014-02-07T19:54:04+00:00 INFO joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
2014-02-07T19:54:07+00:00 INFO joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
2014-02-07T19:54:09+00:00 INFO joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
2014-02-07T19:54:13+00:00 INFO joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
2014-02-07T19:54:16+00:00 INFO joomlafailure Benutzername und Passwort falsch oder das Benutzerkonto existiert noch nicht!
Das Passwort bestand aus Groß- und Kleinbuchstaben gemischt mit Zahlen und umfasste 8 Zeichen. Sonderzeichen waren ja in 2013 nicht möglich. Ob das heute geht, entzieht sich meiner Kenntnis. Überrascht bin ich allerdings, dass dies überhaupt möglich ist und Joomla keine Sperre nach einer bestimmten Anzahl von Anmeldeversuchen vorsieht. Die 2 Komponentenauthentifizierung könnte da sicher Abhilfe schaffen. Das wäre dann ein "Muss"!!! Für User ohne Smartphone ist das natürlich ein Problem (soll es ja noch geben). Es muss also noch eine Notvariante eingebaut werden. Soviel erst einmal dazu. Ich will sehen, wie es weiter geht. Ich denke, irgendwo ist noch ein versteckter Zugang eingerichtet, wenn das System das hergeben sollte. Für einen Profi dürfte das kein Problem sein. Dennoch muss ich dem Angreifer erst einmal den Draht durchschneiden! Hab noch paar Stunden Schlaf. Vielleicht fällt mir im Traum was ein!
Gruß Euch
Wolfgang
Ok, Ok,
Joomladummy geht in sich, David hat die "rote Linie" vorgegeben und nun können wir das abschließen, denke ich! Geht mich eigentlich ja nix an und habe mit der Seite genug Probleme, um die ich mich kümmern muss. Aber David, es ist wie im Leben: wenn etwas falsch ist, ist es besser es zu kommentieren, wie zu "löschen oder auszublenden". Der Lernprozess ist dann für alle einfacher! 
Der wäre in welcher Tabelle mit welchem Inhalt ?
Es ist ein Eintrag in Zeile 191 der Tabelle von easybook (Gästebuch), in dem die Kundenbewertungen abgegeben werden. Ich habe die Tabelle exportiert und der Eintrag zeigt ein ganz merkwürdiges Verhalten. Es sind mehrere leere Zeilen vorangestellt, was nur bei Erweiterung der Spalten sichtbar ist. Diesem Eintrag hat etwas vorangestanden, was dann gelöscht wurde.
Kann mich natürlich auch irren!
Gruß
Wolfgang
Hallo und danke erst einmal für die Beiträge zum Thema. Im Übrigen müsst Ihr "Joomladummy" ja nicht gleich so zur Schnecke machen. Jeder hat oder macht Fehler und keiner ist vollkommen. Etwas Nachsicht wäre angebracht, denke ich.
Zum Thema verweise ich auf eine Seite, die sich dem Problem annimmt und die ich sehr gut finde. Ihr findet Sie unter "https://www.erich-kachel.de/sql-injections/" (Link einfügen funktioniert leider nicht mit Edge, wie es ausschaut)
Eine Woche konnte ich mich nicht mit dem Thema beschäftigen. Jetzt muss eine Lösung her. Um dies nochmals auf den Punkt zu bringen: mir ist schon klar, dass der Hack nicht nur aus einer veränderten Datei besteht. Das System ist durchsetzt von Fremdcode in Dateien und sicherlich auch irgendwo mit Java-Skripten wie auch einem Eintrag in der Datenbank. Das ist aber noch nicht alles. Es wird gleichzeitig beim User, der die Seite besucht, ein Trojaner nachgeladen. Ich bin da nur im Ergebnis einer lokalen Installation des System darauf gekommen. Norton schlägt sofort bei lokalen Aufruf der Seite an und entfernt die Datei im Windows-Cache: "Name der Bedrohung: Trojan.Malscript!htmlVollständiger Pfad: c:\users\xxxxxxxxxxx\appdata\local\packages\microsoft.microsoftedge_8wekyb3d8bbwe\ac\#!001\microsoftedge\cache\aswzn4lt\xxxxxxxxxxxxxxxx[1].htm" Ganz gleich, welche Seite lokal aufgerufen wird, es wird ein "Duplikat"[1] mit dem Trojaner hinterlegt. Theoretisch, muss der Code irgendwo in der Struktur stecken, da dies ja offline geschieht. So macht das Ganze auch Sinn! Dazu ist die Seite allgemein zu unbedeutend, um sie nur lahm zu legen. Der Nutzen des Hacks liegt im Trojaner! "Webworker" hat Recht: Ich suche nicht, denn ich bin kein Profi für so einen speziellen Fall und ich meine, am Ende läuft es auf das Gleiche hinaus. Deshalb setze ich die Seite einfach neu auf (3.6.4). Sollte sich dennoch ein Mutiger finden, kann er mich ja gern anschreiben.
"Walddorf & Städtler": Genau so wird es gemacht
Jan, stell dir die Seite gern als "Offlinepaket zur Verfügung", wenn ich fertig bin. Als Schulungsmaterial, sozusagen . Geändert ist da nix. Updates natürlich schon.
Gruß Euch
Wolfgang
Hallo "hechtnetz" und Christiane,
danke Euch für die Informationen. Ladys first: Christiane, dann gehe ich davon aus, dass es einen administrativen Zugang zu dem System gegeben hat, denn zu TinyURL wird ebenfalls Bezug genommen. Ich sehe das wie "hechtnetz", das System ist aus meiner Sicht nicht mehr zu retten und der Aufwand den Fehler auszumerzen (was sicher kaum möglich ist), ist eh größer, wie das System komplett auf Basis 3.6.4 neu aufzusetzen. Es ist schon erstaunlich, welchen Aufwand die Herren oder Damen betrieben haben.
Beispielsweise habe ich noch einen gut versteckten Eintrag in der "index.php" im Stamm-Verzeichnis gefunden. Versteckt insofern, dass sich der Code ganz am rechten Ende der Seite nach <? php anschließt und dann nach vorgestellten Leerzeichen (dadurch ist er nicht sofort sichtbar) die Anweisung mit eval(base64_decode("aWYgKCFkZWZpbmVkKCdBTF........ beginnt. Der anschließende einzeilige, verschlüsselte Code ist ewig lang. Er füllt fast den ganzen Bildschirm. Nach meiner Kenntnis hat "eval" die Aufgabe zu decodieren und php-Skript auszuführen.
Das Problem ist eigentlich die Datenbank. Auf die Formulareinträge kann ich verzichten, aber die Kundenbewertungen muss ich erhalten. Ich denke, die Tabellen kann ich nach Fertigstellung in die neue Datenbank einlesen. Inzwischen habe ich beide Systeme unter xampp am laufen (die gehackte und die 3.6.4 Version). Ich beginne die Seite so neu zu spiegeln. Es ist zwar aufwendig aber sicher. Sorge habe ich natürlich: da sie die Seite jetzt kennen, werden sie es wieder versuchen!
Einen Vorteil bringt es: Ich beschäftige mich seit langer Zeit wieder mit Joomla!
Gruß und gute Woche
Wolfgang
Hallo Christiane,
danke für den Hinweis und den Link. Habe mir das so in etwa schon gedacht. Hätte mich auch gewundert.
Gruß
Wolfgang
Hallo Chris,
ich meine schon rein beim Betrachten der Seite wird der Schadcode ausgeführt und an den Browser des Betrachters übermittelt, wenn er einmal in der Datenbank abgespeichert ist. Wie er in die index.php kommt tappe ich selbst noch im dunkeln. Ich gehe davon aus, dass ein js.Script nachinstalliert worden ist. Wenn er die Rechte erlangt hat, ist das doch kein Problem. Jedenfalls wird der oben genannte Eintrag auch nach dem Löschen wieder in die Datei geschrieben. Bin da auch nicht so ein Experte und arbeite mich Schritt für Schritt vor. Parallel habe ich ein sauberes 3.6.4 mit zwei Faktoren Authentifizierung aufgesetzt. Alles weitere geschieht hier local. Obwohl ich beispielsweise zum Test die Dateien 404money.php und Money.php gelöscht hatte, zeigen die log. Dateien des Servers (Provider) das verschieden Befehle ausgeführt werden (mkdir, creat etc.) und die Dateien werden wieder angelegt, ohne dass ich auf die Seite zugreife. Ich kann deine Annahme aber bestätigen, das der Hack schon eine Weile zurückliegt. Eine Bereinigung wurde auch nicht vorgenommen, sondern erst nach Providermail Anfang 2016 ein Update vorgenommen. Das dies über eine kompromittierte Installation erfolgt ist, davon hatte ich natürlich keine Ahnung. Einen verdächtigen Eintrag habe ich heute in der SQL-DB in 2014 gefunden. Dem gehen wir gerade nach. Wie meinst du das, mit ....mitgeschliffen? . Das Ganze ist mir jedenfalls noch nie untergekommen, obwohl ich schon paar Jahre auf dem Buckel habe.
Sag, gehört TinyURL eigentlich zur Standardinstallation von Joomla?
Gruß
Wolfgang
Nochmals in der Sache...
Leider zu früh gejubelt. Die Seite lief nur kurz ohne Probleme. Danach war der alte Schad behaftete Zustand wieder da. Alle Backups (STRATO) nützen nichts, da offensichtlich der Hack schon lange implementiert ist. Man sucht sich ja nicht selbst bei Google und so blieb die Sache bis zum Zeitpunkt der Kundeninformationen im Verborgenen.
Nachdem ich mich etwas intensiver damit beschäftigt habe, bin ich sicher, dass es sich nur um einen klassischen Fall von „SQL-Injection“ handeln kann. Als Einfallstor kommen eigentlich aus meiner Sicht nur folgende Faktoren in Betracht:
1. Lücken in Joomla selbst
2. Verspätet Updateinstallation, zum Schließen der Lücke (leider versuchen Kunden oft einen Wartungsvertrag der Seite auszuschließen)
3. Dritt-Module, die hier im speziellen Fall wären:
Aufgrund des Musters des Angriffes, kann sicher der ARI Imagesslider ausgeschlossen werden. Durch die hexadezimale Codierung des Schadcodes schließe ich darauf, dass es sich nur um eine persistente oder nicht persistente „SQL-Injection“ handelt. Ich vermute deshalb Lücken in BreezingForms oder Easybook Reloadet. Entweder war es möglich den Schadcode direkt anstatt des Gästebucheintrages in der Datenbank durch eine XSS-Lücke zu speichern (persistente Injection) oder mit dem Formular wurde Schadcode an mich und einen zweiten User mit höheren Rechten gesendet. Allerdings hätte wir dann noch eine speziell präparierte Website besuchen müssen.
Meine Fragen sind deshalb:
1. Welche von den Joomlaentwicklern geprüften Alternativen gibt es zu den 3 genannten Modulen.
2. Erfolgt generell eine Prüfung von Drittanbieter-Modulen, die hier im Forum empfohlen werden?
3. Ist es möglich, die Datenbank zumindest in Teilen noch zu verwenden und wer würde das zu welchem Preis ausfiltern (Einträge Gästebuch mit Leistungsbewertung)
4. Macht es Sinn, SSEQ_lib unter Joomla für eine zusätzliche Prüfung aufzusetzen (kenne das von xtc_modified)
Für Eure Mithilfe wäre ich sehr Dankbar.
Gruß
Wolfgang
Hallo Anka,
da gebe ich dir natürlich voll Recht. Die Frage ist mehr, ob Kunden auch einen Wartungsvertrag abschließen. Für die eigene Seite mag das sicher gelten, für letzteren Fall aber weniger. Es ist dann eine Kundenentscheidung und dieser trägt auch das Risiko und die Kosten!
Gruß
Wolfgang
E R F O L G !!!
Danke Euch für die rege Anteilnahme und Hinweise. Ganz klar ist mir noch nicht, wie der Zugriff auf die Seite erfolgen konnte. Offensichtlich aber geschehen, als die ältere Version noch installiert war. Meine Vermutung geht in Richtung Joomla-Cache. Wie bereits geschrieben, wurde ständig eine money.php nach Aufruf der index.php über einen entsprechenden Eintrag kreiert. Die Quelle war die wp-sys.manager.php im ARI Images-Slider-Verzeichnis. Diese schaltete eine 404.money.php in das Startverzeichnis und leitete dann um. Gleichlautende Sites konnten noch im Template-Verzeichnis festgestellt werde. Die Seite läuft wieder schnell und stabil. Link sende ich gern. Aber ich denke, dass ist hier nicht erwünscht.
Neu sitzt jetzt die 3.4.8 auf dem Server. Laut Joomla ist das die aktuelle Version obwohl ja eigentlich die 3.6.4 raus ist. Verstehe ich nicht ganz. Sollte ich noch aktualisieren? Wie ich aber gelesen habe, gibt es Probleme beim Einspielen des Updates.
Danke und Gruß
Wolfgang
Hallo Frank,
danke für die "Lösungsvorschläge"!
Aber ein Problem einfach aus der Hand zu geben, nur weil die Lösung nicht gleich in Sichtweite ist, war noch nie mein Ding. Ich bin sicher, dass ich das löse. Im Notfall bleibt dein erster Vorschlag. Der läuft ja nicht weg! Erst einmal sind alle Zugangsdaten geändert. zweitens, versuche ich noch ein saubere Backup zu bekommen. Ich denke, das Tor ist im ARI - Systemmanager. Ich melde mich, wenn ich die Schwachstellen identifiziert habe. Das sollte mein Kopf noch hergeben
Gruß
Wolfgang
Hallo Frank,
noch etwas vergessen. Dazu passend liegt im Rootverzeichnis eine 404-Seite (404.money.php). Die habe ich da noch nie gesehen und taucht auch in keiner der Sicherungen auf. Ich denke, eine scripseitige Umleitung, die diese Seite erzeugt. Für den Server war es das dann 
.
Gruß
Wolfgang
