Beiträge von SniperSister

    Eigentlich würde ich mir wünschen, dass das Security Strike Team bei solchen Dingen entschlossener auftritt mit einem Statement und klar sagt, was Sache ist. Und nicht nur à la 'In response to questions from The Daily Swig'. Ich habe von dieser Sache auch andernorts gelesen, ohne ein Statement vom JSST


    Dazu mal ein Statement vom JSST ;)


    Wir wussten vorab, dass der Blog Post kommen würde, haben uns aber erstmal bewusst dagegen entschieden, ein eigenes offizielles Statement rauszugeben - das würde dem entsprechenden Post der Forscher nämlich sehr viel Aufmerksamkeit bringen und macht die Sache viel größer als sie ist. Es ist auch hier, wie so vieles im Security-Bereich, ein Balance-Akt.

    Ich habe in der DACH Facebook-Gruppe ein paar Zeilen zur Lücke in deutsch geschrieben, ich re-poste das mal hier:


    Anpassung des A-Records der .de Domain wäre dann die Methode der Wahl. Auf die IP des .eu Webspaces zeigen lassen, beim .eu Hoster die de-Domain als externe Domain hinterlegen -> feddig

    Kein Domainumzug, keine Weiterleitung, Mailserver und co bleiben wie gehabt.



    Die wirklich ganz grausame und langsame Alternative: ein Reverse Proxy. Am besten ein richtiger in Form eines nginx o.ä. - wenn alle Stricke reißen dann sowas: https://github.com/michaelfranzl/no.php

    > Stellt sich immer noch die Frage wieso eine Datei ohne Rechte ausgeführt werden kann?

    Die Datei wird nicht ausgeführt, sondern der Code per require in einer anderen PHP-Datei eingebunden, braucht also kein executable flag.


    Warum das lesen ohne r flag möglich war kann ich von außen nicht beurteilen, da gibts diverse Sonderkonstellationen die da die Ursache sein könnten. Ist letztlich aber in meinen Augen auch nicht so relevant, weil der Mailer ja nicht die eigentliche Lücke war, sondern das ungesicherte Mailformular.

    Als Beispiel die JFile::-Klasse. Hier kann ich z.B. die Dateierweiterung per JFile::getExt($filename); bekommen. Mit standard PHP würd ich das über pathinfo oder  SplFileInfo::getExtension machen.

    JFile als Klasse generell gibt einem Entwickler eine einheitliche API für Dateioperationen, ohne das sich der Entwickler Gedanken darüber machen muss, ob in Joomla der FTP-Layer aktiviert ist (was dann bedeutet dass zumindest schreibende Zugriff per FTP erfolgen) oder ob direkt auf der Platte gearbeitet werden kann. Um die API der Klasse dabei möglichst vollständig zu machen, ist auch die getExt dazu gekommen.

    Das Risiko der "alten" Version sehe ich persönlich nicht als sehr gross, da kaum Code zur Ausführung kommt beim öffentlichen Aufruf von Webseiten.


    Das will ich nicht unwidersprochen stehen lassen, insbesondere damit die Idee keine Nachahmer findet: Akeeba ist eine extrem umfangreiche Komponente, hier kommt also nicht “kaum” Code zur Ausführung, sondern sehr viel Code. Insb. durch den Frontend-Cron sind wesentliche Teile dieses Codes auch über das Frontend triggerbar, weshalb ich deine Einschätzung nicht teile.

    O.D. ich antworte einfach mal hier anstatt auf deine Mail, die du an info@joomla.de geschickt hast - dann haben alle was davon.


    Grundsätzlich ist die Aussage des sog. Datenschutz-Experten mal mindestens fragwürdig – wenn du dich hier aber auf eine Diskussion einlassen willst, kannst du auf die CMS Studie des BSI verweisen, in der verschiedene OpenSource CMS, darunter Joomla, auf ihre Sicherheit geprüft worden sind:

    https://www.bsi.bund.de/Shared…_blob=publicationFile&v=2


    Das für dich relevante Kernfazit findet sich dort unter 5.1.1:

    Zitat

    Zuerst darf festgestellt werden, dass die betrachteten Open Source Projekte nachweislich einen Sicher­heitsprozess implementiert haben. Die Software hat Produktcharakter mit einem veröffentlichten Release­plan, einem transparenten Bugtracker etc. Die Umsetzung eines Sicherheitsprozesses entspricht dem Stand der Technik, den selbst viele unter Zeitdruck erstellte kommerzielle Softwarepakete nicht erreichen. Die resultierende Software ist – gemessen an ihrer Funktionalität und der daraus resultierenden Komplexität – eine gute Wahl für einen Dienstanbieter.

    Jo. Treffer. plugins/system/section/section.php - tarnt sich als Plugin mit inhaltlicher Funktion, einziger Zweck ist aber das nachladen von "Content" (vermutlich SEO Spam) von einem anderen Server. Dieser Server scheint nicht zu antworten, daher die 60 Sekunden: PHP wartet hier bis zum Timeout.


    Nein, es reicht nicht diese Datei zu löschen, nächste Schritte: https://www.fc-hosting.de/supp…ehackte-website-hilfe.php


    Angesichts der Tatsache, dass der Hack schon Jahre her sein kann und die Seite noch auf J 2.5 läuft, würde ich an deiner Stelle mit einer neuen Installation starten.

    Davon abgesehen: das Urteil bestätigt nur, was schon länger absehbar war, nämlich dass die ePrivacy Richtlinie der EU auch in Deutschland gilt – und dieser verbietet nicht grundsätzlich Cookies sondern "nur" jegliche Art von Tracking-Maßnahme ohne explizite, informierte Zustimmung des Benutzers. Ob dieses Tracking dann über Cookies oder ein anders Fingerprinting passiert ist irrelevant. Explizit ausgenommen sind technisch notwendige Cookies, wozu die Session-Cookies von Joomla explizit gehören, womit hier nach meiner Rechtsauffassung (Disclaimer: ich bin kein Anwalt, bitte richtigen Anwalt fragen) kein Handlingsbedarf besteht.