Peretasan Jutaan Modem dan Investigasi Kompromi pada Modem Saya

 (samcurry.net)
2 poin oleh GN⁺ 2024-06-05 | 1 komentar | Bagikan ke WhatsApp
  • Permintaan HTTP dari jaringan rumah diputar ulang apa adanya sekitar 10 detik kemudian dari IP DigitalOcean, mengungkap indikasi bahwa lalu lintas beberapa perangkat di balik gateway Cox Panoramic Wifi terekspos ke luar
  • Hasil pelacakan VirusTotal dan URLscan menunjukkan IP tersebut sebelumnya terhubung ke domain phishing dan banyak domain dengan pola word+6 digits+TLD, sehingga muncul dugaan adanya algoritme pembangkitan domain untuk C&C
  • Dalam proses analisis portal Cox Business pada 2024, API berbasis Spring dan dokumentasi Swagger di balik /api/cbma/ terekspos, dan hanya dengan permintaan berulang terjadi bypass verifikasi otorisasi
  • API yang terekspos memungkinkan pencarian pelanggan, melihat PII akun, melihat alamat MAC perangkat, hingga mengubah pengaturan WiFi, dan logika pembuatan encryptedValue juga bisa dipanggil dari JavaScript frontend
  • Setelah laporan dikirim, Cox menurunkan API yang terekspos dalam 6 jam, tetapi layanan ini dimulai pada 2023 sehingga penyebab kompromi modem pertama pada 2021 tetap menjadi hal terpisah

Pemutaran ulang permintaan HTTP yang ditemukan di jaringan rumah

  • Saat menguji kerentanan blind XXE, sebuah server HTTP Python dijalankan di instance AWS, lalu permintaan /test123 dikirim dari komputer rumah
    • Permintaan asli tiba dari IP rumah 98.161.24.100
    • Sekitar 10 detik kemudian, IP tak dikenal 159.65.76.209 mengirim ulang permintaan ke jalur yang sama
  • Ketika URL yang sama diminta dari Safari di iPhone, IP yang sama kembali memutar ulang permintaan itu
    • Fenomena yang sama berulang bukan hanya di komputer rumah, tetapi juga pada perangkat lain di jaringan rumah
  • Fenomena yang sama juga muncul di instance AWS baru dengan Nginx, serta di instance GCP, sehingga kemungkinan masalah dari AWS sendiri menjadi kecil
    • Kemungkinan yang tersisa adalah ISP, modem, atau kompromi pada jalur jaringan
  • Hasil pencarian pemilik IP menunjukkan 159.65.76.209 adalah alamat DigitalOcean, bukan alamat ISP

Infrastruktur berbahaya lama yang terhubung ke IP DigitalOcean

  • Pencarian di VirusTotal menunjukkan domain-domain yang sebelumnya pernah di-resolve ke IP tersebut
    • Dari 5 domain terbaru, 3 adalah situs phishing dan 2 tampak seperti server mail
    • Contoh domain:
      • regional.adidas.com.py
      • isglatam.online
      • isglatam.tk
      • mx12.limit742921.tokyo
      • mx12.jingoism44769.xyz
  • isglatam.online dan isglatam.tk adalah situs phishing yang menargetkan perusahaan keamanan siber Amerika Selatan isglatam.com
    • Di situs ISG Latam yang asli, perusahaan ini dikonfirmasi berbasis di Paraguay dan bermitra dengan Crowdstrike, AppGate, Acunetix, DarkTrace, dan ForcePoint
  • URLscan menyisakan jejak bahwa kedua domain tersebut meng-host situs phishing BeEF yang umum
  • IP yang sama terhubung ke domain terkait Adidas, phishing ISG Latam, dan aktivitas yang tampak seperti pemutaran ulang lalu lintas modem
    • Ada kemungkinan IP itu berputar di antara beberapa pemilik, tetapi karena jeda antaraktivitasnya panjang, kemungkinan langsung dialihkan ke pengguna jahat lain tampak rendah

