nparker - can you evaluate whether there is an issue here? Thanks!

I'll inform safe browsing ops team of this new social engineering sites (usn(.)rewardcentervirusandroid(.)icu) and investigate its landing page and triggering ads. 

Currently it gives me 403 when directly visiting it on android.

The part I'm not sure is what do you mean by 0 day here... 
"This may hint to a potential exploit path: there may be a method to generate multiple malicious redirects whereby Chrome will eventually let one through."

If Chrome knows the redirects are malicious, it will definitely block it unless this malicious site hasn't been flagged by safe browsing service.  Could you provide more details (e.g. code pointers) of why you think "chrome will eventually let one through."?  

Thanks!

Per #3, Needs feedback from reporter

+pstanton@google.com from safe browsing ops

This escalated quickly.

So I'm unable to reproduce the ad on various platforms both controlled and otherwise. My initial suspicion of an 0d stemmed from the following three observations:

1) the presence of the Redirect Blocked notice on the initial Forbes tab after tabbing out of the new tab (as seen in the 3rd screenshot),
2) the fact that a new-origin pop-up tab successfully appeared and subsequently stole focus, circumventing any in-built Pop-Up Blocking that Chrome may have. I'm not familiar with the specific requirements for triggering Chrome's Pop-Up Blocking other than "Chrome blocks pop-ups that users might not find useful."
3) the fact that all ad resources at Forbes appear to render cross-origin, something I _have_ been able to reproduce/confirm.

It seems that whatever front-end code executed ultimately managed to launch a malicious pop-up and draw focus to it prior to launching a series of redirects in the pop-up and landing on the final ad (a tiny bit more on that below). After further reading of Redirect Blocking, this may not be an exploit against Redirect Blocking specifically since that measure seems restricted to iframes; the Redirect Blocked message may just be a red herring stemming from a separate bit of exploit logic that failed in the initial environment, for all I know.

Speaking to cross-origin resources, there's a hunch on the linked HN thread that Forbes' use of same-origin ads moots some of these protections, but it doesn't appear that Forbes uses same-origin ads at all, at least not when I kept an eye on network traffic on my most recent review of the page; it seems like Forbes loads all of these ad resources cross-origin, be they pages rendered in unsandboxed iframes or scripts rendered cross-origin on the page. If this is a pre-requisite for protections like Redirect Blocking and Pop-Up Blocking, then there's possibly some proverbial smoke as, again, it doesn't appear Forbes is running any of its ads same-origin.

Speaking to the fact that this manifested as a pop-up in spite of Pop-Up Blocking: The new tab was created, _claimed focus,_ and subsequently executed numerous (greater than one) redirects before landing on the final ad and throwing a modal alert (not visible here as I'd cleared it out) to impose an inability to navigate away. I noticed the sequence of redirects in the new tab specifically because the new tab took focus, and the pop-up itself was (near-certainly) launched by a cross-origin resource on the Forbes page. Whether this should be a guaranteed trigger for pop-up blocking is something I'm not familiar with; I'm merely reporting the conditions I can deduce here.

I'm sorely lacking technical information or, again, any success at reproducing or drawing out the same ad. The final landing page from the original series of redirects appears ultimately to have been https://usn(.)rewardcentervirusandroid(.)icu/vs/yyhvf.php?siteid=DEADBEEFDEADBEEFDEADBEEFDEADBEEF&model=SM-G965F&brand=Samsung&trackid=201809022224466880# -- but the original page (and likely the one with the false values above) 404s, and I have not explored it further.

I can make an effort to keep exploring or I can hold off, but aside from emulating different environments and constantly reloading this and other pages using the flow previously described, I'm not sure how much more I can do to draw out that ad. I can understand if this is ultimately closed as unconfirmed as a result. I can alert if I see any changes, though my goal with this report was ideally to shine a light on a place to look in code given the sequence of events which played out and the fact that it was actively being exploited in the wild.

Cheers

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+japhet who owns the framebusting redirect blocking feature. I don't quite understand the exploit though. Framebust redirect blocking only blocks redirects from subframes which have not received a gesture. A popup lands the user on a page which executes privileged script and can window.location themselves anywhere. It is common practice for many pages to do client-side (i.e. Javascript) redirects multiple times.

On popup blocking. We basically allow a popup through if there was a user gesture on the page. Did you click or interact with the page before the popup went through?

> It is common practice for many pages to do client-side (i.e. Javascript) redirects multiple times.

Absolutely, e.g. with complex authentication schemes. I'm beginning to think the redirect blocking notice was a red herring, essentially a coincidental notice stemming from an ad which attempted to run a number of different methods to load an ad simultaneously, one of which was a redirect which was blocked. In which case there might be nothing here.

> On popup blocking. We basically allow a popup through if there was a user gesture on the page. Did you click or interact with the page before the popup went through?

I had interacted at least once on the page to scroll the viewport itself. Details:

I'd finished scrolling (i.e. fingers off the screen) further down along the article about ten seconds _before_ Forbes had triggered a modal element for one of its own featurettes. Within a half-second of that modal element appearing on the original Forbes tab, the new tab opened. 

From what you described, it sounds like there's probably no issue here within Chrome and is rather just a malicious ad working around current security expectations/guarantees within Chrome itself.

+mustaq
Hm, it really should not be possible for a new tab to be opened >10s after the last user gesture (except maybe w/ UserActivationV2 feature which is not launched on beta yet).

If anything, this seems like a possible bug bypassing the popup blocker. Unfortunately without a reliable repro it will be hard to verify. However, it does seem like Safe Browsing team is looking into some of these phishing sites.

As long as we have at most one popup per user gesture, the >10sec delay is not a concern because we can have a valid sequence of network requests taking longer than 10sec to resolve and still expecting to see user activation at the end.

The real concern here is #c11: Scrolling is not considered a user gesture, so even the single popup sounds bad!

- One possible explanation for the popup is a crack in popup blocker that missed the lack of gesture token here.

- Another possible explanation could be a bug in user gesture token passing (in UAv1): in code, I know of a possible way to use gesture tokens from another tab through an extension, but never seen a repro.

bryant@zadegan.net: Do you have any extensions installed?  If yes, could you please try to repro after disabling all extensions?

mustaq@chromium.org: my understanding is that my installation of Chrome Beta 69.0.3497.53 on Android 8.0.0 has no extensions.

Since we've confirmed that scrolling is not considered a user gesture, I can confirm here that I did nothing other than scroll the viewport, and there were no interactive elements which required my attention prior to reading the article (i.e. there was no "read more" button now becoming commonplace on many news pages). The moment the in-window modal element appeared was when the new tab opened; I did not have time to touch the screen or interact with the page to close the modal element before the new tab appeared. Could there be any reason for pop-up behavior to differ between mobile v. desktop?

Now that I'm thinking in depth, this campaign has been around for a while. I recall hitting the same ad a number of months ago as well, though I cannot confidently recall whether I'd interacted with the page that spawned it beyond scrolling, nor can I confirm whether it was on Forbes (I'd like to think it wasn't; I make a point of avoiding Forbes for this exact reason). I'm not _as_ certain about the earlier event other than that the ad stuck out in my mind for how it also emulated Google and flagged my device model code in-page with a similar infection scare.

I'm still having no luck drawing out the same campaign, sadly. For what it's worth in case it's device-dependent, I'm currently on a Galaxy S7.

usn(.)rewardcentervirusandroid(.)icu will be in safe browsing blacklist very soon (as we speak).  Given there's no more safe browsing related work can be done here, let me remove the component label and also remove nparker@ as owner. 

Many thanks for the detailed replies. Unfortunately, in the absence of any way to reproduce this, I'm going to mark this as WontFix since there's nothing actionable.

However, if you encounter this again, please re-open this bug or file a new one with the following details:
1. URL of the original page.
2. URL of the abusive page.
3. Device information, if possible. Campaigns are often targeted.
4. Region information, if possible. Campaigns are often targeted.
5. Screenshots, if possible.

Thanks for the follow-up and the insight. I can at least fill that information down here for the record for this event.

1) https://www.forbes.com/sites/williamfalcon/2018/09/01/facebook-ai-just-set-a-new-record-in-translation-and-why-it-matters/
2) https://usn(.)rewardcentervirusandroid(.)icu/vs/yyhvf.php?siteid=DEADBEEFDEADBEEFDEADBEEFDEADBEEF&model=SM-G930F&brand=Samsung&trackid=201809022224466880# (trackID, siteID have been adjusted from the original page I encountered; I don't have the original URL beyond this)
3) SM-G930FD (the original model code in the URL above was SM-G930F)
4) Washington, DC
5) See the root post.

Thanks for the insight; I'll apply the insights gathered from this thread the next time I see this one appear.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot