Akun uji Microsoft yang diretas ternyata memiliki hak admin

• Pelanggaran Microsoft ini lebih serius daripada sekadar pembajakan akun karena akun uji lama tanpa MFA berujung pada akses ke email eksekutif senior serta tim keamanan dan hukum
• Kelompok yang berafiliasi dengan negara Rusia, Midnight Blizzard, masuk ke “legacy non-production test tenant account” dengan mengeksploitasi kredensial lemah melalui password spraying
• Penyerang kemudian menggunakan izin aplikasi OAuth dari tenant uji yang telah dikompromikan untuk memperoleh peran full_access_as_app di Office 365 Exchange Online
• Karena pemberian full_access_as_app memerlukan hak administrator, muncul kritik bahwa akun uji itu adalah salah konfigurasi yang memiliki hak berlebihan di lingkungan produksi
• Akun uji yang menyimpang dari prinsip hak akses minimum serta password spraying berbasis proksi residensial membuat deteksi berbasis indikator kompromi yang ada menjadi lebih sulit

---

Dari akun uji ke akses email

• Peretas negara Rusia masuk ke “legacy non-production test tenant account” dengan mengeksploitasi kredensial lemah melalui password spraying
• Akun uji tersebut tidak dilindungi oleh autentikasi multi-faktor
• Setelah itu, diperoleh hak yang memungkinkan akses ke akun email eksekutif senior Microsoft serta staf tim keamanan dan hukum
• Kelompok penyerang Midnight Blizzard menyalahgunakan protokol autentikasi OAuth untuk mempertahankan akses ke akun email yang memiliki hak istimewa
  • Mereka membuat aplikasi berbahaya di tenant uji yang telah dikompromikan
  • Mereka memberi aplikasi tersebut izin untuk mengakses semua alamat email di layanan email Microsoft Office 365
  • Mereka menggunakan aplikasi OAuth uji yang sudah ada untuk memberikan peran full_access_as_app di Office 365 Exchange Online

Akun uji legacy dengan hak administrator

• Pembaruan Microsoft mencakup keterangan bahwa “legacy test OAuth application” memiliki elevated access di Microsoft corporate environment
• Menurut Kevin Beaumont, untuk memberikan peran full_access_as_app ke aplikasi OAuth, akun tersebut harus memiliki hak administrator
• Beaumont menilai konfigurasi ini sebagai “salah konfigurasi yang cukup besar di produksi”
• Muncul kritik bahwa sulit membayangkan alasan yang masuk akal untuk memberikan dan mempertahankan hak seluas itu pada akun uji legacy yang sudah lama
• Microsoft menolak menjelaskan mengapa akun uji itu sejak awal dikonfigurasi seperti itu, dan mengapa tetap dipertahankan setelah menjadi legacy

Konfigurasi yang melanggar prinsip hak akses minimum

• Konfigurasi ini melanggar prinsip hak akses minimum, yaitu bahwa akun seharusnya hanya memiliki hak minimum yang diperlukan untuk menjalankan tugasnya
• Inti masalahnya adalah sulit dipahami mengapa akun uji legacy harus memiliki hak administrator
• Beaumont mengibaratkan ini seperti menaruh pengguna Domain Admin dari sistem produksi di domain uji yang tidak memiliki keamanan, MFA, firewall, maupun pemantauan
  • Pengguna Domain Admin memiliki hak administrator penuh atas perangkat yang terhubung ke jaringan, termasuk domain controller dan Active Directory
  • Karena ini adalah akun paling kuat di jaringan, akun tersebut seharusnya diisolasi dan jarang sekali menjadi bagian dari sistem produksi
  • Jika akun seperti ini dibiarkan tanpa kata sandi kuat dan langkah keamanan standar, dampaknya bisa sangat besar

Pelanggaran di organisasi lain dan password spraying yang tersembunyi

• Microsoft mendeteksi bahwa Midnight Blizzard juga telah membobol organisasi lain, dan memberi tahu organisasi yang terdampak
• Hewlett-Packard Enterprises juga mengungkap bahwa jaringannya diretas oleh Midnight Blizzard
  • Pelanggaran tersebut terjadi pada Mei
  • Penemuan dan pemblokirannya baru dilakukan pada Desember
• Password spraying yang digunakan untuk mengakses akun uji dilakukan terhadap sejumlah akun terbatas dengan sedikit percobaan per akun
• Penyerang membuat aktivitas jahat mereka kurang menonjol dengan infrastruktur proksi residensial yang tersebar
  • Mereka mengakses dari alamat IP yang bereputasi baik
  • Mereka menggunakan alamat IP yang berada di wilayah yang diharapkan
  • Mereka membuat lalu lintasnya tampak bercampur seperti trafik pengguna sah

Batasan deteksi berbasis indikator kompromi yang ada

• Metode menggunakan proksi residensial bukan teknik baru, dan juga digunakan dalam serangan rantai pasok SolarWinds pada 2020
• Serangan SolarWinds juga dikaitkan dengan Midnight Blizzard
• Karena proksi residensial merutekan trafik melalui banyak IP pengguna sah, deteksi tradisional berbasis indikator kompromi menjadi sangat sulit dalam praktiknya
• Midnight Blizzard adalah kelompok yang menurut pemerintah AS dan Inggris bekerja untuk badan intelijen luar negeri Rusia, SVR
• Nama lain yang digunakan untuk melacak kelompok yang sama adalah APT29, the Dukes, Cloaked Ursa, UNC2452, dan Dark Halo

[GN⁺]

Komentar Hacker News

• Ini mengingatkan pada peretasan Roblox lama yang pernah saya dengar. Ada situs staging non-produksi yang memungkinkan pendaftaran pengguna, dengan banner bertuliskan “apa yang ada di sini tidak permanen”
  Sebuah akun admin baru ditambahkan ke lingkungan produksi, lalu seseorang mendaftar di situs staging dengan nama pengguna yang sama, kemudian menggunakan cookie dan tokennya untuk mengambil alih akun produksi dan membobol situs
  Kalau token kriptografis dibuat berdasarkan nama pengguna atau ID pengguna tanpa memakai secret yang berbeda untuk produksi/staging, atau kalau situs staging berkomunikasi dengan layanan eksternal lalu bercampur dengan otorisasi produksi, masalah seperti ini rasanya tidak terlalu jarang terjadi

  • Dulu saya pernah mengimplementasikan API pengiriman untuk e-commerce dan mengintegrasikannya dengan layanan seperti DHL. Kami lupa beralih ke server produksi, jadi selama beberapa bulan kami mengirim dengan label yang dicetak dari API testing; barangnya terkirim, tetapi tidak ditagih
    Begitu sadar, kami langsung memberi tahu mereka apa adanya
  • Karena itulah ada field audience di token

• Di perusahaan besar, batas antara pengembangan/produksi jauh lebih berlubang daripada yang orang ingin bayangkan
  Bayangkan hari kerja yang umum: login ke PC, memeriksa email, lalu login ke portal Azure dengan kredensial yang sama. Pada akhirnya semuanya terikat ke tenant yang sama, dan akun juga terhubung ke GitHub serta akun cloud
  Groups dan Teams dibuat di mana-mana, dan hal-hal yang muncul demi memakai Teams atau OneDrive dengan izin mencurigakan tetap berada di direktori perusahaan, nyaris tidak bisa dibedakan dari security group
  Sesekali ada email otomatis “apakah ini masih diperlukan”, tetapi pesannya tidak jelas, dan di perusahaan yang sangat besar tidak ada orang yang jelas untuk ditanya. Helpdesk baru menjawab dua hari kemudian, dan kita juga tidak bisa bertanya kepada John Savill di Twitter, jadi akhirnya cukup klik konfirmasi dan lanjut
  Pada akhirnya kain organisasi mulai robek, dan penyerang beruntung masuk lewat titik lemah, melakukan lateral movement di dalam tenant, lalu mengambil apa yang mereka mau
  Seperti kata seorang CISO yang bijak, peretas tidak membobol masuk; mereka login

  • Menarik karena asumsi “umum” di sini cukup berani
    Tentu saja seolah-olah semua orang memakai Microsoft cloud, Skype, Twitter, OneDrive, dan bahkan menyisipkan nama seseorang agar terdengar meyakinkan

