- Kelompok peretas Ukraina bekerja sama dengan badan intelijen militer untuk melumpuhkan infrastruktur TI milik Gaskar Integration, salah satu produsen drone utama Rusia
- Lebih dari 47TB data penting dan materi cadangan dihapus, sehingga operasi bisnis inti terhenti
- Sistem internal pabrik, akuntansi, dan program produksi semuanya berada dalam kondisi tidak dapat beroperasi
- Bahkan pintu masuk pabrik produksi ikut terkunci, sehingga karyawan harus keluar-masuk melalui pintu darurat
- Data yang dicuri mencakup informasi pribadi karyawan dan dokumen teknis drone, lalu diserahkan kepada Kementerian Pertahanan Ukraina
Poin utama
- Aktivis siber Ukraina bekerja sama dengan badan intelijen militer untuk menyerang jaringan dan infrastruktur server Gaskar Integration, salah satu produsen terbesar yang memasok drone ke militer Rusia
- Dalam serangan ini, lebih dari 47TB informasi teknis dan 10TB materi cadangan ikut dihancurkan; data tersebut juga memuat indikasi kerja sama erat antara Rusia dan Tiongkok
- Akibat peretasan ini, internet, program produksi, program akuntansi, dan seluruh sistem perusahaan lumpuh, sehingga pusat riset dan pengembangan Gaskar juga tidak dapat beroperasi normal
- Semua pintu masuk di pabrik produksi drone terkunci sehingga karyawan harus pulang dan berpindah melalui pintu darurat
- Informasi yang dicuri mencakup kuesioner rahasia karyawan dan dokumen teknis terkait produksi drone, dan telah diserahkan kepada para ahli di bawah Kementerian Pertahanan Ukraina
Latar belakang tambahan
- Pakar siber dari badan intelijen militer sebelumnya juga pernah menonaktifkan situs web perkeretaapian Rusia melalui serangan besar
- Sebelumnya mereka juga berhasil melakukan serangan terhadap Regiontransservice Rusia hingga seluruh layanannya terhenti
1 komentar
Komentar Hacker News
Saya menjalankan lab kecil di rumah, dengan sekitar 30 layanan.
Suatu hari saya mengganti disk utama dan membangun ulang semuanya dari nol menggunakan backup; dalam satu jam semuanya hidup lagi.
Tapi setelah itu saya menghabiskan seminggu untuk membetulkan ini-itu dan mengurus bagian-bagian yang saya sendiri sudah tidak ingat kenapa dulu dikonfigurasi seperti itu.
Ini cuma lab sederhana berbasis Docker yang dikelola satu orang, dan saya juga bekerja di bidang IT.
Tapi memulihkan seluruh infrastruktur dari nol yang telah dikelola banyak orang selama bertahun-tahun benar-benar pekerjaan besar.
Saya pernah membantu pemulihan secara sukarela saat rumah sakit terdekat terkena ransomware, dan dua staf IT di sana sama sekali tidak tahu harus berbuat apa, sementara dukungan resminya jauh dari memadai.
Saya juga pernah membantu insiden ransomware di perusahaan besar, dan upaya untuk mengingat kenapa sistem disusun seperti itu sangatlah besar.
Meski ada dokumentasi dan pengujian, di situ terasa sekali benturan dengan realitas di lapangan.
Rumah kami pernah digerebek polisi dan mereka membawa desktop, laptop, NAS, hard drive, dan perlengkapan lain senilai 10 ribu dolar.
Karena dulu di pekerjaan lama saya menangani backup dan rencana pemulihan bencana, saya sudah menyiapkan diri.
Dalam satu-dua hari sebagian besar sudah pulih dan kehilangan datanya sekitar dua hari, untungnya karena ini untuk penggunaan rumah jadi tidak fatal.
Setelah kejadian ini saya melakukan berbagai perbaikan struktural, sehingga kalau hal seperti ini terjadi lagi dampaknya akan lebih kecil.
(Lalu 8 bulan kemudian polisi menyimpulkan saya tidak bersalah dan mengatakan peralatan saya boleh dikembalikan, tapi anak-anak sudah telanjur mengalami trauma.)
Inilah alasan dokumentasi sangat penting, dan hal yang sama berlaku di tingkat arsitektur perangkat lunak.
Setelah beberapa bulan, sangat mudah lupa kenapa saya membuat pilihan tertentu.
Misalnya, "kenapa saya memutuskan memakai Kysely untuk tool ORM/SQL", "kenapa memakai Deno/Bun", "kenapa struktur folder dibuat per fitur", "kenapa sebuah library di-fork dan bagaimana mengelolanya", "kenapa memilih AWS/GCP/Azure/Docker", "kenapa memilih distro Kubernetes tertentu", "kenapa proyek ini dimulai dan apa tujuannya", dan seterusnya.
Karena itu saya membuat bagian
# Decisionsdi README.md untuk mendokumentasikannya.Berkat itu saya terbebas dari terus-menerus meragukan keputusan sendiri sambil membongkar dokumen tanpa akhir.
Mainframe tahun 90-an sangat stabil dan punya redundansi yang bagus, jadi ada kasus tidak direboot lebih dari 10 tahun, bahkan upgrade kernel tanpa downtime pun bisa dilakukan.
Tapi di suatu perusahaan pernah terjadi pemadaman listrik, lalu generator cadangan juga gagal, dan saat listrik kembali butuh berbulan-bulan untuk memahami sebenarnya mesin itu sedang melakukan apa dan bagaimana cara memulainya lagi.
Setelah itu kebanyakan perusahaan mulai sengaja me-reboot mainframe setiap 6 bulan sekali untuk menguji proses startup ulang.
Dalam praktik IT modern, pemulihan bencana hampir tidak dipertimbangkan.
Bahkan organisasi yang backup-nya ketat pun jarang benar-benar menguji proses pemulihan.
Karena kekurangan orang, mereka cuma terus menumpuk sesuatu dengan cepat.
Merancang infrastruktur yang mudah dibangun ulang butuh dua kali lipat usaha dibanding sekadar memasangnya.
Saya penasaran soal cerita sukarelawan ransomware di rumah sakit itu.
Di healthcare IT, hak akses biasanya ditangani sangat ketat, jadi dulu tanpa pelatihan PHI atau pemeriksaan latar belakang rasanya mustahil mendapat akses ke sistem. Saya ingin tahu apakah karena situasi darurat maka dilakukan proses onboarding sementara dengan cepat, atau Anda bisa jadi relawan lewat koneksi internal di rumah sakit.
Saya bekerja di perusahaan Jerman.
Manajemen produksi menjalankan rencana yang dicetak dari Excel untuk 3 bulan ke depan.
Migrasi sistem ERP gagal, dan tidak ada yang tahu cara memperbaikinya.
Departemen manajemen produksi menyembunyikan fakta ini dan bahkan tidak memberi tahu departemen engineering.
Situasi ini sepertinya akan berlanjut bertahun-tahun; para konsultan hidup dari sistem seperti ini.
Ini membuktikan bahwa infrastruktur IT tidak mutlak diperlukan untuk manufaktur; tanpa itu pun masih bisa jalan, hanya saja lebih enak kalau ada.
Pada akhir 90-an hingga awal 2000-an, Kementerian Pertahanan Denmark mencoba memperkenalkan DeMars, sistem pengadaan baru berbasis SAP.
Seorang teman saya yang menangani pengadaan memesan persediaan dalam jumlah sangat besar tepat sebelum DeMars diterapkan, sampai pernah dipanggil karena dicurigai melakukan penipuan.
Itu karena ia sangat tidak percaya pada DeMars dan menilai menjaga stok akan sangat penting.
Dan benar saja, setelah DeMars diterapkan, fungsi pengadaan praktis berhenti selama setahun.
Pada akhirnya, hanya barang-barang yang ditangani teman saya itulah yang stoknya tetap tersedia sepanjang masa transisi ke sistem baru.
Saya dulu bekerja sebagai pengembang firmware di perusahaan manufaktur pada akhir 90-an.
Itu masih masa ketika semuanya dicatat di kertas.
Di perusahaan kami sempat berhasil membangun ERP berbasis Oracle dan semua orang senang, tapi 6 bulan kemudian seseorang menabrakkan forklift ke dinding ruang mesin, memicu kebakaran di UPS, dan tiga rak peralatan termasuk server Oracle habis terbakar.
Karena semua orang tidak benar-benar percaya pada sistem dan masih mencatat di kertas, sampai saya keluar 6 tahun kemudian kami tetap bekerja dengan laporan kertas + Excel.
Pada akhirnya, metode berbasis kertas terbukti tahan terhadap forklift.
Excel bisa dipahami dan diubah secara intuitif oleh banyak pekerja kantoran.
Kalau sebagian besar infrastruktur IT punya fungsi yang seaksesibel itu, rasanya akan jauh lebih praktis.
Di sisi lain, ketika otomatisasi IT sudah benar-benar tertanam dalam produksi dan tidak ada lagi orang yang terbiasa dengan cara manual sebelumnya, kembali ke cara kerja manual bisa sangat sulit.
Tentu ini tergantung kompleksitas pesanan/workflow-nya.
Tanpa software, drone juga tidak ada gunanya.
Kalau stok komponennya sudah di luar kepala, mungkin masih bisa merakit quadcopter kendali manual, tapi produksi part 3D printing, penerbangan stabil, operasi otonom, pengawasan, dan penggunaan canggih lainnya akan mustahil.
Kendali jarak jauh pun akan sulit.
Perang siber di Ukraina sedang mencapai tingkat baru; ini sudah melampaui sekadar serangan siber biasa.
Seperti fasilitas manufaktur drone Rusia yang kali ini diserang, drone telah menjadi elemen kunci yang mengubah wajah perang ini.
Drone membawa inovasi dalam pengintaian, gangguan, intersepsi amunisi, dan lain-lain.
Daya rusaknya besar dibanding materialnya, dan dengan kemajuan teknologi pengenalan citra, sebagian masih bisa berfungsi meski sinyal diganggu.
Rasanya seperti realitas dari film mata-mata.
Ini menunjukkan bahwa Ukraina sangat mahir dalam perang asimetris.
Dengan menghancurkan pembom jarak jauh dan melumpuhkan basis produksi drone, mereka mengguncang kekuatan utama Rusia.
Saya tidak tahu bagaimana perang ini akan berakhir, tapi jelas perlawanan Ukraina akan terus berlanjut.
Dalam novel Ministry of the Future, drone berkembang begitu jauh sampai perang tradisional akhirnya kehilangan makna, karena dunia menjadi tempat di mana tak seorang pun benar-benar aman.
Kelompok kecil pun bisa membunuh siapa saja di mana saja di dunia.
Menarik sih, tapi ceritanya lemah jadi saya tidak terlalu ingin merekomendasikan bukunya.
Soal “drone yang tetap berfungsi meski ada gangguan sinyal elektronik”, sekarang ada juga drone yang dikendalikan lewat kabel serat optik alih-alih gelombang elektromagnetik, dan itu realitas yang bahkan lebih menakutkan.
Bahwa drone memainkan peran penting dalam perang ini belum tentu akan berlaku juga untuk perang-perang lain ke depan.
Situasi khusus Rusia yang terus maju sedikit demi sedikit sambil menerima korban jiwa sangat besar ikut menaikkan nilai drone FPV.
Kebanyakan negara tidak akan menerima tingkat kerugian seperti itu, jadi saya rasa bentuk ini tidak akan menjadi standar perang.
Drone jet jarak jauh yang murah justru mungkin akan memainkan peran yang lebih penting.
Informasi dalam artikel itu banyak bercampur dengan asumsi.
Kita hanya mendengar cerita dari satu pihak, dan nilainya untuk propaganda bisa membuat semuanya dibesar-besarkan.
Kalau version control dikelola dengan baik, biasanya tiap pengembang punya salinan lokal kode dan file CAD.
Email dan file office mungkin hilang, tapi kemungkinan besar itu bukan kerugian yang fatal.
Website-nya juga masih berjalan seperti biasa.
Perusahaan yang diserang kali ini juga bukan nama besar yang terkenal di komunitas drone, jadi sepertinya bukan soal berhentinya produksi model skala besar.
Rasanya mereka pasti tahu hal-hal dasar seperti version control, dan gaya komentar itu malah terasa seperti ditulis ChatGPT.
Saya bekerja di perusahaan menengah di Swiss.
Kami sedang mengembangkan ERP internal, dan stack-nya benar-benar seperti mimpi buruk.
Kami menyebutnya sendiri sebagai ‘security through chaos’.
Bahkan kalau penyerang berhasil masuk, mereka tidak akan bisa keluar lagi.
Meski 90% kode dihancurkan, layanan tidak akan terpengaruh, karena 95% kodenya memang sudah tidak berguna.
Saya pernah punya pengalaman mengembangkan sendiri sistem MRP untuk perusahaan besar, jadi saya penasaran bagaimana hasil pendekatan ini nanti.
Saya biasanya bahkan menambahkan layer autentikasi kunci berbasis OTP-hash di atas praktik keamanan/pemulihan bencana yang direkomendasikan.
Saya pikir saya sudah tergolong ekstrem, tapi sistem ini terasa seperti skenario bertahan hidup kiamat.
Kesan saya ini seperti ketahanan yang lahir lewat proses evolusi.
Lucu juga karena rasanya seperti penghalang ICE di dunia nyata.
Menakutkan, tapi sekaligus mengagumkan juga.
Sebagian besar perusahaan tidak benar-benar siap menghadapi situasi di mana hampir semua penyimpanan data perusahaan terhapus total dan semuanya harus dideploy ulang dari nol.
Kalau Anda belum pernah benar-benar mencoba pemulihan dari nol, kemungkinan besar ada ketergantungan deployment yang membentuk lingkaran.
Anda mulai dengan mendeploy config pusher lewat Jenkins/Puppet/Ansible, lalu pada titik tertentu Jenkins sendiri ikut bergantung pada config pusher, sehingga tidak bisa lagi dibangun satu per satu secara berurutan dan Anda terpaksa menelusuri ulang seluruh riwayat perubahan sejak dulu.
Di IT, hampir semua bagian punya ketergantungan melingkar.
SSO menjadi dependensi hampir semua sistem, lalu di dalam SSO sendiri muncul struktur melingkar dengan jaringan dan pengelolaan berbagai sistem.
Menyalakan semuanya lagi dari benar-benar nol selalu sulit dan memakan waktu.
Kecuali membangun dua infrastruktur yang sepenuhnya terpisah, praktis mustahil menyelesaikan masalah ini secara sempurna.
Salah satu perusahaan yang saya tahu juga mengalami hal seperti ini setahun lalu.
Klaster storage utama yang menjadi tumpuan segalanya mati.
Akhirnya mereka memulihkan semuanya dengan redeploy dari laptop para developer.
black start(pemulihan dari kondisi benar-benar kosong) adalah masalah yang sangat sulit.Facebook pun pernah harus mengebor langsung kunci pintu data center untuk masuk dan memulihkan sistem.
Saya penasaran bagaimana sebenarnya pemulihan dalam situasi seperti ini dilakukan.
Kalau masih ada dokumentasi di kertas, apakah itu cukup untuk bootstrap, atau kita harus menganggap bahkan itu pun sudah hilang?
Industri konstruksi juga menghadapi masalah serupa.
Umur produk bisa lebih dari 50 tahun, kadang sampai ratusan tahun, tapi file desain yang dibuat 30 tahun lalu sering tidak bisa dibuka sekarang karena masalah kompatibilitas format file.
Orang sudah bicara soal digitalisasi sejak puluhan tahun lalu, tapi pada akhirnya gambar 2D lama (atau sekarang PDF yang disebut ‘kertas digital’) mungkin justru akan membantu di masa depan.
Penggunaan kertas fisik memang terus berkurang, tetapi karena masalah kompatibilitas file, bisa jadi kertas akhirnya kembali berguna.
Di judul artikel para pelaku disebut ‘aktivis siber’, sementara di isi artikel disebut ‘penjahat siber’.
Ini mengingatkan saya pada privateer atau surat marque pada masa kapal layar dulu, orang-orang yang beroperasi di area abu-abu antara resmi dan tidak resmi.
Dalam teori perang generasi keempat, kaburnya batas sipil-militer memang menjadi salah satu cirinya.
Aturan keterlibatan pun makin kabur.
Rusia membunuh warga sipil setiap hari dengan drone.
Ini bukan area abu-abu ambigu seperti perang hibrida, hanya warga yang berusaha agar tetangganya tidak menjadi korban drone.
Sepertinya ini masalah terjemahan.
Situs tersebut cukup kuat keberpihakannya pada Ukraina, jadi mungkin mereka tidak ingin membuat para hacker terdengar negatif dan memakai ‘cyber criminal’ sekadar dengan makna ‘hacker’ biasa.
Kenyataannya, yang paling masuk akal adalah ini bergerak secara terorganisasi dari pihak militer Ukraina.
Jadi rasanya memang tidak tepat menyebut mereka penjahat.
Ini agak seperti Robin Hood.
Bagi sebagian orang mereka pahlawan, bagi yang lain penjahat.
Mungkin artikelnya sendiri merupakan gabungan beberapa artikel sehingga istilahnya tercampur.
Akan bagus kalau ada istilah tersendiri untuk membedakan kubu dalam perang siber.
“Cyberactivist” terdengar seperti demonstran online, jadi alih-alih istilah klise ala film, saya berharap ada istilah seperti “cybersoldier” atau “network militia”.
Saya diam-diam merasa lucu melihat tanggal pada foto artikel itu selisih satu hari dari awal Unix epoch.
Website terkait sangat unik.
Pemerintah Rusia memblokirnya sehingga muncul error TLS, dan bahkan setelah melewatinya masih ada halaman "Blocked" dari Cloudflare; baru dengan VPN artikel aslinya (dalam bahasa Rusia) bisa diakses.
Halaman yang ditautkan memang berbahasa Inggris, tapi mungkin warga lokal Rusia memang bukan target versi Rusia dari situs itu.
Di Rusia orang sensitif soal bahasa, tetapi di Ukraina bahasa Rusia juga masih banyak digunakan dan artikel berbahasa Rusia pun memang diterbitkan.
Saya sangat menyarankan memakai situs arsip seperti archive.today, archive.org (Internet Archive), dan sejenisnya.
Tautan arsip juga baru-baru ini sudah disimpan seseorang.
Ini mungkin bukan masalah dari websitenya sendiri, melainkan karena pemblokiran pemerintah atau masalah di sisi CloudFlare.
Bisa jadi Cloudflare memblokirnya justru karena akar penyebab error TLS tersebut.
Saya penasaran apakah kedua pihak juga khawatir soal firmware drone.
Menyisipkan firmware yang sudah dimodifikasi secara diam-diam ke drone yang dipakai musuh tampaknya bisa sangat bernilai secara strategis.
Menarik, tapi risikonya besar (mudah ketahuan dan bisa melumpuhkan seluruh operasi).
Pada akhirnya saya rasa pendekatan yang keras lebih masuk akal.
Firmware drone biasanya di-flash tepat sebelum misi.
Bahkan mungkin lebih efektif daripada menutup pabrik kalau drone-drone itu diam-diam bertindak lain, misalnya menyerang markas sendiri saat peluncuran atau berada di bawah kendali jarak jauh.
Salah satu strategi menarik yang pernah saya dengar adalah menanam virus di kartu SD drone, sehingga ketika drone jatuh di wilayah musuh lalu kartu itu dicolok ke komputer mereka, komputer tersebut ikut terinfeksi.
“Aktivis siber Ukraina bekerja sama dengan badan intelijen militer...”
Artinya, mereka hanya menerima sinyal dari badan intelijen luar negeri sehingga ini bukan perang siber langsung.
Menanggapi pendapat bahwa “karena hanya menerima sinyal dari badan intelijen luar negeri maka ini bukan perang siber langsung”:
badan intelijen Rusia sendiri sudah menyerang negara-negara NATO secara langsung, jadi hampir tidak ada ruang untuk alasan pembenaran.
Ukraina dan Rusia sudah berperang selama bertahun-tahun, jadi tidak perlu lagi berpura-pura punya
deniabilityyang masuk akal.Saya penasaran apa yang dimaksud dengan badan intelijen asing, dan faktanya di seluruh dunia serangan semacam ini memang berlangsung terus-menerus, jadi jangan berpikir terlalu naif.
Ada yang menunjukkan bahwa artikel itu tidak menyebut “badan intelijen asing”.
Yang disebutkan jelas adalah badan intelijen militer Ukraina.