Typo DNS Mastercard Tidak Terdeteksi Selama Hampir 5 Tahun

• MasterCard salah mengonfigurasi salah satu nama server DNS Akamai yang mengarahkan sebagian trafik mastercard.com sebagai akam.ne, bukan akam.net, dan typo ini tetap ada selama hampir 5 tahun, dari 30 Juni 2020 hingga 14 Januari 2025
• Peneliti keamanan Philippe Caturegli melihat bahwa akam.ne di bawah domain tingkat atas negara Niger belum terdaftar, lalu mengamankan domain tersebut dengan biaya 300 dolar AS dan waktu sekitar 3 bulan untuk mencegah kemungkinan penyalahgunaan
• Setelah server DNS di akam.ne dinyalakan, masuk ratusan ribu permintaan DNS per hari dari seluruh dunia, dan di antara organisasi yang melakukan typo yang sama, MasterCard adalah kasus terbesar
• Jika domain ini disalahgunakan, dampaknya bisa berupa penerimaan email yang salah terkirim, perolehan sertifikat SSL/TLS untuk situs web yang terdampak, serta penerimaan manual sebagian kredensial Windows
• MasterCard menyatakan “tidak ada risiko pada sistem” dan memperbaiki typo tersebut, tetapi setelah itu sempat ada permintaan penghapusan posting LinkedIn melalui Bugcrowd sehingga menyisakan kontroversi soal cara pengungkapannya

---

Typo DNS yang Dibiarkan Hampir 5 Tahun

• MasterCard menggunakan 5 server DNS bersama milik Akamai untuk mengarahkan sebagian trafik jaringan mastercard.com
• Dari 30 Juni 2020 hingga 14 Januari 2025, salah satunya dikonfigurasi dengan nama yang salah
  • Nama server yang benar seharusnya berakhiran akam.net
  • Konfigurasi bermasalah mengarah ke akam.ne
• akam.ne adalah domain yang berada dalam lingkup pengelolaan domain tingkat atas negara Niger di Afrika Barat

Peneliti Mengamankan Domain Terlebih Dahulu

• Philippe Caturegli, pendiri perusahaan konsultasi keamanan Seralys, menemukan typo ini
• Caturegli menduga akam.ne belum terdaftar, lalu mengamankan domain tersebut melalui registry Niger
  • Biayanya 300 dolar AS
  • Proses pendaftaran memakan waktu hampir 3 bulan
• Setelah server DNS diaktifkan, ratusan ribu permintaan DNS masuk setiap hari dari seluruh dunia
• MasterCard bukan satu-satunya yang melakukan typo yang sama, tetapi berdasarkan permintaan yang masuk, organisasi inilah yang terbesar

Risiko yang Bisa Ditimbulkan Domain Typo

• Jika Caturegli menyalakan server email di akam.ne, ia bisa menerima email yang salah terkirim yang semestinya menuju mastercard.com atau domain terdampak lain
• Jika akses itu disalahgunakan, ada kemungkinan memperoleh sertifikat SSL/TLS yang dapat menerima dan meneruskan trafik situs web terdampak
• Masih ada juga kemungkinan menerima secara manual kredensial Microsoft Windows dari komputer karyawan
• Caturegli tidak mencoba tindakan semacam itu, dan memberi tahu MasterCard bahwa ia dapat menyerahkan domain tersebut
  • Pemberitahuan itu juga menyertakan penulis Krebs on Security sebagai referensi

Respons MasterCard dan Bugcrowd

• Beberapa jam kemudian, MasterCard mengakui kesalahan tersebut, tetapi menyatakan tidak ada risiko nyata terhadap keamanan operasional
  • “Tidak ada risiko pada sistem”
  • “Typo ini telah diperbaiki”
• Setelah itu, Caturegli menerima pesan melalui Bugcrowd
  • Pesan tersebut menyatakan bahwa tindakan Caturegli mempublikasikan di LinkedIn setelah mengamankan akam.ne tidak sejalan dengan praktik keamanan etis
  • Pesan itu juga menyebut bahwa MasterCard meminta posting tersebut dihapus
• Caturegli menjawab bahwa ia tidak pernah melaporkan melalui program Bugcrowd, dan telah melaporkan masalah tersebut langsung kepada MasterCard
• Ia menyatakan bahwa sebelum publikasi, ia telah mendaftarkan domain yang terdampak untuk mencegah penyalahgunaan, dan menanggung sendiri biayanya

Cakupan Dampak yang Bisa Diperbesar oleh Cache DNS