• Menanggapi ucapan Kevin Beaumont bahwa “hanya akun dengan hak admin yang bisa memberi peran full_access_as_app yang hampir punya kuasa penuh kepada aplikasi OAuth. Seseorang membuat kesalahan konfigurasi yang cukup besar di lingkungan produksi,” kalau dilihat tanpa mengetahui detail sistemnya, itu tidak tampak seperti masalah inti
  Seharusnya tidak ada cara untuk membuat kesalahan seperti itu. Orang yang merancang dan mengoperasikannya seharusnya membuatnya mustahil, dan tanggung jawabnya ada di sana
  Jika Anda membangun dan menjalankan pabrik yang punya tombol untuk menyetrum semua orang di dalamnya, lalu seseorang tidak sengaja menekan tombol itu, sudah jelas di mana letak masalahnya

  • Ini kemungkinan besar bukan masalah teknis. Secara teknis mungkin ada sekitar 20 praktik terbaik dan pengaman untuk mencegahnya, tetapi guardrail seperti itu hanya berarti jika organisasi, kepemimpinan, dan birokrasi peduli
    Selama bertahun-tahun saya beberapa kali diminta mengabaikan semua kebijakan, prosedur, aturan, dan hukum, lalu memberi hak super admin/root kepada VIP yang sama sekali tidak membutuhkan izin semacam itu
    Sekarang makin buruk karena semua pekerjaan menjadi seperti jabatan rangkap lintas fungsi, paruh waktu, peran ganda, peran tiga lapis
    Saya juga pernah melihat role-based access control yang jumlah perannya lebih banyak daripada izin nyata yang bisa diberikan. Kalau begitu tujuan RBAC runtuh dengan sendirinya. Memberikan izin secara individual sebenarnya lebih cepat, tetapi itu tidak diizinkan karena peran tidak akan muncul di laporan
    Hal seperti ini bukan datang dari orang teknis, melainkan dari kepemimpinan yang buruk
    Dulu saya pernah merancang ekstensi untuk sistem izin RBAC ERP internal guna meredakan masalah ini. Ada tipe bernama “pengecualian izin”, dan orang yang membutuhkan izin di luar perannya ditetapkan lewat cara itu, sehingga bisa dibuat laporan daftar orang yang dapat melakukan pekerjaan di luar peran jabatan mereka
    Pada akhirnya itu hanya menambahkan satu flag pada izin, tetapi bekerja dengan baik. HR meninjau pengecualian izin tiap kuartal untuk mempertimbangkan penghapusan, dan alih-alih helpdesk paruh waktu membongkar-bongkar izin lewat coba-coba, pihak berwenang yang benar-benar paham bisa mengendalikannya
  • Saya penasaran bagaimana caranya membuat kesalahan konfigurasi menjadi mustahil

• Lucu juga, ada begitu banyak sertifikasi keamanan keren yang katanya melindungi perusahaan dan industri dengan risiko yang dapat dikuantifikasi, tetapi praktik terbaik yang rasional dan penuh pertimbangan dari buku seharga 36 dolar di Amazon justru diabaikan total
  Keamanan terlihat seperti semacam kampanye pita

  • Keamanan adalah proses, bukan produk
    Orang yang menjual keamanan seperti produk sedang menipu
  • Walau saya punya sertifikasi keamanan, 1.000 karyawan lain mungkin tidak punya
    Karyawan biasa hampir tidak peduli pada keamanan itu sendiri dan hanya mengerjakan pekerjaan mereka
    Ada terlalu banyak server, aplikasi, dan konfigurasi, sehingga karyawan yang sadar keamanan saja tidak cukup untuk meninjau semuanya
    Kalau diamati cukup lama, di perusahaan mana pun pada akhirnya akan ada sesuatu yang terbuka padahal seharusnya tidak. Itulah yang dilakukan kelompok peretas: terus mencari celah
    Perusahaan harus terus membuat server dan konfigurasi baru saat beroperasi, jadi ini bukan masalah yang bisa diatur sekali lalu selesai
  • Saya penasaran buku yang mana

