[German]In the blog post Warning: Infected Cookie Consent logo delivers Ransomware I reported a few days ago about a logo file for a Cookie Consent solution on Amazon AWS that has been replaced by a malware script. Meanwhile I found out that it is not the Osano Cookie Consent Manager but another, now discontinued, solution from SilkTide that has been compromised. Here is a supplement to my previous findings, which I have divided into two articles.
Advertising
A brief background
Attackers have replaced an old Cookie Content logo on Amazon AWS with a malware script. A blog reader had pointed out to me that in his corporate environment websites like bwl – wissen net / schulferien org etc. suddenly triggered virus protection warnings. The URL *https[://]s3-eu-west-1.amazonaws[.]com/assets.cookieconsent.silktide.com/cookie-consent-logo.png triggered the virus scanner warning shown below.
I found out that the alleged logo file delivered from the S3 bucket triggered my virus scanner. You can read the story in the blog post Warning: Infected Cookie Consent logo delivers Ransomware in detail.
Old SilkTide code hijacked
In the first blog post I suspected that an old version of the Osano Cookie Consent solution might have been hijacked. But that turned out to be a false assumption – Arlo Gilbert, CEO & Co-Founder of Osano contacted me by mail and provided the following information.
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.
At this point it becomes clear that Osano's solution is not affected in any way. The problem is the SilkTide solution which has been discontinued in development since years.
Advertising
Why the GitHub entry was deleted
The partnership between SilkTide and Osano, where SilkTide visitors are redirected directly to Osano's open source solution, caused confusion. This explains why the entry on GitHub was deleted.
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.
What happened behind the scenes
Arlo Gilbert then revealed in his mail to me his assumption or what he knows about the takeover of the Amazon AWS S3 Bucket.
- 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.
The folks at SilkTide cancelled the Amazon AWS S3 Bucket a few years ago. Apparently cyber criminals noticed immediately that this SilkTide S3 Bucket was decommissioned. People created a new S3 Bucket with the same name on Amazon AWS and published the copied code there. Since they have control over the S3 Bucket, they could exchange files from time to time.
Arlo Gilbert compares the attack to the registration of a given domain by a malicious attacker. Gilbert also gave me an explanation for the deleted GitHub Issues entry. A user has posted a note with a link to the manipulated .png logo file
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.
Regarding the security assessment that the .png file replaced by a file that contains scripts cannot be executed I currently lack the knowledge to confirm or disprove that conclusion. I recall cases where malicious code scripts were embedded in files, knowing that errors in display programs would then unintentionally execute that very code. In any case, it is an unpleasant and potentially risky situation.
Article series
Warning: Infected Cookie Consent logo delivers Ransomware
Compromised SilkTide Cookie-Consent Logo – Part 2
Compromised SilkTide Cookie-Consent Logo – Part 3