Penggantian modem dan investigasi ulang 3 tahun kemudian

  • Perangkat yang dipakai saat itu adalah gateway Cox Panoramic Wifi, lalu diganti dengan modem baru di toko Cox
    • Perangkat lama adalah perangkat sewaan dari ISP sehingga harus dikembalikan
    • Dump firmware atau reverse engineering tidak sempat dilakukan
  • Setelah modem baru dipasang, fenomena pemutaran ulang permintaan HTTP berhenti total
    • Tidak ada lagi IP lain yang muncul di log
    • Saat itu sulit melakukan penyelidikan lebih jauh selain menyimpulkan modem lama memang telah dikompromikan
  • Pada awal 2024, sekitar 3 tahun kemudian, investigasi dilanjutkan lagi bersama kenalan di industri keamanan dan perhatian tertuju pada format domain seperti limit742921.tokyo dan jingoism44769.xyz
    • Setelah melakukan reverse IP lookup pada IP terkait, ditemukan lebih dari 1.000 domain dengan pola yang sama
  • Format domain itu semuanya mengikuti struktur word + 6 numbers + TLD
    • Karena didaftarkan dalam jumlah besar dan strukturnya algoritmis, pola itu tampak seperti algoritme pembangkitan domain yang dipakai operator berbahaya untuk menyembunyikan alamat server C&C
    • Domain terakhir yang teramati didaftarkan pada 17 Maret 2023, dan setelah itu tidak ada lagi host yang di-resolve
  • Modem baru yang dipasang adalah model yang sama, tetapi berdasarkan pencarian Google tidak ditemukan kerentanan publik untuk model tersebut

Hipotesis yang berawal dari alat dukungan ISP dan TR-069

  • Saat memindahkan modem Cox ke lokasi baru, terlihat bahwa staf dukungan ISP dapat mengubah konfigurasi perangkat dari jarak jauh
    • Staf dukungan dapat memperbarui pengaturan perangkat, mengganti kata sandi WiFi, dan melihat perangkat yang terhubung
  • Manajemen jarak jauh ini dilakukan melalui protokol TR-069 yang diimplementasikan pada 2004
    • Ini adalah cara ISP mengelola perangkat di dalam jaringannya sendiri melalui port 7547
    • Protokol tersebut juga pernah dibahas dalam presentasi DEF CON, tetapi bukan permukaan yang terbuka ke publik
  • Fokus investigasi kemudian bergeser dari protokol itu sendiri ke situs web manajemen perangkat internal yang dipakai staf dukungan dan API di belakangnya
    • Jika API seperti ini bisa melihat atau mengubah konfigurasi perangkat pelanggan, atau menjalankan perintah, maka ini bisa menjadi jalur kompromi modem

Struktur API portal Cox Business

  • Portal Cox Business menyediakan fungsi manajemen perangkat jarak jauh, pengaturan aturan firewall, dan pemantauan lalu lintas jaringan
  • Rute-rute diekstrak dari file JavaScript frontend halaman login main.36624ed36fb0ff5b.js
    • Ditemukan lebih dari 100 panggilan API berbasis /api/cbma/
    • Contoh:
      • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
      • /api/cbma/profile/services/profile/userroles/
      • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
  • /api/cbma/ menampilkan respons yang berbeda dari frontend biasa sehingga tampak seperti reverse proxy menuju backend terpisah
    • Permintaan ke /api/anything_else/example mengembalikan redirect 301
    • Permintaan ke /api/cbma/example mengembalikan 500 Internal Server Error
  • Permintaan pendaftaran memuat beberapa header terkait autentikasi
    • Clientid: cbmauser
    • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
    • Cb_session: unauthenticateduser
    • Authorization: Bearer undefined
  • Setelah metode HTTP diubah, respons error bergaya Spring dikembalikan, sehingga terkonfirmasi backend ini berbasis Spring

