Yesterday I pulled up some websites using Firefox on my Android phone and I was surprised to find two notifications on my phone that a file called “dbsync” had been downloaded. I do not download files without having some idea of what they are, so needless to say I was surprised. The files were zero-bytes, however, so I didn’t think they would pose much of a threat.
I later did some Googling which led me to this reddit page discussing the issue. Several others have had this happen to them. Some linked to dubious “virus scanner” software which would remove it, though this cure looks more dangerous than the disease.
I chalked it up to some fluke until I was reading the website of local TV station WRAL.Com from my Ubuntu desktop. After a while I had a Firefox prompt asking me to download dbsync:
dbsync
This time there was more information! Apparently dbsync is being served up from a LinkedIn ad server, https://px.ads.linkedin.com. Also, FF for Ubuntu thought the file was 20 bytes long but when I saved it the file was actually empty. I’m not sure why there is a discrepancy here.
Ah, those pesky ad servers! While most of the time ad servers are benign, these servers are prime targets for hackers bent on distributing malware. I don’t think this server is compromised but leaving rogue files on visitors’ computers isn’t exactly polite behavior, either. In all probability, px.ads.linkedin.com is likely a run-of-the-mill, pixel-serving analytics server, tracking web visits by making the browser make a request to it.
I decided to send some random requests to this server to see how it would respond. First I tried requesting dbsync to see what would happen:
markt@server:/tmp$ curl -v https://px.ads.linkedin.com/dbsync
* Trying 108.174.10.14...
* Connected to px.ads.linkedin.com (108.174.10.14) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: px.ads.linkedin.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=US,ST=California,L=Mountain View,O=LinkedIn Corporation,CN=px.ads.linkedin.com
* start date: Tue, 06 Jun 2017 00:00:00 GMT
* expire date: Tue, 11 Jun 2019 12:00:00 GMT
* issuer: C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET /dbsync HTTP/1.1
> Host: px.ads.linkedin.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Play
< Set-Cookie: lang=v=2&lang=en-us; Path=/; Domain=ads.linkedin.com
< Date: Fri, 06 Jul 2018 17:06:00 GMT
< Content-Length: 0
< X-Li-Fabric: prod-lva1
< Connection: keep-alive
< X-Li-Pop: prod-edc2
< X-LI-Proto: http/1.1
< X-LI-UUID: QFKXCX7WPhWQpobwjCsAAA==
< Set-Cookie: lidc="b=VGST01:g=927:u=1:i=1530896760:t=1530983160:s=AQEAZXxcH9VtiYHPDeB-WxJJ-DxQNbgx"; Expires=Sat, 07 Jul 2018 17:06:00 GMT; domain=.linkedin.com; Path=/
<
* Connection #0 to host px.ads.linkedin.com left intact
Then for fun I decided to munge the URL to see what happens:
markt@server:/tmp$ curl -v https://px.ads.linkedin.com/dbsyncdf
* Trying 108.174.10.14...
* Connected to px.ads.linkedin.com (108.174.10.14) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 604 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: px.ads.linkedin.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=US,ST=California,L=Mountain View,O=LinkedIn Corporation,CN=px.ads.linkedin.com
* start date: Tue, 06 Jun 2017 00:00:00 GMT
* expire date: Tue, 11 Jun 2019 12:00:00 GMT
* issuer: C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA
* compression: NULL
* ALPN, server accepted to use http/1.1
> GET /dbsyncdf HTTP/1.1
> Host: px.ads.linkedin.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Play
< Set-Cookie: lang=v=2&lang=en-us; Path=/; Domain=ads.linkedin.com
< Content-Type: image/gif
< Date: Fri, 06 Jul 2018 17:07:25 GMT
< Content-Length: 43
< X-Li-Fabric: prod-lva1
< Connection: keep-alive
< X-Li-Pop: prod-edc2
< X-LI-Proto: http/1.1
< X-LI-UUID: 7Y9/4pHWPhVAvgLqjCsAAA==
< Set-Cookie: lidc="b=VGST01:g=927:u=1:i=1530896845:t=1530983245:s=AQEyVaQKzLlPvdBSshsYbMbyGC3qpCry"; Expires=Sat, 07 Jul 2018 17:07:25 GMT; domain=.linkedin.com; Path=/
<
* Connection #0 to host px.ads.linkedin.com left intact
GIF89a????!?,D;
So, a cookie gets set but this time a 40-byte GIF file is returned as well. This is what convinced me this is an analytics server.
I can understand if LinkedIn was measuring my use of its own website, but when this file got requested I wasn't on LinkedIn's homepage. Nor, was I logged into LinkedIn at the time. Thus, it's possible that WRAL (which uses Google's AdChoices ad network) uses third-party cookies that prompted my Firefox browser to make a request to the LinkedIn server. As a result, I will activate Firefox's dumping of third-party cookies upon exit feature and get Ghostery and other tools back up and running. Hopefully this will block crazy requests.
Thanks for this post! I got these mysterious downloads too when opening a CNN link from iMessage on Firefox for Mac. Good to know that the download seems to be on the benign side being just an ad server.
Thanks for the post, saved me digging into the this!
I’ve been getting this too. I haven’t downloaded it. To deal with it, I added https://px.ads.linkedin.com to my list of blocked cookies, and got an add-on called BlockSite [ https://addons.mozilla.org/en-US/firefox/addon/blocksite/ ] and added that url to the list as well. I prefer not to use an ad block extension unless absolutely necessary, as they tend to change their TOS without notice if they get bought. We’ll see if this keeps it under control.
Hi,
There might be some nefarious angle to it. When I Google I find a fair bit ot ‘DBSync virus removal software’.
These are clearly trojans – softwares meant to hijack the computer once the user installs them.
So, the whole DBSync thing (which is annoying, but AFAIK, harmless) might be an attempt to get people to panic and download and install these ‘DBSync Virus removal tools’ (after which their computers are in the hands of the scammers).
What I think might happen is that some ill-willing person is pushing out ads that have a reference to px.ads.linkedin.com/dbsync.
Such ads probably pass the ad network’s security scans. But they cause the user’s browser to bring up weird messages.
After which the user panics, starts Googling, finds some page claiming DBSync is a very bad virus.
User installs the Trojan, and they’re in.
Have you contacted LinkedIn on this subject? If someone is abusing their analytics servers (including them!), it should be called out. If someone else is doing it, they may want to look to fixing that.
One other approach (that works until the server url changes) is use your hosts file and add
127.0.0.1 px.ads.linkedin.com
Assuming you can do that on your PC and phone, that should route all requests to nowhere. It’s inelegant, but it works.
I tried. I filed an issue with LinkedIn, posted on the LinkedIn help forums, and also send a ‘scam’ report to Google. It is hard to find usable contact info for this kind of stuff. Right now I am caught up in a ‘standard’ LinkedIn support queue (“Dear, we don’t see the problem, please send us a screenshot”) – I don’t think the person at LinkedIn handling my report quite understands what I am on about.