Menyelami lebih dalam insiden keamanan Mei 2019: umpan balik entri blog

Jan 25 2021

Kami baru saja memposting pembaruan insiden keamanan yang terjadi pada Mei 2019 dengan detail teknis tentang apa yang terjadi, bagaimana itu terjadi, dan perbaikan yang kami terapkan untuk mencegah insiden seperti itu terjadi lagi. Berikut beberapa kutipan dari postingan - pertama dari pendahuluan:

Pada 12 Mei 2019, sekitar pukul 00:00 UTC, kami diberi tahu tentang eskalasi hak istimewa yang tidak terduga untuk akun pengguna baru oleh beberapa anggota komunitas. Pengguna yang tidak dikenali siapa pun telah mendapatkan akses tingkat moderator dan pengembang di semua situs di Jaringan Stack Exchange. Tanggapan langsung kami adalah mencabut hak istimewa dan menangguhkan akun ini, lalu menjalankan proses untuk mengidentifikasi dan mengaudit tindakan yang mengarah ke peristiwa tersebut.

Setelah penemuan awal, kami menemukan bahwa eskalasi hak istimewa hanyalah puncak gunung es dan serangan itu benar-benar mengakibatkan eksfiltrasi kode sumber kami dan pemaparan PII secara tidak sengaja (email, nama asli, alamat IP) dari 184 pengguna Jaringan Stack Exchange (semuanya telah diberi tahu). Untungnya, tidak ada database — baik publik (baca: konten Stack Exchange) maupun privat (Teams, Talent, atau Enterprise) —yang dieksfiltrasi. Selain itu, tidak ada bukti adanya akses langsung ke infrastruktur jaringan internal kami, dan penyerang tidak pernah memiliki akses ke data dalam produk Teams, Talent, atau Enterprise.

Dan dari paragraf terakhir:

Kejadian ini mengingatkan kami tentang beberapa praktik keamanan mendasar yang harus diikuti setiap orang:

Catat semua lalu lintas masuk Anda. Kami menyimpan log pada semua koneksi yang terikat. Ini memungkinkan semua penyelidikan kami. Anda tidak dapat menyelidiki apa yang tidak Anda catat.

Gunakan 2FA. Sistem tersisa yang masih menggunakan otentikasi lama bisa menjadi kerentanan terbesar Anda.

Jaga rahasia dengan lebih baik. TeamCity memiliki cara untuk melindungi rahasia, tetapi kami menemukan bahwa kami tidak menggunakannya secara konsisten. Mendidik teknisi bahwa "rahasia bukan hanya sandi". Lindungi kunci SSH dan string koneksi database juga. Jika ragu, lindungi. Jika Anda harus menyimpan rahasia di repo Git, lindungi dengan git-crypt atau Blackbox .

Validasi permintaan pelanggan. Semakin tidak biasa permintaan dari pelanggan, semakin penting untuk memverifikasi apakah permintaan tersebut sah atau tidak.

Tanggapi laporan keamanan dengan serius. Kami bersyukur komunitas kami melaporkan aktivitas mencurigakan dengan sangat cepat. Terima kasih!

Masih banyak lagi di postingan blog - jangan ragu untuk mengajukan pertanyaan atau komentar apa pun yang berkaitan dengan postingan di bawah ini dan kami akan melakukan yang terbaik untuk menjawabnya. Kami tidak dapat mengomentari detail lain apa pun yang terkait dengan serangan tersebut selain yang disertakan dalam entri blog, karena penyelidikan yang sedang berlangsung.

Jawaban

28 Luuklag Jan 26 2021 at 02:11

Bisakah Anda memberikan komentar tentang niat penyerang?

Apakah tampaknya mereka mengejar tujuan tertentu / data (pengguna) tertentu?

Atau mungkin ini lebih seperti "remaja yang penasaran" yang mengacungkan tongkat untuk melihat seberapa jauh mereka bisa melaju?

PS terima kasih atas keterbukaan mengenai hal ini, sangat dihargai!

27 GeorgeStocker Jan 25 2021 at 22:46

Garis ini:

Tindakan mencari sesuatu (pertanyaan kunjungan) di seluruh Jaringan Stack Exchange menjadi sering terjadi dan memungkinkan kami mengantisipasi dan memahami metodologi penyerang selama beberapa hari mendatang. (penekanan saya)

membuatnya terdengar seperti dalam waktu nyata , saat serangan itu terjadi, Anda dapat menentukan apa yang akan dilakukan penyerang berdasarkan apa yang mereka kunjungi di Stack Overflow, bukan apa yang mereka lakukan dengan melihat secara forensik pada apa yang mereka lihat (setelah serangan). Yang mana yang kamu maksud?

20 ShadowWizardisVaccinating Jan 25 2021 at 22:58

Beberapa pertanyaan terkait terutama dengan penyerang:

Apa yang terjadi dengan penyerang?
Apakah Anda menangguhkan akun mereka?
Apakah SE menghubungi penyerang kapan saja?
Mengapa Anda tidak mengungkap identitas penyerang?
Adakah orang lain yang mencoba menggunakan metode serangan yang sama ini nanti?

19 bad_coder Jan 26 2021 at 00:01

Apakah ada siklus tidur yang terdeteksi di akhir acara?

Edit untuk memperjelas:

Setelah mengetahui si penyerang, dan karena Anda mengikuti beberapa tindakan mereka saat mereka terbuka, apakah Anda melihat sesuatu yang menyerupai siklus biologis, baik dari hari ke hari maupun secara retrospektif? Misal: Makan (istirahat 1-2 jam), tidur (pola tidak aktif 8 jam), "power naps" (90 menit), dll ...?

18 MadScientist Jan 26 2021 at 17:45

Ini sebenarnya bukan bagian dari insiden, tetapi masalah yang lebih umum tentang langkah-langkah keamanan di sekitar rekening karyawan. Ada banyak langkah dalam insiden ini, tetapi yang terakhir adalah meningkatkan hak istimewa akun SE. Saya dapat membayangkan jauh lebih banyak cara langsung untuk mencoba ini daripada mendapatkan akses admin ke server CI melalui contoh dev untuk mengeksekusi SQL dalam produksi, dan saya tertarik dengan mitigasi dan praktik keamanan apa yang telah diterapkan SE untuk mempertahankan diri dari upaya sederhana untuk mendapatkan akses ke akun karyawan.

Anda tidak dapat menempatkan situs SE utama di belakang firewall dengan jelas, sehingga mereka akan selalu terekspos. Dan metode login internal SE tidak menyediakan metode 2FA apa pun, yang menurut saya agak mengkhawatirkan.

apakah akun karyawan 2FA dilindungi melalui cara lain (atau penyedia login lainnya)?
Adakah langkah-langkah untuk memastikan bahwa tidak ada alamat email pribadi atau penyedia login yang dilampirkan ke akun karyawan yang mungkin kurang aman dan masih digunakan untuk menerima email pemulihan untuk mendapatkan akses ke akun tersebut?
apakah ada pemantauan upaya login dari sumber baru untuk akun karyawan?
apakah ada perlindungan tambahan untuk alat karyawan yang berbahaya jika seseorang mendapatkan akses ke sesi berjalan dari akun karyawan (misalnya memerlukan kata sandi dan / atau token 2FA lagi saat mengakses alat penting keamanan)

Sesuatu seperti spear phishing mungkin masih merupakan salah satu cara yang lebih mungkin dilakukan seseorang untuk mendapatkan akses ke akun karyawan.

16 SonictheCuriouserHedgehog Jan 26 2021 at 03:35

Di sekitar waktu yang sama insiden keamanan ini terjadi, beberapa hari kemudian, beberapa pengguna mulai memperhatikan bahwa oneboxing Twitter di chat tidak berfungsi lagi . Seorang karyawan kemudian mengkonfirmasi pada Februari tahun depan bahwa itu memang sengaja dinonaktifkan karena harus "menutup beberapa celah" sebagai akibat dari insiden keamanan ini.

Bisakah kita mendapatkan penjelasan lengkap mengapa oneboxing Twitter di chat harus dinonaktifkan akibat insiden keamanan ini? The posting blog yang diterbitkan pada saat menyatakan bahwa "vektor potensial lainnya" telah ditutup kemudian, dan Februari 2020 staf pesan saya terkait di atas menyatakan bahwa Twitter oneboxing fitur "memanfaatkan salah satu celah kami menutup". Benda apa itu, dan risiko keamanan apa yang ditimbulkannya?

Terakhir, adakah cara agar fungsi ini dapat diimplementasikan kembali dengan cara yang aman? Pada Agustus 2020, beberapa bulan setelah pesan staf di atas, laporan bug yang diajukan pada saat itu ditandai status-bydesign oleh karyawan lain. Akankah permintaan fitur untuk mengubah desain kembali (dengan cara yang aman) dipertimbangkan, atau tidak mungkin melakukannya tanpa membuka vektor serangan?

10 Zhaph-BenDuguid Jan 26 2021 at 00:35

Saya akan menandai bahwa jenis parameter "password" di TeamCity tidak dianggap terlalu aman:

Nilai kata sandi disimpan di file konfigurasi di bawah TeamCity Data Directory. Bergantung pada Setelan Enkripsi server, nilainya bisa diacak atau dienkripsi dengan kunci khusus.

Nilai log build disembunyikan dengan algoritme cari-dan-ganti sederhana, jadi jika Anda memiliki sandi sepele "123", semua kemunculan "123" akan diganti, berpotensi mengekspos sandi. Mengatur parameter ke jenis kata sandi tidak menjamin bahwa nilai mentah tidak dapat diambil. Setiap administrator proyek dapat mengambilnya, dan setiap pengembang yang dapat mengubah skrip build berpotensi menulis kode berbahaya untuk mendapatkan kata sandi.

10 Makoto Jan 26 2021 at 06:15

Mengapa tautan ajaib dalam dev dapat dilihat oleh CM (mungkin hanya dalam dev) tautan ajaib yang nyata?

10 AnitShresthaManandhar Jan 27 2021 at 14:50

Ini benar-benar laporan insiden yang luar biasa! Salah satu yang terbaik yang pernah saya baca.

Terima kasih Stack untuk mempublikasikannya dan Dean untuk tulisan yang bagus!

Saya hanya ingin tahu beberapa hal:

Berapa ukuran tim tanggap insiden?
Apakah ada protokol khusus yang diikuti selama investigasi?
Faktor kunci apa yang terlibat untuk melibatkan vendor keamanan eksternal? Apa poin yang dipertimbangkan dalam memilih vendor tertentu?
Pelajaran apa yang dipetik dari vendor keamanan eksternal? Apakah proses audit mereka berbeda (efektif / tidak efektif) dari yang telah digunakan oleh tim?

Artikel ini memberikan gambaran sekilas tentang seluruh arsitektur Stack dan proses pengembangan. Baca lebih detail mau atau linknya kalau sudah ada artikel tentangnya alangkah bagusnya.