Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE)

  • Hallo zusammen!


    Nach einem (Zwangs-)Update von PHP 5.3 auf PHP 5.6 habe ich nun auch ein Problem: Das Frontend bleibt weiß. Ich habe daher den obligatorischen Debugmodus aktiviert - dieser liefert als Fehlermeldung die folgende Zeile:


    Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING) in ~/www/modules/mod_articles_popular/profiler.php on line 446


    Das ~ im Pfad entspricht dabei dem absoluten Pfad zum Joomla-Verzeichnis. Die Forensuche zeigt mir ähnliche Fälle, bei denen das Problem allerdings immer in der index.php lag. Das ist bei mir offenbar nicht der Fall. Ich habe versucht, herauszufinden, obfür das Problem ggf. ein Modul/Theme verantwortlich ist, leider ohne Erfolg - dafür bin ich wohl (noch) zu wenig mit Joomla vertraut.


    Nützlich sind sicher noch einige kurze Infos zu meinem System: Debian 8, PHP 5.6 - allerdings Update auf PHP 7 geplant, Joomla 3.6.5


    Für Tipps und Hilfe jeder Art wäre ich sehr dankbar!


    Besten Dank und viele Grüße,
    Ju

  • Ich habe mir die Datei eben (noch)mal näher angesehen - es scheint, als wäre das eine Datei, die aus dem verwendeten Template stammt. Bedeutet das, dass ich mich eher an die Macher des Templates wenden sollte? Das Template ist übrigens von Web Komp das Jomi3.

  • Gut zu wissen, dann habe ich jetzt direkt den wichtigsten Schritt unternomen: Seite vom Netz.
    Als Nicht-Profi ist meine nächste Frage jetzt: Wie finde ich heraus, was passiert ist? Oder anders gesagt: Welche Logs enthalten nützliche Informationen?

  • Du könntest nachsehen, wann die Datei angelegt bzw. zuletzt verändert wurde. Wenn du Glück hast, und der Angreifer das Datum nicht angeglichen hat, dann kannst du dadurch den Zeitraum die Hack-Aktivität eingrenzen, und dann in den Zugriffslogs deines Servers nachsehen, was der Angreifer gemacht hat, d.h. welche Dateien angelegt/verändert wurden, und wie er überhaupt eindringen konnte. Natürlich vorausgesetzt, dass er eine Schwachstelle ausgenutzt, und nicht auf andere Weise, z.B. über Schadsoftware auf deinem Computer, die dein Passwörter (FTP, SSH, etc.) mitgelesen konnte, Zugang zu deinem Webspace erhalten hat.

  • Nur so, weil grad entdeckt:
    Ihr hattet/habt wohl auch eine Subdomain site. usw.
    Sollte die in einem anderen Ordner liegen, eine eigene Installation sein, enthält die weitere, eingeschleuste Schaddatei(en), die seit mindestens Okt.2016 "wirksam" genutzt werden. (Dies Datum hat aber keine Aussagekraft für deine Recherchen. Ist nur das Erscheinungsdatum in EINER einzelnen Suchmaschine.)


    Bin schon wieder weg...

  • Danke für die ergänzende Info! Das Datum ist leider kein Anhaltspunkt, offenbar hat sich der ungebetene "Gast" da etwas Mühe gemacht.
    Der Punkt "Subdomain" interessiert mich - kannst du mir vielleicht nähere Informationen dazu zukommen lassen? Gerne auch per PN, falls das was sensibleres ist.

  • Ich wollte nur darauf hinaus, dass falls diese Subdomain-Installation beginnend mit site. eine andere ist als Eure Hauptdomain ("sich in einem anderen Ordner befindet"), Ihr unbedingt den gesamten Webspace bereinigen müsst und nicht nur diese 1 Joomla, wo obiger Fehler jetzt auftauchte. Dass Hacks auch quer über Domain-/Subdomainordner, generell Verzeichnisse, "kooperieren können", die auch nicht unbedingt "Joomla" sein müssen.


    Ich seh halt, wie immer, die Gefahr, dass du diese 1 Datei löscht und denkst, damit ist gut, wie schon so viele Opfer vor dir:
    shoesco.php in mindestens einem der ROOT-Verzeichnisse im Webspace, VERMUTLICH. Diese ist lediglich "ein Vermittler".

  • Woher sollte er das als Nicht-Profi wissen? Das ist letzendlich auch irrelevant, die Installationen sind verseucht, wer weiß, wie lange schon?! Vermutlich war der Eindringling sogar im Backend, wenn das Modul in der DB steht, und der TE nicht weiß, dass er es selbst installiert hat.

  • Also, nach Durchsicht des Quellcodes kann ich dir mitteilen, dass du Opfer von einem sogenanntem SERP Hijacking-Angriff geworden bist, mehr z.B. hier: https://blog.sucuri.net/2016/0…gle-seo-spam-results.html


    Das Skript lädt Daten von einem vermutlich ebenfalls gehackten Server (doorgen.org), versucht sie in deine Datenbank zu schreiben (schau mal, ob du Tabellen mit »wp_«-Präfix findest), und erstellt dann daraus Sitemaps und Inhaltsseiten, die es nur an Google, Yahoo und Bing ausliefert. Andere Useragents sehen die normale, also deine, Seite. Da in diesem Skripot weder eine Backdoor noch Funktionen, um die oben genannten DB-Tabellen anzulegen, angegeben sind, wirst du sehr wahrscheinlich noch mehr veränderte bzw. hinzugefügte Dateien in deinem Webspace haben.

  • Okay, dann mal der Reihe nach:
    Ja, es existieren weitere Subdomains. Auf denen ist allerdings kein Joomla unterwegs, sondern ein Cloudservice und Webmail.
    Woher der Aufruf kam, kann ich leider nicht sagen.
    Die Datenbank hab ich überprüft, dort ist allerdings nichts von wp_ Tabellen zu sehen.


    Was mir allerdings noch nicht ganz klar ist: Wo liegt die Schwachstelle, über die der Angreifer erfolg hatte? Auf der von flow verlinkten Seite sind einige potentielle Schwachstellen (Schwache Passwörter etc.) genannt - auf derartige Lücken achte ich i.d.R. ganz besonders, ich kann auch mit sicherheit sagen, dass es nur einen einzigen Admin der Installation gab und die Passwörter mit mindestens 14 Zeichen Groß/Kleinschreibung, Zahlen und Sonderzeichen gesetzt waren (und es auch keine von den üblichen "leicht zu knackenden" Kombinationen war, z.B. 1234567.... etc.) - das wäre wohl grob fahrlässig.


    Aus Sicherheitsüberlegungen ist der gegenwärtige Stand der, dass die Installation komplett gelöscht und ab Null noch einmal frisch aufgesetzt werden wird.
    Interessant wäre jetzt natürlich, ob sich aus dem Angriff Sicherheitsvorkehrungen fürs nächste Mal folgern lassen.

  • Ja, es existieren weitere Subdomains. Auf denen ist allerdings kein Joomla unterwegs, sondern ein Cloudservice und Webmail.


    Auch dort kann sich theoretisch eine Lücke befinden oder befunden haben oder eine aus anderen Installationen eingeschleust worden sein, die wiederum Zugriff auf alle Verzeichnisse zulässt usw. Du glaubst auch noch zu sehr daran, dass sich im kompletten Webspace mit allen Domains und Subdomains nur 1 Art Hack befindet. Nur, wenn du extremes Glück hast, ist dem so.


    Woher der Aufruf kam, kann ich leider nicht sagen.


    Da schließe ich mich @j!-n an. Ist am Ende dann zwar auch nett, zu wissen, aber dieser Zugriff liegt ja NICHT in der noch offensichtlicher befallenen Subdomain. Nur reine Theorie, dass der irgendwas damit zu tun haben könnte.


    dort ist allerdings nichts von wp_ Tabellen zu sehen


    Das ist auch gar nicht nötig, da diese Art des SEO-Spammings (nennt man das so?) verschiedene Variationen kennt. Also auch ohne Datenbank, sondern dateibasiert, mit Codes, die sich bspw. Inhalte on-the-fly abholen. Ich hab in vielen Jahren nur 1x die Kombination mit Datenbanktabelle gesehen. Vielleicht hast du auch nicht alle Datenbanken geprüft. Noch mal: Wie du es beschreibst, muss das nicht alleine Joomla sein.


    Interessant wäre jetzt natürlich, ob sich aus dem Angriff Sicherheitsvorkehrungen fürs nächste Mal folgern lassen.


    Die Antwort hast in Teilen hier schon bekommen:

    Zur Spezifischen Frage "Welche Logs": das Access Log des Apache ist hier die wichtigste Anlaufstelle, FTP-Log ist auch noch einen Blick wert.


    Meist ist es jedoch so, dass man gar nicht ausreichend zurückliegende Logs "noch rumliegen hat". Musst mal beim Provider anfragen.

    Aus Sicherheitsüberlegungen ist der gegenwärtige Stand der, dass die Installation komplett gelöscht und ab Null noch einmal frisch aufgesetzt werden wird.


    Da hast Recht, aber auch hier wieder: Nicht nur Die 1 Installation, sondern Alle Installationen.