Meretas Jutaan Modem dan Menyelidiki Orang yang Meretas Modem Saya

• Saat melakukan pengujian kerentanan di rumah 2 tahun lalu, penulis mengalami kejadian aneh
• Penulis menjalankan server HTTP di sebuah box AWS untuk mengambil file dari server yang rentan
• Semua konfigurasi tampak benar, tetapi tepat saat hendak kembali ke pengujian kerentanan, muncul log yang tidak terduga
• Seseorang mencegat lalu mengirim ulang permintaan HTTP yang sama 10 detik kemudian di antara jaringan rumah dan box AWS
• Trafik ini seharusnya tidak bisa diakses dan tidak boleh ada perantara
• Pikiran pertama adalah komputer penulis telah diretas dan peretas secara aktif memantau trafik
• Penulis memeriksa apakah hal yang sama terjadi di iPhone, dan alamat IP tak dikenal itu juga mencegat serta mengirim ulang permintaan HTTP dari komputer dan iPhone
• Kemungkinan besar yang telah disusupi adalah ISP, modem, atau AWS
• Untuk menyingkirkan dugaan konyol bahwa AWS diretas, penulis menyalakan box di GCP dan gejala yang sama tetap terjadi
• Satu-satunya kemungkinan adalah modem telah diretas, tetapi siapa penyerangnya? Setelah memeriksa pemilik alamat IP, hasilnya menunjukkan milik DigitalOcean
• IP tersebut telah digunakan untuk berbagai situs phishing dan server email dalam beberapa tahun terakhir
• Karena perangkat yang disusupi masih terus berjalan, penulis mencabut dayanya dan menyimpannya di dalam kotak
• Penulis pergi ke toko Cox, mengembalikan modem yang diretas, dan menerima yang baru
• Setelah memasang modem baru, perilaku aneh berhenti, tetapi metode pasti komprominya tetap tidak diketahui
• Tiga tahun kemudian, saat berlibur bersama teman-teman ahli keamanan, penulis menceritakan kejadian ini dan mereka tertarik untuk menyelidikinya
• Saat meninjau domain yang didaftarkan oleh alamat IP itu, ditemukan banyak domain yang dibuat secara algoritmis. Ini mengindikasikan server C&C
• Penyerang melakukan berbagai aktivitas berbahaya dari IP yang sama, tetapi tidak pernah dihentikan selama 3 tahun. Sulit memahami motifnya
• Karena modem baru juga model yang sama, dipertimbangkan pula kemungkinan penyerang kembali menyusupinya
• Perhatian tertuju pada protokol TR-069 yang memungkinkan ISP mengelola perangkat. Jika infrastruktur alat dukungannya diserang, modem bisa diambil alih
• Dengan menganalisis JavaScript portal bisnis Cox, ditemukan lebih dari 700 jalur API. Di antaranya, API dengan fungsi akses peralatan dan akun pelanggan terbanyak adalah accountequipment, datainternetgateway, dan account
• Ditemukan kerentanan yang memungkinkan bypass autentikasi. Dengan mengirim ulang permintaan HTTP berulang kali, perintah dapat dijalankan tanpa izin
• Dipastikan bahwa siapa pun dapat berkomunikasi langsung dengan peralatan milik orang lain hanya dengan alamat MAC. Cox melayani jutaan pelanggan
• Terbukti bisa mendapatkan hak akses serupa tim dukungan teknis ISP, termasuk menimpa konfigurasi perangkat, mengakses router, dan menjalankan perintah di perangkat
• Ini adalah kerentanan yang memungkinkan perubahan konfigurasi jutaan modem tanpa prasyarat, akses ke PII pelanggan, dan perolehan hak setingkat tim dukungan ISP
• Skenario insidennya sebagai berikut
  1. Mencari pelanggan bisnis Cox melalui API
  2. Mengambil PII pelanggan seperti alamat MAC peralatan, email, nomor telepon, dan alamat melalui UUID
  3. Melihat kata sandi WiFi dan perangkat yang terhubung melalui alamat MAC
  4. Menjalankan perintah arbitrer, mengubah properti peralatan, dan mengambil alih akun
