Kerentanan UPnP lama dengan cara baru

Semua yang baru adalah yang sudah lama terlupakan (atau lebih baik, sudah sangat lama terlupakan). Tentu saja, memang benar untuk memantau kerentanan baru, tetapi Anda tidak boleh melupakan yang lama. Apalagi saat pabrikan membiarkan dirinya “melupakan” mereka. Seseorang harus ingat. Kalau tidak, kita akan menginjak menyapu yang sama lagi dan lagi.

Artikel ini akan fokus pada satu yang lama, tetapi ternyata, tidak pernah kehilangan relevansinya dengan hari ini, lubang UPnP.



PS Saya tidak akan memanggil penyedia, ia tidak bersalah atas hal ini, tetapi di sisi lain ada pengawasan yang jelas terhadap kebijakan keamanan, yang, ditambah dengan arsitektur jaringan, memungkinkan untuk mengeksploitasi kerentanan ini. Seperti biasa, bintang-bintang bertemu. Penyedia menginstal router di jaringannya ke klien dengan chip yang diperlukan dan menghubungkannya dengan alamat ip eksternal. Ya, sebagian besar port telah difilter, tetapi karena alasan tertentu tidak 52869.

PPS Semua acara terjadi pada akhir 2018. Pahlawan adalah fiksi, dan kebetulan dengan kepribadian nyata adalah acak.


Penyebutan kerentanan pertama kali dilakukan pada tahun 2014: tyk
Upaya untuk menghubungi pabrikan tidak membawa banyak kesuksesan dan kerentanan diterbitkan. Satu-satunya rekomendasi tanggapan adalah:

"... membatasi interaksi dengan layanan ... Hanya klien dan server yang memiliki hubungan prosedural hukum ... yang dapat berkomunikasi dengannya."

Kelemahan ada dalam layanan SOAP miniigd. Masalahnya adalah memproses permintaan NewInternalClient karena ketidakmampuan untuk menghapus data pengguna sebelum membuat panggilan sistem. Seorang penyerang bisa menggunakan kerentanan ini untuk mengeksekusi kode dengan hak akses root.

Yaitu Pada semua router dengan UPnP versi 1.0, Anda dapat mengeksekusi kode jarak jauh sewenang-wenang.
Tanpa otorisasi. Dari akar. Bagus kan?

Siapa pun dapat menemukan plugin yang siap pakai untuk metasplit di github, yang kinerjanya diuji oleh kursi yang terbakar dari teknisi kami.
Itu tidak terduga dan sama sekali tidak menyenangkan.

Kronologi singkat peristiwa hari itu:

14:00 Dalam dukungan teknis, pelanggan mulai menerima panggilan ke Internet yang berfungsi buruk.

• Gejala di sisi klien: "itu bekerja lambat, setelah reboot itu berfungsi dengan baik untuk sementara waktu, sekali lagi perlahan."
• Gejala pada bagian peralatan: lonjakan kecil dalam lalu lintas dan beban CPU dihapuskan ke beban yang dihasilkan klien.

Aplikasi tunggal terdaftar untuk memeriksa jalur untuk admin atau untuk keberangkatan penginstal. Tidak ada template umum untuk tindakan. Tidak ada yang jelas.

15:00 Jumlah aplikasi mulai melebihi suhu rata-rata di rumah sakit dan aplikasi tunggal mulai mengukir ke dalam aplikasi untuk lebih dengan jenis "Kecelakaan". Aplikasi diajukan kepada administrator senior untuk memverifikasi segmen jaringan.

15:20 Admin menutup crash massal, karena Tidak ada masalah di jaringan, semua permintaan pelanggan dari titik koneksi berbeda tunggal. (Misalnya: switch penuh dengan pelanggan aktif, tetapi tidak berfungsi dengan baik untuk satu). Pada saat ini, seruan jatuh dan semuanya tenang. Seseorang memperhatikan (akhirnya) bahwa semua aplikasi untuk pekerjaan buruk dengan model router yang sama, semua orang bersama-sama berpura-pura semuanya baik-baik saja.

15:30 Sekali lagi masuknya aplikasi dari pelanggan, lagi pendaftaran kecelakaan massal dan transfer ke admin. Pada saat ini, menjadi jelas bahwa ada sesuatu yang benar - benar salah dan sesuatu perlu dilakukan (yang bekerja dengan layanan klien akan memahami betapa sulitnya kadang-kadang dilakukan. Pelanggan selalu berbohong, dan kadang-kadang baris pertama terletak untuk meningkatkan tugas lebih lanjut) .

15:35 Insinyur yang bertugas menerima permintaan untuk masalah dengan layanan pelanggan. Mendapat daftar semua klien, jenis koneksi dan model perangkat mereka. Dan kemudian sihir kecil dimulai.




