Artikel ini dibagi menjadi tiga bagian. Yang pertama berisi informasi umum tentang pembajakan BGP dan versi tradisionalnya. Bagi mereka yang akrab dengan fenomena ini, disarankan untuk langsung menuju ke bagian kedua. Bagian kedua akan menjelaskan metode mengumumkan awalan asing dengan menambahkan AS asing ke AS-SET Anda. Pada bagian ketiga, penilaian akan dibuat dari kompleksitas menggunakan metode yang dijelaskan di bagian kedua untuk menangkap alamat IP dari sumber daya torproject.org dan mengeluarkan sertifikat untuk itu. Diasumsikan bahwa pembaca akrab dengan prinsip-prinsip BGPv4.
Pembajakan BGP sederhana
Singkatnya, pembajakan BGP adalah menangkap alamat IP orang lain (acak atau disengaja).
Biasanya, pembajakan BGP terlihat seperti ini: AS yang tidak memiliki awalan mulai mengumumkannya (awalan orang lain), uplink / rekan menerimanya, dan mulai menyebar melalui Internet. Mereka menerimanya dengan alasan tidak ada penyaringan awalan di persimpangan (baik ini adalah kesalahan konfigurasi, atau lebih dikandung (karena sangat sulit untuk membangun filter awalan di persimpangan dengan operator yang sangat besar karena berbagai alasan, ini tidak penting untuk artikel ini) ) Salah satu contoh paling terkenal saat ini ketika Rostelecom (
AS12389 )
mulai mengumumkan prefiks Mastercard (
AS26380 ), Visa dan beberapa organisasi keuangan lainnya (sesuai dengan
versi resmi , sebagai akibat dari kegagalan perangkat lunak). Anda dapat melihat bagaimana pengumuman ini terlihat dalam sejarah bgplay (
melihat melalui web ,
json (
arsip )), berikut adalah salah satunya di salah satu kolektor RIPE (awalan 216.119.216.0/24 milik Mastercard (AS26380)):
"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24
Dan inilah tampilan pengumuman sebenarnya:
"source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24
Yaitu dalam hal ini, Rostelecom mengumumkan awalan langsung dari AS-nya (AS terakhir di AS-PATH adalah 12389). Masalah dapat dihindari jika uplink dan hari raya Rostelecom memfilter awalan dari Rostelecom dengan membuat
daftar awalan sesuai dengan AS-SET dan / atau
memvalidasi awalan menurut ROA RPKI . Pembangunan daftar awalan antara operator besar sering tidak dilakukan, dan tidak semua telah menerapkan RPKI (tetapi ada
kemajuan ). Pembajakan semacam itu, secara teoritis, dapat dilakukan oleh siapa saja, tetapi hanya jika awalan yang diumumkan "bocor" melalui setidaknya satu uplink / pesta. Biasanya, operator besar Rusia mengkonfigurasi filter awalan ke arah pelanggan mereka dan oleh karena itu, AS kecil (operator kecil / menengah, beberapa hosting dan beberapa perusahaan), hampir selalu, tidak dapat melakukan serangan seperti itu (tapi sekali lagi, semuanya tergantung pada wilayah / negara / operator tertentu).
Namun, penyerang masih menemukan tempat (uplink) di mana penyaringan tidak dikonfigurasikan (pada 2017, Brasil adalah
pemimpin dalam pembajakan ) dan melakukan serangan dengan mengambil alamat IP (sering, peristiwa seperti itu masuk ke feed berita), untuk serangan yang lebih efektif, umumkan awalan yang lebih spesifik (dengan topeng yang lebih panjang) daripada pencetus yang sebenarnya. Sekarang mari kita beralih ke versi serangan, di mana tidak ada validasi ROA RPKI atau daftar awalan AS-SET.
BGP membajak dengan penambahan korban AS di AS-SET-nya
Pertimbangkan skenario berikut:
- Seorang penyerang mendapatkan alamat AS dan IP (pada kenyataannya, secara teknis, dia tidak membutuhkan alamat IP, mereka lebih cenderung tidak menimbulkan pertanyaan).
- Penyerang terhubung ke berbagai operator besar dan IX (setidaknya satu operator atau IX), menentukan tidak hanya AS-nya, tetapi AS-SET-nya sebagai sumber data tentang awalan yang diumumkan (ini adalah praktik normal untuk interaksi antar-operator (termasuk termasuk ketika dalam hubungan client-uplink) atau untuk dimasukkan pada IX-ah)). Dalam kasus normal, AS-SET ditentukan, dan bukan hanya AS, ketika diasumsikan bahwa klien bukanlah jalan buntu, tetapi ia sendiri memiliki (atau akan memiliki) klien dengan bgp dan jaringan mereka sendiri.
- Setelah beberapa waktu, penyerang menambahkan AS korban ke AS-SET-nya dan mulai mengumumkan awalannya melalui dirinya sendiri, mis. AS-PATH yang diumumkan terlihat seperti ini: "AS_ penyerang AS_ korban". Dari sudut pandang daftar awalan yang dibuat secara otomatis dan dari sudut pandang RPKI, ini adalah pengumuman yang sepenuhnya valid, sehingga kedua mekanisme perlindungan tidak akan berfungsi di sini.
- Awalan yang diumumkan mulai bersaing dengan pengumuman yang sebenarnya (pengumuman korban), di suatu tempat ia menang dan masuk ke tabel rute, di suatu tempat ia kalah dan tidak akan (pengumuman korban akan tetap ada di sana). Itu tergantung pada berapa banyak uplink dan berapa banyak IXs yang digunakan penyerang. Ketika seorang penyerang terhubung ke beberapa AS sebagai klien, maka di dalamnya (paling sering) ia akan memenangkan korban karena lebih besar dari local-pref (jika korban bukan klien dari uplink yang sama, maka korban akan menang oleh AS-PATH jika ia tidak prepend), mis. seorang penyerang perlu terhubung ke uplink sebanyak mungkin dengan AS-SET-nya untuk memaksimalkan efektivitas serangannya.
Juga, penyerang harus terhubung ke jumlah IXs maksimum, sebagai biasanya, AS deadlock menetapkan local-pref tertinggi ke IXs dan jika awalan korban tidak terlibat dalam IX, maka itu akan kehilangan pengumuman penyerang di tabel routing ASs kebuntuan.
Secara teori, ini adalah serangan yang cukup kuat, tetapi untungnya, dalam praktiknya, batasan berikut akan muncul:
- Anda perlu membuat badan hukum, setidaknya satu, tetapi pada kenyataannya, kemungkinan besar akan diperlukan di berbagai negara.
- Penting untuk menyimpulkan perjanjian dengan operator, IX, hampir selalu membuat biaya koneksi, dengan LIR / RIR.
- Beberapa operator masih tidak membuat daftar awalan AS-SET secara otomatis, mereka perlu menulis surat untuk ini. Administrator yang berpengalaman akan mencurigai sesuatu jika AS-ka perusahaan terkenal tiba-tiba muncul di AS-SET perusahaan yang tidak dikenal.
- Setelah serangan itu, peralatan yang digunakan (jika terletak di semacam pusat data) kemungkinan besar akan disita jika kasus kriminal dibuka.
- Daftar awalan untuk berbagai operator / IX diperbarui pada waktu yang berbeda, sehingga Anda perlu menganalisis siapa yang memperbarui saat ini juga bukan pekerjaan termudah.
Kemungkinan langkah perlindungan:
- Secara teoritis, untuk bertahan melawan serangan seperti itu, Anda harus memiliki sebanyak mungkin antarmuka dengan operator (lebih baik, yang dari klien, karena mereka memiliki lebih tinggi lokal-lebih tinggi) dan IXs. Yaitu lakukan hal yang sama dengan yang dilakukan penyerang. Tentu saja, dalam praktiknya ini sangat sulit untuk diterapkan dan akan membutuhkan sumber daya yang signifikan. Metode ini hanya relevan untuk layanan yang menyediakan layanan keamanan informasi secara profesional.
- Jika Anda memiliki situs web, gunakan catatan CAA dengan tugas akun (jika penyedia sertifikat SSL Anda mendukungnya. Letsencrypt mendukung) (lihat RFC6844 ). Dalam hal ini, penyerang tidak akan dapat mengeluarkan sertifikat (kecuali jika ia dapat mengubah catatan CAA)
- Secara teoritis, implementasi BGPsec yang meluas harus menghilangkan serangan seperti itu, tetapi nasibnya belum jelas (dalam praktiknya belum diterapkan atau sangat jarang).
- Implementasi verifikasi alternatif AS_PATH (tanpa BGPsec) (sejauh ini ini adalah konsep yang memecahkan masalah yang dijelaskan dalam kasus implementasi yang meluas).
- Larangan penambahan AS asing yang tidak terkendali ke AS-SET Anda (tanpa izin dari pemilik AS) dapat mengurangi kemungkinan melakukan serangan seperti itu di wilayah tempat AS-SET digunakan untuk memfilter di persimpangan. Sekarang tidak ada larangan seperti itu.
Bahkan, bagi sebagian besar pembaca, satu-satunya saran yang berlaku bagi mereka adalah No. 2 (mengenai penggunaan akun dalam catatan CAA) dan sebagian No. 1 dalam konteks memilih host dengan konektivitas yang baik. Pada saat yang sama, Anda perlu mengingat kemungkinan serangan pada layanan DNS tempat Anda menyimpan catatan Anda (tetapi ini adalah masalah yang terpisah dan ada banyak materi di dalamnya)
Apakah sulit untuk menangkap torproject.org
Seorang penyerang perlu menyelesaikan dua masalah:
- Alihkan lalu lintas ke audiens target (audiens target - yang akan menerima situs palsu)
- Buat sertifikat
Pendahuluan:
$ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197
Seperti yang Anda lihat, ada catatan CAA, Anda bisa mendapatkan sertifikat dari letsencrypt, tidak ada ikatan ke akun dalam catatan CAA, yang berarti masalah secara teoritis diselesaikan oleh penyerang. Alamat IP torproject.org dimiliki oleh hosting Hezner yang terkenal.
Misalkan target audiens penyerang adalah klien dari beberapa operator Rusia. Hezner bukan klien dari operator Rusia (tetapi telah mengintip dengan yang besar - langsung atau melalui IX-s). Cara termudah bagi penyerang untuk mengarahkan kembali lalu lintas CA ke dirinya sendiri adalah menjadi klien operator ini dan hanya menang dengan mengorbankan preferensi lokal yang lebih tinggi. Semuanya di sini relatif sederhana dan jelas.
Untuk mendapatkan sertifikat di letsencrypt, Anda memerlukan penyedia yang memungkinkan hostencrypt mengarahkan lalu lintas ke penyerang, dan bukan ke Hezner (AS24940). letsencrypt memutuskan ke alamat yang berbeda untuk IP Amerika dan Eropa, tetapi mari kita lihat betapa sulitnya untuk memengaruhi lalu lintas dari acme-v02.api.letsencrypt.org/2.19.125.202 ke host penyerang. Di sini kita dihadapkan dengan fakta bahwa letsencrypt di-host di Akamai CDN, yang memiliki konektivitas yang sangat baik di seluruh dunia (hadir di sebagian besar IXs utama, memiliki sambungan langsung dengan sejumlah besar pemain besar). Akamai tidak memiliki LG publik, pada prinsipnya, ada
API untuk klien yang dapat Anda lakukan traceroute / ping, tetapi bahkan tanpa LG publik, Anda dapat melihat
peering db untuk menilai skala keberadaan mereka. Demikian pula, Anda dapat melihat
hezner . Sangat mudah untuk melihat bahwa kedua AS memiliki kehadiran pada IXs yang sama, maka kita dapat menyimpulkan bahwa dengan probabilitas mendekati kesatuan, awalan AS Hezner (AS24940) dalam tabel Akamai (AS20940) terlihat dengan AS_PATH 24940. Ini berarti bahwa jika seorang penyerang Jika mencoba mengumumkan awalan Hezner melalui beberapa IX, maka mereka akan kehilangan menurut AS_PATH pengumuman sebenarnya dari Hezner (karena AS_PATH akan berisi penyerang AS). Sebuah solusi yang mungkin adalah dengan mengatur "langsung" mengintip antara penyerang dan Akamai (jika Akamai setuju dengan ini dan jika itu akan menjadi lokal-lebih tinggi daripada di persimpangan dengan IXs).
Untuk meringkas, dengan menambahkan AS orang lain ke AS-SET Anda, Anda dapat menyebabkan degradasi signifikan situs web torproject.org (untuk sejumlah besar klien, tetapi tidak untuk semua orang dalam kasus umum), tetapi dapatkan sertifikat SSL torproject.org di letsencrypt, kemungkinan besar itu tidak akan berhasil karena konektivitas yang baik antara pencetus nyata (Hezner) dan CDN yang digunakan oleh letsencrypt (Akamai). Namun, dalam kasus lain, ketika ada AS transit antara hosting situs korban dan otoritas sertifikasi dan mereka ada di AS_PATH, risiko mendapatkan sertifikat dengan metode yang dijelaskan meningkat secara signifikan.