Wenn Online-Verkäufe steigen – So stellt ihr sicher, dass eure E-Commerce-Plattform nicht für Betrug genutzt wird

Trotz der angespannten wirtschaftlichen Lage verzeichnet der E-Commerce-Sektor seit Anfang März eine 25-prozentige Steigerung¹. Gleichzeitig haben jedoch auch die Betrugsversuche zugenommen. Laut Malwarebytes ist das Online-Kreditkarten-Skimming allein im März um 26% angestiegen².

In unserem im April veröffentlichten Blogbeitrag „Staff Picks for Splunk Security Reading“ (derzeit nur in englischer Sprache verfügbar) habe ich auf eine Geschichte über eine E-Commerce-Website Bezug genommen, die mit einem virtuellen Kreditkarten-Skimmer gehackt wurde (vielen Dank an Matthew Joseff, der mich darauf aufmerksam gemacht hat). Der Autor der Geschichte beendet die Analyse mit der Aufforderung an die Kunden, sich mit clientseitiger (vom Verbraucher installierter) Malware Detection/Prevention zu schützen. Gegen diesen Ansatz habe ich nichts einzuwenden, aber nicht alle Antivirus- (AV) / Anti-Malware- (AM) Lösungen schützen vor dieser Art von Angriffen. Und natürlich haben Betreiber von E-Commerce-Websiten auch eine Verantwortung für den Schutz ihrer Systeme und der jeweiligen Kundendaten. Sehen wir uns also drei Möglichkeiten an, mit denen E-Commerce-Websiten diese Art von Angriffen erkennen und Kunden vor Datendiebstahl schützen können.

Hier eine kurze Zusammenfassung der Ereignisse, wie von Malwarebytes berichtet:

1. Die Angreifer erhielten Zugang zu Dateien auf der Opfer-Website (mutmaßlich aufgrund von veralteter Magento E-Commerce-Software).
2. Die Startseite wurde verändert (durch Hinzufügen eines verschleierten JavaScripts), sodass ein verstecktes PNG-Bild geladen werden konnte.
3. Dieses PNG-Bild enthielt bösartigen JavaScript-Code.
4. CyberSource wird als Händler-Prozessor (Merchant-Processor) verwendet, und die User werden zur Eingabe ihrer Kreditkarteninformationen berechtigterweise auf eine CyberSource-Bezahlseite weitergeleitet.
5. Das JavaScript in der PNG-Datei erzeugte einen iFrame auf der Bezahlseite und überlagerte damit den bestehenden Checkout-iFrame von CyberSource.
6. Die bösartige Bezahlseite wurde von „deskofhelp[.]com“ geladen (registriert für eine E-Mail-Adresse von Yandex[.]ru)
7. Die User gaben Ihre Kreditkartendaten in den bösartigen iFrame ein, erhielten eine Sitzungs-Timeout-Meldung und wurden anschließend auf den echten Kassen-iFrame von CyberSource umgeleitet.
8. Die Betrüger entwendeten folgende Zahlungsdaten:
   - Vor- und Nachname
   - Rechnungsadresse
   - Telefonnummer
   - Kreditkartennummer
   - Ablaufdatum der Kreditkarte
   - Sicherheitscode der Kreditkarte
   

Dabei ist zu beachten, dass der bösartige iFrame von einer bösartigen Remote-Website nur im Browser des Benutzers dargestellt wurde. Direkt in den Webprotokollen des Händlers finden sich keine Hinweise darauf, dass der Browser des Kunden eine Anforderung an diese Remote-Website gesendet hat.  

Schauen wir uns drei Möglichkeiten an, die Splunk geboten hätte, um diesen Angriff zu erkennen. Dabei sollte man immer im Auge behalten, dass die Erkennung von Anomalien ein wichtiger Bestandteil der Betrugserkennung ist.

1. Monitoring des Betriebssystems:

Der erste Punkt, an dem ihr ansetzen könnt, sind Betriebssystemprotokolle. Das Ändern/Hinzufügen/Löschen von Dateien ist in den meisten Betriebssystemen einfach zu protokollieren. Native, Open-Source- und kostenpflichtige Lösungen können zur Überwachung auf Änderungen verwendet werden. Für wertvolle Ziele wie öffentlich zugängliche Server sollte dieses Monitoring aktiviert sein. Damit wäre die bösartige PNG-Datei erkannt worden, die dem System hinzugefügt wurde, ebenso wie die an der Startseitendatei vorgenommenen Änderungen. Beide Events hätten bei Security-, DevOps- bzw. Content-Management-Teams die Alarmglocken schrillen lassen müssen, da sie nicht erwartet wurden.

