gefährlicher Code

[Opferlamm :-)]

Hallo allerseits,

nun hat es mich auch erwischt. Eine meiner Homepages wurde gehackt und es wurde ein Javascript installiert, das Malware von einem anderen Server nachlädt. Hab natürlich erstmal alles plattgemacht, Kennwörter geändert und neu installiert. Und nun überlege ich, was man da noch so tun kann.
Da man einen erfolgreichen Hack wohl nicht 100% verhindern kann schwebt mir da noch etwas anderes vor: eine Art Monitoring, welches sich den HTML-Code der einzelnen Seiten holt und auf potentiell gefährlichen Code untersucht (und ggf. auch die HP per .htaccess dichtmacht damit der Schaden für die Kunden so gering wie möglich ist).
Welche HTML-Befehle sind denn gefährlich und sollten nicht vorkommen? Spontan fällt mir ein:

<script...>
<frame...>
<iframe...>
<object...>
<applet...>

Auf diese Elemente kann ich bei der HP sogar komplett verzichten, so dass ein Scannen nach diesen Schlüsselwörtern in diesem Fall ausreichend ist. Habt Ihr noch mehr Befehle, die es zu vermeiden gilt?

viele Grüße vom Opferlamm
(das sich aber wehrt :-))

[ChrisB]

Hi,

Welche HTML-Befehle sind denn gefährlich und sollten nicht vorkommen?

Es gibt immer noch eine „HTML-Befehle“ - und es gibt auch keine per se gefährlichen Elemente, die pauschal auszufiltern wären.

Analysiere, wie der Hack stattgefunden hat, und dichte die Lücke ab.
Halte dabei auch gleich nach potentiellen Lücken Ausschau.

Aber doktore nicht sinnlos an Symptomen herum.

MfG ChrisB

[Opferlamm]

Analysiere, wie der Hack stattgefunden hat, und dichte die Lücke ab.
Halte dabei auch gleich nach potentiellen Lücken Ausschau.

Gute Idee, aber ich hab keine Ahnung, wie das gehen soll. Ich kriege von meinem Provider ja nichtmal ein vernünftiges Serverlog mit dem ich z.B. die ftp-Zugriffe sehen kann.
Wie analysiert man denn sowas im Nachhinein?

[Shadowcrow]

'ǝɯɐu$ ıɥ

Gute Idee, aber ich hab keine Ahnung, wie das gehen soll. Ich kriege von meinem Provider ja nichtmal ein vernünftiges Serverlog mit dem ich z.B. die ftp-Zugriffe sehen kann.
Wie analysiert man denn sowas im Nachhinein?

hast du zugriff auf deine access logs? sudieren!
deine scripts..studieren!
(alle kennwörter ändern is ja eh klar)
HOSTER BESCHEID SAGEN 11elf1zwölw

snɹƃ
ʍopɐɥs

[hotti]

moin,

Da man einen erfolgreichen Hack wohl nicht 100% verhindern kann schwebt mir da noch etwas anderes vor: eine Art Monitoring, welches sich den HTML-Code der einzelnen Seiten holt und auf potentiell gefährlichen Code untersucht...

Warum so kompliziert? Für sowas reicht ne Checksumme.

Hotti

[Opferlamm]

Warum so kompliziert? Für sowas reicht ne Checksumme.

Sicher würde das reichen. Aber meine Seiten ändern sich ab und zu wenn z.B. neue Infos dazukommen. Und die Neueinträgekommen nicht immer von mir sondern vom "Pflegepersonal", d.h. das kriege ich nicht immer mit.

Opferlamm

[Multi]

Sicher würde das reichen. Aber meine Seiten ändern sich ab und zu wenn z.B. neue Infos dazukommen. Und die Neueinträgekommen nicht immer von mir sondern vom "Pflegepersonal", d.h. das kriege ich nicht immer mit.

Dann lässt du die Checksumme nach dem Hochladen automatisch per Script erzeugen und arbeitest dann damit weiter.

[Tom]

Hello,

Welche HTML-Befehle sind denn gefährlich und sollten nicht vorkommen? Spontan fällt mir ein:

HTML-Anweisungen können keine Gefahr für die Dokumente auf dem Server darstellen, denn sie werden ja erst im Client aktiv. Die Frage muss also lauten: wurden Deine Dokumente auf dem Webservcer verändert?

Dies kann üblicherweise nur durch Arbeiten auf dem Host selber oder durch Uploads geschehen. Zum Arbeiten auf dem Host benötigt der "Hacker" eine Shell auf dem Host oder einen infizierten Prozess, der ihm eine Quasi-Shell dann stellt. Wahrscheinlicher ist ein gehackter FTP-Zugang, bei dem das Passwort zu einfach war oder noch wahrscheinlicher ist ein kaputtes Upload-Script, ein Form-Mailer mit Attachmentmöglichkeit, oder sonst irgendeine Möglichkeit, über die Dateien oder Teile davon auf den Server gelangen können.

Eine weitere Möglichkeit stellen unüberlegte Includes in PHP-Dokumenten dar.

Diese berühmt-berüchtigte Methode, sich eine Menusteuerung mittels PHP zu bauen, ist odt die Ursache:

index.php?site=name_des_zu_includierenden_scriptes

Findet an dieser Stelle zwischen "name_des_zu_includierenden_scriptes" und dem tatsächlichen Namen auf dem Datenträger keine beschränkte Übersetzung statt, dann kann ein Angreifer dort meistens auch

index.php?site=url_des_fremdscriptes

einsetzen und schon ist der frende Code aktiv auf dem Server. Von nun an gehört der Server im Rahmen der PHP-Möglichkeiten dem Hacker. Und die sind vielfältig!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Opferlamm]

Die Frage muss also lauten: wurden Deine Dokumente auf dem Webservcer verändert?

Ja, wurden sie.

Wahrscheinlicher ist ein gehackter FTP-Zugang, bei dem das Passwort zu einfach war oder noch wahrscheinlicher ist ein kaputtes Upload-Script, ein Form-Mailer mit Attachmentmöglichkeit, oder sonst irgendeine Möglichkeit, über die Dateien oder Teile davon auf den Server gelangen können.

Ich tippe mal auf ein geratenes Passwort für den FTP-Zugang. Hatte vor ein paar Tagen auch eine exe, die der Virenscanner angemeckert hatte, vielleicht hat die den FTP-Zugang ausgeplaudert??
Uploadmöglichkeiten habe ich in den Scripten nicht, da kann eigentlich nix sein.

Eine weitere Möglichkeit stellen unüberlegte Includes in PHP-Dokumenten dar.

Da bin ich zum Glück auf der sicheren Seite, da meine Includes komplett fest verdrahtet sind. Und auch die sonstigen Übergabeparameter werden vor der Weiterverarbeitung geprüft. Das sollte eigentlich sauber sein.

viele Grüße vom
Opferlamm

[Sven Rautenberg]

Moin!

Ich tippe mal auf ein geratenes Passwort für den FTP-Zugang.

Wie lautete dein altes FTP-Passwort? Kannst du ja jetzt verraten, da du es ja nicht mehr benutzt. Interessiert mich mal, was du als "sicher" angesehen hattest.

Hatte vor ein paar Tagen auch eine exe, die der Virenscanner angemeckert hatte, vielleicht hat die den FTP-Zugang ausgeplaudert??

Nicht unbedingt ausgeschlossen, aber unwahrscheinlich.

Die Tatsache, dass du dich auf einen Virenscanner verlässt, ist aber für sich genommen sehr bedenklich. Nennt man Risikokompensation. Die Annahme, der Virenscanner würde dich vor Virenbefall schützen, veranlasst dich zu einem sorgloseren Umgang mit heruntergeladenen oder gemailten Programmen. Erst wenn der Virenscanner meckert, stoppst du die Aktivität mit der Datei. Dadurch kriegen alle Viren eine Chance, die dein Scanner nicht entdecken kann - und das sind erschreckend viele.

- Sven Rautenberg

[Tim]

Hi,

index.php?site=url_des_fremdscriptes

einsetzen und schon ist der frende Code aktiv auf dem Server. Von nun an gehört der Server im Rahmen der PHP-Möglichkeiten dem Hacker. Und die sind vielfältig!

Ui...reicht eine Püfung a la

