Domain CDN Terbiar Didaftar Semula: Ribuan Laman Terdedah

Domain CDN Terbiar Didaftar Semula: Ribuan Laman Terdedah

Pada Julai 2025, seseorang mendaftar semula domain yang pernah menjadi milik sebuah content delivery network. CDN itu sudah ditutup bertahun-tahun lalu dan domainnya dibiarkan luput. Yang tidak luput ialah laman-laman yang masih memanggilnya: ribuan laman web, code repository dan halaman dokumentasi masih menyimpan rujukan keras kepada hostname di bawah domain itu.

Domain itu ialah netdna-ssl.com, domain yang menyajikan aset untuk MaxCDN — sebelum itu, NetDNA, sebuah CDN yang bermula pada 2010. Jika anda pelanggan WP Engine di "Legacy Network", aset statik anda — JS, CSS, fonts, imej — disajikan dari host yang kelihatan seperti <site-hash>.wpengine.netdna-ssl.com. MaxCDN diambil alih oleh StackPath pada 2016, jenama itu dihentikan hujung 2022, dan CDN StackPath ditutup pada hujung 2023. WP Engine sudah lama mengarahkan semua orang ke Advanced Network mereka.

Kecuali domain itu sendiri dibiarkan luput — dan pada 24 Julai 2025, ada orang membelinya.

Pemilik baharu kawal seluruh namespace

Pendaftar baharu memegang wildcard DNS untuk seluruh namespace *.wpengine.netdna-ssl.com. Ini bukan spekulasi; anda boleh buktikannya sendiri dalam masa beberapa minit, sama seperti penyelidik Scott Helme:

# Who owns it now — RDAP lookup
curl -s https://rdap.verisign.com/com/v1/domain/netdna-ssl.com
#   registration   2025-07-24T18:13:09Z
#   expiration     2027-07-24T18:13:09Z
#   nameservers    JACK.NS.CLOUDFLARE.COM, MEILING.NS.CLOUDFLARE.COM
#   registrar      Gname.com Pte. Ltd.

# Does a made-up subdomain resolve? (it does)
dig +short test123random.wpengine.netdna-ssl.com
#   104.21.72.58
#   172.67.175.240

# What does the apex serve today?
curl -s https://netdna-ssl.com/ | grep -io '<title>[^<]*</title>'
#   <title>Snapinsta - Download Instagram Videos, Reels, Stories for FREE</title>

Kini apex menyajikan halaman downloader Instagram yang sarat iklan, disambung ke Google AdSense dan Tag Manager. Jadi pihak ketiga yang tiada kaitan langsung — dan berorientasikan monetisasi iklan — memiliki domain yang masih digunakan oleh ribuan laman sebenar untuk memuatkan aset. Keputusan tentang kandungan yang akan dimuatkan laman-laman itu seterusnya berada di tangan orang asing — dan tiada siapa dimaklumkan, kerana dari luar semuanya nampak masih normal.

Kenapa ia belum meletup

Inilah nuansa yang paling kerap terlepas dari tajuk berita. Hostname aset dalam — iaitu URL <hash>.wpengine.netdna-ssl.com yang sebenar dipanggil oleh laman — kini gagal TLS handshake:

openssl s_client -connect netdna-ssl.com:443 \
  -servername wrz...gpg.wpengine.netdna-ssl.com
#   ... sslv3 alert handshake failure

Sebabnya remeh. Sijil Cloudflare Universal SSL di edge hanya meliputi netdna-ssl.com, proxy.netdna-ssl.com dan *.proxy.netdna-ssl.com — ia tidak meliputi *.wpengine.netdna-ssl.com. Jadi sekarang, permintaan script-src dan font-src yang lama itu gagal dan bukannya melaksanakan kod penyerang. Laman-laman itu belum lagi terjejas oleh perkara ini.

Tetapi jangan silap — menutup jurang itu hanyalah satu toggle dalam Cloudflare Advanced Certificate Manager, seperti yang Scott Helme tunjukkan. Kawalan DNS sudah mutlak dan monetisasi sudah berjalan. Hari sijil *.wpengine.netdna-ssl.com dikeluarkan, semuanya bertukar dari "aset yang gagal dimuat" kepada "JavaScript sewenang-wenang yang berjalan dalam ribuan halaman."

Jangkauan impak ini nyata, bukan andaian. Carian kod GitHub untuk wpengine.netdna-ssl.com menghasilkan hampir 4,000 fail, termasuk rujukan sebenar dalam projek sebenar — repo mozilla/webxr-polyfill memuatkan web fontsnya dari host .wpengine.netdna-ssl.com, dan senarai itu turut merangkumi Kong, Nextcloud, Yale Daily News dan Server Density. Bukan semua itu laman langsung yang disahkan terdedah — ia rujukan residual — tetapi Cloudflare Radar meletakkan netdna-ssl.com dalam 20,000 domain teratas global, diukur dari data live DNS resolver. Pelayar sebenar masih resolve nama ini hari ini, dalam jumlah yang besar.

Filem yang sama pernah kita tonton

Jika semua ini terasa biasa, ia memang serangan polyfill.io dari Jun 2024 dengan pakaian lain. Di situ, domain shim JavaScript yang tertanam dalam lebih 110,000 laman bertukar pemilik dan mula menyajikan redirect bersyarat kepada pengunjung telefon mudah alih. Laman yang menjalankannya tidak pernah digodam — mereka cuma outsource satu <script> tag bertahun lalu dan tidak pernah menyemak keputusan itu semula.

Kedua-dua kes ini berkongsi masalah yang di luar kawalan kebanyakan pasukan keselamatan: kod berniat jahat itu tidak pernah berada di pelayan mereka, dan ia sampai lama selepas deployment terakhir.