Für Splunk stehen auf Splunkbase technische Add-ons (TA) zur Verfügung, die das Monitoring dieser Events und die Ausgabe von Warnmeldungen vereinfachen. Darüber hinaus gibt es zahlreiche Blogbeiträge von Splunk und Drittanbietern, die sich mit dem Audit von Dateisystemen unter Windows und Linux befassen.

2. Website-Metriken

Website-Metriken bieten eine weitere Möglichkeit zur Erkennung eines Angriffs. Die durchschnittliche Checkout-Zeit und Warenkorbabbrüche sollten als Metriken bekannt sein. Diese sind normalerweise für Marketing- und Site-Reliability-Teams besonders wichtig. Entweder braucht der Kunde doppelt so lange, um den Checkout-Prozess abzuschließen, oder er bricht den Vorgang nach der Timeout-Meldung ab. In beiden Fällen sollten die Metriken für diese unterschiedlichen Events einen starken Anstieg aufweisen. Auf Splunkbase ist eine App für Website-Metriken verfügbar, die interessante Details liefern kann. Einige dieser Metriken können jedoch auch mit einfachen Suchen problemlos berechnet werden.

Apache-Zugriffsprotokolle bieten beispielsweise eine Möglichkeit, verdächtige Aktivitäten auszumachen. Das Monitoring der Checkout-Zeit ist ganz einfach. Wenn ihr die Seite davor und danach kennt, braucht ihr nur die Differenz zwischen beiden zu berechnen. Ich habe mir die Freiheit genommen, das Ganze anhand einiger Beispieldaten zu demonstrieren, da mir keine echten Zahlungsprozessordaten vorliegen. Wenn ich die Zeit zwischen der Anzeige des Warenkorbs (Cart View) und der Seite nach dem Abschluss der Bestellung (Post to Checkout) berechne, kann ich die Zeit zwischen zwei Haupt-Events ermitteln und einen Stundendurchschnitt anzeigen:

index="web-site" sourcetype="access_combined_wcookie" | transaction JSESSIONID startswith="GET /viewCart" endswith="POST /checkout" | timechart span=1h avg(duration)

Meine Daten ergeben durchschnittlich 5,5 Sekunden für meinen „Checkout-Prozess“. Die Checkout-Zeit einer echten E-Commerce-Website kann 30 Sekunden oder mehr betragen, aber die fiktive Fehlerseite und der zweite Checkout-Prozess würden die durchschnittliche Checkout-Zeit auf jeden Fall beträchtlich verlängern.

Außerdem können wir einige coole Mathefunktionen von Splunk einsetzen, um Transaktionen zu finden, die länger als die Zeit plus zweimal die Standardabweichung („time + 2x standard deviations“) eines durchschnittlichen Checkouts sind, indem wir die Standardabweichung der letzten 100 Transaktionen berechnen, diese (oder ein Vielfaches der Standardabweichung) zur durchschnittlichen Transaktionszeit addieren und dann mit der tatsächlichen Transaktionszeit vergleichen:

index="web-site" sourcetype="access_combined_wcookie" | transaction JSESSIONID startswith="GET /viewCart" endswith="POST /checkout" | table _time, duration, JSESSIONID 

| streamstats window=100 avg("duration") as avg stdev("duration") as stdev

| eval upperBound=(avg+stdev*2)

| eval isOutlier=if('duration' > upperBound, 1, 0)

| table "_time", "JSESSIONID", "duration", "upperBound", "isOutlier"

| sort - isOutlier

Mit wenigen Klicks in der GUI ließe sich dies als wiederkehrende Suche (alle paar Minuten) planen und es könnte eine Warnmeldung ausgegeben werden, wenn die Ausreißer-Bedingung erfüllt ist. Splunk unterstützt viele unterschiedliche Typen von Warnmeldungen, unter anderem E-Mail, Skripte und Webhooks. 

Darüber hinaus dürfte die fiktive Fehlerseite die Customer Experience beeinträchtigen und zu einer höheren Rate von Warenkorbabbrüchen führen. Durch Subtrahieren erfolgreich abgeschlossener Bestellungen von der Gesamtzahl der Warenkorbzugriffe erhalten wir die Warenkorbabbrüche. Nachfolgend eine Möglichkeit, diese Daten anzuzeigen, es gibt jedoch in Abhängigkeit von der Beschaffenheit eurer Protokolle noch viele weitere:

index="web-site" sourcetype="access_combined_wcookie" "GET /viewCart" 

| timechart span=1h dc(JSESSIONID) AS Cart

| appendcols 

    [search index="web-site" sourcetype="access_combined_wcookie" "POST /checkout" 

    | timechart span=1h dc(JSESSIONID) AS Purchased] 

| eval Abandoned=Cart-Purchased 

| table _time, Cart, Purchased, Abandoned

Die Anzahl der Ressourcen-Zugriffe ist ebenfalls eine gängige Metrik, über die Marketing-Teams und andere feststellen können, ob Seiten schwer zu finden oder nicht interessant sind, oder ob Bilder vielleicht im Cache gespeichert werden müssen, damit häufiger darauf zugegriffen wird. Die bösartige PNG-Datei müsste aus dem Nichts aufgetaucht sein, und irgendjemand sollte sich gefragt haben, warum sie eine so hohe Zugriffsrate hatte. Selbst wenn die Datei auf der Seite versteckt war, wurde doch die HTTP-Anforderung protokolliert.

Nachfolgend eine einfache Suche anhand einiger Beispieldaten aus einem Apache-Zugriffsprotokoll mit den Webressourcen, auf die im Laufe der Zeit zugegriffen wurde. Ihr seht, dass die Datei „member.php“ an einem Tag eine sehr hohe Spitze aufweist:

index=botsv2 sourcetype="access_combined"   | timechart  span=1d count by file limit=20 usenull=false useother=false

3. Website-Monitoring

Zu guter Letzt hätte diese Gefahr auch mit automatisiertem Website-Monitoring erkannt werden können. Skriptbasiertes Monitoring einer Website ist gängige Praxis und kommt seit Jahren zum Einsatz, um die Websitestabilität zu wahren und dafür zu sorgen, dass die Abläufe durchgängig richtig funktionieren. Wenn Ressourcen von Drittanbietern (Zahlungs-Prozessoren) Teil einer Website sind, muss unbedingt sichergestellt werden, dass alles reibungslos läuft und diese externen Anbieter sämtliche SLAs einhalten. Selenium WebDriver ist eine Open-Source-Lösung, die das skriptbasierte Testen einer vollständigen Transaktion auf der E-Commerce-Website ermöglicht. Wären die Details mit diesem Client-Monitoring-System protokolliert worden, dann hätten die Enterprise-Proxy-Protokolle einige wichtige Events offenbart:

• Die Sitzungs-Timeout-Meldung hätte (obwohl fiktiv) ein Event generieren sollen, da die Seite unerwartet war (auch legitime Timeouts sollten zu Warnmeldungen führen).
• Ein Hash der gefälschten Bezahlseite oder gefälschten Sitzungs-Timeout-Seite hätte nicht mit dem Hash der erwarteten Seite übereingestimmt.
• DNS-Anforderungen vom Client (erfasst auf dem Client oder im Netzwerk) hätten eine unbekannte Domäne und DNS-Anforderung angezeigt (deskofhelp[dot]com).
• Die Betrüger hatten es versäumt, den bösartigen iFrame für die nicht-englischsprachigen Websites zu übersetzen. Das Testen der spanischen und französischen Websites hätte eine englische Kassenseite zurückgegeben – ein weiteres unerwartetes Ergebnis, das eine Warnmeldung auslösen sollte.
  

Dies sind keine neuen Erkennungslösungen. Sie wurden bereits in Blogbeiträgen zum Website-Monitoring und zum Erkennen neuer Domänen erörtert.

Auf Grundlage des oben erwähnten Blogbeitrags zum Erkennen neuer Domänen wurde diese Erkennungsmethode zur kostenlos verfügbaren Splunk Security Essentials App hinzugefügt. Ihr findet diese Suche, indem Ihr nach dem Begriff „neue Domäne“ („new domain“) sucht.

Vielleicht ist einigen von euch aufgefallen, dass manche Methoden und Verweise, die ich verlinkt habe, schon ein paar Jahre alt sind. Daran lässt sich erkennen, dass Angriffe nicht unbedingt neu oder hochmodern sein müssen, um wirkungsvoll zu sein – und dass altbewährte Monitoring-Systeme noch immer sehr wirkungsvoll sind.

Die oben illustrierten Erkennungstechniken hängen nicht alle mit dem Bereich Cyber-Security zusammen. Splunk wird auch regelmäßig von IT Operations-, Marketing- und Fraud-Operations-Teams verwendet. Wäre Splunk nur von einem dieser Teams eingesetzt worden, dann wäre dieser Sicherheitsverstoß wesentlich früher erkannt worden. Und nun stellt euch vor, was man erreichen kann, wenn alle Teams Splunk Enterprise einsetzen und auf der Grundlage derselben Daten zusammenarbeiten.

Vielen Dank an James Brodsky für die Hilfe beim Sammeln von Ideen für diese Erkennungsszenarios.

<sub><sup>1. https://www.digitalcommerce360.com/2020/04/01/us-ecommerce-sales-rise-25-since-beginning-of-march/
2. https://blog.malwarebytes.com/cybercrime/2020/04/online-credit-card-skimming-increases-by-26-in-march/</sup></sub>

*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Online Sales Are Up! Ensure Your E-Commerce Platform is Not Being Used for Fraud (11.05.2020).