Sehr geehrte/r Frau Anne Nühm,
Vor wenigen Minuten hat der 2|2 Anti-Viren-Scanner gemeldet, dass eine
schädliche Datei auf Ihren Webspace geladen wurde.
Das bedeutet für Sie: Ihr 2|2 Webspace wird gerade von kriminellen Hackern
angegriffen. Der Angriff erfolgt entweder über eines Ihrer Passwörter oder über
die Software, die Sie installiert haben.
1. Ändern Sie Ihre Passwörter
2. Aktualisieren Sie Ihre Software
.. das war der wesentliche Inhalt einer Mail meines Internet-Hosters, die ich gestern erhalten habe.
Mir fuhr zuerst der Schreck in alle Knochen. Sofort begann ich dann aber, zügig Maßnahmen zu ergreifen.
Zuerst änderte ich das Passwort des FTP-Zugangs. Zwar ist das schon recht kryptisch, und ich hatte den Zugang auch schon seit zwei Wochen nicht mehr benutzt, aber sicher ist sicher.
Ein Ärgernis ist natürlich, dass Passwörter bei FTP im Klartext übertragen werden. Aber ein SFTP-Zugang wird leider nicht bereitgestellt.
Das Datenbank-Passwort änderte ich für alle Fälle ebenfalls.
Software wie WordPress oder Joomla hatte ich gar nicht auf dem Webspace installiert, nur einmal ein paar Sachen ausprobiert. Die entsprechenden Ordner löschte ich aber sofort, nachdem ich mich mit meinem neuen Passwort eingeloggt hatte.
Außerdem läuft nur mein selbstgeschriebenes CMS. Das kann halt nicht so viel wie die verbreiteten, sondern macht nur genau das, was ich brauche.
Gerne hätte ich die genannte HTML-Datei mir einmal näher angesehen. Natürlich nicht im Browser, sondern in einem Editor. Aber die Datei war irgendwie geblockt, so dass ich sie nicht herunterkopieren konnte.
Schließlich löschte ich sie, und ersetzte sie durch das Original von meinen Backups.
Selbstverständlich warf ich noch einen Blick in meine Log-Dateien. Aber da fiel mir nichts besonderes auf.
Jetzt kann ich nur hoffen, dass das Problem hiermit erledigt ist.
breakpoint 
Das sind meistens Bots die permanent irgendwie probieren über Scripte Code bei beliebigen Seiten einzuschleusen. Manchmal sind auch die Webhoster schuld indem die z.B. laden von externen Inhalten zulassen.
Meistens hilft ein Blick in die Apache-Log. Oder mal die GET-Parameter mitzuloggen… damit wenn es wieder vorkommt du genau siehst wo die Lücke ausgenutzt wird. Gerade bei selbstgeschriebenen CMS habe ich das schon des öfteren erlebt.
LikeLike
In den aktuellen Logs stand nichts Ungewöhnliches, auch nicht bei den Querystrings.
Ich überlege jedoch, sämtliche Dateien mit meinen Originalen zu überschreiben.
Das wäre halt ein ziemlicher Aufwand, den ich mir gerne sparen würde.
Falls nicht wieder oder noch ein Problem auftritt, werde ich es wohl lassen.
Mein CMS liest im wesentlichen aus einer XML-Datei (die ich mit einem speziellen Tool offline schreibe; die Website ist nicht so umfangreich, dass sich dafür eine DB lohnen würde).
Der Pfad ist hardkodiert. An keiner Stelle schreibe ich irgendwo skriptgesteuert ins Dateisystem. Eigentlich wüsste ich nicht, wo da eine Lücke sein sollte. Bin aber jetzt auch kein PHP-Experte.
LikeLike
das mit dem 2|2 solltest Du dir noch überlegen… wenn dasselbe wie bei dem großen Hostingprovider mit dem & rauskommen soll wäre eher 2|3 (bei „|“ = „XOR“) bzw. 0|1 (bei OR) angemessen, mit 2|2 ist das Ergebnis ja „0“ bzw. „2“
LikeLike
Ich wollte den Namen nur etwas verändern, damit er nicht im Klartext dasteht. Warum sollte da das Gleiche rauskommen müssen?
Für bitweises XOR hätte ich ^ als Operator benutzt.
Hätte ich z.B. 2^3 geschrieben, hätte allerdings sicherlich wieder jemand das als 23 = 8 interpretiert.
In welcher Programmiersprache nutzt man | als exklusives Oder?
LikeLike
äh… keine Ahnung, kenne zu wenige. wollte nur sichergehen 🙂
Ein reines | ist aber für OR auch nicht extrem häufig, in C wäre es ja ||, dafür in der bash, und die hat dann ^ für XOR
Am saubersten wäre ja U+22BB für XOR und U+2228 für OR, aber setz‘ das mal durch 🙂
LikeLike
Also ich kenne auch keine.
Hätte aber natürlich auch eine Wissenslücke meinerseits sein können. Deshalb habe ich nachgefragt.
| kenne ich als bitweises Oder, || als logisches Oder (& und ^ entsprechend), obwohl sich das eigentlich – bei typisierten Sprachen – ohnehin aus dem Typ ergeben sollte.
Die Unicode-Zeichen werden sich nicht durchsetzen, solange man sie nicht auf einfache Weise über eine Standard-Tastatur eingeben kann.
LikeLike
Pingback: breakpoint’s Wayback Archive #1F //1769 | breakpoint