Indikasi penyadapan lalu lintas terenkripsi Jabber.ru ditemukan di Hetzner dan Linode

 (notes.valdikss.org.ru)
1 poin oleh GN⁺ 2023-10-21 | 1 komentar | Bagikan ke WhatsApp
  • Pada server dedicated Hetzner dan VPS Linode milik layanan XMPP Rusia jabber.ru/xmpp.ru, ditemukan indikasi bahwa koneksi XMPP STARTTLS port 5222 disadap oleh proxy MiTM transparan
  • Penyerang menerbitkan beberapa sertifikat TLS dengan Let’s Encrypt lalu mengakhiri koneksi terenkripsi di tengah; masalah ini terungkap ketika port 5222 jabber.ru di Hetzner mulai menyajikan sertifikat kedaluwarsa
  • Tidak ditemukan jejak kompromi server atau ARP spoofing pada segmen jaringan yang sama, dan instance Linode menunjukkan rute serta MAC gateway yang berbeda dari VM biasa, sehingga besar kemungkinan terjadi rekonfigurasi jaringan hosting
  • MiTM terkonfirmasi setidaknya dari 21 Juli 2023 hingga 19 Oktober 2023, mungkin sudah sejak 18 April 2023; 100% koneksi port 5222 terdampak, sedangkan port 5223 tidak
  • Komunikasi jabber.ru/xmpp.ru selama periode tersebut harus dianggap telah dikompromikan, dan enkripsi ujung ke ujung seperti OMEMO, OTR, dan PGP hanya melindungi jika kedua pihak telah memverifikasi kunci

Penyadapan terungkap lewat sertifikat kedaluwarsa

  • jabber.ru adalah layanan XMPP Rusia yang dimulai pada tahun 2000 dan juga dikenal sebagai xmpp.ru
  • Saat mengakses layanan pada 16 Oktober 2023, muncul pesan “Certificate has expired”, padahal semua sertifikat yang terpasang di server masih mutakhir
  • Keanehan ini hanya muncul pada port 5222 untuk XMPP STARTTLS, dan tidak terlihat pada port lain seperti port 5223 untuk XMPP TLS
  • Server yang terdampak adalah 1 server dedicated Hetzner di Jerman dan 2 server virtual Linode
  • Pada lalu lintas port 5222, terlihat bahwa server menerima ClientHello yang telah diganti, bukan ClientHello asli dari klien

Hasil penyelidikan kompromi di dalam server

  • Fokus penyelidikan adalah kemungkinan peretasan server dan spoofing pada jaringan lokal
  • Di sisi server, poin-poin berikut diperiksa tetapi tidak ditemukan hal mencurigakan
    • keseluruhan log
    • waktu modifikasi file executable dan library
    • proses yang sedang berjalan, memory map, dan dangling file descriptor
    • keberadaan library pembajakan LD_PRELOAD di user space menggunakan busybox yang dikompilasi statis
    • keberadaan modul pembajakan level kernel dengan dump memori kernel memakai LiME dan analisis menggunakan volatility
  • Dalam log kernel server dedicated Hetzner, satu-satunya temuan yang menonjol adalah putusnya link jaringan fisik selama 19 detik pada 18 Juli 2023
  • Server Linode hanya digunakan sebagai tunnel jalur alternatif menuju server Hetzner dan hanya menjalankan layanan dasar seperti SSH dan NTP
  • Di dalam tunnel Hetzner↔Linode, ServerHello normal dari server Hetzner terlihat, tetapi berubah saat dikirim ke klien melalui antarmuka jaringan Linode
    • Ini berarti penyadapan koneksi terenkripsi dengan tipe yang sama terjadi baik di Hetzner maupun Linode

Tanda-tanda aneh pada jaringan Linode

  • Dari sudut pandang jaringan, poin-poin berikut diperiksa tetapi tidak ditemukan jejak pembajakan di sekitar jaringan server
    • apakah ada ARP spoofing pada alamat MAC gateway
    • apakah satu IP menjawab beberapa kali terhadap permintaan ARP di segmen L2
    • aturan routing abnormal yang disuntikkan melalui ICMP redirect dan sejenisnya
    • aturan Netfilter
    • keberadaan tunnel yang sulit dideteksi seperti IPsec
  • Mesin Linode yang terdampak tidak bisa mencari IP tetangga pada segmen jaringan yang sama lewat ARP atau melakukan ping, tetapi dari jaringan luar IP tetangga tersebut berfungsi normal
  • VM Linode pihak ketiga yang tidak terdampak dapat melakukan ping ke host tetangga dan terhubung ke router Cisco Systems
  • Sebaliknya, VPS yang terdampak terhubung ke gateway dengan alamat MAC yang vendornya tidak bisa diidentifikasi
  • Perbedaan ini menunjukkan kemungkinan besar VM Linode yang terdampak berada pada konfigurasi jaringan berbeda dari instance Linode biasa, atau diisolasi dalam VLAN terpisah

Sertifikat palsu dan jejak di Certificate Transparency

  • Di basis data certificate transparency crt.sh ditemukan rogue certificates yang tidak pernah diterbitkan oleh server jabber.ru
  • Layanan XMPP normal menggunakan dua jenis sertifikat
    • xmpp.ru, *.xmpp.ru
    • jabber.ru, *.jabber.ru
  • Sertifikat yang diterbitkan secara jahat memiliki konfigurasi yang sedikit berbeda dari sertifikat normal
    • wildcard Subject Alternative Name tidak ada, atau
    • jabber.ru, xmpp.ru digabungkan ke dalam satu sertifikat
  • Konfigurasi MiTM di sisi Linode yang mengarah ke domain xmpp.ru sebagian salah
    • Server asli diatur untuk menyajikan baik sertifikat jabber.ru maupun xmpp.ru sesuai domain XMPP yang diminta
    • Sisi MiTM hanya menyajikan sertifikat xmpp.ru
  • Waktu penerbitan sertifikat pada 18 Juli 2023 hampir sama dengan waktu link jaringan server Hetzner terputus selama beberapa detik
  • Pemindai jaringan eksternal mengonfirmasi bahwa server Linode setidaknya sejak 21 Juli 2023 menyajikan sertifikat 04:b7:85… pada port 5222
  • Pemindai tersebut tidak memproses rentang Hetzner

Perangkat di depan port 5222 dan perbedaan jalur

  • Pengujian jaringan tambahan dilakukan dari luar terhadap VPS Linode
  • Host tetangga pada segmen Linode yang sama dapat dicapai pada hop 13 dari koneksi internet laptop
  • Port 5222 yang disadap pada server Linode dawn.jabber.ru juga dapat dicapai pada hop 13
  • Namun port yang tidak disadap seperti SSH port 22 pada server yang sama hanya bisa dicapai pada hop 14 setelah melewati hop tambahan nonpublik
  • Hasil ini berarti alamat IP VM Linode ditempatkan di belakang perangkat tambahan, dan perangkat tersebut menangani langsung TCP port 5222 sementara port lain dirutekan ke tujuan sebenarnya
  • Dari dalam VPS, tidak bisa dibuat koneksi baru dengan source port 5222
    • router tidak merespons paket yang keluar dari source port tersebut
    • juga tidak mengirim ICMP error atau Time-to-Live Exceeded untuk outgoing packet dengan TTL=0 atau TTL=1

Cara terminasi STARTTLS dan sidik jari deteksi

  • Hasil pemeriksaan dengan testssl.sh menunjukkan bahwa proxy penyadap mengizinkan anonymous ciphers baik pada Linode xmpp.ru maupun Hetzner jabber.ru
  • Ini adalah salah konfigurasi yang jarang terjadi dan bisa dipakai sebagai sidik jari deteksi MiTM XMPP
  • Library SSL/TLS umum biasanya dikompilasi tanpa dukungan anonymous cipher, dan meskipun diizinkan secara eksplisit dalam file konfigurasi, sering kali sulit membuat layanan benar-benar menggunakannya
  • Server asli tidak mengatur anonymous cipher
  • Perintah testssl.sh yang sama juga digunakan untuk memeriksa sekitar 20 layanan XMPP populer, tetapi tidak ditemukan keanehan seperti dukungan Anonymous NULL Ciphers

Kesimpulan yang terkonfirmasi dan dampaknya bagi pengguna

  • Penyerang menerbitkan beberapa sertifikat SSL/TLS untuk domain jabber.ru dan xmpp.ru melalui Let’s Encrypt sejak 18 April 2023
  • Serangan Man-in-the-Middle untuk mendekripsi lalu lintas XMPP klien jabber.ru/xmpp.ru terkonfirmasi setidaknya dari 21 Juli 2023 hingga 19 Oktober 2023
  • Ada kemungkinan sudah berlangsung sejak 18 April 2023, tetapi belum terkonfirmasi
  • Cakupan dampaknya adalah 100% koneksi XMPP STARTTLS port 5222, sedangkan port 5223 tidak termasuk
  • Penyerang gagal memperbarui sertifikat TLS, dan proxy MiTM mulai menyajikan sertifikat kedaluwarsa pada port 5222 jabber.ru di Hetzner
  • Serangan MiTM berhenti segera setelah penyelidikan dan pengujian jaringan dilakukan pada 18 Oktober 2023 serta tiket dukungan dikirim ke Hetzner dan Linode
  • Namun pada setidaknya satu server Linode, penyadapan pasif dalam bentuk hop routing tambahan masih tetap ada
  • Tidak ada jejak server diretas, dan tampaknya jaringan Hetzner serta Linode direkonfigurasi untuk memungkinkan serangan ini terhadap alamat IP layanan XMPP tersebut
  • Komunikasi jabber.ru/xmpp.ru selama periode itu harus dianggap telah dikompromikan
    • penyerang dapat bertindak seolah dijalankan dari akun yang sudah terautentikasi tanpa mengetahui kata sandi akun
    • mereka dapat mengunduh roster akun, mengakses seluruh riwayat pesan sisi server yang tidak terenkripsi, mengirim pesan baru, dan mengubah pesan secara real time
  • Komunikasi terenkripsi ujung ke ujung seperti OMEMO, OTR, dan PGP hanya terlindungi dari penyadapan jika kedua pihak telah memverifikasi kunci enkripsi
  • Pengguna harus memeriksa apakah ada kunci OMEMO·PGP baru yang tidak sah di penyimpanan PEP dan mengganti kata sandi

Pencegahan dan pemantauan yang dapat dilakukan operator

  • Penerbitan sertifikat baru dicatat di Certificate Transparency, sehingga pemantauan Certificate Transparency dapat diaktifkan
  • Dengan memakai CAA Record Extensions for Account URI and ACME Method Binding dari RFC 8657, metode penerbitan sertifikat dan identitas akun yang boleh menerbitkan dapat dibatasi
  • Perubahan sertifikat SSL/TLS untuk semua layanan dapat dipantau melalui layanan eksternal
  • Perubahan alamat MAC gateway default dapat diawasi
  • channel binding pada XMPP dapat mendeteksi MiTM meskipun pihak penyadap menyajikan sertifikat yang valid
    • baik klien maupun server harus mendukung mekanisme autentikasi SCRAM PLUS
    • saat serangan terjadi, fitur ini tidak diaktifkan di jabber.ru
  • Rekomendasi tambahan dari pengembang ACME Hugo Landau dirangkum di More recommendations from ACME developer Hugo Landau

