SoylentNews

23/02/15/161207 story

Thousands of Websites Infected to Redirect Users in Google Ads View-Pumping Scam

posted by janrinok on Thursday February 16, @04:20PM   

upstart writes:

WordPress sites infected to redirect visitors to crypto Q&A spam:

Security researchers at Sucuri have spent the last few months tracking malware that diverts users to fraudulent pages to inflate Google ad impressions. The campaign has infected over 10,000 websites, causing them to redirect visitors to completely different spam sites.

Suspect pages often have Q&A forms mentioning Bitcoin or other blockchain-related subjects. Savvy users might assume these sites are trying to sell Bitcoin or other cryptocurrencies, possibly for a pump-and-dump scheme. That may be the case, but Sucuri theorizes that all of the text is just filler content covering up the scam's actual revenue stream, Google ad views.

A clue suggesting this is that many of the URLs involved appear in a browser's address bar as if the user clicked on Google search results leading to the sites in question. The ruse could be an attempt to disguise the redirects as clicks from search results in Google's backend, potentially inflating search impressions for ad revenue. However, it is unclear if this trick works because Google doesn't register any search result clicks matching the disguised redirects.

Sucuri first noticed the malware in September, but the campaign intensified after the security group's first report in November. In 2023 alone, researchers tracked over 2,600 infected sites redirecting visitors to over 70 new fraudulent domains.

The scammers initially hid their real IP addresses using CloudFlare, but the service booted them after the November story. They have since migrated to DDoS-Guard, a similar but controversial Russian service.

The campaign mainly targets WordPress sites, suggesting existing zero-day WordPress vulnerabilities. Moreover, the malicious code can hide through obfuscation. It can also temporarily deactivate when administrators log in. Site operators should secure their admin panels through two-factor authentication and ensure their sites' software is up-to-date.

---

Original Submission

«  Bing's AI-Based Chat Learns Denial and Gaslighting | Seven States Push to Require ID for Watching Porn Online  »

• Gotta kill those ad-blockers, though. (Score: 4, Informative) by Freeman on Thursday February 16, @05:25PM

  by Freeman (732) on Thursday February 16, @05:25PM (#1292032) Journal

  https://tech.co/news/google-chrome-ad-blockers-2023 [tech.co] https://developer.chrome.com/blog/more-mv2-transition/ [chrome.com]

  In With the New Extension Manifest, Out With the Old

  Here's the newly revealed timeline, via Google's own blog:

          Starting in January 2023 in Chrome 112, Chrome may run experiments to turn off support for Manifest V2 extensions in Canary, Dev, and Beta channels.
          Starting in June 2023 in Chrome 115, Chrome may run experiments to turn off support for Manifest V2 extensions in all channels, including stable channel.

  If you're a developer with a Manifest V2 extension, you'll have to update it following another timeline as well.

          In January 2023, use of Manifest V3 will become a prerequisite for the Featured badge as we raise the security bar for extensions we highlight in the store.
          In June 2023, the Chrome Web Store will no longer allow Manifest V2 items to be published with visibility set to Public. All existing Manifest V2 items with visibility set to Public at that time will have their visibility changed to Unlisted.
          In January 2024, following the expiration of the Manifest V2 enterprise policy, the Chrome Web Store will remove all remaining Manifest V2 items from the store.

  Sure, I've heard the whole, Google's going to kill ad-blocking for a while now. That doesn't mean that they aren't actively, but stealthily doing exactly that.

  https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security [eff.org]

  Manifest V3 replaces these capabilities with a narrowly-defined API (declarativeNetRequest) that will limit developers to a preset number of ways of modifying web requests. Extensions won’t be able to modify most headers or make decisions about whether to block or redirect based on contextual data. This new API appears to be based on a simplified version of Adblock Plus. If your extension doesn’t work just like Adblock Plus, you will find yourself trying to fit a square peg into a round hole.

  If you think of a cool feature in the future that doesn’t fit into the Adblock Plus model, you won’t be able to make an extension using your idea unless you can get Google to implement it first. Good luck! Google doesn’t have an encouraging track record of implementing functionality that developers want, nor is it at the top of Google’s own priority list. Legitimate use cases will never get a chance in Chrome for any number of reasons. Whether due to lack of resources or plain apathy, the end result will be the same—removing these capabilities means less security and privacy protection for Chrome’s users.

  For developers of ad- and tracker-blocking extensions, flexible APIs aren’t just nice to have, they are a requirement. When particular privacy protections gain popularity, ads and trackers evolve to evade them. As a result, the blocking extensions need to evolve too, or risk becoming irrelevant. We’ve already seen trackers adapt in response to privacy features like Apple’s Intelligent Tracking Prevention and Firefox’s built-in content blocking; in turn, pro-privacy browsers and extensions have had to develop innovative new countermeasures. If Google decides that privacy extensions can only work in one specific way, it will be permanently tipping the scales in favor of ads and trackers.

  --
  Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"