• Secara umum, organisasi memiliki setidaknya 2 server DNS otoritatif, tetapi organisasi dengan banyak permintaan menggunakan lebih banyak domain server DNS untuk load balancing
• Karena MasterCard menggunakan 5 server DNS, tampaknya jika penyerang menguasai satu saja, ia hanya dapat melihat sekitar seperlima dari seluruh permintaan DNS
• Namun, karena pengguna internet pada praktiknya bergantung pada resolver DNS publik seperti Cloudflare atau Google, dampaknya bisa menjadi lebih besar
  • Cukup satu resolver menanyakan nameserver yang salah lalu menyimpan hasilnya di cache
  • Jika TTL panjang ditetapkan pada record DNS, instruksi yang salah dapat menyebar melalui penyedia cloud besar
• Caturegli menilai bahwa dengan TTL panjang, cakupan rerouting trafik bisa jauh lebih besar daripada sekadar seperlima

Subdomain Bermasalah dan Jejak Pendaftaran Masa Lalu

• Dalam tangkapan layar yang dipublikasikan Caturegli, server DNS yang salah dikonfigurasi terkait dengan subdomain az.mastercard.com milik MasterCard
• Tidak jelas persis bagaimana subdomain ini digunakan
• Dari aturan penamaannya, domain ini tampaknya terkait dengan server produksi di cloud Microsoft Azure, dan Caturegli menyatakan domain-domain tersebut di-resolve ke alamat internet Microsoft
• akam.ne pernah terdaftar sebelumnya
  • Pada Desember 2016, domain ini didaftarkan oleh pengguna dengan email [e-mail]
  • Yandex menampilkan akun ini sebagai milik “Ivan I.” dari Moskow
  • Menurut catatan DNS pasif DomainTools.com, dari 2016 hingga 2018 domain ini terhubung ke server internet di Jerman, lalu kedaluwarsa pada 2018
• Seorang mantan karyawan Cloudflare menautkan laporan yang membahas kasus serupa di komentar pada posting LinkedIn Caturegli
  • Kasus tersebut adalah domain typo yang kemungkinan muncul karena beberapa organisasi salah mengetik server DNS AWS awsdns-06.net menjadi awsdns-06.ne
  • Menurut DomainTools, domain typo ini juga terdaftar atas pengguna Yandex dan di-hosting di ISP Jerman yang sama, Team Internet

[GN⁺]

Opini Hacker News

