2018-05-31 5 Minuten

Jemand hat versucht, einen meiner Onlineshops zu hacken.

Da sitzt man gemütlich um 8 Uhr 30 und schreibt eine Präsentation für einen Workshop, und erhält folgende E-Mail:

“Wordfence Alert] trueyou-fashion.com Increased Attack Rate”

Aha.

“The Wordfence Web Application Firewall has blocked 213 attacks over the last 10 minutes.”

Mkay.

Mai 30, 2018 6:29am 209.90.225.115 (United States) Blocked for SQL Injection in POST body

Hmm.

Da versucht doch jemand wirklich gerade, die Webseite meiner Studienkollegen zu übernehmen.

Und ich muss zugeben: ich habe mich gefreut. Über die Möglichkeit gefreut, den Angriff live verfolgen zu können. Und etwas zu lernen.

Die Seite selbst ist gut abgesichert und up-to-date. Dass hier also irgendetwas passiert, da mache ich mir keine Sorgen.

Trotzdem:

Erstmal blockieren

Ich logge mich sofort in die Webseite ein, und werde mit folgendem Screen begrüßt:

Interessant:

  • Die Angriffe kommen alle von einer IP-Adresse. Das würde ich sagen ist eher unüblich. Weil es dann natürlich leicht ist, den Angreifer zu blockieren (was ich dann auch getan habe).
  • Dass hier USA steht, ist eigentlich relativ sinnlos. Das sagt nur aus, woher die IP-Adresse kommt – nicht aber der Angreifer. Das kann mit jedem handelsüblichen VPN “gefälscht” werden.

Achtung, DSGVO:

Und genau deshalb ist es so wichtig, dass ich als Webseitenbetreiber die IP-Adresse als Ganzes verarbeiten darf. Würde ich hier die IP z.B. auf 209.90.xxx.xxx anonymisieren, hätte weder mein Security-Plugin, noch ich eine Chance, Angriffe zu analysieren.

Nicht einmal die blockierte IP-Adresse hält den Angreifer davon hab, es weiter zu versuchen:

Auch heute früh wurde bereits wieder versucht, die Seite anzugreifen. Aber weit nicht mit dem Wumms des Angriffs vom 30. Mai.

Erster Check – Ist der Angreifer schon drin?

Das ist relativ einfach herauszufinden. Mein Security-Plugin bietet die Möglichkeit, die Seite auf Schadsoftware zu scannen.

Nix gefunden.

Phew.

Auch jetzt, 1 Tag später: keine verdächtige Aktivität.

Aber jetzt geht es erst an den richtig interessanten Part: die Analyse.

Was wurde eigentlich versucht? Was war das Ziel?

Die Analyse von Angriffen ist ein Thema, in das könnte ich mich stundenlang vertiefen. Das ist Detektivarbeit vom Feinsten 🧐.

Hierzu lade ich mir die Log-Files der Zugriffe auf die Webseite herunter, und filtere die normalen Userzugriffe heraus.

Normalerweise passieren so Angriffe / Scans von vielen IP-Adressen aus, um eben genau zu vermeiden, dass mit einem Block der gesamte Angriff vorbei ist. Hier hat es mir der Angreifer leicht gemacht, den Angriff zu analysieren.

So sieht das Ganze aus:

209.90.225.115 – – [30/May/2018:08:24:57 +0200] „POST //.asp;.jpg HTTP/1.1“ 404 27624 „http://www.trueyou-fashion.com//.asp;.jpg“ „Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)“ „www.trueyou-fashion.com“
209.90.225.115 – – [30/May/2018:08:24:58 +0200] „POST //.asp;.jpg HTTP/1.1“ 403 455 „http://www.trueyou-fashion.com//.asp;.jpg“ „Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)“ „www.trueyou-fashion.com“
209.90.225.115 – – [30/May/2018:08:25:00 +0200] „POST //.asp;.jpg HTTP/1.1“ 404 27624 „http://www.trueyou-fashion.com//.asp;.jpg“ „Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)“ „www.trueyou-fashion.com“
209.90.225.115 – – [30/May/2018:08:25:01 +0200] „POST //.asp;.jpg HTTP/1.1“ 404 27624 „http://www.trueyou-fashion.com//.asp;.jpg“ „Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1)“ „www.trueyou-fashion.com“

Jede Zeile, die du hier liest, ist ein Zugriff auf den Server, auf dem die Webseite läuft. Dieser enthält:

  • die IP-Adresse
  • Datum
  • Was angefragt wurde (also welche URL genau)
  • Welcher Browser
  • Wo der User herkommt (Referrer)
  • Ein HTTP Status-Code, der sagt, was das Ergebnis des Zugriffs war.

Vielleicht hast du schon einmal irgendwo die Zahl “404” gelesen, als du auf eine Webseite wolltest. Das ist einer dieser Statuscodes. 404 heißt in diesem Fall: “Nicht gefunden”.

Andere Statuscodes wären:

200 – “OK”

403 – “Zugriff nicht erlaubt”

418 – “I’m a teapot”

Ich versuche jetzt, mir auf Basis der angefragten URL und des Statuscodes herauszulesen, was eigentlich versucht wurde.

Wordfence hat mir bereits mitgeteilt, dass eine SQL-Injection versucht wurde. Das ist eine Sicherheitslücke, die in modernen CMS eigentlich nicht mehr bzw. kaum mehr vorkommt – aber hin und wieder wird noch eine gefunden.

Zum Glück sehe ich bei allen versuchten Angriffen nur 404 und 403 – das heißt keine der Dateien, die angefragt wurden, haben überhaupt existiert oder sie waren richtig gesichert. Wäre hier irgendwo ein 200 dabei, hätte ich hier weiter ins Detail analysieren müssen.

Wir wissen jetzt also:

  • Der Angreifer hat 1 IP-Adresse verwendet,
  • hat versucht eine SQL-Injection auszunutzen – und zwar automatisiert (Es wurde also ein Tool für diesen Angriff verwendet),
  • hat es aber nicht geschafft, die Seite zu übernehmen.

Die Basics, lieber Angreifer, die Basics!

Ein besonders komischer Punkt, der mir sofort ins Auge gestochen ist, war folgender:

Der Typ hat sich nicht einmal angeschaut, welche Technologie hinter dem Onlineshop steht!

Vielleicht ist es dir oben schon aufgefallen: Im Log ist zu lesen, dass .asp-Dateien angefragt wurden. Diese gehören zum .NET-Framework und haben überhaupt nix mit WordPress zu tun. Pfff.

Ich weiß nicht, ob das nur mein Qualitätsstandard ist, aber:

Würde ich versuchen, einen Onlineshop zu hacken, schaue ich mir zumindest einmal an, auf welcher Technologie der läuft.

Ich bin fast beleidigt, dass meine Webseite nur so einen Low-Effort-Angriff wert ist.

Aber immerhin wissen wir jetzt, dass es nicht persönlich war, nur ein Numbers Game.

Fazit

  • Insgesamt gab es 1.800 Zugriffe auf die Webseite, wovon 806 als “Complex Attacks” eingestuft wurden.
  • Kein Schaden wurde zugefügt
  • Es war nicht persönlich

Das Einzige, was mir jetzt noch fehlt, ist ein Grund. Hier kann ich jedoch nur spekulieren.

Was ich aber vermute ist, dass das Ziel nicht ganz zufällig ausgewählt wurde. Auf der Webseite läuft WooCommerce, mit dem man Online-Shops erstellen kann. Und Onlineshops sind ein lukrativeres Ziel als zum Beispiel ein einfacherer Blog.

Somit könnte der Angreifer

  • Zahlungsdaten / Bankdaten abgreifen
  • Schadsoftware an die User verbreiten
  • Cryptojacking betreiben

Da sind schon ein paar interessante und finanziell lukrative Spielchen dabei.

Alles in Allem war das der (bis jetzt) “intensivste” Angriff auf eine meiner Kundenwebseiten. Ich kann nur hoffen, dass es so bleibt.

Aber wahrscheinlich ist es nicht.

Von Hackern, Wordpress, SEO & Co

  • Wo kommt mein Spam her?
  • Wie leicht ist es, eine Wordpress Seite zu hacken?
  • Wie Umzugsfirmen ihre Gaunereien mit SEO umsetzen

...wöchentlich in deiner Inbox! 🚀

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.