hack? links nach google-recherche leiten auf jahoo-japan weiter

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

Mein Tipp: Google mal nach Dienstleistern, die sich auf die Wiederherstellung gehackter Seiten spezialisiert haben. Die haben deine Installation vermutlich schnell und kostengünstig wieder sauber - das ist etwas, das viel Erfahrung und Fachwissen erfordert, das selbst der ambitioniertes Normaluser naturgemäß nicht hat.

ITA-Marketing ich verstehe nicht was Du da treibst. dachtest Du wirklich so ein Hack besteht nur aus 1-2 Dateien ? Da werden etliche Backdoors abgelegt wenn Du Pech hast. So was muß vernünftig bereinigt werden. In der Zeit wo Du rätselst, hättest Du was anderes tun sollen wie ZB Geld verdienen.

Lass da wen ran der weiss was er macht.

Evtl. etwas OT, aber @ITA-Marketing bezieht sich merfach darauf:
Schadcode in der Datenbank. Wissende mögen mich bitte korrigieren.
1. Manipulierte oder zusätzliche PHP-Dateien != Schadcode in der DB
2. Wo soll derartiger Code in der Datenbank liegen, wenn überhaupt möglich? IMHO doch dann schon als PHP-Skipt in den Tabellen mit den Beiträgen (zzgl. Kommentaren) oder Menüeinträgen. Wenn ich ihn dort unter Umgehung von Editoren plaziere, dann kann er beim Laden eines Beitrages ggf. zur Ausführung kommen? Ich las hier bisher aber, dass Derartiges noch nicht bekannt ist.
Wo irre ich / was übersehe ich?

Da wird kein Schadcode in der db liegen. Das hatte ich bisher bei Joomla erst ein Mal und da waren es lediglich n paar Sexlinks die vermutlich von Hand in einem Beitrag eingegeben wurden. Was ich bisher hatte war, das eine Tabelle angelegt wurde. Die war jedoch leer und wurde von mir entfernt.

Die Seite wurde einfach nicht ordentlich bereinigt.

Zitat von hechtnetz

Ich las hier bisher aber, dass Derartiges noch nicht bekannt ist.

Richtig ist, dass es sehr selten ist/war, dass DB betroffen und das auch so geschrieben gehört.

Ich habe aber seit der letzten Lücke den Fall gehabt. (Und früher bereits schon mal, aber ganz andere "Technik".)

Schadcode muss nicht nur PHP-Code sein. Kann ja auch JS in Beiträgen sein. Ebenso können von Hacker neu angelegte, veränderte Beiträge Spamlinks, Redirects u.ä. enthalten. Oder das Joomla hat Erweiterung, die einfügen und ausführen von PHP-Code in Beiträgen möglich macht. Und/oder... Diese Codes liegen dann nat. in der Datenbank.

Es hängt vom individuellen Joomla und "Joomla-Schlauheit" des Hacker ab, ob man diese Hacks als dramatisch oder nicht betrachten will, nachdem die "echten" Lücken webspaceseitig beseitigt wurden und Zugänge abgesichert.

Im momentanen Fall war er/sie nicht allzu schlau. Ich hätte mehr draus gemacht

Zitat von Webworker Berlin

Die Seite wurde einfach nicht ordentlich bereinigt.

Das kommt bei @ITA-Marketing jedenfalls dazu, ohne, dass ich die Seite sehen müsste...

Lass mal https://sitecheck.sucuri.net/ drüberlaufen.
Wie schnell bei einem Hack professionelle Hilfe nötig ist finde ich schon erstaunlich
Wenn auf dem Server der securitymod läuft dürfte eine weitere Schwachstelle sicher sein. Kann natürlich durch Drittanbietersoft sein, nur ohne geht es fast nicht. Ich vermute auch ein Javascript. Leider wird immer mehr davon verwendet obwohl es nicht wirklich notwendig wäre.
Weiteren Hack gefunden. POST /components/com_joomgallery/views/downloadzip/search.php
Falls einer die Componente benutzt.

@joomladummy
Ich verlink mich mal ausnahmsweise selber, bevor noch jemand auf deine "genialen Tipps" und deine "Fachkompetenz" reinfällt.
Webseite gehackt, Script wird in template eingefügt

Du hast immer noch nicht kapiert, dass du weiter irgendwelche Dateien melden kannst, die bei dir rumdümpeln, ohne, dass damit die eigentliche Lücke geschlossen werden könnte.

