4

I host my website by my own using droplet/VPS service and node.js server. My wesbite uses SSL Cert/HTTPS from LetsEncrypt, VPS service from DigitalOcean, domain registered from local vendor (RumahWeb) managed by CloudFlare.

My VPS server is secured and clear, only I have the key (private key file) to access it. I enforce firewall with ufw, use correct permissions to files, sanitize and encrypt everything from the user/client, and secure the database. The website works with no problem for years.

But, Several days ago, I notice there's an ad for a online gambling site suddenly popped up. here's what I know so far:

SYMPTOMS

  1. The ad is composed of a single javascript file: https://kassadin.fsource.io/1214B.js
  2. It doesn't affect all ISP and cellular operators in my country. Only INDOSAT and TRI.
  3. On INDOSAT, the SSL works, the browser detects the injected script and gives a warning to user that the connection is not private. On TRI the website including the ad is displayed.
  4. It attacks by domain name. If I use the server IP to access it directly, it works, no ads whatsoever. Other domains and website from the same server are also not affected only this one particular domain

enter image description here

WHAT I TRIED SO FAR

  1. Restart the server

  2. Checking for the compromised files, Nothing's found. To prove it, I make a single blank html file and host it on a new node.js process. Even with the blank HTML page, the ad keeps showing up. It's injecting itself

  3. Turn off the cloudflare and using the default (RumahWeb) nameservers. Not working

My domain provider can't help, the local ISP (INDOSAT and TRI) are too big to care. The only solutions I can think of is to provide alternate domain for my customers who're affected.

Or is it possible to remove the offending foreign script after website was loaded ?

This is beyond me. So I asked for help here... maybe some people will kindly offer me options or know-how to solve my situation.

14
  • look up the IP address of your domain, when using INDOSAT or TRI. Is it your server's IP? or a different one?
    – user253751
    Jan 3, 2023 at 5:17
  • 1
    Hmm... No problem when using IP address, only when using the symbolic name and on specific ISP networks: really looks like a DNS attack on those network. How to make sure: find the DNS of the (possibly) compromissed ISP, and make direct requests to them - you should see a different IP address. What to do: at your (site owner) level nothing more than you already did. You can just try to fill a request to the compromissed ISP telling them that their DNS cache have been compromissed with the evidences you found. If they do not fix it, you can try to fill a request to your national sec. office. Jan 3, 2023 at 7:25
  • 2
    Just thinking - maybe you have a 3rd party script you're using on the website that will only inject the ad to certain ISP users? Jan 3, 2023 at 8:05
  • 2
    Have you verified that the certificates are matching when the ads is shown...?
    – vidarlo
    Jan 5, 2023 at 16:18
  • 2
    To elaborate on @vidario's suggestion, you must read and compare the "fingerprint" of the certificate. Do not rely on fields such as Common Name or Organization which can be copied by a MITM fake certificate.
    – Ben Voigt
    Jan 5, 2023 at 16:32

1 Answer 1

1

I can only guess what might be the reasons.

1. Some operators force their clients to install their CA certificates

It can be that the mentioned operators forced theirs users to install their CA certificates. In such case these operators act as a man-in-the-middle and can decrypt, modify and re-encrypt any traffic, and the browsers will not notice that.

On a PC of some affected user, check the list of installed certificates. There can be a certificate that belongs to the particular operator.

2. Some operators ask their clients to accept warnings in browser if any displayed

The mentioned operators may intercept the traffic and act as a man-in-the-middle. Since they have not asked clients to install their CA certificate, their fake certificates used for interception will be noticed by browsers and the clients will see warnings in their browsers.

3. Affected users have purchased smartphones from operators

Operators have preinstalled their own OS version including their own CA certificates. Then clients will not notice anything at all. To check it, connect to such provider from a clean PC (directly or, if impossible, via tethering) and connect to your website. If browser shows a warning about certificate, it means the provider acts as a man-in-the middle.

4. Invalid DNS entries

It might be, but very improbable, that the mentioned operators have their own DNS that incorrectly resolves some domain names and points them to some other hosts, that inject JavaScript into your responses.

Attach to the networks of such operators, check the IP of your website and compare it to the real one.

3
  • the operators do not display any warning to accept anything. The web browser detected my website is compromised and just stop users from accessing it. The affected users do not buy their smartphone from operators at all. DNS server is correct. I double check, reset the settings to default (hosting DNS servers instead of Cloudflare). the SSL fingerprint is same for both unaffected and normal website.
    – DennyHiu
    Jan 7, 2023 at 12:54
  • yesterday I managed to call the mobile operator to report this problem. they fixed it and the ad is gone today. There's nothing I can do here from the server side.
    – DennyHiu
    Jan 7, 2023 at 12:55
  • 2
    and what was the problem?
    – robob
    Jan 9, 2023 at 6:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .