[English]Im Blog-Beitrag Achtung Mal-/Ransomware: Infiziertes Cookie-Consent-Logo hatte ich vor einigen Stunden über ein Cookie-Consent-Logo auf Amazon AWS berichtet, welches ein Malware-Script ersetzt wurde. Inzwischen habe ich herausgefunden, dass es nicht der Osano Cookie Consent Manager, sondern eine andere, inzwischen eingestellte, Lösung von SilkTide ist, die kompromittiert wurde. Hier eine Ergänzung meiner bisherigen Erkenntnisse, die ich in zwei Beiträge gegliedert habe.
Anzeige
Worum geht es genau?
Angreifer haben wohl ein altes Cookie-Consent-Logo auf Amazon AWS durch ein Malware-Script ersetzt. Ein Blog-Leser hatte mich darauf hingewiesen, dass in seiner Unternehmensumgebung Webseiten wie bwl – wissen net / schulferien org etc. plötzlich Virenschutzwarnungen auslösten. Die URL *https://s3-eu-west-1.amazonaws.com/assets.cookieconsent.silktide.com/cookie-consent-logo.png löst die nachfolgend gezeigte Warnung des Virenscanners aus.
Ich war der Geschichte nachgegangen und konnte feststellen, dass die ausgelieferte vorgebliche Logo-Datei einen Alarm des Virenscanners auslöste. Den Aufhänger für die Geschichte könnt ihr ja im Blog-Beitrag Achtung Mal-/Ransomware: Infiziertes Cookie-Consent-Logo im Detail nachlesen.
Alter SilkTide-Code gekapert
Im ersten Blog-Blog-Beitrag hatte ich noch gemutmaßt, dass eventuell eine alte Version der Osano Cookie Consent-Lösung gekapert wurde. Das hat sich aber als falsche Annahme erwiesen – Arlo Gilbert, CEO & Co-Founder von Osano hat mich per Mail kontaktiert und folgende Informationen übermittelt.
Anzeige
It is nice to meet you by email. Forgive me, but I do not speak German so I hope that writing you in English is ok.
Your article about the cookie consent ransomware was great, but the reference to our company Osano is inaccurate. The cookie consent solution that hosted that logo was from a company named SilkTide in the UK and the library was written in 2012. That cookie consent library is not from Osano in the USA.
Silk Tide stopped development of their cookie consent solution several years ago. We have a partnership with SilkTide whereby they redirect visitors to their legacy open source products to Osano's open source product by redirecting the URL to our pages.
Es wird an dieser Stelle durch die Mail von Osano klar, dass deren Lösung in keiner Weise betroffen ist. Das Problem stellt die inzwischen in der Entwicklung eingestellte SilkTide-Lösung dar.
Warum der GitHub-Eintrag gelöscht wurde
Durch die Partnerschaft zwischen SilkTide und Osano, wo SilkTide-Besucher direkt auf die Open Source-Lösung von Osano umgeleitet werden, kam es zur Verwirrung. Daher erklärt sich auch, warum der Eintrag auf GitHub gelöscht wurde.
To be clear, our open source solution is not the same code as the library which referenced this attack. The open source code we maintain is different than SilkTide's code. This is also why we deleted the GitHub issue, because it is not our open source or our commercial cookie consent products that were affected and we do not want to scare our users since the issue is not related to our code.
When the security researchers mistakenly contacted us, because we care about security in general and because we saw the potential for confusion about who maintains the library, we reached out to AWS abuse and also SilkTide notifying them about the security report. AWS then suspended the account which was hosting this ransomware. If you read the research report, you'll note that the phrase "Osano" is not in the URL of the offending image.
Was hinter den Kulissen passiert ist
Arlo Gilbert hat mir dann in seiner Mail noch seine Vermutung bzw. das, was ihm bekannt ist, zur Übernahme des Amazon AWS S3 Buckets offen gelegt.
- Several years ago, SilkTide deleted the bucket which hosted that image after they decommissioned the solution.
- Recently an attacker discovered that the image was broken.
- The attacker created a new S3 bucket with the same name on AWS.
- The attacker uploaded an executable file in the path of the image file on this new bucket.
Die Leute von SilkTide haben das Amazon AWS S3 Bucket vor einigen Jahren gekündigt. Offenbar haben Cyber-Kriminelle sofort bemerkt, dass dieses SilkTide S3 Bucket dekommissioniert wurde. Die Leute haben ein neues S3 Bucket mit dem gleichen Namen auf Amazons AWS angelegt und dort den kopierten Code veröffentlicht. Da sie Kontrolle über das S3 Bucket besitzen, konnten sie immer mal wieder Dateien austauschen.
Arlo Gilbert vergleicht den Angriff mit der Registrierung einer aufgegebenen Domain durch einen böswilligen Angreifer. Zum gelöschten GitHub Issues-Eintrag hat Gilbert mir auch eine Erklärung geliefert. Ein Benutzer hatte dort ja einen Hinweis mit dem Link auf die manipulierte .png-Logo-Datei gepostet
Our team quickly reviewed the report that the researchers provided, and although it is bad what happened, my understanding is that the image src would not execute the file, it would still show as a broken image and would trigger anti-virus warnings. The only way the executable would load is if a user downloaded the .png file, changed the extension to .exe, and then opened the .exe file. So while you are correct that this is a security issue, there is no evidence that any user was affected by this and although we helped solve the problem, we were not part of the problem.
Bezüglich der Sicherheitseinschätzung, dass die durch eine Datei, die Scripte enthält, ersetzte .png-Datei nicht ausgeführt werden kann: Da fehlt mir aktuell das Wissen, um diesen Schluss zu bestätigen oder zu widerlegen. Mir sind noch Fälle erinnerlich, wo Schadcode Scripte in Dateien eingebettet wurde, im Wissen, dass Fehler in Anzeigeprogrammen dann genau diesen Code ungewollt ausführten. Es ist jedenfalls eine ungute und potentiell riskante Situation.
Artikelreihe
Achtung Mal-/Ransomware: Infiziertes Cookie-Consent-Logo
Kompromittiertes SilkTide Cookie-Consent Logo – Teil 2
Kompromittiertes SilkTide Cookie-Consent Logo – Teil 3
Anzeige