• Kerentanan tersebut dilaporkan ke Cox, dan dalam 6 jam mereka memblokir API serta mulai memperbaiki masalah autentikasi
• Dari lebih dari 700 API yang terekspos, banyak yang menyediakan fungsi administratif, dan semuanya memiliki masalah otorisasi yang sama
• Kasus ini menunjukkan rapuhnya lapisan kepercayaan antara ISP dan perangkat pelanggan
• Penulis masih penasaran bagaimana tepatnya modemnya diretas. Penulis juga tidak mengerti mengapa penyerang mengirim ulang trafik tersebut
• Teori atau pendapat terkait sangat diterima

Opini GN⁺

• Kerentanan keamanan: Artikel ini menunjukkan betapa serius dampak kerentanan keamanan di ISP. Khususnya, kemampuan untuk mengubah konfigurasi perangkat dari jarak jauh dapat disalahgunakan.
• Keamanan API: Menekankan pentingnya keamanan API. Kerentanan seperti bypass autentikasi dapat memicu masalah keamanan yang serius.
• Perlindungan data pengguna: Memperingatkan risiko bahwa informasi pribadi pelanggan dan konfigurasi perangkat dapat dengan mudah terekspos. ISP harus mengambil langkah keamanan yang lebih kuat untuk melindungi data ini.
• Pemahaman teknis: Dengan menjelaskan detail teknis agar dapat dipahami bahkan oleh software engineer pemula, artikel ini membantu pembaca mempelajari cara mendeteksi dan memperbaiki kerentanan keamanan.
• Usulan alternatif: Untuk menyelesaikan masalah seperti ini, penting menggunakan peralatan jaringan dan protokol keamanan yang lebih aman. ISP lain atau solusi keamanan lain juga bisa dipertimbangkan.

[GN⁺]

Komentar Hacker News

• Mengesankan bahwa Cox merespons dengan bertanggung jawab tanpa menyangkal masalah atau menyerang pembawa kabar. Saya ingin membaca artikel lanjutan tentang apa sebenarnya bug tersebut.
• Tidak nyaman ketika ISP memaksa penggunaan modem atau router milik mereka sendiri. Router AT&T mungkin bisa diretas, tetapi untungnya ada HTTPS.
• Ini adalah artikel dan investigasi yang sangat bagus. Antarmuka admin lokal router Nokia tampaknya tidak diautentikasi dengan benar. Saya tidak bisa mengubah pengaturan tertentu, tetapi bisa membajak halaman untuk mengubahnya.
• Banyak router mengharuskan pembaruan firmware manual. Router GL.iNet baru-baru ini memiliki kerentanan RCE. Disarankan melakukan pembaruan firmware dan langkah-langkah seperti menonaktifkan akses SSH.
• Saya masih penasaran bagaimana penyerang mencegat lalu lintas HTTP. Cox seharusnya dapat memeriksa versi firmware dan menyelesaikan masalah melalui pembaruan otomatis.
• Cox mengklaim kerentanan ini belum pernah dieksploitasi di masa lalu, tetapi sulit untuk memercayainya. Jaringannya ceroboh.
• Cukup mengejutkan bahwa kerentanan sebesar ini ditemukan di perusahaan teknologi besar. Artikelnya bagus, tetapi kerentanan ini tidak bisa dimaafkan.
• Saya penasaran apakah orang yang melaporkan kerentanan ini mendapat imbalan. Dia telah memberikan kontribusi besar, tetapi tampaknya tidak menerima apa pun. Ini sangat menghina.
• Alasan Cox mengklaim ini belum pernah dieksploitasi di masa lalu mungkin karena kurangnya log atau data audit.
• Isi artikelnya sangat bagus, tetapi penyerang yang benar-benar berniat bisa menyamar sebagai teknisi Cox untuk mendapatkan akses. ISP harus menerapkan pengaturan yang menonaktifkan akses jarak jauh secara default.