Serangan IP spoofing yang membuat seluruh dunia mengirim laporan penyalahgunaan ke teman

 (delroth.net)
1 poin oleh GN⁺ 2024-10-30 | 1 komentar | Bagikan ke WhatsApp
  • Hetzner meneruskan laporan penyalahgunaan bahwa terjadi pemindaian port SSH dari 195.201.9.37, tetapi di dalam server tidak ditemukan bukti proses berbahaya, perubahan file, atau lalu lintas aneh
  • Alur sebenarnya yang terlihat lewat tcpdump bukan server yang terhubung ke 22/tcp eksternal, melainkan lebih mirip backscatter, yaitu beberapa host internet mengirim balik TCP RST ke server
  • Penyebab utamanya adalah bahwa paket dengan IP sumber sembarang dapat dikirim melalui jaringan yang tidak melakukan pemfilteran BCP38; pada TCP, QUIC, dan TLS yang membutuhkan respons dua arah, penyerang tidak dapat melihat responsnya secara langsung
  • Pola yang sama juga muncul pada 2 Tor relay lain milik penulis, dan fenomena serupa sudah dilaporkan sejak beberapa hari sebelumnya di milis tor-relays serta isu Tor Project, dengan beberapa node sempat turun sementara
  • Penyerang dapat memalsukan IP korban sebagai sumber, mengirim percobaan koneksi ke berbagai target SSH, lalu memicu laporan penyalahgunaan otomatis, daftar blokir, dan tindakan dari penyedia hosting

Laporan penyalahgunaan Hetzner dan pemeriksaan server

  • Hetzner mengirim email AbuseInfo untuk IP 195.201.9.37
    • Pelapornya adalah abuse@watchdogcyberdefense.com
    • Log berisi beberapa entri DENIED yang mengarah ke 22/tcp milik target 202.91.16x.x
  • Sekilas terlihat seolah server mulai mengirim koneksi SSH ke internet, situasi yang biasanya membuat orang mencurigai infeksi malware
  • Setelah pemeriksaan 1–2 jam, kondisi server terlihat nyaris normal
    • Tidak ada proses aneh
    • Tidak ada perubahan filesystem
    • Tidak ada lalu lintas jaringan aneh dari sudut pandang hypervisor
  • Di server tersebut berjalan beberapa layanan terdistribusi dan federatif
    • Syncthing relay
    • Mastodon instance
    • Tor relay
    • Matrix homeserver
  • Tor relay memang terhubung ke beberapa relay 22/tcp, tetapi tidak cocok dengan jaringan pelapor, dan di log Matrix maupun Mastodon serta antrean Mastodon Sidekiq tidak terlihat jejak permintaan ke IP atau port sembarang

Alur paket sebenarnya yang ditunjukkan tcpdump

  • Awalnya, penulis mencoba memeriksa lalu lintas keluar dari server ke 22/tcp eksternal dengan filter dst port 22
  • Setelah filter diubah menjadi not src host 195.201.9.37, terlihat paket TCP RST yang masuk dari 22/tcp beberapa IP eksternal ke port sementara server penulis
  • Jadi yang sebenarnya terjadi bukan server mengirim koneksi ke 22/tcp host sembarang, melainkan host internet sembarang mengirim paket reset ke server
  • Pola ini cocok dengan backscatter, yaitu paket respons kembali ke IP yang dipalsukan akibat pemalsuan IP sumber

Pemalsuan IP sumber dan celah BCP38

  • Di internet, IP tujuan harus benar, tetapi mengirim paket ke banyak tujuan dengan IP sumber palsu masih memungkinkan
  • BCP38 adalah praktik terbaik saat ini yang menyarankan agar jaringan peer hanya diizinkan memakai alamat IP sumber yang memang diharapkan
  • Pemfilteran ini harus diterapkan di awal jalur paket agar efektif
    • Pada tingkat transit provider besar, pemfilteran yang bermakna sulit dilakukan karena peer mengharapkan provider tersebut meneruskan lalu lintas ke seluruh internet
  • Jika menemukan satu saja transit provider tanpa penerapan BCP38, pengiriman paket dengan IP sumber sembarang menjadi mungkin
  • APNIC pada 2023 menerbitkan tulisan tentang mengapa validasi alamat sumber masih menjadi masalah
  • Keluarga TCP, QUIC, dan TLS membutuhkan komunikasi dua arah, sehingga jika IP sumber dipalsukan, penyerang tidak dapat melihat responsnya
    • Tidak cocok untuk memeriksa hasil pemindaian port biasa
    • Namun ada bentuk penyalahgunaan yang sudah dikenal, seperti reflected DDoS

