3. Downtime

Downtime

  • R

    nman schrieb:

    Rhombicosidodecahedron schrieb:

    Wurde denn Schadware verteilt, oder war der Angriff nur passiv?

    Was du hier mit "passiv" meinst ist mir nicht vollkommen klar.

    Es wurde nur der Rechner gekapert ohne, dass was von der Seite geändert wurde.

    Im nachhinein war der Begiff passiv eh dumm gewählt. Wenn jemand den Server kapern konnte ohne dass er danach was aktiv gemacht hätte, wäre es wohl nicht so leicht aufgefallen ...

    0
  • N

    -lowbyte- schrieb:

    nman schrieb:

    Überraschend ist für mich eher, dass sie so selten sind.

    Die meisten Exploits werden in freier Wildbahn gar nicht gesichtet.

    Ich meinte ja genau "in freier Wildbahn so vergleichsweise selten".

    0
  • C

    Marc++us schrieb:

    Hallo zusammen,

    Nachdem das bemerkt wurde machte es natürlich Sinn die VM gleich komplett neu aufzusetzen. Datenbackups sind immer vorhanden, allerdings war die Verseuchung des Servers schon einige Tage alt, so daß ein Rollback auf einen relativ alten Backup-Stand notwendig wurde. D.h. es ging immer Backup für Backup zurück, bis ein unverseuchtes gefunden war. Das hat natürlich ein wenig gedauert, und erklärt auch warum wir nun Beiträge seit dem 1.11. verloren haben.

    Woran hast du eigentlich die "Verseuchung" erkannt bzw. woran hast du gemerkt, dass ein bestimmter Backupstand nicht mehr verseucht war? Hast du es an den Sourcecodes oder Datensätzen bemerkt? Irgendwie möchte ich jetzt auch meine Webanwendungen auf solche Verseuchungen überprüfen. Aber eigentlich weis ich gar nicht wonach ich ausschau soll ... 😞

    0
  • N

    Chris++ schrieb:

    Hast du es an den Sourcecodes oder Datensätzen bemerkt

    An der Reverse-Shell, die der Angreifer installiert hatte. Daraufhin die Logs nach dem entsprechenden Angriffsmuster durchforstet und gesucht, bis der Angriff rekonstruiert war.

    Irgendwie möchte ich jetzt auch meine Webanwendungen auf solche Verseuchungen überprüfen. Aber eigentlich weis ich gar nicht wonach ich ausschau soll ... 😞

    Optimal waere, wenn du einen garantiert unkompromittierten Stand haettest und schnell und einfach den ganzen Verzeichnisbaum diffen koenntest.

    0
  • C

    Solange diff nicht kompromittiert wurde^^

    0
  • N

    CppNeuland schrieb:

    Solange diff nicht kompromittiert wurde^^

    Wenn das diff(1) auf der Maschine, wo man den ursprünglichen Stand archiviert hat, kompromittiert ist, hat man auch andere Probleme.

    Abgesehen davon: Typische 0815-PHP-Angriffe zielen auf den Webserver ab, der läuft ja hoffentlich heutzutage nirgends mehr so, dass er den Rest des Systems mit in den Abgrund reißen kann.

    0
  • K

    War das nun eine Lücke in phpBB oder in PHP selbst?
    Könnt ihr mehr Details über die Lücke preisgeben? Nun haben sicher einige Leute, die ebenfalls Seiten betreiben, ein bisschen Panik gekriegt. Wäre super, wenn ihr uns sagen könntet, wie man sich vor solchen Angriffen schützt.

    0
  • C

    Lücken hast du doch eh in jeder Version von Software. Sobald was online ist, kommt man auch rein, denn 0-Day-Exploits gibt es für so ziemlich jede Software in ausreichender Stückzahl. Da ist vom Router, über das OS bis zum Webserver wirklich alles dabei.

    Wer genug Geld investiert, ist in deinem System, außer du nutzt was eigenes. Das müsste dann explizit geknackt werden.

    Das einzige was du mit Updates und allen möglichen Sicherheitstipps abhältst, sind die ScriptKiddies, was ja schon mal was ist. Aber ein System, was am öffentlichen Internet hängt und welches ein gängiges Betriebssystem hat, mit den gängigen Diensten nach außen, ist immer ein offenes System.

    Ich möchte nicht wissen, wie viele professionelle Angriffe nie erkannt werden und wie viele Lücken jahrelang in Systemen schlummern. Wie das Ding, mit der Win16 DLL oder wie die hieß, die von Win3.11 bis Windows7 immer schön die Türe offen gehalten hat.

    0
  • N

    kanikl: Direkt in PHP selbst, ist aber in aktuellen Versionen behoben. Wir waren wegen diverser Kompatibilitaetsprobleme (siehe aktuelle Umlautprobleme und Schwierigkeiten mit dem CMS) noch auf eine alte PHP-Version angewiesen und hatten eine Zeile im Config-File uebersehen, die uns angreifbar machte (PHP via CGI war erlaubt).

    Ich habe meine Notizen gerade nicht zur Hand, aber wenn wir nicht sowohl die alte PHP-Version als auch PHP via CGI erlaubt gehabt haetten, waere das nicht passiert. Dumme Geschichte, aber wenigstens gab es so wieder mal eine komplett frische VM ohne Altlasten. 😉

    CppNeuland: Das klingt fuer mich sehr undifferenziert und uebergeneralisiert. Wuerde ich so nicht unterschreiben.

    0
Anmelden zum Antworten