• Saya benar-benar tidak suka ketika di tempat kerja baru seseorang memberi banyak izin sambil berkata “ini lebih mudah.” Jangan lakukan itu
  Itu bukan hanya membuat perusahaan terekspos pada pembobolan, tetapi juga melemparkan tanggung jawab yang tidak saya inginkan kepada saya. Saya bisa saja tidak sengaja merusak sesuatu yang penting, dan jika sesuatu diretas, orang bisa mencurigai saya hanya karena saya punya izin itu

  • Kalau memikirkan banyaknya akun dan izin di berbagai layanan yang harus dikelola untuk tiap karyawan, alur seperti itu juga terasa seperti evolusi yang wajar
    Pada dasarnya kita sedang mengalami semacam popup keamanan Windows XP di tingkat layanan. Di setiap langkah pekerjaan, kita diminta mengautentikasi ke sesuatu yang berbeda, dan bisa butuh berhari-hari sampai mendapatkan kredensial yang tepat dengan izin yang sesuai
    Secara manusiawi, bisa dimengerti juga jika tim dukungan menyerah lalu melemparkan akun dan izin sekaligus kepada karyawan baru

• Bagian yang terlewat dari tulisan ini adalah bagaimana penulis mendefinisikan “produksi” jika akun non-produksi memiliki hak admin domain produksi

  • Menurut saya ini inti masalahnya. Tulisan dan kutipan menyebutnya “kesalahan”, tetapi di organisasi sebesar dan serumit Microsoft, penetapan hak akses yang keliru menurut saya tidak terhindarkan
    Jadi berfokus pada sudut pandang bahwa “di perusahaan berisi 220 ribu orang, pada suatu titik seseorang melakukan kesalahan” tidak terlalu membantu
    Namun di kebanyakan perusahaan biasanya ada garis pemisah yang kuat dan tebal antara sistem produksi dan sistem uji. Memberikan akses produksi ke akun uji seharusnya nyaris mustahil, jadi fokus investigasinya seharusnya bagaimana hal seperti itu bisa terjadi

• Saya pernah melihat kasus yang lebih parah. Saya bekerja di firma hukum yang memberi para admin dan partner akses administrator ke semuanya
  Setelah reset kata sandi, kata sandi default-nya adalah “passme”, dengan alasan kata sandi asli terlalu panjang dan sulit diingat. Mereka seharusnya mengganti kata sandi setelah login ke server
  Peretas mengambil alih beberapa akun mereka, mengutak-atik berbagai hal, dan mencuri data. Beberapa akun uji juga punya hak admin
  Untung saya tidak lagi bekerja di sana. Saya adalah programmer analyst dan hanya punya hak admin atas PC saya sendiri agar Visual BASIC 6.0 bisa berjalan

• Pola seperti ini di seluruh ekosistem Microsoft lebih mirip aturan daripada pengecualian, tetapi fakta bahwa Microsoft sendiri melakukannya sangat memalukan
  Tim keamanan Microsoft telah mencurahkan banyak upaya untuk alat dan dokumentasi praktik terbaik guna mencegah insiden besar seperti ini

  • Saya penasaran bagaimana akun uji awalnya diretas. Mungkin tidak ada autentikasi multifaktor, lalu setelah password spraying melalui alur OAuth ROPC, terjadi pergerakan lateral
    Penegakan autentikasi multifaktor di M365 cukup buruk. Strukturnya mengharuskan Anda membayar
  • Hal seperti ini terjadi di mana-mana. Cara pengujian banyak orang yang pernah bekerja dengan saya hampir selalu berupa pemberian hak akses maksimum. Entahlah, rasanya seperti debugging ala shotgun
    Masalah yang lebih besar adalah orang-orang lupa. Mereka membuat lima akun uji dengan hak admin, dan itu tidak terlihat sampai seseorang melakukan audit hak akses pengguna di seluruh perusahaan

• Perusahaan tempat saya dulu bekerja menyimpan semua kata sandi server produksi dan database dalam file teks di repositori kode. Alasannya, arsitek utama tidak mau mengingat kata sandi
  Ketika saya memberi tahu CTO betapa bodohnya hal itu, jawabannya adalah “kami memercayai karyawan” dan “kami lolos audit keamanan”
  Sampai sekarang efek facepalm itu masih terasa

  • Saya juga tidak suka kata sandi database. Terlalu cepat di-crack
    Itu hanya elemen yang menyebalkan, bukan fitur keamanan. Saya tidak memakai kata sandi seperti “c00lz500”, melainkan sesuatu seperti string kosong
    Sebagai gantinya, saya menggunakan firewall dan jaringan internal