Dass du jetzt auch noch versuchst einzelne Komponenten madig zu machen, nur, weil du in diesen Ordnern was gefunden hast, was andere wegen einer von DIR nicht geschlossenen Lücke hochladen konnten, läuft bei mir unter Rufmord, noch dazu, weil in ähnlichen vielenvielen Threads schon mehrfach hingewiesen wurde, dass das kein Kriterium ist und du es wissen könntest.

DUU bist die Lücke in deinem System, Troll.

Zitat von joomladummy

... Ich vermute auch ein Javascript. Leider wird immer mehr davon verwendet obwohl es nicht wirklich notwendig wäre.

Keine moderne Webseite kommt ohne JavaScript aus. Versuch mal, deine Seite ohne aktiviertes JScript zu laden und staune, was alles nicht geht.

Das eigentlich Problem ist doch, dass man wissen muss wonach man sucht. Das einem halbwegs bekannt ist, welche Dateien an den jeweiligen Ort gehören und ob der Inhalt wirklich "Joomla" ist. Kenne ich das System nicht halbwegs, dann sind das alles nur Mutmaßungen und es bleibt garantiert Schadcode übrig, der wahrscheinlich für den nächsten Hack genutzt wird. Der Hauptgrund ist aber wie gesagt das mangelnde Detailwissen zum System selbst.

Wenn man sich das auch verschiedenen Gründen nicht aneignen kann oder möchte, bleibt als einzig praktikable Möglichkeit, die Webseite von Grund auf neu nachzubilden und die Inhalte dann manuell zu übertragen.

PS: Projekte auf denen der Besitzer bereits selbst herum probiert hat, am besten noch mit Updates, fasse ich persönlich auch als Auftrag nicht mehr an. Das hat einfach damit zu tun, dass wichtige Spuren verwischt werden, die für eine erfolgreiche Bereinigung nötig sind. Ausserdem treibt es den Aufwand enorm in die Höhe und macht viel Nacharbeit notwendig.

Gruß Jan

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

Zitat von ITA-Marketing

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.

Entschuldige, aber es gibt eine Vorgeschichte, die das rechtfertigte. """Dumme""" Fragen gerne, dann aber durch Beratungsresistenz brillieren, eigene Fehler wegignorieren, schließlich wüste Behauptungen und Beschuldigungen aussenden, fremde Threads kapern, falsche Tipps geben, ist für den einen oder anderen kostenlos arbeitenden Helfer schon mehr als nervtötend. Und dieser dezent reingemixte Vorwurf/Kommentar/Whatever, so in der Art, man würde hier im Forum Säuberungs-Jobs aufreißen wollen, wenn man letztlich empfiehlt, einen Profi hinzuzuziehen.

Zitat von ITA-Marketing

wie auch einem Eintrag in der Datenbank.

Der wäre in welcher Tabelle mit welchem Inhalt ?

Ist man ja gewöhnt hier Jedenfalls ist bei mir nun alles sauber. Man kann nicht wissen welche Dateien orginal sind, dazu ist joomla viel zu aufgebläht und zerstückelt. Mit der access.log und zur Sicherheit noch mit der der transfer.log (pure-ftp) bekommt man es jedoch relativ schnell heraus. Wobei letztere sauber war. Die meiste Arbeit übernehmen die hacker selbst. Wenn man die accesslog mehrmals am Tag durchschaut und umbenennt wird eine neue erzeugt und diese bleibt dann recht übersichtlich. Man sucht einfach nach post und kann seine eigene IP schon mal ausklammern. Da hat man die entsprechenden Stellen in ein paar Minuten gefunden. Es ist meist der selbe Schadcode. Nebenbei läßt man schnell noch alle Dateien danach absuchen.
Die Angriffe kamen über Proxy aus Afrika, Asien und Südamerika.
Eine Möglichkeit ist die IPs via Banlist auszusperren. Joomla scheint wohl ein besonders beliebtes Ziel zu sein das es für Banlisten extra einen Autoupdater gibt.
https://www.ip-bannliste.de/autoupdater.html

Zitat

Ist man ja gewöhnt hier

Wie bitte? Was ist man hier gewöhnt?

Zitat

Man kann nicht wissen welche Dateien orginal sind, dazu ist joomla viel zu aufgebläht und zerstückelt.

Man weiss das sehr wohl wenn man (frau) Joomla kennt. Da ist nichts "zerstückelt".

Und auch deine letzten Tipps sind nichts wert, @joomladummy
Ich schreib das nur als Warnung für Hackopfer, die hier landen und sich deinen Unsinn zu eigen machen.