if ( file_exists($_GET["site"] . ".php") ) {

zur Einschränkung aus oder liefert sie bei einer fremden, gefährlichen PHP Dateien ebenfalls true?

LG, Tim

[Tom]

Hello,

index.php?site=url_des_fremdscriptes

einsetzen und schon ist der frende Code aktiv auf dem Server. Von nun an gehört der Server im Rahmen der PHP-Möglichkeiten dem Hacker. Und die sind vielfältig!

Ui...reicht eine Püfung a la

if ( file_exists($_GET["site"] . ".php") ) {

zur Einschränkung aus oder liefert sie bei einer fremden, gefährlichen PHP Dateien ebenfalls true?

Man würde das besser immer statisch übersetzen, also nur Zugriffe auf erlaubte includes ermöglichen, und zwar mit einer statischen Tabellen.

Dazu muss das Schlüsselwort (der Wert) in der URL ja auch nicht denselben Wortlaut haben, wie der Dateiname.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Multi]

Man würde das besser immer statisch übersetzen, also nur Zugriffe auf erlaubte includes ermöglichen, und zwar mit einer statischen Tabellen.

Ich benutze nur statische Includes die dann die Seite per Datenbank füllen, hab das Problem selbst also nicht.
Nur mal als Überlegung, weil ich es in einem früheren Projekt so gemacht hab:

Ich habe die Includes in etwa so geladen:

include "/ordner/zum/include/" . $datei . ".php";

Vorher hab ich aus $datei (wird per Get oder Post übergeben) Dinge wie "://" und ".." entfernt, falls vorhanden.
Gibt es dann npoch möglichkeiten, "böse" Dateien einzuschleusen? Wäre natürlich einfacher als eine statische Tabelle, die ja bei  jeder neuen Datei gepflegt werden muss.

[Tom]

Hello,

Ich habe die Includes in etwa so geladen:

include "/ordner/zum/include/" . $datei . ".php";

Vorher hab ich aus $datei (wird per Get oder Post übergeben) Dinge wie "://" und ".." entfernt, falls vorhanden.

Du "kastrierst" also den Paramter und prüfst dann, ob der zusammengesetzte Pfad auch wirklich existiert, nehme ich mal an? Und dann schaust Du vielleicht noch in einer internen Tabelle (*g*) nach, ob der authentifizierte User dieses Include überhaupt nutzen darf?

Da wäre es dann sicher einfacher, gleich in der Tabelle (in der Datenbank) nachzusehen.
Und welche, die (im Abfrageergebnis) nicht drinstehen, werden eben abgelenht.

Gibt es dann noch Nöglichkeiten, "böse" Dateien einzuschleusen? Wäre natürlich einfacher als eine statische Tabelle, die ja bei  jeder neuen Datei gepflegt werden muss.

Das sollte man ja sowieso tun, wenn Includes durch Benutzersteuerung ausgewählt werden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

nun hat es mich auch erwischt. Eine meiner Homepages wurde gehackt und es wurde ein Javascript installiert, das Malware von einem anderen Server nachlädt. Hab natürlich erstmal alles plattgemacht, Kennwörter geändert und neu installiert. Und nun überlege ich, was man da noch so tun kann.

Hast du analysiert, wie der Hack Erfolg haben konnte?

Da man einen erfolgreichen Hack wohl nicht 100% verhindern kann

Natürlich kann man einen Hack nie zu 100,00 Prozent ausschließen. Aber man kann entweder nichts oder sehr viel für die Sicherheit tun. Wenn du gehackt wurdest, hast du bislang offenbar nichts für die Sicherheit getan.

Alleroberstes Gebot für Sicherheit sind sichere Passwörter. Ein sicheres Passwort ist mindestens 8, lieber 10 Zeichen lang, ist kein Wort einer menschlichen Sprache, auch kein Name, enthält kleine und große Buchstaben und Zahlen, gerne auch noch Satzzeichen, und sieht hinreichend "zufällig" aus. Ideal, wenn es tatsächlich mit einem Zufallsgenerator erzeugt wurde.

Noch schöner als ein Passwort für die Zugangskontrolle sind Krypto-Protokolle mit Public-Key-Authentisierung. Das ist vor allem beim SSH-Zugang von Vorteil, denn ein Account, der gar nicht mit Passwort zugänglich ist, kann mit Passwort auch nicht gehackt werden.

Der zweite Punkt: Stetige Aktualisierung von eingesetzter Standardsoftware. Also alles, was man als Blog, Forum, Board, Gästebuch, Uploadskript, Mailer etc. aus typischen Standardquellen bezieht, sollte immer topaktuell gehalten werden. Denn die Angreifer können mit einer simplen Google-Suche herausfinden, welche Softwareversion auf welcher Domain eingesetzt wird - und schlagen genau dann zu, wenn dafür eine Sicherheitslücke bekannt wird.

Wenn diese beiden Punkte beachtet werden, hat man schon mal deutlich mehr für seine eigene Sicherheit getan, als die meisten Hobbywebmaster. Und ist deshalb ein deutlich unattraktiveres und sehr viel kleineres Ziel, deshalb unwahrscheinlicher von erfolgreichen Angriffen betroffen.

Die Wahrscheinlichkeit, dass eine Sicherheitslücke in selbstgeschriebenen Skripten erfolgreich ausgenutzt werden kann, ist zwar gegeben - aber deren Ausnutzung ist viel unwahrscheinlicher, weil für solche eigenen Skripte keine auf HTTP basierenden Sicherheitsscanner nur sehr schwierig automatisiert herausfinden können, ob du angreifbar bist.

Das entbindet dich natürlich nicht von der Notwendigkeit, sichere Skripte zu schreiben, die man nicht mißbrauchen oder hacken kann, aber die Wahrscheinlichkeit, dass darüber tatsächlich ein böser Angreifer Malware platziert, würde ich als eher gering ansehen.

Das allergrößte Einfallstor sind schwache Passworte!

- Sven Rautenberg

[suit]

Alleroberstes Gebot für Sicherheit sind sichere Passwörter. Ein sicheres Passwort ist mindestens 8, lieber 10 Zeichen lang, ist kein Wort einer menschlichen Sprache, auch kein Name, enthält kleine und große Buchstaben und Zahlen, gerne auch noch Satzzeichen, und sieht hinreichend "zufällig" aus. Ideal, wenn es tatsächlich mit einem Zufallsgenerator erzeugt wurde.

Da man sich ein solches Passwort ohnehin idR. nicht merken kann und meistens niemals braucht ist 8 oder 10 Stellen imho ebenfalls zu kurz - da kannst ruhig eine längere Zeichenkette sein.

Bei unsicheren Protokollen wie etwa FTP hilft das natürlich nichts - wenn der Angreifer z.B. ein Scriptkiddie in der Nachbarschaft ist den Traffic des WLAN mitliest.

Noch schöner als ein Passwort für die Zugangskontrolle sind Krypto-Protokolle mit Public-Key-Authentisierung. Das ist vor allem beim SSH-Zugang von Vorteil, denn ein Account, der gar nicht mit Passwort zugänglich ist, kann mit Passwort auch nicht gehackt werden.

Alternativ ist natürlich auch eine Zugangsbeschränkung über ein VPN möglich.

Natürlich sollten geschichten wie Datenbankzugänge entsprechend Beschränkt sein - der Produkt-Account der Datenbank braucht idR. keine GRANT-, ALTER-oder CREATE-Rechte. Entsprechende erweiterte Rechte kann man im bedarfsfall schnell temporär hinzufügen (z.B. bei einem Update, welches die Struktur verändert).

Der zweite Punkt: Stetige Aktualisierung von eingesetzter Standardsoftware. Also alles, was man als Blog, Forum, Board, Gästebuch, Uploadskript, Mailer etc. aus typischen Standardquellen bezieht, sollte immer topaktuell gehalten werden.

Denn die Angreifer können mit einer simplen Google-Suche herausfinden, welche Softwareversion auf welcher Domain eingesetzt wird - und schlagen genau dann zu, wenn dafür eine Sicherheitslücke bekannt wird.

Für solche Zwecke gibst auch einschlägige Suchmaschinen und Tracker - wie z.B. milw0rm.

Setzt man eine Version einer Software mit einer sehr leicht auszunützenden Sicherheitslücke ein, ist man möglicherweise ein leichtes Ziel für ein automatisiertes Mass-Defacement.

Die Wahrscheinlichkeit, dass eine Sicherheitslücke in selbstgeschriebenen Skripten erfolgreich ausgenutzt werden kann, ist zwar gegeben - aber deren Ausnutzung ist viel unwahrscheinlicher, weil für solche eigenen Skripte keine auf HTTP basierenden Sicherheitsscanner nur sehr schwierig automatisiert herausfinden können, ob du angreifbar bist.

Zudem greift in diesem Fall - so seltsam es klingt security through obscurity doch ein bisschen. Ein Script welches nur auf meiner Seite Verwendung findet und ich selbst geschrieben habe hat möglicherweise Sicherheitslücken, aber diese sind (sofern nicht durch Brute-Force ausnutzbar) weniger kritisch als eine bekannte Sicherheitslücke in einem verbreiten System welches ich einsetze.

[Tom]

Hello,

Zudem greift in diesem Fall - so seltsam es klingt security through obscurity doch ein bisschen. Ein Script welches nur auf meiner Seite Verwendung findet und ich selbst geschrieben habe hat möglicherweise Sicherheitslücken, aber diese sind (sofern nicht durch Brute-Force ausnutzbar) weniger kritisch als eine bekannte Sicherheitslücke in einem verbreiten System welches ich einsetze.

Dem widerspreche ich energisch. Alle Seiten, die Uploads enthalten, sind potentiell gefährdet. Die betroffenen Seiten kann man ebenfalls per Suchmaschine finden und dann mit ein paar Klicks sehen, ob es sich lohnt, zu hacken, oder nicht.

Und es scheint in China, Osteuropa usw. viele gute Leute zu geben, die auch viel Zeit und viel Eigenantrieb haben dafür...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg