Hab isch Frage: Webseiten"einbruch"

[Lemmy]

Servus,

einem Bekannten wurde jetzt das zweite mal innerhalb 4 Wochen auf das Controlpanel seines Hosters zugegriffen.
Lt. Seitenbetreiber kann der nicht nachvollziehen, wie der ins Ssystem kam - außer halt mit einem PWD. Da mehr oder weniger Zeitgleich seine Rechner zu Hause mit einem Verschlüsselungstrojaner überrollt wurden, gehe ich aktuell davon aus, dass die immer noch Zugriff auf sein System haben und daher das neue Passwort übernommen haben.

Ich habe jetzt ihm geraten, dass ich die PWD von meiner Kiste aus ändere, was ich auch gemacht habe. Was mir aufgefallen ist, "meinen" ftp-Zugang zur Seite hat der Angreifer gelöscht und einen "Default" Zugang angelegt. das Passwort habe ich schon geändert. Ich habe alle Dateien mal durchgeschaut, keine Änderung lt. Datumsangabe seit dem letzten Einbruch.

Ich werde jetzt noch die pwd der Emailaccounts ändern - Datenbanken sind keine angelegt - hat jemand ne Idee, was ich ggf. übersehen habe / noch überprüfen könnte?

Grüße

[Gausi]

Zunächst mal würde ich das infizierte System "wegschmeißen", d.h. der (oder die?) Rechner auf dem der Trojaner gewütet hat, sollten platt gemacht werden erst dann wieder ins Netz.

Mir ist etwas vergleichbares einmal vor ein paar Jahren passiert. Vermutlich wurden die FTP-Zugangsdaten abgefischt (Filezilla, Klartext). Dann wurde per FTP ein JavaScript in die index.html bzw. index.php eingefügt, das versucht hat, Schweinkram zu verbreiten. Glücklicherweise ist das recht schnell aufgefallen, weil dadurch die Seite nicht mehr korrekt funktioniert hat.

Ich habe dann das FTP-Passwort geändert, die index.html des CMS durch "Wartungsarbeiten" ersetzt (also die Seite defacto abgeschaltet), "Format c:\", Windows neu installiert, mir dann die Dateien des CMS auf dem Server näher angeschaut (da gibt's ein Check-Tool für), und dann die Seite wieder online gesetzt. Und den Vorgang auf der Seite transparent veröffentlicht.

Diese Maßnahmen haben geholfen - danach hatte ich keine Probleme mehr damit. Wichtig ist halt, dass das kompromittierte System ersetzt wird - und zwar nicht nur mit "Antivirus", sondern komplett neu.

[Lemmy]

das ist zum Glück erst mal sein Problem. am liebsten wäre mir, er würde seine Kisten alle wegschmeißen, da steht lt ihm noch ein Windows XP Rechner irgendwo in der Ecke :-(

[jaenicke]

Zitat:

Zitat von Gausi (Beitrag 1521499)

Zunächst mal würde ich das infizierte System "wegschmeißen", d.h. der (oder die?) Rechner auf dem der Trojaner gewütet hat, sollten platt gemacht werden erst dann wieder ins Netz.

Insbesondere vergessen viele die Dateien auf dem System. Manche machen nur das Betriebssystem platt, starten aber vorhandene Exen, Setups oder Office-Dateien mit Makros munter nach dem Neuaufsetzen wieder, so dass ein darin eingeschleuster Virus gleich wieder aktiv ist.

Zitat:

Zitat von Lemmy (Beitrag 1521501)

das ist zum Glück erst mal sein Problem. am liebsten wäre mir, er würde seine Kisten alle wegschmeißen, da steht lt ihm noch ein Windows XP Rechner irgendwo in der Ecke :-(

Da fängt man sich natürlich sehr einfach etwas ein, wenn der noch am Netz hängt. Einen XP-Rechner könnte selbst ich recht einfach kompromittieren (bzw. habe es schon aus Interesse gemacht :)), obwohl ich mich damit ansonsten kaum auskenne.

[Sinspin]

Zitat:

Zitat von Lemmy (Beitrag 1521498)

<snip> Ich habe alle Dateien mal durchgeschaut, keine Änderung lt. Datumsangabe seit dem letzten Einbruch. <snip>

Die Dateien auf dem FTP? Das Änderungsdatum kann man nachträglich ändern. Interesanter sind Transfer- und Zugriffs-logs.
Allerdings bringen die nur was wenn sie unter einem anderen Zugang liegen oder nicht gekapert werden können. Zumindest bei mir sind die Dateien für mich read only.

[Lemmy]

Zitat:

Zitat von Sinspin (Beitrag 1521506)

Zitat:

Zitat von Lemmy (Beitrag 1521498)

<snip> Ich habe alle Dateien mal durchgeschaut, keine Änderung lt. Datumsangabe seit dem letzten Einbruch. <snip>

Die Dateien auf dem FTP? Das Änderungsdatum kann man nachträglich ändern. Interesanter sind Transfer- und Zugriffs-logs.
Allerdings bringen die nur was wenn sie unter einem anderen Zugang liegen oder nicht gekapert werden können. Zumindest bei mir sind die Dateien für mich read only.

Danke, das hatte ich schon befürchtet, die Nacht hat der Provider aber nochmal eine Prüfung durchgeführt und 3 Dateien wurden als problematisch angesehen, die habe ich inzwischen gelöscht. Dann werde ich mir das Zeugs nochmal speziell auf PHP/JS durchschauen ob da noch was rumliegt was suspekt ist...

[Phoenix]

Zitat:

Zitat von Lemmy (Beitrag 1521498)

Lt. Seitenbetreiber kann der nicht nachvollziehen, wie der ins Ssystem kam - außer halt mit einem PWD. Da mehr oder weniger Zeitgleich seine Rechner zu Hause mit einem Verschlüsselungstrojaner überrollt wurden, gehe ich aktuell davon aus, dass die immer noch Zugriff auf sein System haben und daher das neue Passwort übernommen haben.

Ich habe jetzt ihm geraten, dass ich die PWD von meiner Kiste aus ändere, was ich auch gemacht habe. Was mir aufgefallen ist, "meinen" ftp-Zugang zur Seite hat der Angreifer gelöscht und einen "Default" Zugang angelegt. das Passwort habe ich schon geändert. Ich habe alle Dateien mal durchgeschaut, keine Änderung lt. Datumsangabe seit dem letzten Einbruch.

Ich werde jetzt noch die pwd der Emailaccounts ändern - Datenbanken sind keine angelegt - hat jemand ne Idee, was ich ggf. übersehen habe / noch überprüfen könnte?

Vielleicht ist mit dem Verschlüsselungstrojaner auch weitere unerwünschte Schnüffelsoftware bei ihm gelandet.

Ähnliches ist letztens beim Linus Tech Tips Youtube-Kanal passiert:

Jemand war als Admin auf einem infizierten System eingeloggt. Die Schnüffelsoftware hat aber nicht das Passwort geklaut, sondern den Session-Cookie aus dem Browser.

Egal wie oft das Passwort geändert wurde, und auch egal ob ggf. sogar ein Zweitfaktor beim Login abgefragt wurde: am Ende landet ein Cookie im Browser als Beweis das er authentifiziert wurde. Wird dieses Cookie Abgefangen, kann ein Angreifer damit mit seinem Browser den Login umgehen und ist sofort "drin".

[Sinspin]

Das ist mal was interessantes!

Also müsste, um das sicherer, zu machen solch ein Key nicht als Cookie abgelegt werden.
Oder zumindest eben nicht auf die Platte geschrieben werden. Es ist ja eh nur für die aktuelle Session gültig.

Damit ist faktisch jede Art von Passwort elegant zu umgehen solange der Angreifer schon im System ist.

Das sollte auf die Todoliste von Browserherstellern. Cookies nicht mehr auf die Platte zu schreiben wenn da ein Sessionkey drinne ist ;-)

[Phoenix]

Wenn fremde Software auf Deinem System mit Admin-Rechten läuft, kann die auch Browser-Plugins installieren.
Oder, noch einfacher, einen lokalen Proxy registrieren der HTTPS aufbricht (mit einem lokalen Zertifikat, das ja auch installiert werden kann). Dann kann er die cookies (und alles andere auch) schon unterwegs unverschlüsselt abfangen.
Kurzum: Das ist nicht mehr "Dein" Computer. Da hilft es auch nichts wenn die Tools wie Browser keine Files sondern was auch immer nutzen um Daten abzuspeichern.

[Lemmy]

Danke. Krass, dass so was möglich ist. Ich frage mal beim Provider nach, ob die schauen können, welche Session-Cookies auf dem Zugang aktiv sind, damit die die einmal wegschmeißen...

Grüße

[Delphi.Narium]

Ob Cookies gelöscht werden oder nicht, ist aber auch eine Frage der Browserkonfiguation, auf die man selbst Einfluss nehmen kann.

Oder auch die Antwort auf die Frage: Immer angemeldet bleiben, bei etlichen Seiten ...

Wer den FireFox nutzt, schaue mal hier Datenschutz & Sicherheit, was man da so alles selbst in der Hand hat.

Grob kann man aber sagen: Bequemlichkeit bei der Browsernutzung geht zu Lasten der Sicherheit. Wenn ich vom Browser erwarte, dass er so allerlei für mich automatisch erledigt, muss ich damit leben, dass jemand anderes das missbrauchen kann. Und das Ergebnis ist schlimmstenfalls, dass ich keinerlei Einfluss mehr auf mein System habe.

[Phoenix]

Zitat:

Zitat von Delphi.Narium (Beitrag 1521553)

Grob kann man aber sagen: Bequemlichkeit bei der Browsernutzung geht zu Lasten der Sicherheit.

Das gilt allgemein. In meinen Sessions / Workshop zu IAM-Themen kommt immer der Spruch: "Du kannst es einfach haben, oder sicher. Such Dir eins aus."

[himitsu]

Nja, wenn besser gemacht, dann haben die Token nur eine gewisse kürzere Lebensdauer. (nach 15 bis 60 Minuten läuft bei vielenen APIs so ein Sicherheitstoken ab)

Aber ja, "angemeldet bleiben" kann öfters auch Monate bis Jahre gültig sein.
Hier wäre es gut, wenn beim "Abmelden" solche Cookies ungültig werden und nächstes Mal mit neuem Wert erstellt.
Bzw. es gibt Webportale, wo jeder Client seinen eigenen Eingeloggtbleiben-Keks bekommt und man sie im Portal auch einzeln löschen/sperren kann. Oder zumindestens irgendwo einen Knopf "alle gespeicherten Logins löschen/sperren".

[dummzeuch]

Ich dachte immer, Session Cookies hätten serverseitig eine relativ kurze Gültigkeit, eben um genau solche Szenarien zu verhindern?

Aber OK, jetzt, wo ich das schreibe, fällt mir auf, dass mein Login in Wordpress auch ziemlich lange gültig ist. In der Regel mehrere Wochen.

[himitsu]

Ja eigentlich schon, aber du kennst die Vergesslichkeit, Dummheit oder Faulheit von Entwicklern nicht.

[add]
Hier in der DP auch bestimmt ein halbes Jahr, oder eher mehr.
Session-Kekse bis zum Ende der Session, aber das Merken für ein Jahr.

[Rollo62]

Zitat:

Zitat von Phoenix (Beitrag 1521534)

... am Ende landet ein Cookie im Browser als Beweis das er authentifiziert wurde. Wird dieses Cookie Abgefangen, kann ein Angreifer damit mit seinem Browser den Login umgehen und ist sofort "drin".

Ich dachte immer ein SessionCookie wird zusätzlich verifiziert und abgesichert, also z.B. mit UserAgent, IP-Adresse und so weiter.
Klar, auch das kann man faken, aber so ohne Weiteres sollten ein SessionCookie von Browser PC-A bei Browser PC-B doch nicht laufen, oder etwa doch ?

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1521565)

Klar, auch das kann man faken, aber so ohne Weiteres sollten ein SessionCookie von Browser PC-A bei Browser PC-B doch nicht laufen, oder etwa doch ?

Doch, denn auch z.B. die IP kann sich ändern (z.B. Wechsel zwischen W-LAN und Mobilfunk). Du kannst ein Gerät nicht immer eindeutig identifizieren.

Wenn eine weitere bestehende Session weiterlebt, wenn das Passwort geändert wird, würde ich das allerdings als grob fahrlässigen Fehler einstufen. Das geht gar nicht.