Tooling server-side tengok tempat yang salah

Static analysis, dependency scanning dan software composition analysis kesemuanya meneliti apa yang organisasi bina dan hantar. Skrip pihak ketiga bukan mana-mana satu daripadanya. Ia di-fetch oleh pelayar pengunjung, dari pelayan yang tidak dikendalikan organisasi, secara langsung pada setiap page view.

Itulah sebabnya ia sukar dikesan dengan ujian konvensional — respons boleh berbeza mengikut geografi, user agent, referrer, masa hari dan sesi. Crawler yang menarik fail sekali dari range IP pusat data dapat versi bersih; pembeli di rangkaian mudah alih di negara lain dapat sesuatu yang lebih jahat. Serangan client-side jenis Magecart tidak memerlukan pelayan dipecahkan langsung — ia cuma perlukan satu script tag yang diluluskan mula berkelakuan berbeza. Skrip itu sendiri memegang keistimewaan yang sama dengan kod first-party anda: ia boleh baca DOM, baca form fields aksara demi aksara sementara anda menaip, baca cookies dan local storage, dan buat outbound request ke mana-mana sahaja yang disukainya.

Pelayar ialah pemerhati yang tak pernah terlepas sesi

Ada satu pemerhati yang sentiasa hadir untuk setiap page view itu: pelayar yang melaksanakan kod tersebut. Sebab itulah perbincangan ini kembali berulang kali kepada Content Security Policy — bukan sekadar pertahanan XSS, tetapi sebagai cara untuk tahu kod apa yang sebenarnya berjalan di laman anda. CSP boleh kawal kod yang dibenarkan berjalan, sekat kod yang tidak diberi kuasa, dan beritahu anda bila ia berlaku — dari sesi sebenar, geografi sebenar, pengguna sebenar. Payload berniat jahat yang hanya aktif untuk pengguna log masuk di satu negara tetap dilaporkan, kerana pelayar yang menjalankannya ialah yang menghantar alert.

Ini bukan teori. Pada September 2026, alert CSP mendedahkan sekumpulan laman e-commerce yang terjejas menjalankan kempen social engineering jenis ClickFix: loader ber-encode Base64 ditanam dalam kandungan CMS selepas kompromi pentadbiran, berantai melalui redirector ke overlay palsu "verify you are human" yang meletakkan perintah PowerShell pada clipboard mangsa dan mengekalkannya sebagai scheduled task. Hostname yang dikawal penyerang muncul dalam alert pelayar sedangkan sebahagian domain itu masih dinilai bersih oleh perkhidmatan reputasi arus perdana. Di pelayan, halaman-halaman itu nampak normal — tiada scanner yang menandakannya.

Pematuhan sudah menjadikan ini kewajipan

Bagi sesiapa yang mengendalikan pembayaran kad, hujah ini sudah selesai. Keperluan PCI DSS v4.0.1 6.4.3 dan 11.6.1 berhenti menjadi amalan terbaik dan menjadi mandatori pada 31 Mac 2025. Kedua-duanya menuntut setiap skrip pada halaman pembayaran diberi kuasa, integritinya dijamin, inventori bertulis dengan justifikasi perniagaan wujud, dan ada mekanisme yang mengesan serta memberi amaran tentang pengubahsuaian tidak sah pada kandungan halaman pembayaran dan HTTP headers. Seorang QSA boleh dan akan bertanya tentang inventori itu, mekanisme amaran dan jejak bukti yang dihasilkannya.

Apa yang perlu anda buat

Anda tidak boleh "unpublish" rujukan DNS yang anda lupa, tetapi anda boleh mencarinya:

1. Grep seluruh estate anda — HTML, themes, databases, configs, docs — untuk netdna-ssl.com, netdna-cdn.com dan *.wpengine.netdna-ssl.com. Keluarkan atau rehost apa sahaja yang anda jumpa. Pelanggan WP Engine patut keluar dari Legacy Network ke Advanced Network.
2. Guna SRI — Subresource Integrity pada tag <script> dan <link> pihak ketiga bermakna fail yang ditukar akan gagal secara fail-closed dan bukannya berjalan. Ia tidak menyelamatkan fonts atau imej (tiada SRI untuk itu), jadi pasangkan bersama langkah seterusnya.
3. Tegaskan CSP, dan report padanya — script-src / font-src / connect-src yang ketat menghentikan senjata terkokang itu daripada menembak dalam halaman anda. Deploy ia dalam mod Content-Security-Policy-Report-Only dahulu: mod itu tidak menegaskan apa-apa dan tidak mengubah sebarang tingkah laku, ia hanya memberitahu apa yang polisi akan sekat. Bagi kebanyakan organisasi, senarai itu jauh lebih panjang daripada sangkaan — memang itulah cara penyelidik terus menjumpai domain seperti ini.
4. Audit dependency anda — yang DNS pun sekali. Domain yang anda berhenti fikirkan bertahun lalu ialah tepat domain yang diharap oleh orang lain agar anda lupa.

Ini kelas kegagalan kepercayaan yang sama dengan pintu belakang rantaian rental-cacat dan worm bungkusan beracun: kita memautkan kepercayaan pada satu domain, bukan pada kod, dan apabila domain itu bertukar tangan, setiap laman yang merujuknya turut terseret. Tidak seperti polyfill.io, kes ini sudah diatur tetapi masih berhibernasi — maksudnya, sekali ini, ada ruang untuk membaikinya sebelum ia meletup. Grep estate anda hari ini.

Sumber

• Scott Helme: A dead CDN, a wildcard, and an attack waiting to happen — the netdna-ssl.com takeover
• The Hacker News: An Abandoned CDN Domain Was Re-Registered. Thousands of Sites Still Call It.