Tanggapan Hetzner dan Linode

  • Hingga 20 Oktober 2023, belum ada jawaban memadai dari Hetzner dan Linode
  • Dalam pembaruan 3 November 2023 pun, kedua perusahaan masih belum memberikan tanggapan yang layak terkait insiden ini
  • Hetzner menjawab bahwa mereka hanya menyediakan perangkat keras, akses jaringan, dan infrastruktur yang diperlukan untuk server root dedicated serta server Cloud, dan tidak bisa menawarkan solusi tambahan
  • Linode menutup tiket setelah menerima log dan menyatakan tidak mengamati aktivitas ilegal yang memengaruhi layanan
  • Pihak operator lebih condong pada kemungkinan bahwa Hetzner dan Linode dipaksa menerapkan konfigurasi tersebut untuk penyadapan yang sah berdasarkan permintaan kepolisian Jerman
  • Kemungkinan lain adalah adanya intrusi ke jaringan internal Hetzner dan Linode yang secara spesifik menargetkan jabber.ru, tetapi skenario ini jauh lebih sulit dipercaya meski belum sepenuhnya mustahil

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-21
Opini Hacker News

  • Kemungkinan besar ini terkait dengan penyelidikan kejahatan siber Rusia. Kalau pernah membaca Krebs atau forum Rusia yang lebih bawah tanah, xmpp.ru mungkin terasa familiar, dan memang ada konteks semacam itu
    Bukan bermaksud menuduhkan sesuatu kepada operatornya; maksudnya, kalau menjalankan layanan anonim, layanan itu memang cenderung menjadi seperti ini
    https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
    https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
    https://blog.talosintelligence.com/picking-apart-remcos/
    https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
    Artikelnya sendiri sangat menarik, dan tampak seperti contoh praktis mengapa semua orang sebaiknya memakai layanan pemantauan transparansi sertifikat

    • Kelompok narkoba banyak memakai XMPP bersama Tor sebagai kanal komunikasi yang aman. Pasar darknet Hydra sempat mencoba memperluas “layanannya” ke UE lalu ditutup polisi Jerman pada 2022; hal serupa mungkin saja terjadi di sini, mungkin juga tidak
    • Saya juga kurang lebih melihatnya begitu. Sepertinya mungkin terkait dengan penutupan Genesis Market atau Qakbot

  • Saya setuju dengan sebagian besar usulan mitigasinya. Kalau Anda target berisiko tinggi, layak juga mempertimbangkan menumpuk lapisan autentikasi tambahan yang tidak bergantung pada otoritas sertifikat tepercaya: misalnya Tor onion services, SSH, atau WireGuard
    Saya setuju bahwa semua sertifikat SSL/TLS yang diterbitkan masuk dalam cakupan transparansi sertifikat, dan crt.sh juga punya RSS feed
    Menggunakan CAA pada umumnya ide yang bagus, tetapi saya ragu apakah itu membantu dalam kasus ini. Sebab penyerang tinggal meminta konfigurasi sertifikat persis seperti yang diizinkan oleh CAA; mungkin akan membantu jika metode validasi tertentu bisa dibatasi lebih ketat
    Saya juga setuju bahwa perubahan sertifikat SSL/TLS untuk semua layanan harus dipantau oleh layanan eksternal. Target berisiko tinggi harus selalu tahu sertifikat mana yang valid dan harus memeriksanya
    Untuk cara memantau perubahan alamat MAC gateway default, serangan yang lebih canggih bisa saja mempertahankan alamat MAC yang sama
    Saya baru tahu bahwa “channel binding” di XMPP juga bisa mendeteksi serangan man-in-the-middle yang menyajikan sertifikat valid

    • Saya penulis ACME-CAA (RFC 8657). Karena Anda bisa memasukkan pengenal unik akun ACME ke dalam record CAA, serangan seperti ini dapat dimitigasi kecuali penyerang mendapatkan private key akun ACME atau memaksa layanan ACME
      Tentu saja dengan asumsi nameserver dilindungi DNSSEC. Kalau tidak, permintaan DNS juga bisa disadap saat otoritas sertifikat melakukan lookup
      Untuk seluruh catatan keamanan, lihat RFC 8657. RFC ini dirancang agar lebih mudah dibaca daripada RFC pada umumnya
      Tulisan blog saya yang berisi penjelasan latar belakang: https://www.devever.net/~hl/acme-caa-live
    • Bagaimana kalau sebuah negara memerintahkan otoritas sertifikat di dalam negerinya untuk menerbitkan sertifikat tanpa log CT dan sekaligus memberlakukan perintah bungkam? Dalam situasi di mana tidak patuh berarti masuk penjara, sepertinya admin sistem biasa tidak akan mau masuk penjara demi melindungi server Jabber Rusia
    • Kalau punya akses fisik ke server, saya akan menargetkan sisi itu saja. Dengan sedikit usaha, disk, jaringan, dan RAM pada hardware umum bisa di-mirror

  • Kalau mereka berhasil melakukan serangan man-in-the-middle sungguhan dengan sempurna lalu lupa memperpanjang sertifikat, itu cukup khas Jerman :-)

    • Saya curiga mungkin ada orang yang sengaja “lupa”. Bisa jadi agar orang-orang mengetahui hal ini
      Atau mungkin ada seseorang yang menjalankan perintah dengan sangat patuh. Ada perintah untuk memasang sertifikat, tetapi tidak ada persyaratan untuk memperpanjangnya otomatis :)
    • Let’s Encrypt terus mengirim email pemberitahuan, bagaimana bisa begitu?

  • Arsip: https://archive.ph/C0jYJ
    Teori-teorinya menarik, dan jika benar, menjelaskan bagaimana sertifikat itu didapat. Pelajaran yang bisa diambil mungkin adalah menaruh beberapa probe di beberapa penyedia, memeriksa semua fingerprint TLS, menerima peringatan jika muncul fingerprint yang tidak dikenal, dan juga memeriksa keberadaan log transparansi sertifikat
    openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
    SHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16

    • Saya menambahkan bagian “Bisakah serangan seperti ini dicegah atau dipantau?”. Ada beberapa sinyal yang bisa dipakai untuk menemukan serangan sejak hari pertama
      Karena semua sertifikat SSL/TLS yang diterbitkan masuk dalam cakupan transparansi sertifikat, sebaiknya atur pemantauan transparansi sertifikat seperti Cert Spotter agar mendapat notifikasi email ketika sertifikat baru diterbitkan untuk domain Anda
      Dengan ekstensi record CAA dari RFC 8657, yaitu Account URI dan ACME Method Binding, Anda bisa membatasi metode validasi dan menentukan pengenal akun persis yang boleh menerbitkan sertifikat baru, sehingga penerbitan sertifikat domain melalui otoritas sertifikat, akun ACME, atau metode validasi lain dapat dicegah
      Perubahan sertifikat SSL/TLS semua layanan harus dipantau melalui layanan eksternal, dan perubahan alamat MAC gateway default juga harus dipantau

  • Saya agak penasaran karena alamat MAC-nya bukan alamat yang dikelola secara lokal. Tampaknya ada kemungkinan seseorang sengaja memilih rentang alamat ini
    https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
    Jika mencari "90:de:01" linode dan "90:de:00" linode, sepertinya alamat dari blok ini baru-baru ini juga dialokasikan ke VM Linode lain. Saat ini saya tidak punya VM Linode untuk dibandingkan langsung, tetapi tampaknya trafik dirutekan ke VM lain di infrastruktur Linode

  • Ini spekulasi tanpa dasar, tetapi menurut saya Jabber menjadi target karena terkenal dipakai di pasar darknet untuk transaksi narkoba atau aktivitas ilegal lain
    Ini menunjukkan bahwa tidak boleh hanya percaya pada “karena terenkripsi, pasti aman”. Setidaknya pesan harus dienkripsi dengan PGP
    Saya juga penasaran apakah PGP bisa dipecahkan oleh komputer kuantum, dan apakah ke depannya akan ada penguatan terhadap serangan seperti itu. Jika pesan dikumpulkan secara massal dalam bentuk terenkripsi, pada akhirnya dekripsi bisa jadi hanya soal waktu
    Dan tampaknya hal semacam ini terjadi pada hampir semua trafik web yang bisa mereka dapatkan. Lihat https://en.wikipedia.org/wiki/Utah_Data_Center

    • Jabber/XMPP sudah memiliki enkripsi end-to-end setidaknya sejak 10–15 tahun lalu. Pada masa Facebook/Google Talk masih mendukung XMPP, saya memakai pidgin, kopete, dan sejenisnya untuk menggunakannya juga dengan teman-teman biasa
      Tentu saja bertukar kunci dengan penjual narkoba anonim di internet secara aman itu rawan salah
    • Serangan man-in-the-middle ini mungkin bagian dari penutupan Genesis Market, tetapi itu hanya dugaan yang tiba-tiba saja
      https://therecord.media/genesis-market-takedown-cybercrime
    • Lapisan enkripsi kedua akan membantu, tetapi saya tidak secara khusus merekomendasikan PGP itu sendiri
      PGP punya banyak masalah dan banyak orang menyarankan untuk menghindarinya. Contoh: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780

  • Komunikasi terenkripsi end-to-end seperti OMEMO, OTR, dan PGP hanya terlindungi dari penyadapan jika kedua pihak telah memverifikasi kunci enkripsinya. Penyerang harus menyusun serangan man-in-the-middle terpisah untuk tiap metode enkripsi end-to-end yang digunakan
    Beberapa klien XMPP yang pernah saya lihat tidak mengizinkan penggunaan jika tidak menandai secara eksplisit bahwa identitas enkripsi tertentu telah diverifikasi
    Tetap saja ini pengingat yang bagus. Jika Anda belum pernah melihat dan memproses angka yang sangat panjang atau nilai sejenisnya, sulit mengatakan bahwa enkripsi end-to-end benar-benar terjadi

  • Ada satu bagian dari cerita ini yang tidak saya mengerti. Jika ini penyadapan legal, mengapa Hetzner dan Linode menyiapkan penyadapan man-in-the-middle dengan sertifikat dan kunci LE terpisah
    Padahal mereka bisa saja mengekstrak langsung private key TLS dari RAM atau penyimpanan VPS. Bahkan pada server fisik dedicated, private key bisa diambil dengan melakukan dump RAM setelah reboot tanpa pemberitahuan
    Ekstraksi private key tidak terlihat di log CT, sehingga jauh lebih diam-diam dan pada praktiknya sulit dideteksi

    • Kemungkinan besar karena cara itu lebih mudah
      Kemungkinan lain adalah satu sisi dikategorikan sebagai “penggeledahan” dan sisi lain sebagai “penyadapan”, sehingga tingkat persetujuannya berbeda. Namun saya tidak terlalu tahu situasi hukum Jerman saat ini
    • Mungkin karena cara itu “lebih ilegal”. Jika server tidak terlibat langsung dalam aktivitas kejahatan siber, sepertinya meretas server tidak diizinkan
    • Kalau server fisik, bukankah mereka bisa hot-plug kartu PCIe dan mengambil data yang diinginkan lewat DMA? Sepertinya bisa dilakukan dengan kartu jaringan yang berisi firmware khusus untuk tujuan itu
      Kedengarannya seperti metode yang terlalu standar bagi aparat penegak hukum, jadi perangkat seperti itu mungkin tersedia jadi

  • Seorang pengguna sudah memposting ini di Reddit 3 hari lalu: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...

  • Saya penasaran apakah ada cara untuk secara hukum meminta Hetzner/Linode memberi komentar tentang situasi ini. Besar kemungkinan pihak di balik penyadapan ini adalah suatu lembaga pemerintah atau kepolisian

    • Karena Hetzner adalah perusahaan Jerman, jika ini penyadapan legal, sulit meminta jawaban tanpa terlebih dahulu melalui pengacara
      Sebaliknya, jika ini bukan penyadapan legal, kecil kemungkinan Hetzner mengizinkannya. Itu juga melanggar hukum
    • Juga tidak ada jaminan bahwa penyadapan dilakukan melalui Hetzner atau Linode. Misalnya bisa saja dari sisi operator telekomunikasi, dan di hampir semua negara operator telekomunikasi sudah dipaksa bekerja sama dalam penyadapan legal sejak puluhan tahun lalu