15:40 Insinyur menjalankan daftar klien melalui semua diagnostik yang ada, setiap router diperiksa sesuai dengan semua metrik standar dan ... tidak ada yang ditemukan. Router seperti router. Ya, CPU telah meningkat, tetapi indikatornya tidak kritis, tetapi menuangkan lalu lintas di suatu tempat, yang artinya berfungsi.

Ya, layanan UPnP berputar di port 52869. Ya, masih ada banyak port terbuka, terbuka berarti mereka diperlukan (logika besi), dan selalu berbalik dan tidak ada masalah (satu lagi argumen logika besi). Ssh langsung ke model router ini tidak mungkin (terus terang itu mungkin, tetapi di dalam busybox yang sangat dilucuti dan kebijakan perusahaan, seperti berjalan di sekitar perangkat klien sangat tidak dianjurkan). Semuanya berdiri lagi.

16:00 Baru sekarang kami mengetahui bahwa ada beberapa masalah. Insinyur yang bertugas melapor kepada atasannya, dan atasan menelepon kami tentang dugaannya tentang pelabuhan 52869 dan meminta bantuan.

16:05 Lalu semuanya terjadi dengan sangat cepat. Model router yang sama disertakan pada dudukan uji, alamat IP diambil dari klien yang bermasalah dan digantung pada yang uji. Wireshark dihidupkan. Ini untuk menangkap permintaan ke perangkat.

Untuk menangkap permintaan dari router (pada saat itu skema umum tentang bagaimana interaksi masih belum diketahui) klien diisolasi di segmen uji dan semua lalu lintasnya dicerminkan ke mesin uji terdekat di mana wireshark lain dinaikkan.

Kami menunggu lebih jauh, kami melihat layar.

Hacks sudah terjebak dengan cara ini - cukup efisien dan karenanya memutuskan untuk tidak mengubah kebiasaan.

16:10 Sementara wireshark berkarat, di Google ada kerentanan CVE-2014-8361 tentang yang dilaporkan ke insinyur. Insinyur, tanpa mendengarkan, membuat keputusan (dan, pada prinsipnya, logis) - filter pelabuhan ini di perbatasan. Tidak lebih cepat dikatakan daripada dilakukan.


16:25 Kita diberitahu bahwa semua remake omong kosong Misha tidak berhasil. Dan kami sudah tahu itu tidak akan berhasil. Pada saat itu, mereka telah mengetuk router uji, mengangkat kebalikannya pergi ke port lain dan mulai menggunakannya untuk DDOS-a hingga 1900 (!) Port menggunakan kerentanan lain. Tuhan, sungguh sampah yang bocor


Hal yang paling menarik adalah bahwa aturan firewall pada perangkat telah diubah dan nmap sekarang tidak menampilkan port terbuka dari luar. Hanya di tempat pembuangan lalu lintas yang memungkinkan untuk mendeteksi permintaan pada port-port ini. Yaitu seorang penyerang setelah peretasan memblokir akses ke yang lain. Bukan pendekatan hi-tech, tapi tetap saja bravo.

16:30 Sebuah konferensi berkumpul dengan pertanyaan "siapa yang harus disalahkan dan apa yang harus dilakukan." Port 1900 dan 52869 diblokir, sedang dilakukan upaya untuk memperbaiki sesuatu pada perangkat yang diretas. Reboot - tidak membantu, gagasan reflashing segera ditolak. Ya, ada fungsi seperti itu, memungkinkan untuk mengatur ulang perangkat lunak dari jarak jauh melalui TR069 dengan satu tombol di semua perangkat. Tapi sejak itu perangkat itu bukan kesegaran pertama, tetapi jumlah pelanggan besar - persentase tertentu dari perangkat bata akan menimbulkan masalah.

16:40 Untuk meringkas: perangkat diretas, berpartisipasi dalam minimum dalam ddos ​​dan mengirimkan sesuatu di suatu tempat di saluran terenkripsi. (Semua pada port yang berbeda ). Masuk tidak mungkin, vendor menolak akses penuh melalui ssh ke perangkat dan melihat apa yang tidak mungkin untuk sampai ke sana. Konsol dilindungi kata sandi.

Di suatu tempat lebih dekat ke 17:00, diputuskan untuk menjahit perangkat sebagai cara tercepat. Setelah flashing dan reboot, semuanya kembali normal.

Alih-alih total

Sayangnya, kami tidak dapat menyelesaikan masalah ini sepenuhnya.

Dengan "memutuskan" yang saya maksudkan adalah mendapatkan informasi peretasan yang lengkap dan memperbarui kebijakan kami untuk menghadapi ini di masa depan. Ya, tidak semua tugas diselesaikan dengan sukses dan seperti yang kita inginkan. Ini normal. Meskipun menghina.

Jika baik untuk mencari di shodan,
Anda dapat menemukan sendiri sesuatu
untuk eksperimen:
satu atau lain cara
tapi aku tidak memberitahumu itu.