Saat nama host internal bocor ke cloud

• Ditemukan kasus ketika antarmuka web perangkat NAS mengirim nama host khusus internal ke layanan eksternal
• Skrip pelaporan error sentry.io yang disertakan dalam UI web NAS mengirim nama host internal ke luar bersama stack trace
• Teramati perilaku aneh ketika pihak sentry.io mencoba koneksi TLS balik ke nama host tersebut, tetapi tidak pernah mengirim permintaan nyata
• Berkat konfigurasi DNS wildcard yang sudah disiapkan sebelumnya, kebocoran dapat terdeteksi, dan ada risiko kebocoran informasi serius bila memakai nama host yang sensitif
• Mekanisme ini berpotensi menjadi masalah keamanan karena bisa disalahgunakan untuk memicu pemindaian DNS terhadap host arbitrer

---

Instalasi NAS dan konfigurasi nama host internal

• Membeli perangkat NAS, memasang drive, lalu menghubungkannya ke jaringan rumah dan menjalankannya dalam mode HTTPS
• Memasang sertifikat TLS wildcard untuk subzona dari domain yang tidak bermakna di internet publik (misalnya *.nothing-special.whatever.example.com)
• Menambahkan entri khusus lokal seperti 172.16.12.34 nas.nothing-special.whatever.example.com ke file /etc/hosts agar bisa diakses dari browser

Menemukan akses tak terduga dari luar

• Beberapa hari setelah NAS dipasang, mulai muncul permintaan dari luar ("outside world") ke nama host yang sama
• Nama host tersebut adalah nama yang sepenuhnya khusus internal dan hanya ada di file /etc/hosts laptop
• Karena sebelumnya sudah disiapkan entri DNS wildcard untuk seluruh *.nothing-special.whatever.example.com yang mengarah ke mesin yang dikelola sendiri, kebocoran ini bisa terdeteksi
• Setiap kali NAS dimuat, host GCP mencoba terhubung sambil menyajikan nama host internal tersebut sebagai SNI

Penyebab kebocoran: pelaporan error sentry.io

• Antarmuka web NAS memiliki fitur phone home, dan sebagai bagian darinya mengirim stack trace ke sentry.io
• Saat browser melakukan callback ke sentry.io, nama host yang dipakai untuk perangkat penyimpanan internal ikut terkirim
• Dikonfirmasi bahwa pihak sentry.io membuat koneksi TLS balik ke nama host tersebut, tetapi sama sekali tidak mengirim permintaan HTTP nyata

Implikasi keamanan dan respons

• Jika nama host memuat informasi sensitif (misalnya nama seperti mycorp-and-othercorp-planned-merger-storage), ada risiko kebocoran informasi serius
• Dengan memanfaatkan mekanisme pelaporan sentry ini, dimungkinkan untuk memicu pemindaian DNS terhadap host eksternal arbitrer (cara detailnya diserahkan kepada pembaca)
• Sebagai langkah mitigasi, menjalankan Little Snitch untuk memblokir seluruh domain tersebut bagi semua aplikasi

[GN⁺]

Komentar Hacker News

• Sepertinya orang-orang salah paham. Ini bukan masalah log CT, melainkan terkait sertifikat wildcard
  Sentry mengumpulkan trace sisi klien, mengekstrak hostname yang mengirim permintaan, lalu mencoba melakukan polling kembali ke sana dan ditolak

  • Mungkin saja ini adalah upaya untuk mengambil favicon yang akan ditampilkan di UI trace
  • Namun dengan struktur seperti ini, Sentry bisa memiliki kerentanan keamanan yang memungkinkannya mengirim permintaan ke IP arbitrer. Terutama karena ia bisa berulang kali mengakses IP yang otomatis melaporkan traffic berbahaya
  • Alasan orang-orang bingung adalah karena tulisan blognya ditulis dengan sangat membingungkan dan tidak jelas

• Hostname pada dasarnya bukan informasi privat
  Ia terekspos ke luar lewat berbagai jalur seperti kueri DNS atau sertifikat TLS
  Jika ingin menyembunyikan layanan privat, lebih baik menaruh rahasia di path URL daripada di hostname
  Misalnya seperti fileservice.example.com/my-hidden-service-007-abc123/, karena ini hanya dikirim lewat HTTPS sehingga eksposurnya jauh lebih kecil

  • Tentu saja, bahkan dalam kasus ini path juga bisa terkirim ke layanan eksternal seperti Sentry, jadi tetap perlu membiasakan memakai URL opak dan tidak menaruh rahasia di URL
  • Ada juga pertanyaan, “Kalau hanya memakai HTTP, apakah kebocoran seperti ini berkurang?”