Mengapa spoofing seperti ini menimbulkan kerugian

  • Alur yang paling masuk akal adalah seseorang menggunakan IP penulis sebagai sumber untuk mengirim percobaan koneksi ke 22/tcp berbagai host internet
  • Jika tujuannya eksplorasi port terbuka biasa, hal itu tidak logis karena pemalsu tidak dapat melihat respons
  • Dulu ada teknik bernama Idle Scanning, tetapi teknik itu bergantung pada server yang tidak sibuk dan counter network stack yang dapat diprediksi, dan sudah tidak praktis sejak puluhan tahun lalu
  • Skala lalu lintasnya terlalu kecil dan durasinya terlalu panjang, sehingga skenario salah memasukkan IP sumber dalam konfigurasi scanner juga tampak kurang meyakinkan
  • Kerugian nyata muncul dari otomatisasi laporan penyalahgunaan
    • Percobaan koneksi yang dipalsukan mencapai jaringan yang memiliki honeypot atau sistem deteksi intrusi
    • Sebagian sistem otomatis mengirim laporan penyalahgunaan
    • Penyedia hosting dapat salah mengira server korban telah disusupi atau bersifat berbahaya

Pola berulang pada Tor relay lain

  • Penulis kembali memastikan bahwa servernya beroperasi sebagai Tor relay
  • Tor relay adalah node internal jaringan Tor, dan jika bukan exit node, ia tidak berkomunikasi langsung dengan internet publik
    • Relay meneruskan lalu lintas anonim terenkripsi di antara node peserta jaringan Tor
    • Sebagian relay dapat bertindak sebagai Guard Node dan menjadi titik masuk ke jaringan Tor
  • Penulis menjalankan tcpdump pada 2 relay tambahan di negara dan ISP berbeda
    • Relay pada koneksi rumah
    • Relay pada VPS Linode di Jepang
  • Pada kedua relay tersebut juga muncul pola respons TCP hasil spoofing yang sama, dari 22/tcp eksternal menuju IP relay
  • Penulis mengirim email ke milis tor-relays, dan sudah ada isu Tor Project yang mendiagnosis fenomena sama sejak beberapa hari sebelumnya
  • Serangan spoofing ini bermula pada jenis node lain sebelum relay, dan ada kasus beberapa node sempat turun sementara karena koneksi palsu berskala lebih besar

Alur serangan yang bisa menargetkan siapa saja

  • Alur serangan yang mungkin adalah sebagai berikut
    • Penyerang mendapat akses ke jaringan tanpa pemfilteran BCP38
    • Mengirim permintaan koneksi TCP ke 22/tcp berbagai host internet sembarang
    • IP sumber dipalsukan menjadi IP korban
    • Host target atau sistem keamanan melihatnya sebagai percobaan koneksi dari korban dan mengirim laporan penyalahgunaan
    • Jika skalanya cukup besar, IP korban masuk ke berbagai daftar blokir, dan penyedia hosting dapat menghentikan server
  • Tidak ada unsur yang khusus untuk Tor dalam serangan ini
  • Cara ini tampaknya tidak terlalu sulit dijalankan oleh satu penyerang yang termotivasi
  • Korban bukan pelaku sebenarnya, melainkan pemilik IP sumber yang dipalsukan, tetapi mereka dapat mengalami gangguan operasional akibat laporan penyalahgunaan otomatis dan respons penyedia hosting

Masalah operasional internet yang masih ada pada 2024

  • Situasi bahwa IP sumber palsu masih menjadi masalah pada 2024 nyaris merupakan kegagalan operasional internet
  • Selain BCP38, RPKI juga mengalami masalah serupa dalam hal penyebaran, dan baru mulai meluas setelah perusahaan internet besar mulai memaksakan persyaratan langsung kepada peer mereka
  • Langkah berikutnya terhadap serangan ini belum jelas
    • Serangan ini sudah benar-benar terjadi
    • Penulis tidak tahu apakah ini serangan yang sudah terdokumentasi sebelumnya
    • Penulis tidak tahu cara melacak sumber sebenarnya dari paket IP palsu secara retrospektif
  • Operator yang menerima laporan penyalahgunaan serupa perlu memastikan bahwa servernya mungkin bukan pelaku, melainkan korban, dan mengumpulkan dasar untuk menjelaskannya kepada penyedia hosting

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-30
Komentar Hacker News

  • Masalah jenis ini benar-benar menyebalkan untuk ditangani. Karena jawaban yang sah atas laporan penyalahgunaan, yaitu “seseorang memalsukan IP saya, itu bukan saya, dan perangkat saya juga tidak diretas,” persis sama dengan alasan yang akan diberikan pelaku jahat
    Pada akhirnya, seperti dalam tulisan itu, kita harus membuktikan ketiadaan kepada pihak yang sebenarnya tidak terlalu peduli, dan itu pada praktiknya hampir mustahil

    • Hetzner mengatakan dalam email bahwa balasan tidak diperlukan
      Laporan penyalahgunaan otomatis untuk sesuatu yang mudah dipalsukan memang tidak membenarkan laporan itu sendiri, tetapi bisa menjadi alasan untuk segera memastikan server saya berjalan normal dan tidak diambil alih
    • Jika itu jawaban yang sah, seharusnya ada bukti nyata dalam bentuk penjaminan oleh pihak ketiga tepercaya di dunia nyata
      Setidaknya diperlukan dasar mengenai identitas dan yurisdiksi, mungkin juga panggilan video. Sekadar mengklaim secara anonim di internet “saya orang baik” dan meminta dipercaya saja tidak cukup

  • Hal yang sama berlaku untuk alamat MAC yang dipalsukan, alamat email, pesan ARP, Neighbor Discovery, dan sertifikat TLS man-in-the-middle
    Tetap saja, luar biasa bahwa masih ada sesuatu yang berfungsi

    • Internet bukan rusak, melainkan memiliki kegunaan dan keandalan yang luar biasa
      Jika dibuat agar dirancang dan dioperasikan dengan sempurna, kemungkinan justru akan cukup sering rusak besar-besaran. Sifatnya yang menoleransi sedikit ketidaksempurnaan sangat berkontribusi pada ketangguhan dan kegunaan internet
      Bukan berarti kita tidak perlu memperbaikinya; ini lebih sebagai peringatan bahwa mengejar perfeksionisme mudah membuat kita melakukan kesalahan besar yang merusak semuanya
    • Alamat MAC yang bisa dipalsukan cukup penting untuk privasi Wi-Fi
    • Di jaringan seluler, SS7 juga punya masalah serupa: https://youtu.be/wVyu7NB7W6Y
    • Saya mulai merasa usulan China untuk mereformasi protokol internet mungkin ada benarnya
    • Saya sering mendengar keluhan tentang DNS, tetapi penasaran sebenarnya seberapa aman DNS dan mengapa upaya untuk memperbaikinya begitu sedikit

  • Dulu kami memindai server refleksi DrDoS dengan cara serupa. Karena tidak ada penyedia hosting yang ingin menerima laporan pemindaian port, jika alamat sumber pemindaian dibuat sebagai IP penyedia cloud bereputasi baik yang tidak bersalah, server refleksi akan dengan senang hati mengirim respons UDP ke sana
    Penyedia cloud tentu menerima banyak sekali laporan, tetapi ketika saya mengatakan bahwa pemindaian tidak dilakukan dari server saya, mereka memeriksanya dan tidak mematikan layanan. Karena server yang mengirim paket pemindaian palsu tidak terdeteksi, seluruh internet bisa dipindai berulang kali tanpa masalah laporan penyalahgunaan biasa
    Saya tidak tahu seberapa sering hal ini benar-benar terjadi, tetapi dengan bekerja sama dengan operator transit dan menelusuri hop ke belakang, asal paket palsu bisa dilacak. Pernah suatu kali JPMorgan bekerja sama dengan Cogent dan memberi tahu kami agar tidak mengirim paket ke alamat IP mereka. Sebagai catatan, Cogent termasuk operator tier-1 internet yang cukup toleran terhadap spoofing
    Ini pertama kalinya saya mendengar metode ini dipakai secara khusus untuk Tor, dan itu agak berlawanan dengan intuisi. Karena jika seseorang mengirim paket palsu, saya membayangkan mereka pendukung Tor. Kemungkinan besar ini cuma troll, dan untungnya penyedia yang meng-host Tor tampaknya tidak akan terlalu mempermasalahkan hal seperti ini

    • Cogent secara umum juga tampaknya kurang bagus
      Bisa saja ini hanya troll, tetapi bisa juga pihak yang ingin membuat Tor diperlakukan seperti limbah radioaktif karena Tor mengganggu operasi pengawasan

  • Ini bukan hal baru. Beberapa tahun lalu saya membuat aturan firewall yang sangat dasar: untuk paket TCP masuk ke port tujuan 22, jika SYN=1 dan ACK=0, maka IP sumber diblokir selama sehari
    Lalu muncul keluhan bahwa situs dan layanan tertentu tidak bisa diakses, dan ternyata setiap beberapa hari ada paket seperti itu dari IP server populer seperti 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram, dan berbagai layanan chat. Tentu saja semuanya adalah paket palsu, dan akhirnya saya menambahkan sedikit verifikasi lagi ke aturan firewall
    Jadi saya yakin ini cukup umum. Secara pribadi, saya tahu kasus saya agak tidak biasa karena mengoperasikan beberapa alamat IP, tetapi saya membutuhkan fleksibilitas untuk bisa mengirim paket ke ISP mana pun dengan memakai salah satu alamat sumber saya. Itu penting bagi saya, dan jika ISP memfilter berdasarkan sumber, itu alasan untuk memutus kerja sama, jadi saya akan pindah ke ISP lain

    • Jika Anda benar-benar memiliki alamat IP sendiri, itu perilaku yang normal dan diharapkan. Namun jika alamat IP milik ISP A bisa digunakan melalui ISP B, atau sebaliknya, itu selalu merupakan bug dan tidak seharusnya digunakan begitu
      Jika kasusnya yang terakhir, itu lebih mirip kategori “menyalakan kembali pemanas spacebar”, dan saya berharap ISP memperbaiki jaringan mereka yang rusak
    • Saya akan memberi contoh nyata yang spesifik
      Di sebuah perusahaan, sebagian aset web di-host di on-premise kantor cabang, yang memiliki koneksi 1Gbps. Karena kantor pusat punya beberapa koneksi 10G dan datacenter yang cukup bagus, VM web dipindahkan ke kantor pusat sambil mempertahankan alamat IP yang dialokasikan, yaitu IP publik statis dari ISP-A. Lalu dirutekan ke kantor pusat lewat VPN, dan server memakai gateway default untuk mengirim respons dengan IP sumber ISP-A melalui koneksi 10G milik ISP-B
      Dengan begitu, meski penerimaan dibatasi 1G, pengiriman bisa memanfaatkan 10G. Lagi pula isinya hanya permintaan GET. Ini bukan konfigurasi optimal dan akhirnya IP diganti, tetapi menurut saya ini use case yang valid
      Kedua, ada dua koneksi ISP berbeda, ASN sendiri, dan alamat /23 sendiri. Untuk load balancing sebagian trafik, separuh IP dikirim lewat ISP-A dan separuh lainnya lewat ISP-B. Itu berjalan baik, tetapi ketika mencoba sedikit mencampur keseimbangannya, muncul masalah menarik. /24 pertama diumumkan ke ISP-A, /24 kedua ke ISP-B, tetapi ISP-A memiliki RP filtering. Jadi semua IP harus diumumkan juga ke pihak mereka
      Karena cara kerja RP filter, kita tidak bisa melakukan hal seperti prepend, dan semua trafik harus masuk melalui mereka. Jika terlihat rute yang lebih baik untuk prefix tersebut, mereka memfilternya. Selama berbulan-bulan mereka menolak memperbaikinya dengan alasan keamanan. Karena alasannya disebut praktik terbaik keamanan, saya rasa boleh menyebut nama ISP-nya: Virgin Media
      Sebagai catatan, koneksi internet yang memiliki rp_filter ini bukan seharga 20 dolar per bulan, melainkan lebih dari 5.000 dolar per bulan. Di wilayah itu tidak ada alternatif sehingga tidak bisa pindah, tetapi jika ada alternatif, sudah jelas siapa yang akan kehilangan kontrak
    • Karena saya biasanya mengaktifkan rp_filter di mana-mana, saya benar-benar penasaran mengapa fleksibilitas seperti itu diperlukan
    • Secara teknis, ISP seperti itu juga mungkin berada dalam kondisi melanggar. Anda perlu ASN sendiri

  • Hipotesis bahwa “ada seseorang yang membenci relay Tor” tampaknya kurang meyakinkan dibandingkan dengan upaya yang dikeluarkan
    Bisa jadi pihak yang menjalankan relay jahat ingin menurunkan relay yang sah secara tidak etis, agar meningkatkan proporsi jaringan yang mereka kendalikan

    • Hampir pasti rasanya ke arah itu. Di sini cukup banyak penghindaran realitas soal betapa mudahnya penyerang yang bisa mengakses log dari sebagian node yang bahkan tidak terlalu besar untuk melihat pola akses layanan milik individu
    • Jika membenci jaringan Tor, cara yang lebih mudah adalah membanjirinya dengan trafik hingga layanannya menurun
      Menjalankan beberapa unduhan BitTorrent saja mungkin sudah cukup

  • Apa yang dibutuhkan agar cukup banyak operator jaringan menolak trafik dari semua AS yang tidak menerapkan BCP38, sehingga spoofing tidak lagi memungkinkan?

    • Cloudflare saja mungkin sudah cukup
      Karena mereka sudah menguasai trafik inbound yang cukup besar, “memeriksa keamanan koneksi” bisa benar-benar punya arti
    • Harus menemukan cara agar operator jaringan peduli. Terutama operator transit Tier 1 atau jaringan yang ukurannya tidak wajar besarnya
      Namun mengurangi faktor amplifikasi refleksi jauh lebih mudah. Sebab pada IPv4, vektor refleksi bisa dipindai, lalu kita bisa mengajukan komplain kepada pihak yang merespons dengan 10 kali lipat byte input

  • Ini masalah yang mirip dengan swatting. Ia bergantung pada pihak berwenang yang mengambil tindakan keras berdasarkan laporan masalah yang belum diverifikasi
    Bedanya mungkin, alih-alih menghubungi pihak berwenang secara langsung, pelaku memanfaatkan pihak ketiga yang tidak terkait untuk mengirim laporan

  • Untuk permintaan yang hanya berupa satu paket dan tidak memiliki round trip, sistem sepertinya tidak boleh otomatis mengirim laporan penyalahgunaan kecuali trafiknya sudah setingkat denial-of-service
    Khususnya untuk SSH, sebelum terjadi handshake jenis apa pun, tidak ada cara untuk menganggapnya sebagai upaya koneksi yang valid

    • Jika siapa pun bisa mengajukan laporan penyalahgunaan, penyedia server harus benar-benar memeriksa laporan sebelum memberlakukan tindakan berdasarkan ketentuan layanan seperti “server akan dihentikan jika tidak dijawab dalam 2 hari”
      Server utama saya juga pernah diturunkan karena laporan penyalahgunaan palsu. Mereka mengklaim menerima serangan DoS lebih dari 1Gbps dari IP saya, padahal koneksi server saya dibatasi 400Mbps. Kalau ada manusia yang sekadar membaca laporan itu, mereka akan tahu itu mustahil, dan saya tidak perlu bertengkar dengan dukungan telepon selama dua hari saat sedang liburan
    • Namun ada juga kasus ketika perilaku penyalahgunaan yang tampak nyata, seperti port scanning, memang hanya berupa satu paket seperti itu

  • Ini seperti swatting versi IP, pelecehan paten, menjebak orang tak bersalah, atau permintaan takedown DMCA untuk menyingkirkan pesaing
    Pada dasarnya ini adalah cara mempersenjatai mekanisme anti-penyalahgunaan untuk menyerang target yang tidak disukai. Menarik bahwa pihak berwenang menjadi mata rantai lemah dan bisa dimanfaatkan secara aktif untuk mencapai tujuan aktor yang tidak bermoral, tetapi ini bukan fenomena yang sepenuhnya baru

    • Jika cukup pintar dan juga memiliki relay sendiri, semakin banyak relay lain yang berhasil diturunkan, semakin besar pula probabilitas relay miliknya dipilih
      Melihat grafik jumlah relay dan “advertised bandwidth” di metrics.torproject.org, tampaknya tidak membuat perbedaan besar, tetapi tetap menarik
      Bagian terburuknya adalah pihak-pihak yang meniru pemeras seperti “Watchdog Cyber Defense”, Spamhaus, Shadowserver, atau UCEPROTECT bisa mengirim jutaan laporan otomatis, dan host pada praktiknya harus menuruti laporan itu agar rentang IP mereka tidak masuk daftar blokir

  • Tidak ada solusi in-band untuk masalah ini, tetapi solusi out-of-band mungkin ada
    Misalnya: (1) beri tahu ISP tujuan bahwa kita menerima trafik balik, (2) ISP itu memeriksa dari mana paket berasal dan memberi tahu ISP tersebut, (3) ulangi langkah 2 sampai sumbernya ditemukan, (4) isolasi sebagian jaringan itu sampai berfungsi dengan benar
    Pada akhirnya, internet terdiri dari manusia

    • Kadang ada orang yang terkejut oleh fakta bahwa seluruh internet bisa berjalan karena ada sebagian umat manusia yang benar-benar suka mengelola permainan pipa paling dilebih-lebihkan di dunia
    • Langkah 2 dan 3 mengharuskan banyak orang bekerja tanpa bayaran untuk menyelesaikan masalah orang lain
    • Referensi: https://news.ycombinator.com/item?id=41985920