• Nameserver yang bisa didaftarkan secara publik seperti kasus ini hanyalah subtipe yang relatif jarang dari masalah dangling DNS; yang lebih umum adalah ketika domain dipetakan langsung ke alamat IP milik penyedia cloud yang bisa diperoleh penyerang.
  Layanan cloud cakupannya luas dan sering kali kurang memiliki visibilitas global, sehingga perusahaan yang memakai cloud besar kemungkinan memiliki kerentanan semacam ini di suatu subdomain.
  Program bug bounty sering mengecualikan “pengambilalihan subdomain” secara menyeluruh, tetapi jika ditemukan, ini mudah dieksploitasi, dan ada pula data internal maupun publik berisi informasi sensitif yang bocor akibat salah konfigurasi seperti ini.
  Lingkungan pengungkapan kerentanan saat ini membuat perusahaan terlalu mudah menghindari pengakuan atas kerentanan nyata, sementara peneliti beritikad baik sulit memberikan bukti pada tingkat yang diminta penyedia karena batasan etika dan hukum.
  Risiko bahwa kerentanan seperti ini dapat dengan mudah memungkinkan penerbitan sertifikat TLS juga diremehkan.
  [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
  [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
  [3] https://pauley.me/post/2022/cloud-squatting/
  [4] https://arxiv.org/pdf/2204.05122

  • Selain IP, ada kategori besar masalah berupa “record DNS yang menunjuk ke resource cloud bersama yang tidak lagi dikendalikan organisasi”, dan makin besar perusahaannya, makin luas penyebarannya.
    Contohnya CNAME yang menunjuk ke bucket S3 yang sudah dilepas, instance Azure Website/WebApp, record A yang menunjuk ke IP non-elastis, nameserver Route53 yang tidak lagi termasuk dalam akun AWS organisasi, akun Heroku/Shopify/GitHub Pages yang dihapus atau dinonaktifkan, serta record MX yang menunjuk ke domain penyedia email transaksi yang sudah bangkrut.
    Penyebabnya adalah desentralisasi IT: orang yang kurang paham membuat infrastruktur, DNS terlupakan saat dibongkar, banyak anak perusahaan, merek, dan organisasi regional membuat kebijakan sulit ditemukan dan ditegakkan, banyak situs web dan aplikasi per negara, serta penggunaan vendor eksternal tanpa memberi tahu tim keamanan terus menumpuk.
    Saya bekerja sebagai Field CTO di sebuah perusahaan keamanan siber Israel di bidang ini, dan baru kemarin saya berbicara dengan sebuah perusahaan besar komponen komputer tentang sekitar 12 situs judi Indonesia yang “beroperasi” dengan memanfaatkan domain, PageRank, dan tautan mereka; percakapan seperti ini berulang setiap minggu.
  • Menganggap semua “pengambilalihan subdomain” sebagai tidak valid dalam bug bounty adalah respons yang terlalu menyamaratakan; seharusnya dibedakan berdasarkan seberapa mudah domain itu bisa diperoleh.
    “Jika entah bagaimana seseorang mengambil alih google.com, mereka bisa membahayakan pengguna Google” bukan kerentanan keamanan yang valid, tetapi jika pengambilalihan domain yang belum terdaftar atau kedaluwarsa seperti di sini berujung pada kompromi, itu harus dianggap sebagai kerentanan yang valid.
  • Pengungkapan bug bounty bisa lebih efektif jika secara otomatis juga dilaporkan ke lembaga pemerintah seperti FCC dan email perusahaan terkait di-CC.
    Jika perusahaan ingin menolak laporan, mereka harus menyertakan bukti yang jelas; jika eksploitasi dari laporan tersebut terbukti, atau perusahaan melakukan perubahan sehingga langkah reproduksi dalam laporan tidak lagi berfungsi, itu bisa menjadi dasar pembayaran imbalan atau denda.
  • Di sebuah bursa kripto, mereka pernah mengelola allowlist alamat IP yang bisa mengakses load balancer yang lebih cepat tanpa kontrol di tingkat aplikasi.
    Dengan mengalokasikan IP cloud dalam jumlah sangat besar dan berulang kali mencari IP lama, mereka mendapatkan kapasitas jauh lebih besar daripada semula dan mengirim request dengan batas kecepatan yang lebih tinggi.
    Sepertinya sekarang cara itu tidak lagi berhasil, dan kini sudah menjadi metode yang diketahui semua orang.

• Bagian tentang Bugcrowd dalam cerita ini tidak terduga.
  Screenshot emailnya tampak seolah berasal dari “Platform Behavior Standards Team”; jika demikian, berarti Bugcrowd menafsirkan standar platform terlalu luas sampai mencoba mengatur perilaku di luar platform, atau Mastercard berpura-pura menjadi staf resmi Bugcrowd.
  Keduanya sulit diterima.
  [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

  • Ada tafsir bahwa platform Bug Bounty bukan hadir untuk mendorong responsible disclosure, melainkan untuk menangkap dan menghambatnya.
    Orang yang sering mengemukakan argumen itu mungkin bisa menjelaskannya dengan lebih baik.
  • Redaksinya juga sangat buruk.
    Ditulis seolah-olah sudah diputuskan bahwa orang itu bersalah, dan pilihannya hanya mematuhi atau meminta penjelasan tambahan tentang mengapa itu salah.
    Tidak ada kesempatan untuk menjelaskan bahwa dirinya tidak bersalah.
  • Berdasarkan pengalaman saya, BugCrowd melakukan segala cara untuk menunda dan menenggelamkan laporan agar tidak sampai ke perusahaan yang sebenarnya.
    Dari sisi perusahaan, ini mengurangi pembayaran bounty dan biaya tinjauan internal, sekaligus memberi plausible deniability yang tampak masuk akal secara hukum.
  • Pasti ada juga karyawan Bugcrowd di sini, jadi mungkin mereka bisa menjelaskan email itu.

• Respons semacam “tidak ada ancaman nyata” kemungkinan akan membuat peneliti keamanan lain kali menyusup lebih dalam di perusahaan ini atau perusahaan lain untuk mengumpulkan lebih banyak bukti dampak.
  Jika ingin juru bicara perusahaan bisa mengatakan “tidak ada masalah”, mereka harus memberi imbalan yang cukup agar peneliti mau menerimanya meski dampaknya diperkecil.
  Padahal penelitinya tampak sudah bertindak benar, tetapi mereka menekan peneliti untuk meredam berita; saya bertanya-tanya apakah perusahaan kartu kredit memang punya alasan untuk itu, atau ini karena pemahaman kerja yang keliru dari bagian PR, atau apakah orang yang pada akhirnya bertanggung jawab atas kesalahan infosec itu menggunakan sumber daya perusahaan untuk menghindari malu selama masa jabatannya.

  • Ada alasannya.
    Mereka ingin membuat peneliti keamanan takut mempublikasikan temuan mereka.

• Beberapa tahun lalu di Ukraina, semua atau sebagian besar transaksi online harus diverifikasi lewat layanan bernama masterpass, yang tampaknya semacam 3DS versi Mastercard.
  Namun, seperti yang sering terjadi di web perusahaan, sertifikat SSL-nya kedaluwarsa, dan semua atau sebagian besar transaksi online dengan jenis kartu MasterCard tertentu langsung terblokir sepenuhnya pada saat itu.
  Mastercard tidak memperbarui sertifikat itu selama lebih dari setahun, dan meski saya sebagai pelanggan maupun departemen TI bank berkali-kali menghubungi mereka, tidak ada hasil; belakangan layanan itu diam-diam ditutup.
  Setelah dilihat, layanan tersebut dibuat dengan teknologi Microsoft (IIS), rantai sertifikatnya sangat panjang secara tidak wajar dengan sertifikat perantara yang belum pernah saya dengar, dan di-hosting di negara dunia ketiga yang cukup jauh dari Ukraina.

  • masterpass adalah versi 3DS dari Mastercard, dan digunakan secara global ketika transaksi terlihat mencurigakan.
    Dari sudut pandang Mastercard, tampaknya semua transaksi di negara itu pada dasarnya dianggap mencurigakan meskipun seluruhnya terjadi antar pihak lokal.
    Saya belum pernah melihatnya kedaluwarsa di AS, dan tidak tahu bagaimana pemrosesan trafik per negara dilakukan, tetapi ini terdengar seperti trafik dirutekan ke tempat lain, bukan ke Mastercard.

• Fakta bahwa akam.ne didaftarkan pada 2016 oleh “Ivan I.” dari Moskow yang memakai email Yandex, sempat terhubung ke server Jerman pada 2016–2018, lalu kedaluwarsa, terasa mengganjal.
  Yang sangat mencurigakan adalah bagian bahwa domain typo serupa yang tampaknya menargetkan organisasi yang salah mengetik server DNS AWS awsdns-06.net menjadi awsdns-06.ne juga didaftarkan dengan akun Yandex dan di-hosting di ISP Jerman yang sama, Team Internet (AS61969).

  • “Ivan I” kemungkinan besar merujuk pada Ivan Ivanov, nama umum palsu ala Rusia, seperti “John Smith” di dunia berbahasa Inggris.

• Pernyataan “jika akses itu disalahgunakan, pihak tersebut bisa saja memperoleh sertifikat SSL/TLS yang dapat menerima dan meneruskan trafik situs web terdampak” dan “sistem kami tidak berisiko” tidak mungkin sama-sama benar.
  Kedua pihak punya insentif untuk berbohong atau melebih-lebihkan.

  • Satu pihak punya insentif bernilai puluhan miliar dolar untuk berbohong atau melebih-lebihkan, sementara pihak lain menghabiskan hari-harinya memikirkan skenario terburuk dari penyerang canggih.
    Kalau ini server CS:GO, serangan terburuk dari penyerang canggih mungkin terdengar berlebihan, tetapi ketika membicarakan salah satu perusahaan pemroses pembayaran terbesar di dunia, itu bukan berlebihan.
  • Jika Anda tahu sedikit saja bagaimana sertifikat diterbitkan, Anda akan tahu bahwa penelitinya benar dan MasterCard sedang bicara omong kosong.
    Riset 10 menit saja akan membawa Anda ke kesimpulan yang sama.
  • Jika tidak ada dampak, mereka tinggal mengizinkan dia memublikasikan daftar lengkap kueri DNS yang ia tangkap.
    Satu-satunya alasan untuk tidak melakukannya adalah karena daftar itu memberi petunjuk infrastruktur kepada aktor jahat.
    MasterCard sedang berbohong, atau mereka tidak tahu dan tidak kompeten.
  • Intinya sangat bergantung pada apa sebenarnya az.mastercard.com dan apa fungsinya.
    Klaim bahwa email ke [e-mail] bisa diterima terdengar tidak tepat; ini hanya subdomain yang tujuannya tidak jelas.
    TLS mungkin bisa dilakukan, tetapi risikonya bergantung pada domain itu sebenarnya apa, dan tampaknya tidak langsung berdampak pada pengguna yang mengunjungi mastercard.com.
  • Kalau bicara sertifikat SSL/TLS, yang pertama terpikir adalah penyedia sertifikat berbasis ACME.
    Kontrol DNS domain saja sudah cukup, dan bisa dilakukan lewat record TXT atau dengan mengarahkan permintaan ke server HTTP yang dikendalikan sendiri.

• Ini jelas kesalahan besar Mastercard, tetapi membiarkan ada domain yang hanya beda satu huruf dari TLD asli juga terasa seperti kesalahan.
  Contohnya .com dan .co, .net dan .ne; strukturnya memang mengundang masalah.
  Jika domain seperti itu tidak ada, domain itu tidak bisa didaftarkan dan permintaan DNS yang salah ketik hanya akan berakhir tanpa tujuan.

  • Tidak selalu begitu.
    Typo bisa terjadi bukan hanya pada TLD, tetapi di mana saja dalam nama; bahkan tanpa typo, orang bisa mendapatkan trafik dari berbagai kesalahan komputer lewat bitsquatting, yaitu mengambil domain yang berbeda 1 bit dari nama situs populer.
    Ada juga makalah dengan contohnya.
    [1] https://en.wikipedia.org/wiki/Bitsquatting
    [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
  • Untuk perusahaan besar, saya mengira masalah seperti ini akan ditangani lewat Markmonitor.
    Pada dasarnya caranya adalah mendaftarkan sekaligus domain typo dengan edit distance 1 sejauh memungkinkan.
    Menurut Wikipedia, Akamai adalah salah satu pelanggan Markmonitor, jadi cukup mengejutkan domain ini belum terdaftar.
  • Masalahnya, apa yang akan dilakukan terhadap kode ISO 3166-2 Niger dan Kolombia?
  • Saya tidak melihat apa bedanya dengan adanya nomor telepon yang hanya berbeda satu digit dari nomor telepon sensitif.
  • TLD ISO 3166-1 alpha-2 jelas berguna, tetapi karena sifat ruang alamatnya, banyak typo satu huruf akan muncul.
    Domain non-kode negara pun bisa tumpang tindih dengan bentuk TLD kode negara yang kehilangan satu huruf, jadi tidak banyak bedanya.
    Namun, kesalahan konfigurasi seperti ini seharusnya bisa ditangkap oleh alat pemeriksa DNS yang baik.
    Misalnya terlihat dari salah satu nameserver terdaftar yang tidak dapat di-resolve, atau nameserver yang tidak mengembalikan nomor seri zona yang sama maupun respons aktual yang sama.
    Di .is, dulu untuk mendaftarkan domain Anda harus menyediakan 2 nameserver yang berfungsi dengan benar, tetapi .com sekarang tidak seketat itu.

• Nama domain itu seharusnya diserahkan kepada akamai.
  Permintaan lain juga masuk ke alamat yang sama, dan akamai seharusnya menanganinya secara bertanggung jawab.

• “Kami menyelidiki diri sendiri dan mendapati tidak ada kesalahan” adalah respons klasik.
  Mastercard adalah perusahaan publik bernilai miliaran dolar, dengan setidaknya 3,4 miliar kartu bermerek di seluruh dunia, dan pada kuartal III 2024 memproses 44,3 miliar transaksi kredit, debit, dan tunai di seluruh dunia.
  Mengakui kesalahan mungkin merugikan pasar dalam jangka pendek, tetapi budaya penyangkalan merusak budaya perusahaan.
  Ini tidak ada bedanya dengan ClownStrike, dan sudah waktunya kekacauan datang bagi jaringan kredit dan debit yang predatoris serta parasitik.

• Pernyataan seperti “typo sudah diperbaiki dan tidak ada risiko pada sistem” selalu saja sama, dan pernyataan semacam ini benar-benar membuat kesal

  • Perhitungan mereka mungkin begini
    Kalau mengakui masalahnya, harga saham bisa hilang jutaan dolar, tetapi kalau menyangkal, hanya ada segelintir geek yang akan makin merengek
    Tanpa bukti pelanggaran, sulit untuk memaksa; kalau ada bukti pelanggaran, mereka bisa masuk penjara
  • Makna sebenarnya lebih dekat ke “kami bicara dengan staf departemen IT yang tidak tahu apa-apa, staf itu punya insentif pribadi untuk tidak mencari paparan, dan dalam 15 detik ia tidak bisa memikirkan cara mengeksploitasinya”
    Orang yang benar-benar paham jarang merasa cukup aman untuk memastikan bahwa sesuatu tidak bisa dieksploitasi