Facebook pretending to be Bing

Bing UA from Facebook IP

[dstiles]

Got a hit from FB early this morning (actually, similar hits to two sites):

IP: 66.220.149.nn
GET: /?fbclid=IwAR0Uuiuw7Yat7n2wij7HyVs3_9kXGdIJJ4cJdNsU_TD_0vVhH7r8prlW7eA

UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

This single access grabbed favicon, CSS and images from the page - in fact just as one would expect from Chrome. The querystring drew my attention - I do not use querystrings on these sites.

The second site hit is a single-page semi-honeytrap - when I get around to it. Until a few days ago it was HTTP, now HTTPS; FB came in on port 80 so historical. No one except nasties and genuine bots ever hit it. So far, no second hit (see below).

Three hours later I got...

IP: 173.252.87.nn
GET: /?fbclid=IwAR3Zi-gZca-49iQ7nqAcy8UMfyAKX1pFejaeoBTD5xW8i29yl_2eEOgOcXs

UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b

A second hit at the same time with the same bing UA tried to grab favicon.

In the interim I had set up a block on FB IPs except for facebookexternalhit and blocked all accesses that included querystrings.

The querystrings are not the same apart from fbclid but I would say the second access was prompted by the first.

Anyone else noticed this? Why are they forging BingPreview?

[Dimitri]

Facebook pretending to be Bing

I had a joke to make about it, but I'll keep it for myself :)

[tangor]

/?fbclid=(gibberish)

This is a facebook hit (most days) and is fb's way of tracking users clicking on a link from their site to an exterior.

I generally allow to keep track of SM hitting my site ... but in recent days it appears others (as in bad actors) are emulating same ... so what do you do?

Easy enough to kill. Question is, should you? And when?

[lucy24]

UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

I’ve been seeing humanoid visits from FB ranges for a while now--since December 2018, give or take. Most but by no means all are on some recent version of Chrome. Spot-checking, possibly, in the same way that the major search engines do human spot-checking?

I happen to have a generic redirect that strips off query strings, so when the fbclid people show up, I see them twice.

I'm not absolutely certain what Bing Preview is, but I’m pretty sure it isn’t a preview in the ordinary sense. Most of the time they request only scripts, stylesheets and fonts--in other words, all supporting files except images. Very very rarely, there's a full request including HTML and images. There are some interesting alternative behaviors--and a few clear fakers--but that’s a matter for another thread.

[Dimitri]

/?fbclid=(gibberish)

Another reason why web publishers should never answer URLs which are not "your". I mean, we all know (right?), that you must not answer requests made to your server's IP with a host name which is not your... a similar good practice is to also control that the URL of the page is "the right one".

Sanitizing parameters passed to a page (script), is verifying that the parameters contain values they should, but also to verify that no "unknown" parameters are passed.

Here, it's Facebook talking to an hypothetical facebook javascript on the page, but more generally this can also be attempts of exploits and things like that.

[dstiles]

tangor:
> users clicking on a link from their site to an exterior.

As I said, one of the sites (the one given in the OP) is a semi-honeypot with a single page that has absolulety no content relevant to anyone (in fact it's total gibberish), so how would it have been listed anywhere on facebook?

The other site is new and has been live for only a few weeks, during which time only bots and scrapers have found it, so again, how would facebook have a link to it?

Lucy:
As I understand it, BingPreview is similar to google's preview, though I could be wrong. I have it blocked.

My guess is that a scrape of either google/bing or of DNS has come up with an A record and this bot has followed it up, hiding behind BingPreview for the initial hit. Just a guess.

[tangor]

@dstiles ... bit slow and old ... then again, I don't deal these these things simply because anything after MY url is banned ... just seems cleaner that way.

Should I change my habits?

[dstiles]

> @dstiles ... bit slow and old

I know I am. :)

If you have no querystrings on your pages then I see no reason not to block querystrings in general. Some of the ones I've seen in the past have characters which may be probing for vulnerabilities, but my old ASP sites often use querystrings as page identifiers within more generalised pages.

I have begun using POST on my new Apache sites to avoid querystring corruption by nasties, so tt is now feasilbe to block all querystrings.