Dokumentasi Swagger dan bypass sumber daya statis

  • Jalur Spring actuator tidak ditemukan, tetapi sebagian jalur Swagger UI dapat diakses
    • Jalur /api/cbma/userauthorization/swagger-ui/index.html memberikan respons
  • Halaman Swagger yang pertama dimuat kosong
    • Sumber daya statis seperti .png, .js, .css diarahkan ke jalur host asli, bukan ke proxy API, sehingga memicu redirect tanpa akhir
  • Dengan Burp Intruder, URL diuji dengan menambahkan %00 hingga %FF di akhir, dan ketika %2f yaitu / yang di-URL-encode ditambahkan setelah .js, server mengembalikan 200 OK
    • Contoh: /swagger-initializer.js%2f
  • Setelah memakai fitur match-and-replace Burp untuk menambahkan %2f ke semua sumber daya statis, dokumentasi Swagger termuat normal
  • Secara keseluruhan teridentifikasi sekitar 700 panggilan API
    • account: 115
    • voiceutilities: 73
    • user: 70
    • datainternetgateway: 57
    • accountequipment: 55
    • billing: 53
    • ticket: 52
    • Selain itu ada profile, voicecallmanagement, voicemail, userauthorization, csr, dan lainnya
  • API yang paling penting karena terkait langsung dengan perangkat dan akun pelanggan tampak berada di accountequipment, datainternetgateway, dan account

Bypass verifikasi otorisasi lewat permintaan berulang

  • Saat semua endpoint GET diuji untuk melihat apakah bisa diakses tanpa autentikasi, sebagian mengembalikan error autentikasi dan sebagian lain mengembalikan 200 OK
  • Endpoint profilesearch pada awalnya mengembalikan respons sukses dengan hasil pencarian kosong
    • Permintaan yang sama kadang mengembalikan Authorization Error-Invalid User Token, lalu saat dikirim ulang justru berhasil
  • Ketika permintaan yang sama dikirim berkali-kali, error otorisasi menghilang dan hasil pencarian pelanggan dikembalikan
    • Pencarian cox mengembalikan 10000+ hits
    • Pencarian fbi mengembalikan hasil yang mencakup alamat fisik kantor lapangan FBI yang menjadi pelanggan bisnis Cox
  • Hanya dengan mengulang permintaan API, bypass otorisasi menjadi mungkin, dan masalah yang sama tampak memengaruhi lebih dari 700 API secara luas

Akses ke perangkat pelanggan dan penelusuran akun

  • Untuk memastikan apakah API Cox Business juga dapat mengakses perangkat jaringan residensial, diuji API sederhana yang menerima alamat MAC
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
  • Setelah melihat alamat MAC dari akun Cox milik sendiri dan mengulang permintaan, alamat IPv4 modem sendiri pun dikembalikan
    • Ini mengonfirmasi bahwa API tersebut benar-benar dapat berkomunikasi dengan perangkat Cox yang nyata
  • API daftar perangkat yang menggunakan ID akun juga berfungsi
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
    • Respons memuat informasi perangkat internet, perangkat suara, dan perangkat TV
    • Model perangkat, jenis perangkat, alamat MAC, daftar port, dan nomor seri turut dikembalikan
  • API pencarian pengguna berbasis email juga mengembalikan informasi akun bisnis
    • Contoh permintaan: /api/cbma/user/services/user/admin@cox.net
    • Data yang dikembalikan mencakup email, nama, nomor telepon, status, hak akses, apakah pemilik profil, dan email alternatif
  • Permintaan POST serupa untuk pembaruan akun juga berfungsi, sehingga terkonfirmasi adanya kemampuan baca dan tulis terhadap akun bisnis

encryptedValue dan perubahan konfigurasi perangkat

  • Permintaan untuk mengubah pengaturan perangkat keras memerlukan parameter bernama encryptedValue
    • Contohnya perubahan kata sandi perangkat dan perubahan pengaturan WiFi
  • Logika pembuatan dan dekripsi encryptedValue dilacak di JavaScript frontend
    • encryptWithSaltandPadding
    • decryptWithSaltandPadding
  • PIN 4 digit yang disetel saat pendaftaran akun juga dienkripsi dengan fungsi yang sama, sehingga titik pemanggilan fungsi itu dapat diberi breakpoint di debugger browser lalu dipanggil langsung dari console
  • Ketika encryptedValue yang diperoleh dari respons akun nyata didekripsi, format nilainya berisi:
    • Nomor akun Cox
    • Nama perangkat
    • ID perangkat
    • Nilai yang tidak diketahui
    • Alamat MAC
    • Label
  • Bahkan jika sebagian besar nilai seperti nomor akun diisi sembarang dan hanya alamat MAC yang valid, permintaan tetap berhasil saat encryptedValue baru dibuat
    • Server tidak memverifikasi apakah ID akun dan alamat MAC benar-benar cocok