Jedenfalls hat der angebliche Unsinn bestens funktioniert. Liegt wohl draan das es niemand von den Professionellen gesagt hat
Dann kann es natürlich nur Unsinn sein. Sorry aber ich sehr wohl in der Lage eine access.log zu analysieren auch wenn ich nicht jede der Dateien von Joomla auswendig kenne. Für denjenigen der so sein Joomla bereinigt ist es sicher was wert

Firstlady: Die Standardinstallation 3.6.4 besteht aus 5641 Dateien in 1683 Verzeichnissen nicht zerstückelt? Und Mann oder Frau kennt die alle auswendig? Ist klar....

Zitat von joomladummy

Firstlady: Die Standardinstallation 3.6.4 besteht aus 5641 Dateien in 1683 Verzeichnissen nicht zerstückelt? Und Mann oder Frau kennt die alle auswendig? Ist klar....

Ich bin zwar nicht Firstlady, aber ich kann deinen gequirlten Sch.... nicht mehr lesen. Du verstehst die Verzeichnisstruktur von Joomla nicht und beschwerst dich über zu viele Dateien ? Mach doch bitte erst mal Hausaufgaben bevor Du rumschwafelst. Das hat schon alles seine Berechtigung und einen tieferen Sinn. Und das was Du da analysiert hast, war mit Sicherheit nicht der vorhandene Hack.
Ich analysiere täglich gehackte Seiten um die Scanner der Hoster zu verbessern und gebe dieses Wissen auch gerne weiter.
Deine Ausführungen bringen keinen einzigen gehackten User an sein Ziel. Die sind schlichtweg ein Armutszeugnis und zeigen Dein Nichtwissen.

Zitat von joomladummy

Und Mann oder Frau kennt die alle auswendig?

Belegt doch, dass du keinen Plan hast. Es gibt AUCH KOSTENLOSE Tools, die dir das auswendig kennen ersparen. Dein Problem ist, dass du mit Querschüssen Leute anmachst (oben schon wieder), die dir vielleicht entsprechende Hinweise hätten geben können/wollen.
Und nicht nur Profis wissen, dass dein Vorgehen dilletantisch und auf Dauer unnütz ist. Auch Leute, die gut gemeinte KOSTENLOSE Tipps und Hinweise in Foren wie diesem immer und immer wieder wegignorieren.

Mal klipp und klare Frage: Warum kommst du immer wieder und meinst was Neues posten zu müssen? Warum kaperst du einen Thread nach dem andern anstatt deinen eigenen zu öffnen? Weil deine selbstgestrickten Methoden so supergut funktionieren?

Du schadest der Qualität dieses Forums.

Hallo joomladummy,

ich lese hier schon seit geraumer Zeit mit, habe jetzt den Post von Re:Later nochmal zum Anlass genommen um mir deine Posts nochmal durchzulesen. Ich muss ja sagen dass so Beiträge wie der hier das Blut in den Adern gefrieren lassen:

Zitat von joomladummy

Lass mal https://sitecheck.sucuri.net/ drüberlaufen.
Wie schnell bei einem Hack professionelle Hilfe nötig ist finde ich schon erstaunlich
Wenn auf dem Server der securitymod läuft dürfte eine weitere Schwachstelle sicher sein. Kann natürlich durch Drittanbietersoft sein, nur ohne geht es fast nicht. Ich vermute auch ein Javascript. Leider wird immer mehr davon verwendet obwohl es nicht wirklich notwendig wäre.
Weiteren Hack gefunden. POST /components/com_joomgallery/views/downloadzip/search.php
Falls einer die Componente benutzt.

Die Schlussfolgerungen (Joomgallery verwundbar, sichere Website ohne mod_security "fast" nicht möglich) sind fachlich gesehen leider wirklich Blödsinn - und weil hier genug andere Hilfesuchende mitlesen, haben wir hier ein Problem, das Re:Later gut auf den Punkt bringt:

Zitat von Re:Later

Du schadest der Qualität dieses Forums.

Wenn du selber an deiner eigenen Seite rummurksen willst ist mir das wurscht, mit deinen Posts hier gefährdest du aber auch die Websites von anderen Betroffenen und da hört der Spaß auf. Daher hiermit die Ankündigung: ich werde weitere fachlich falsche Posts zum Thema Sicherheit von dir ab jetzt kommentarlos löschen.

Beste Grüße
David