• Ada yang penasaran apakah “clown GCP Host” itu istilah teknis. Ternyata itu adalah ungkapan penulis untuk menyindir cloud
  Inti masalahnya adalah antarmuka web NAS mengirim log ke Sentry dengan hostname internal ikut terbawa
  Dalam kasus seperti ini, saya mungkin akan menggantinya dengan OS open source tepercaya, atau memblokir panggilan ke Sentry lewat DNS blocking seperti PiHole

  • “clown” disebut sebagai ungkapan sindiran untuk cloud milik Big Tech, dan dulu di IRC juga ada istilah “clown computing”
    Ada yang menjelaskan bahwa ia memakai DNS lokal dan proxy TLS untuk memblokir total traffic yang keluar
  • Orang lain menambahkan bahwa “clown” adalah istilah lama untuk menyindir penyedia cloud besar dan para penggunanya
  • Ada juga yang bercanda bahwa kadang ia memakai kata “weenie” alih-alih “clown”
  • Muncul juga humor seperti, “Sirkusnya sudah pergi, tapi para badutnya masih tertinggal”

• Karena kasus seperti ini, saya menganggap uBlock Origin sebagai standar minimum keamanan web
  Terlalu parah melihat kebanyakan halaman web memuat segunung skrip pihak ketiga dan membocorkan data
  Ini bukan solusi mendasar, tetapi itulah yang terbaik yang bisa kita lakukan saat ini

  • Saya juga memasang AdGuard Home di router, dan 15~20% traffic terblokir. Ini benar-benar menunjukkan separah apa pelacakan dan iklan sekarang

• Untuk mencegah masalah seperti ini, bagus jika menaruh reverse proxy Nginx di depan dan menyuntikkan header CSP
  Dengan begitu, memang tidak bisa menghentikan NAS mengirim permintaan ke luar, tetapi bisa mencegah browser yang melakukannya sebagai pengganti
  Misalnya permintaan avatar Steam (https://avatars.steamstatic.com/HASH_medium.jpg) juga bisa diblokir dengan kebijakan CSP
  Jika perlu, cukup buka sebagian saja. Tambahkan juga Referrer-Policy: no-referrer agar hostname tidak tertinggal di log eksternal

  • Seseorang menyinggung ungkapan berulang seperti “ATM machine”
  • Orang lain menjawab sambil bercanda, “NPM itu cukup sederhana”

• Saya membeli Synology NAS dan sudah beberapa kali menyesalinya
  Di luar software komunitas, hampir tidak banyak yang bisa dilakukan
  Menerapkan SSL dengan Let's Encrypt juga rumit, dan path-nya tidak standar sehingga sulit menemukan lokasi konfigurasinya
  Ada banyak keluhan seperti versi rsync yang sudah tua, utilitas bawaan yang kurang, dan lain-lain. Rasanya lebih baik dulu memakai NAS berbasis Linux atau BSD

  • Ada juga pendapat bahwa Synology sangat memuaskan bila dipakai hanya sebagai file server karena sangat stabil. Namun ada yang berencana pindah ke UniFi NAS karena kebijakannya yang tertutup
  • Ada juga respons bahwa “ingin server tapi mengeluh NAS bukan server” itu kontradiktif
  • Seseorang membagikan bahwa ada panduan memasang Debian terbaru di Synology NAS di forum Doozan
  • Ada pula saran, “kalau cuma dipakai sebagai file/iscsi server, itu sangat stabil, jadi jangan diutak-atik”
  • Sebaliknya, ada yang bilang membeli model RS217 seharga $100 adalah pembelian terbaiknya. Ia memakai Synology Office sebagai pengganti Google Docs dan terkesan dengan kualitas UI-nya

• Saya baru-baru ini mencoba mengonfigurasi Sentry, dan sistem ini punya fitur yang mencoba mengatur uptime monitoring secara otomatis
  Jika mengenali host, ia akan mengirim ping berkala, lalu jika responsnya stabil selama beberapa hari, muncul notifikasi, “Apakah Anda ingin menyiapkan uptime monitoring untuk host ini?”

  • Ada yang berkomentar singkat, “Peluang ekspansi”

• Secara pribadi saya memblokir seluruh domain terkait Sentry
  Ini bukan solusi umum, tetapi di lingkungan saya itulah pilihan terbaik

• Server reverse lookup alamat kadang terlihat mencoba menyelesaikan bahkan alamat jaringan internal (ULA, RFC1918)
  Jika data seperti ini digabungkan dengan informasi lain, kondisi internal bisa diinferensikan
  Ada juga yang berkata, “Bahkan pernah tertangkap audio UDP saat mengumpulkan data darknet”

  • Menanggapi itu, ada yang bertanya, “Audio UDP itu traffic SIP dari tahun berapa?”

• Dulu saya pernah menyelidiki fenomena serupa di Heroku
  Saat membuat aplikasi baru, sebuah subdomain acak diberikan, dan bahkan tanpa melakukan lookup DNS pun permintaan dari pemindai kerentanan langsung masuk
  Setelah ditanya ke Heroku, mereka menjelaskan bahwa URL aplikasi baru itu dipublikasikan di log Certificate Transparency (CT)

  • Ada yang berkata, “Ini seperti memasang plang ‘tolong serang saya’ pada setiap layanan baru,” dan mengkritik bahwa log CT seharusnya hanya mencatat hash, bukan sertifikat aslinya
    Ia juga membagikan tautan Cara kerja Certificate Transparency
  • Orang lain mengunggah tangkapan layar (tautan gambar) sambil berkata, “Saya menghindari masalah itu dengan memakai domain wildcard”