nicht angemeldet
Seite infiziert
0 0 archivierter Thread
0 0
Seite infiziert
Hallo Forum,
ich bin vor Kurzem erstmals damit konfrontiert worden. Mein neuer Kunde meinte, seine Website sei in der Vergangenheit mal gehacked worden, worunter ich mir zuerst mal nichts vorstellen konnte. Einige Zeit später schien es einen erneuten Angriff gegeben zu haben. Er schickte mir einen Screenshot der Site zu auf dem ein Layer zu sehen war, auf dem ein Link zu sehen war ("Update Your VEOH-Player"). Beim Aufruf der Site mit meinem Browser wurde der Link dann auf angezeigt. Nach einem Blick in den Quellcode konnte ich dann das für den Layer verantwortliche Javascript sehen also machte ich mich auf die Suche in den Sourcefiles und fand Code, den ich nicht eingebaut hatte. Jemand anders musste sich also per FTP auf dem Server angemeldet und den Code in dem betreffenden File eingebaut haben, also die FTP-Zugangsdaten gehabt haben. Ich habe den Code entfernt und der Layer wurde nicht mehr angezeigt. Wenige Tage später passierte das selbe nochmal. Etwas Recherche und ich las von irgendwelchen Botnetzen und schlussfolgerte dass die FTP-Zugangdaten wohl irgendwann mal in die falschen "Hände" geraten waren. Due Zugangsdaten geändert und das Phänomen trat seit dem nicht wieder auf.
Jetzt weiss ich, was es bedeutet, wenn eine Website gehacked wird. (Ja?)
Nun bekomme ich gerade eine Mail von einem anderen Kunden. Der hat einen ähnlichen Screenshot von einem anderen Kunden bekommen.
Was kann ich tun, um die Sache aufzuklären?
Kann es sein, dass hier nicht die Site sondern der Client infiziert ist?
Was ich bisher getan habe:
1. Wenn ich die Site mit meinem Browser (OS X Firefox 27.0.1) aufrufe, wird der Layer nicht angezeigt. Auf mit dem IE9 auf meiner virtuellen Maschine nicht.
2. Im Quellcode finde ich auf keinen Content, der da nicht hingehört.
3. Ich habe diverse Security-Check-Seiten im Netz gefunden:
- https://www.virustotal.com
- http://www.unmaskparasites.com
- http://sitecheck3.sucuri.net
- http://safeweb.norton.com
Keine findet irgendetwas. Ist das verlässlich?
Was kann ich noch tun / was kann ich resümieren?
danke für Tipps und
beste gruesse,
heinetz
-
Mahlzeit,
Jemand anders musste sich also per FTP auf dem Server angemeldet und den Code in dem betreffenden File eingebaut haben, also die FTP-Zugangsdaten gehabt haben.
Nein. FTP ist nur eine Möglichkeit einen Server zu infiltrieren
Jetzt weiss ich, was es bedeutet, wenn eine Website gehacked wird. (Ja?)
Nö. Du weisst, dass es EINE Möglichkeit gibt, einen Server zu hacken. Da gibts noch zig andere.
Was kann ich noch tun / was kann ich resümieren?
Betreibst du den Server selbst?
--
42-
Hello,
Nein. FTP ist nur eine Möglichkeit einen Server zu infiltrieren
Jetzt weiss ich, was es bedeutet, wenn eine Website gehacked wird. (Ja?)
Nö. Du weisst, dass es EINE Möglichkeit gibt, einen Server zu hacken. Da gibts noch zig andere.
Das hatte ich mir schon gedacht und gehört hatte ich auch schon davon, aber vorstellen, kann ich mir noch nicht wie das funktioniert.
Betreibst du den Server selbst?
Nein, ich habe nur Shell- und (S)FTP-Zugriff
gruss,
heinetz-
Hello,
Nö. Du weisst, dass es EINE Möglichkeit gibt, einen Server zu hacken. Da gibts noch zig andere.
Das hatte ich mir schon gedacht und gehört hatte ich auch schon davon, aber vorstellen, kann ich mir noch nicht wie das funktioniert.
Die beliebteste Möglichkeit sind immer Upload-Scripte, z. B. für Bilder o. ä.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hello,
danke für den Tipp. Das hätte natürlich sein können!
Im Frontend der Site gibt es keine Möglichkeit, irgendwas hochzuladen, aber es gibt ein CMS, wo was hochgeladen wird, das natürlich nicht öffentlich ist. Der Schutz ist jedoch kein .htaccess-Schutz, sondern wird über eine SESSION organisiert. Die Verzeichnisstruktur ist so aufgebaut, dass nur /_admin/index.php per http erreichbar ist und die darin inkludierten Ressourcen alle ausserhalb des DocumentRoot liegen, aber Requests auf alle von /_admin/index.php referenzierten js, css, jpg werden ohne Authentifizierung beantwortet.
gruss,
heinetz-
Im Frontend der Site gibt es keine Möglichkeit, irgendwas hochzuladen,
Ein Frontend der Seite ist gar nicht nötig. Ein Frontend kann sich jeder selber zusammenbauen und auf deine Seite zeigen lassen. Wichtig ist, daß auf dem Server nichts ist, was irgendwas annimmt und in gefährlicher Weise verarbeitet.
war gerade erst wieder Thema: https://forum.selfhtml.org/?t=216882&m=1488473
... es gibt ein CMS, ...
Forensoftware, Gästebücher, newsletter-scripts, alles ohne irgendwelche Dateiuploads, Sicherheitslücken finden sich auch dort immer wieder.
Wenn man es selbst nicht besser, d.h. sicherer, kann, dann: Fremde scripte nur im erforderlichen Umfang und möglichst nur mit erforderlichem Funktionsumfang nutzen und immer alles aktuell halten.
-
Im Frontend der Site gibt es keine Möglichkeit, irgendwas hochzuladen,
Ein Frontend der Seite ist gar nicht nötig. Ein Frontend kann sich jeder selber zusammenbauen und auf deine Seite zeigen lassen. Wichtig ist, daß auf dem Server nichts ist, was irgendwas annimmt und in gefährlicher Weise verarbeitet.
Wenn ich Dich richtig verstehe, meist Du, dass der Server keine per GET oder POST übergebenen Variablen verwendet, um deren Inhalte ungeprüft zu verarbeiten. Gefährlich wird's dann, wenn die Werte der Variablen verwendet werden, wenn (dauerhaft) entweder auf Dateiebene oder in einer DB geschrieben wird. Richtig?
Mit Frontend meinte ich die Website, die öffentlich erreichbar ist. Auf der gesamten Website gibt es für den User keine Möglichkeit, irgendwo dauerhaft etwas zu hinterlassen. Deshalb verarbeitet der Server empfangene Daten aus GET- oder POST-Variablen auch nur um, etwas bestimmtes anzuzeigen.
Hingegen das CMS (,das ich ach gerne als Backend bezeichne) verarbeitet natürlich die empfangenen Daten um DB-Inhalte und Dateien zu schreiben. Dieses CMS ist über www.example.org/_admin/ erreichbar. Sämtliche Requests innerhalb des CMS nimmt eine /_admin/index.php entgegen und für die gibt es eine SESSION-basierte Authentifizierung.
ABER: js, css, jpg usw., die sich auch in dem Verzeichnis befinden, werden ohne Authentifizierung vom Server ausgeliefert UND ... und darin besteht theoretisch die Schwachstelle, mein CMS basiert auf einem RT-Editor (TinyMCE), der nicht ganz ohne PHP-Files auskommt, weil er eine Dateiupload-Funktionalität beinhaltet, die aber wiederum eine SESSION-Authentifizierung enthält.
Kurzum: Meiner Ansicht nach ist alles abgesichert. Trotzdem kann es natürlich immer etwas geben,
was ich dabei vergesse.Ich stelle mir 2 Fragen:
1. Kann es sein, dass doch der Client infiziert ist (und sich das so äussert)
2. Die einzig mir bewussten Schwachstellen können nur (jetzt oder zukünftig) unterhalb des Verzeichnis /_admin/ auftreten. Das liesse sich ja relativ einfach über eine htaccess schützen. Das ist aber nicht sonderlich komfortabel, denn nach Eingabe eines htaccess-Passwortes müsste der User sich nochmal authentifizieren. Gibt es eine einfache Möglichkeit sämtliche Requestes in dem Verzeichnis bspw. mit mod_rewrite über die bestehende SESSION-Authentifizierung zu organisieren?Für PDFs in einem geschützten Verzeichnis habe ich das mal gemacht:
- Alle Requests nach PDF in dem geschützten Verzeichniss werden per mod_rewrite nach einem php-wrapper umgeleitet.
- der php-Wrapper prüft eine Variable $_SESSION['login'] und
- leitet entweder zum Login um oder
- gibt den Inhalt der Datei mit readfile() aus
... aber da ging es eben ausschliesslich um PDFs
gruss,
heinetz-
Ich stelle mir 2 Fragen:
- Kann es sein, dass doch der Client infiziert ist (und sich das so äussert)
Die kann ich mir jetzt selbst beantworten :
Ja, und zwar mit dem Browser Hijacker namens Text EnhanceObwohl ich mir eigentlich sicher war, dass ich alles abgesichert hatte, war es trotzdem gut, diese Diskussion geführt zu haben. Danke euch allen! Und ich nehme das zum Anlass, noch eine weitere Sicherheit einzubauen.
gruss,
heinetz -
Mit Frontend meinte ich die Website, die öffentlich erreichbar ist.
Und darunter würden die meisten etwas verstehen was irgendwie beim user angezeigt wird (unter anderem auch Formulare). Dem bedarf es aber nicht, bzw. kann das so (scheinbar) abgesichert sein wie es will. Darauf wollte ich in dem Zusammenhang hinaus.
Auf der gesamten Website gibt es für den User keine Möglichkeit, irgendwo dauerhaft etwas zu hinterlassen.
Wenn dem so ist, dann ist es ja gut. (Wenn man mal von sowas absieht, daß beispielsweise auch mit einer nicht dauerhaften sql-Injektion Paßwörter abgefragt werden könnten, nur zur Info.)
Hingegen das CMS (,das ich ach gerne als Backend bezeichne) verarbeitet natürlich die empfangenen Daten um DB-Inhalte und Dateien zu schreiben. Dieses CMS ist über www.example.org/_admin/ erreichbar. Sämtliche Requests innerhalb des CMS nimmt eine /_admin/index.php entgegen und für die gibt es eine SESSION-basierte Authentifizierung.
Das CMS ist mindestens über jede url erreichbar über die es Inhalt ausliefert, also nicht nur über _admin, nur zur Info. Daß Potential für Sicherheitslücken mag im Admin bereich deutlich höher sein aber wenn man es genau nehmen will, dann sollte man es im Sprachgebrauch auch genau nehmen.
ABER: js, css, jpg usw., die sich auch in dem Verzeichnis befinden, werden ohne Authentifizierung vom Server ausgeliefert UND ... und darin besteht theoretisch die Schwachstelle,
Wenn das eine Schwachstelle sein soll (oder überhaupt sein kann), dann hast Du woanders eine Schwachstelle. Oder was lieferst Du da aus
Kurzum: Meiner Ansicht nach ist alles abgesichert. Trotzdem kann es natürlich immer etwas geben,
Es ging mit in erster Linie darum, daß fremde software nun mal fremde software ist und Sicherheitslücken aufweisen kann (wie aber auch eigene software). Auch scheinbar einfache scripte bilden da keine Ausnahme.
-
Hello,
Das CMS ist mindestens über jede url erreichbar über die es Inhalt ausliefert, also nicht nur über _admin, nur zur Info. Daß Potential für Sicherheitslücken mag im Admin bereich deutlich höher sein aber wenn man es genau nehmen will, dann sollte man es im Sprachgebrauch auch genau nehmen.
ABER: js, css, jpg usw., die sich auch in dem Verzeichnis befinden, werden ohne Authentifizierung vom Server ausgeliefert UND ... und darin besteht theoretisch die Schwachstelle,
Fragt sich, wie die auf den Server gelangen, in welchem Verzeichnis sie landen, wie sie geprüft werden, usw.
Und das Beispiel
http://selfhtml.bitworks.de/angriffsmuster/20140219_0929_access_log.txt
zeigt ja auch, wie genau es die Hacker-Robots nehmen, wenn sie Lücken suchen. Da geht es um jeden Punkt :-ODeinen Einwand,
"... dann sollte man es im Sprachgebrauch auch genau nehmen ..."möchte ich daher voll unterstützen!.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ich verstehe deinen Beitrag nicht so ganz, warum Du zitierst, was Du zitierst und was die Antwort darauf soll.
Fragt sich, wie die auf den Server gelangen, in welchem Verzeichnis sie landen, wie sie geprüft werden, usw.
Wenn das das Problem ist, ...
dann hast Du woanders eine Schwachstelle
... als bei der Auslieferung der Dateien.
-
-
-
-
-
-
Mahlzeit,
Nein, ich habe nur Shell- und (S)FTP-Zugriff
Passwort oder Key?
Grad Shell-Zugang kann zum Licherheitsloch werden, wenn die SSH-Lib zu alt ist. Dann kann der Angreifer alles auf dem Server machen, auch per FTP was hochladen.Warscheinlicher st aber ein Loch in nem Uploadscript, wie schon geschrieben wurde.
--
42
-
-
-
Meine Herren!
ich bin vor Kurzem erstmals damit konfrontiert worden.
Der Thread von damals ist inzwischen archiviert: http://forum.de.selfhtml.org/archiv/2014/2/t216626/#m1485789
--
“All right, then, I'll go to hell.” – Huck Finn -
Moin
Kannst du die URL (natürlich nicht als Link) zu dem Problem nennen? Wenn ja, dann bitte so dass ein "folgen" nicht möglich ist. Ich hatte ähnliche bei einem Kunden und da war ein Javascript (sehr klein) der Überltäter
Gruß Bobby
--
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
### Henry L. Mencken ###
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
### Viktor Frankl ###
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:) -
Meine Herren!
Was kann ich noch tun?
Wirf mal einen Blick in die Access-Logs für HTTP und FTP.
Tom war neulich auch einem Angriff ausgesetzt, da kannst du dir ansehen, wie ein verdächtiger Access-Log aussieht.--
“All right, then, I'll go to hell.” – Huck Finn-
Ok, ich hab mir das Logfile angesehen und versucht zu verstehen, warum es verdächtig aussieht. Mir erscheint nur folgendes verdächtig:
Hier werden verschieden PHP-Skripte mit GET-Paramtern aufgerufen. In dieden Parametern steht der Pfad nach etc/passwd.
... und das würde ich wie folgt interpretieren:
Hier probiert ein Automat aus, ob der in einem GET-Paramter übergebene Wert dazu verwendet wird, den Inhalt eines Files auszugeben, während der Wert des Paramters als Pfad zum File verwendet wird.
Interessant!
-