Kemungkinan mengubah pengaturan modem mana pun

  • Sebuah permintaan POST dikirim untuk mengubah SSID WiFi perangkat sendiri menjadi Curry
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
    • Isi permintaan memuat wifiSettings, additionalProperties, dan encryptedValue
  • Responsnya adalah {"message": "Success"}, lalu jaringan sempat terputus dan sekitar 5 menit kemudian perangkat reboot
    • SSID benar-benar berubah menjadi Curry
  • Perilaku ini menunjukkan bahwa perubahan konfigurasi perangkat melalui API benar-benar diterapkan ke perangkat nyata
    • Penyerang bisa memperoleh UUID akun melalui pencarian pelanggan
    • Melihat alamat MAC perangkat yang terhubung
    • Membaca atau mengubah pengaturan perangkat berdasarkan alamat MAC
  • Hak akses ini setara dengan tingkat akses tim dukungan ISP, dan merupakan jalur yang berpotensi memengaruhi jutaan perangkat Cox

Cakupan dampak dan skenario serangan

  • Kombinasi kerentanan ini menunjukkan bahwa penyerang eksternal dapat melakukan hal-hal berikut tanpa prasyarat
    • Menjalankan perintah dan mengubah konfigurasi pada jutaan modem
    • Mengakses PII pelanggan Cox Business
    • Memperoleh hak akses setara tim dukungan ISP
  • Cox adalah penyedia broadband swasta terbesar di AS, penyedia TV kabel terbesar ketiga, operator telepon terbesar ketujuh, dan ISP paling populer di 10 negara bagian
  • Contoh alur serangan:
    • Mencari target Cox Business berdasarkan nama, nomor telepon, email, dan nomor akun
    • Menggunakan UUID yang dikembalikan untuk melihat seluruh PII akun beserta alamat MAC perangkat, email, nomor telepon, dan alamat
    • Menggunakan MAC perangkat keras untuk melihat kata sandi WiFi dan perangkat yang terhubung
    • Menjalankan perintah arbitrer, mengubah properti perangkat, dan mengambil alih akun korban
  • Dari lebih dari 700 API yang terekspos, banyak yang menyediakan fungsi administratif, dan masalah otorisasi yang sama muncul lewat permintaan berulang

Laporan ke Cox dan perbaikan

  • Kerentanan ini dilaporkan melalui program responsible disclosure milik Cox
  • Cox menonaktifkan panggilan API yang terekspos dalam 6 jam setelah laporan diterima dan mulai memperbaiki kerentanan otorisasi
    • Pada hari berikutnya, kerentanan itu sudah tidak bisa direproduksi lagi
  • Linimasa publik:
    • 2024-03-04: Kerentanan dilaporkan ke Cox
    • 2024-03-05: Hotpatch diterapkan, endpoint bisnis yang tidak esensial mulai mengembalikan 403 dan berhenti berfungsi
    • 2024-03-06: Email dikirim ke Cox untuk memberi tahu bahwa kerentanan tidak lagi bisa direproduksi
    • 2024-03-07: Cox membalas bahwa mereka memulai tinjauan keamanan menyeluruh
    • 2024-04-10: Cox diberi tahu tentang niat publikasi 90 hari setelah pelaporan
    • 2024-04-29: Tautan draf blog dibagikan ke Cox

Pertanyaan yang tersisa

  • Cox menyelidiki apakah jalur kerentanan tertentu pernah dieksploitasi sebelumnya dan mengonfirmasi tidak ada riwayat eksploitasi
    • Layanan tersebut mulai beroperasi pada 2023
    • Kompromi modem pertama terjadi pada 2021, sehingga kerentanan API Cox Business yang dipublikasikan ini bukan penyebab kompromi saat itu
  • Cox menyampaikan bahwa mereka sama sekali tidak terkait dengan IP DigitalOcean tersebut
    • Perangkat itu memang benar-benar diretas, tetapi dengan metode yang berbeda dari kerentanan API yang dipublikasikan
  • Modem tidak pernah dikonfigurasi agar bisa diakses dari luar, dan tidak pernah ada login ke perangkat itu dari jaringan rumah
    • Jalur lain yang mungkin dibicarakan adalah metode seperti 0day yang berawal dari CSRF lokal lalu berujung pada RCE
  • Pertanyaan terbesar adalah mengapa penyerang memutar ulang permintaan HTTP
    • Jika mereka sudah berada di dalam jaringan, mereka sebenarnya bisa mengakses tanpa ketahuan, jadi alasan semua permintaan HTTP diputar ulang masih belum diketahui

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-05
Opini Hacker News

  • Tulisan yang bagus dan mudah diikuti. Saya terutama suka bahwa Cox tidak menyerang pelapor atau menyangkal masalahnya, melainkan bertindak seperti contoh respons keamanan yang bertanggung jawab yang bisa diharapkan dalam situasi seperti ini.
    Saya ingin melihat tulisan lanjutan tentang bug apa yang sesekali memungkinkan akses API tanpa otorisasi. Kesalahan seperti ini mudah terlewat oleh pengujian dangkal, atau tergantung penyebabnya, mungkin sama sekali tidak bisa direproduksi di lingkungan pengujian.

    • Memang Cox merespons dengan bertanggung jawab, tetapi rasanya akan lebih baik kalau sejak awal mereka lebih memanfaatkan kesempatan saat seseorang datang membawa perangkat yang terinfeksi.
      Dulu saya pernah secara tidak sengaja menemukan kerentanan serius di operator telekomunikasi tradisional, tetapi hanya lewat kanal dukungan pelanggan biasa, butuh hampir seminggu untuk bisa mencapai orang yang tepat, dan organisasi dukungan sama sekali tidak bisa melakukan eskalasi. Di Cox juga, seorang profesional keamanan informasi datang langsung membawa perangkat yang terinfeksi, tetapi organisasi dukungan tidak menanganinya dengan benar.
    • Tulisannya juga mudah dibaca dan respons Cox juga bagus. Saya juga suka bahwa proses penemuan dan bug itu sendiri tidak disampaikan dengan cara negatif atau merendahkan.
    • Perusahaan seharusnya memberi imbalan kepada orang yang menemukan hal semacam ini, bukan menggugat mereka karena “meretas”.
    • Saya juga penasaran bug apa yang sesekali memungkinkan akses API tanpa otorisasi. Mungkin kita tidak akan pernah tahu, tetapi bisa saja itu adalah kasus backend pengujian yang tidak melakukan pemeriksaan otorisasi dan secara keliru masuk ke konfigurasi load balancer.
    • Tulisannya bagus, tetapi penggunaan kata super yang terus-menerus seperti “super curious”, “super interesting”, “super interested” agak mengganggu.

  • Hal yang menyebalkan dalam situasi seperti ini adalah ketika ISP memaksa kita memakai modem atau router mereka. Misalnya, AT&T fiber memakai autentikasi 802.1X berbasis sertifikat untuk akses jaringan; tanpa itu, seharusnya kita bisa mencolokkan perangkat apa pun ke ONT.
    Ada atau pernah ada cara bypass, tetapi saya tidak ingin menjalani prosedur seperti itu hanya untuk memakai internet, jadi saya mematikan semua fitur router AT&T dan memasang router saya sendiri yang saya kelola agar tetap terbaru di belakangnya. Kalau router AT&T diretas, saya mungkin tidak menyadarinya sampai ada dampak buruk pada layanan. Untungnya sekarang sebagian besar sudah memakai HTTPS.

    • Kalau AT&T fiber dengan ONT yang terpisah dari modem, bypass 802.1X cukup mudah. Colokkan switch unmanaged di antara modem dan ONT, biarkan modem melakukan autentikasi, lalu cabut modemnya.
      Kalau ONT reboot, kemungkinan besar harus dilakukan lagi, tetapi dalam kasus saya AT&T memberi UPS untuk ONT, jadi frekuensi reboot seharusnya rendah. Secara pribadi, saya membuat konfigurasi rumit berbasis NIC bypass: saat firewall mati atau sedang reboot, trafik melewati modem AT&T; saat menyala, firewall saya menerima trafik dan secara selektif meneruskannya lewat modem. Namun sebenarnya memakai switch unmanaged saja sudah cukup.
    • Kemungkinan router CPE AT&T diretas tidak membuat banyak perbedaan jika ada router saya sendiri di antara jaringan saya dan jaringan AT&T. Meskipun router CPE AT&T dihapus, pada akhirnya kita tetap terhubung ke kotak hitam yang tidak kita kendalikan, dan perangkat itu juga bisa saja diretas atau memeriksa trafik dengan berbagai cara.
    • Untungnya Cox bukan ISP seperti itu. Mereka menerima modem DOCSIS yang cukup modern dan sesuai dengan kecepatan langganan.
      Namun pujian untuk Cox berhenti sampai di situ. Selama 2 tahun saya mengalami packet loss sesekali, dan meskipun saya mengumpulkan data bahwa node tertentu kemungkinan kelebihan pelanggan, tampaknya tidak ada jalur eskalasi dukungan untuk mencapai orang yang bisa memahaminya.
    • Sebagai catatan, di xgspon proses bypass sekarang sudah otomatis. Kurang lebih “colok SFP+, unggah firmware lewat antarmuka web, masukkan nomor seri perangkat”, dan tergantung modul SFP yang digunakan, langkah kedua juga bisa dilewati.
      Pada praktiknya, status 802.1X tidak diverifikasi di sisi server. Standarnya mengatakan jika 802.1X diwajibkan tetapi tidak dijalankan, modem tidak boleh meneruskan trafik, tetapi kebanyakan tetap meneruskannya atau bisa diubah agar begitu. Di pihak AT&T, mereka tidak memverifikasi dan selalu melewatkan trafik; secara internal memang itulah yang terjadi.
    • Ada beberapa cara untuk tersambung tanpa gateway AT&T, dan berbagai metodenya dirangkum di https://pon.wiki/.

  • Tulisan yang enak dibaca dan investigasinya juga luar biasa. Menyenangkan juga melihat contoh perusahaan besar tidak menjatuhkan bom nuklir ke peneliti keamanan.
    Saya tidak yakin, tetapi saya curiga permintaan ke antarmuka admin lokal router Nokia ini tidak diautentikasi dengan benar. Baru-baru ini saya mendapat perangkat yang sama, dan ada pengaturan yang tidak bisa diubah dengan hak admin biasa, sementara ISP tidak memberi akun super admin. Namun dengan inspector halaman, jika field yang dinonaktifkan diaktifkan kembali lalu nilainya diubah, API menerimanya begitu saja. Jika dalam kondisi seperti ini sebuah aplikasi bisa berjalan di dalam jaringan internal, mengambil alih router dengan cara seperti ini tidak akan terlalu sulit, meski tampaknya membutuhkan kondisi yang cukup spesifik.

    • Fakta bahwa Cox adalah penyedia broadband swasta terbesar di AS, penyedia TV kabel terbesar ketiga, operator telepon terbesar ketujuh, dan ISP paling populer di 10 negara bagian membuat saya berpikir bahwa ISP tidak seharusnya sebesar ini.
      Cox jelas merupakan target serangan yang menarik, dan seperti contoh dalam artikel, satu kerentanan saja bisa membahayakan bahkan kantor lapangan FBI. Rasanya akan lebih tepat menulis “Cox mengklaim telah menyelidiki apakah pernah dieksploitasi dan tidak menemukan catatan”, bukan “Cox menyelidiki apakah pernah dieksploitasi dan tidak menemukan catatan”.

  • Bisakah kita percaya klaim “tidak ada riwayat eksploitasi sebelumnya”? Seluruh jaringan terlihat penuh lubang seperti keju Swiss.

    • Karena itulah semua log dikirim ke bucket S3 di akun AWS yang hanya punya izin tulis, lalu untuk masuk ke akun yang bisa melakukan operasi lain pada bucket itu diperlukan tiga orang. Saya tidak tahu apakah Cox melakukan itu, tetapi jika merancang sistem agar bisa mengatakan “tidak ada riwayat eksploitasi”, strukturnya akan seperti itu.
    • Kalau Anda pihak yang memulai percakapan, Anda tidak bisa terus tidak ikut serta sampai akhir. Pada titik tertentu, Anda harus mengatakan, “informasi yang kami miliki sejauh ini, dan ini lebih baik daripada sebelumnya.”
    • Jika mereka mengatakan “tidak ada”, dalam situasi ketika perangkat yang sudah terinfeksi ditemukan, itu juga bisa berarti ada jalur serangan lain yang mungkin diketahui atau tidak diketahui Cox.

  • Banyak router harus diperbarui firmware-nya secara manual. Router GL.iNet dalam 6 bulan terakhir memiliki beberapa kerentanan eksekusi kode jarak jauh, jadi sebaiknya segera cek apakah router Anda pernah diretas dan, jika memungkinkan, naikkan firmware-nya.
    Gejala yang terlihat dari sudut pandang pengguna biasa adalah kecepatan internet menurun, sinyal Wi-Fi terputus-putus dan perangkat gagal tersambung, serta router sendiri terhubung ke internet tetapi halaman admin internal (192.168.8.1) tidak merespons. Dalam kasus saya, penyerang memasang aplikasi Pawns dari IPRoyal untuk menjadikan router sebagai server proxy dan menghasilkan uang; mereka juga mencuri log sistem yang berisi waktu penggunaan dan apakah NAS terhubung, serta memiliki reverse shell. Urutan penanganan yang baik adalah memperbarui firmware, mereset router untuk menghapus malware, menonaktifkan SSH, lalu mematikan akses jarak jauh seperti dynamic DNS. Jika membutuhkan akses jarak jauh, Anda bisa mempertimbangkan Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier, Tailscale, dan semacamnya, tetapi saya tidak terlalu tahu mana yang paling cocok. GL.iNet tidak mengikuti prinsip least privilege dan secara default menjalankan proses sebagai root; SSH juga aktif secara default dengan akses root, jadi tampaknya lebih baik dihindari.

  • Pernyataan “tidak ada riwayat eksploitasi” bisa saja berarti sejak awal log atau materi auditnya tidak cukup, atau karena setelah peretasan tidak ada log yang tersisa.

    • Dari yang saya lihat di tulisan itu, jalur serangan tertentu yang “mencoba ulang permintaan tidak sah sampai berhasil” sangat mudah terlihat di log. Kebijakan log dasar yang hanya mencatat path, IP, dan kode status saja sudah cukup, dan itu mendekati default kebanyakan web server dan framework.
    • “Absence of evidence is not evidence of absence” sangat cocok untuk kasus ini.
    • Atau mungkin mereka berbohong. Kalau dilihat dari sudut pandang Cox, kenapa mereka mau mengungkap ke orang di luar perusahaan bahwa sebelumnya memang ada riwayat eksploitasi? Sebenarnya mereka tidak punya alasan untuk mengungkap apa pun.

  • Sistem autentikasi macam apa yang sesekali meloloskan panggilan secara acak? Benar-benar terlihat tidak kompeten.

    • Saya pernah menemukan hal seperti ini di API vendor. Provider pengguna saat ini didaftarkan sebagai singleton, bukan per request, sehingga kadang bisa ikut terbawa di ekor pengguna yang sudah terautentikasi.
    • Saya pernah melihat bug besar yang mirip. API menolak permintaan tanpa autentikasi tepat selama 10 menit, lalu mengizinkannya tepat selama 1 menit, dan siklus ini berulang tanpa henti. Saya benar-benar penasaran apa yang terjadi di backend.
    • Dari pengalaman saya, hal seperti ini bisa terjadi karena load balancer. Misalnya, tidak merutekan dengan benar ke server di dalam pool, atau konfigurasi maupun level patch antarserver berbeda.
    • Bisa juga sebagian origin server yang menerima routing permintaan salah konfigurasi.
    • Jika API berada di belakang reverse proxy, mungkin juga itu masalah cache.

  • Apakah mereka membayar? Orang ini pada dasarnya menyelamatkan Cox, dan memberi tahu mereka soal pengambilalihan total infrastruktur keamanan yang tidak mudah ditemukan.
    Kelihatannya ia tidak menerima apa pun sebagai imbalan karena “melakukan hal yang benar”, dan itu cukup menghina. Bagaimana perusahaan memandang orang yang datang ke kantor membawa informasi penting mungkin sangat berbeda dari persepsi diri orang itu sendiri. Kasus seperti ini menunjukkan dengan baik mengapa 0day sebaiknya jangan pernah dilaporkan.

    • Untuk ukuran Cox, tidak menuntut orang yang memperbaiki kesalahan mereka saja mungkin sudah termasuk beruntung.
    • Sam adalah peneliti keamanan yang sangat terkenal, jadi tidak mengejutkan kalau ia menghasilkan lebih dari 350 ribu dolar AS per tahun. Tulisan seperti ini bisa bernilai banyak uang lewat peningkatan reputasi.
    • Cox tidak membayar bug bounty.

  • Pertanyaan yang masih terbuka adalah bagaimana para penyerang menangkap traffic HTTP miliknya.
    Sebagian CPE punya fitur semacam Wireshark cloud untuk debugging. Saya tidak tahu apakah image firmware produksi Cox punya fitur seperti itu. Biasanya firmware produksi dan firmware pengujian terpisah, sehingga menguji masalah di lingkungan produksi jadi lebih sulit. Cox semestinya bisa mengecek versi firmware apa saja yang ada di lapangan; ISP bisa melakukan auto-upgrade firmware yang tidak cocok dengan versi tertentu, dan karena ini modem Cox, kemungkinan besar mereka juga punya firmware-nya. Kalau itu firmware debug, saya penasaran bagaimana bisa terpasang dan bagaimana bisa tetap bertahan.

    • Di Linux, jika membuat socket dengan PF_PACKET, Anda bisa menyadap traffic dari semua interface. Anggap saja seperti tcpdump level rendah.
      Mudah saja menyadap semua data di port 80, mem-parsing header HTTP, lalu melakukan tindakan yang diperlukan. Namun saya tidak begitu tahu kenapa seseorang memutar ulang request tersebut.
    • Jika itu HTTP, bukan HTTPS, siapa pun atau perangkat apa pun di jalur koneksi bisa melihat request-nya.
    • Ini alasan lain untuk tidak memercayai dan tidak menggunakan perangkat yang disediakan ISP. Manajemen jarak jauh oleh ISP? Tidak, terima kasih.

  • Ini salah satu alasan mengapa kita tidak seharusnya menyambut modem kabel dari ISP yang memiliki fitur Wi-Fi, dan mengapa keamanan endpoint serta layanan di dalam LAN harus diperhatikan. Minimal, di segmen modem/ISP perlu TLS dan DNS over TLS.
    Saya cukup menaruhnya dalam bridge mode, mematikan Wi-Fi, lalu membiarkan semua fungsi jaringan ditangani perangkat saya sendiri. Modem terakhir yang saya sewa dari ISP tidak pernah diperbarui firmware-nya oleh ISP selama hampir 10 tahun, tetapi berkat itu memang sangat stabil.

    • Ada juga argumen tandingan. ISP dengan lebih dari 1 juta pelanggan punya insentif untuk meng-upgrade home gateway “selamanya” demi mengurangi biaya belanja modal.
      Free, tempat saya bekerja, adalah ISP Prancis dan juga menyediakan home gateway di Italia melalui Iliad; perangkat yang dirilis pada 2011 pun masih kami perbarui. Perangkat itu menjalankan Linux 6.4 terbaru, serta menyediakan fitur modern seperti airtime QoS, pembaruan aplikasi mobile, dan berbagai fitur software.
    • Router adalah perangkat IoT yang paling banyak dieksploitasi di muka bumi, dan karena pengguna akhir tidak melakukan patch, kerentanan firmware sering bertahan selama bertahun-tahun. Jika ISP bisa mendorong patch ke router dan menarik kembali perangkat yang tidak bisa di-patch, maka termasuk fakta bahwa kepemilikannya ada pada ISP, itu memberi keuntungan bersih bagi keamanan siber.
    • Saya juga menaruhnya dalam bridge mode dan mematikan Wi-Fi. Suatu ketika saya meminta dipasang modem sederhana tanpa fungsi router dan access point, dan saya tidak menyangka perangkat tujuan tunggal seperti itu masih ada.
      Saya membeli router yang relatif bagus, memasang OpenWrt, lalu menghubungkannya ke jaringan melalui perangkat ISP sebagai bridge, dan semuanya berjalan baik. Sekarang saya juga memakai HTTPS di dalam LAN.
    • Saya bilang kepada ISP bahwa kalau mereka tidak mengizinkan saya memakai router sendiri, saya akan pindah ke ISP lain.