Bagaimana cara menonaktifkan atau menghapus akun root yang dibuat sebagai efek samping dari bug keamanan Sierra Tinggi ini?


40

Artikel ini menjelaskan bug tempat memasukkan root ketika diminta untuk membuka kunci memungkinkan setiap pengguna untuk membuka kunci preferensi sistem. Ini memperingatkan bahwa:

Tidak perlu melakukan ini sendiri untuk memverifikasinya. Melakukan hal itu akan membuat akun "root" yang dapat dimanfaatkan orang lain jika Anda tidak menonaktifkannya.

Artikel ini tidak menjelaskan apa yang harus dilakukan jika seorang insinyur yang terlalu bersemangat mereproduksi masalah dan sekarang perlu menghapus atau menonaktifkan akun root.

Bagaimana akun ini dinonaktifkan atau dihapus dengan aman?

Halaman Apple ini menjelaskan cara menonaktifkan akun tetapi ini tidak melindungi terhadap kesalahan karena kesalahan hanya dapat mengaktifkan kembali akun. Ini akan berfungsi untuk mengembalikan sistem ke kondisi normal dengan root dinonaktifkan setelah bug keamanan diperbaiki.

Pembaruan 2017-11-29 16:43 UTC

Lihat Tentang konten keamanan Pembaruan Keamanan 2017-001 untuk memperbarui macOS High Sierra untuk melindungi dari mem- bypass otentikasi administrator tanpa menyediakan kata sandi administrator.


Judul pertanyaan ini adalah XY seperti yang dinyatakan saat ini, karena menghapus atau menonaktifkan akun tidak diinginkan.
Monty Harder

Jawaban:


40

Tambalan tersedia, klik di sini, atau cukup perbarui pada mesin

Yang cukup menarik, belum ada patch untuk versi beta dan pengembang OSX sejauh yang saya tahu. Saya akan memperbarui jawaban ini segera setelah saya mendengarnya.

Unduh tambalan di atas. Meninggalkan sisa pos untuk riwayat :-)

CVE adalah CVE-2017-13872 dan NIST akan memperbarui analisis dalam waktu dekat.

Jawaban asli, relevan tanpa tambalan

Off pertama, jangan tidak menonaktifkan account root melalui GUI, memiliki "cacat" account root adalah penyebab masalah.

Anda harus mengaktifkan pengguna root dan memberinya kata sandi. Ini penting , karena kerentanan tersedia dari jarak jauh juga, melalui VNC dan Apple Remote Desktop (untuk beberapa nama) (sumber lain) .

Ada dua cara dasar untuk melakukan ini; GUI dan terminal.

Pertama, GUI

Untuk mengaktifkan akun root, buka "Direktori Utility", yaitu cmd + space dan cari. Tekan kunci untuk membuka "mode admin", lalu aktifkan akun root melalui edit -> "Aktifkan Pengguna Root".

Cara mengaktifkan root

Seharusnya meminta kata sandi root, untuk saat ini masukkan kata sandi normal Anda (jadi jangan lupa). Jika tidak meminta kata sandi, gunakan Edit -> "Change Root Password ..." di atas.

Terminal

Jika Anda lebih dari orang terminal, gunakan di bawah ini:

sudo passwd -u root
## Enter passwords as needed.... 
## (if you are using the terminal you should know what you are doing...)

Ini cukup dengan terminal, masalah dengan cara GUI adalah bahwa kita harus mengaktifkan akun untuk mengatur kata sandi, yang tidak harus kita lakukan dengan terminal.

Catatan

Bahkan jika Anda memiliki kata sandi yang ditetapkan untuk akun root, komputer Anda akan menjadi rentan jika Anda menonaktifkan akun root. Tindakan menonaktifkan akun root tampaknya menjadi penyebabnya. Jadi saya ulangi, pengguna root harus diaktifkan dan memiliki kata sandi jika menggunakan GUI, sementara melalui terminal hanya menggunakan ´passwd´ adalah "ok" (walaupun keadaan ini tidak dapat dijangkau hanya melalui GUI). Tampaknya "Nonaktifkan Pengguna Root" di "Direktori Utility" menghapus kata sandi untuk akun root, dalam arti memberi Anda akun root tanpa kata sandi yang rentan.

Sepertinya mencoba masuk dengan "root" di jendela masuk sistem memungkinkan akun root jika sebelumnya dinonaktifkan. Yaitu dengan akun root yang dinonaktifkan, Anda perlu memasukkan root dua kali dalam sistem login-windows untuk mendapatkan akses root, dan (menurut pengujian saya) pada percobaan pertama akun root diaktifkan (tanpa kata sandi jika tidak disetel melalui passwd), dan pada percobaan kedua Anda pergi.

Tampaknya masalah telah di buka sejak setidaknya 2017-11-13 (13 November), ketika disebutkan dalam forum dukungan Apple .

Tolong buktikan kalau saya salah, saya sangat menghargai kesalahan sekarang.

Pembaruan menakutkan

Setelah mengaktifkan akun root tanpa kata sandi (yaitu melalui panel preferensi sistem dan mengklik "kunci" dan memasukkan "root" dengan kata sandi kosong satu, dua atau tiga kali (jumlah kali tergantung pada keadaan awal)) dimungkinkan untuk masuk ke komputer dari layar masuk utama menggunakan "root" dan kata sandi kosong (!). SSH / Telnet tampaknya tidak berfungsi, tetapi Apple Remote Desktop, Berbagi Layar dan VNC rentan.

Jadi untuk admin jaringan mungkin menarik untuk sementara waktu mengirim paket ke port berikut:

  • 5900-5905 (ish, agar aman ninja) untuk mendapatkan port VNC yang paling umum. VNC mulai pada 5900 secara default dan menyebutkan ke atas jika Anda menggunakan beberapa tampilan (meskipun tidak umum). Berbagi Layar dan Apple Remote Desktop juga tampaknya menggunakan port ini ( daftar port perangkat lunak Apple )
  • 3283 dan 5988 untuk Apple Remote Desktop ( daftar port perangkat lunak Apple )

Bacaan tambahan:

Upaya berani untuk referensi sumber lain yang berurusan dengan masalah ini. Edit dan perbarui jawaban saya jika Anda punya lebih banyak.


5
Baiklah saya mengerti mengapa jawaban-diri itu salah. Menonaktifkan root tidak ada gunanya sampai kesalahan ini diperbaiki karena kesalahan itu sendiri hanya akan mengaktifkan kembali akun. Miliki beberapa upvotes sehingga Anda dapat berkomentar!
Freiheit

1
Saya bukan orang mac, tetapi di dunia * nix, menonaktifkan kata sandi root tidak boleh kurang aman daripada memiliki kata sandi aman. Bahkan, sangat umum untuk menonaktifkan kata sandi dan mengatur shell /dev/nulluntuk root. Dengan cara ini akses ke akun root terjadi melalui susyscalls untuk pengguna dengan izin itu.
crasic

1
@crasic AFAIK OSX melakukan sesuatu yang aneh dengan sistem login windows mereka. Mereka tampaknya mengaktifkan akun secara umum atau root secara spesifik jika dicoba. Dan hampir tidak ada dokumentasi yang tersedia untuk perilaku ini. Perhatikan bahwa spesifikasi BSD (mis. Penggunaan commandline / bash) tidak bermasalah.
flindeberg

Jadi dengan perintah Terminal, Anda dapat mengatur kata sandi root tanpa mengaktifkan root? Itu sepertinya pilihan paling aman.
wisbucky

1
@ jcm Nah, sebenarnya bukan itu hanya kata-kata yang sangat buruk setelah memindahkan teks sekitar sedikit. Saya akan mencoba sedikit mengosongkannya, lihat sebentar lagi?
flindeberg

10

Jika Anda tidak dapat menginstal tambalan resmi atau tidak ingin percaya bahwa itu berhasil, maka

Anda tidak ingin menonaktifkan pengguna root hanya di Sierra Tinggi.

Untuk mengamankan Mac Anda, aktifkan root dengan kata sandi aman yang panjang.

Kami tidak mengubah ini di tempat kerja sampai rilis poin penuh berikutnya keluar untuk macOS yang kemungkinan akan 10.13.2


Kecuali Anda mengambil tindakan, pengguna root dinonaktifkan di luar kotak dan ini buruk jika Mac Anda tidak ditambal dengan benar.

Jika Anda mau, secara opsional mengeraskan shell hingga Apple memiliki patch atau perbaikan resmi.

Berikut ini adalah skrip yang bagus untuk mengatur kata sandi root acak dan mengubah / mengatur shell root /usr/bin/falsesehingga bahkan jika kata sandi ditebak, shell root tidak dapat login:

Ini pada dasarnya melakukan tiga hal utama:

rootpassword=$(openssl rand -base64 32)
/usr/bin/dscl . -passwd /Users/root "$rootpassword"
/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false

Pembuatan UserShell adalah jika shell tidak disetel, dan skrip lengkap memeriksa shell yang ada dan -changememilihnya alih-alih -create.

Bagaimana cara melindungi diri dari kerentanan root di macOS High Sierra?


1
Secara umum lebih disukai untuk tidak menyimpan kata sandi bahkan untuk sementara waktu seperti ini. The Halaman dcsl man menunjukkan "tidak memberikan password sebagai bagian dari perintah dan Anda akan aman diminta"
Josh Caswell

1
Setuju @JoshCaswell - memilikinya dalam skrip lebih baik karena variabel tidak diekspor dan dihasilkan. Kabar baiknya adalah Apple memiliki tambalan resmi yang membuat peretasan ini menjadi kebutuhan yang singkat - kami menjalankan ini sebagai profilaksis terhadap bahaya yang jauh lebih besar dari pengodean kata sandi yang sama di seluruh armada atau tidak memiliki kata sandi sama sekali. Itu pasti kompromi dan bukan solusi.
bmike

Karena penasaran, mengapa Anda memiliki tautan ke pertanyaan ini di akhir jawaban Anda?
reirab

1
@ reirab benar-benar kacau. Lihat edit untuk memperbaiki tautan yang tepat. Terima kasih!
bmike


0

Anda harus masuk sebagai pengguna root dan mengubah kata sandi menjadi sesuatu yang kuat. Jika benar-benar membuat akun baru (sebagai lawan mengaktifkan akun root yang sudah ada) Anda harus menghapus akun itu terlebih dahulu.


Lihat jawabanku. Saran Anda untuk membuat kata sandi yang kuat masuk akal, tetapi sepenuhnya menonaktifkan akun sepertinya perlindungan yang lebih ketat dan mengembalikan OS X ke keadaan default. support.apple.com/en-us/HT204012 . Apakah pengaturan kata sandi yang kuat terhadap eksploitasi bug yang dijelaskan bahkan jika akun root diaktifkan kembali?
Freiheit

Pada High Sierra, 10.13.0 dan 10,13.1, Anda sama sekali tidak ingin menonaktifkan akun root. Masalahnya adalah jika root dinonaktifkan dan Anda mencoba menggunakan Jendela Login apa pun untuk masuk sebagai root, Jendela Masuk akan mengaktifkan akun root dengan kata sandi kosong. Jika root sudah diaktifkan dengan kata sandi yang kuat, Jendela Masuk tidak menghapus kata sandi. Satu-satunya mitigasi adalah mengaktifkan root dengan kata sandi yang kuat .
Brian Reiter

0

Apple baru saja merilis pembaruan untuk memperbaiki masalah tersebut.

Pembaruan Keamanan 2017-001 https://support.apple.com/en-us/HT208315

Juga untuk mencegah akses tidak sah ke komputer Mac Anda, Anda harus mengaktifkan akun pengguna root dan menetapkan kata sandi khusus untuk pengguna root.

https://support.apple.com/en-ph/HT204012

Jika akun pengguna root Anda sudah aktif, pastikan Anda mengubah kata sandi hanya untuk memastikan bahwa kerentanan kata sandi kosong tidak disetel.


0

Tidak! Jangan hapus akun root!

Pertama-tama, roottelah hadir di semua versi macOS, Mac OS X, Mac OS, dan bahkan versi kuno dari sistem operasi. macOS tidak baru-baru ini membuat akun ini karena kerentanan. Itu hanya mengeksposnya secara tidak sengaja.

Menghapus rootakan menjadi ide yang sangat buruk, dan biarkan saya memberi tahu Anda alasannya.

Itu benar-benar akan melumpuhkan macOS, karena tidak akan ada akun dengan hak istimewa yang cukup untuk menjalankan layanan kritis (seperti WindowServer, yang menjalankan GUI). Ada pengamanan di tempat untuk mencegah pengguna yang tidak mengerti menghapus root, dan Anda tidak boleh mencoba untuk mem-bypass mereka.

Mari cari tahu siapa yang menjalankan proses pertama dalam sistem, proses yang paling penting (menggunakan Activity Monitor):

kernel_task dan launchd juga dimiliki oleh

Hei, ini lingkungan ramah kita rootlagi! Proses pertama (dengan PID 0) sebenarnya dikendalikan oleh kernel, dan mungkin akan tetap memiliki izin penuh, tetapi proses turunannya, launchd(yang bertanggung jawab untuk memulai layanan seperti jendela masuk dan server jendela itu sendiri) dimulai dengan hak istimewa root. Jika roottidak ada, proses ini tidak akan pernah dimulai, atau tidak memiliki izin.

Mengamankan akun root

Jawaban lain telah menyediakan tambalan yang dirilis oleh Apple yang seharusnya memperbaiki masalah tersebut. Namun, jika Anda tidak dapat atau tidak mau menginstalnya ...

Ini berfungsi karena macOS mem-hash ulang kata sandi yang dimasukkan sebagai "pemutakhiran" karena akun yang dinonaktifkan (root) terdeteksi secara salah memiliki hash lama. Itu masih akan mengatakan itu salah, tetapi waktu berikutnya, hash akan cocok (karena macOS mengubahnya) dan itu akan membiarkan Anda masuk

Untuk mengamankan root, Anda harus menggunakan Utilitas Direktori. Ada dua cara untuk mengaksesnya:

  1. Gunakan Spotlight. Memulai Utilitas Direktori menggunakan Spotlight
  2. Gunakan Finder. Buka Finder, tekan Command + Shift + G (atau pilih, masuk /System/Library/CoreServices/Applications/, dan tekan Go (atau tekan Enter). Lalu buka Directory Utility dari sana.Memilih Pergi Memilih ke mana harus pergi Membuka Utilitas Direktori

Setelah Anda membuka Direktori Utilitas, Anda harus melakukannya klik kunci untuk melakukan perubahan

Setelah Anda selesai melakukannya, pilih Change Root Passwordatau Enable Root Userdari menu Edit. Saya tunjukkan Change Root Passwordkarena akun root saya sudah diaktifkan dengan kata sandi yang kuat.

Memilih Ubah Kata Sandi Root

Pilih kata sandi, dan sekarang kata sandi kosong tidak akan berfungsi lagi.

Memilih kata sandi

Selamat! Anda tidak lagi rentan terhadap peretasan root.


"Menebak dengan spekulasi murni, sistem mungkin mengaktifkan kembali akun root karena Anda memasukkan kata sandi yang benar (kosong dalam kasus ini)." - tidak tepat. Ada jalur migrasi untuk memperbarui kata sandi menggunakan mekanisme hashing lama, dan itu tidak menangani !(yang, sebagai jenis UNIX, Anda mungkin akan mengenali) dengan benar.
Charles Duffy

Lihat objective-see.com/blog/blog_0x24.html untuk analisis akar-penyebab.
Charles Duffy

Benar - jadi spekulasi saya tidak akurat. Jadi itu mem-hash ulang kata sandi kosong sebagai "peningkatan" karena akun yang dinonaktifkan salah terdeteksi sebagai hash lama? Apakah saya benar?
Dev

Secara teori, apa yang seharusnya dilakukan dalam codepath ini adalah memeriksa apakah algoritma hash yang lama memvalidasi kata sandi yang dimasukkan, dan kemudian memperbarui dengan hash baru (kata sandi yang dimasukkan, yang dikenal cocok dengan yang lama). Dalam praktiknya, ini tidak memeriksa kesalahan dari fungsi yang seharusnya mengambil hash lama dari bidang "ShadowHash" (atau, lebih tepatnya, memeriksa hanya nilai kembali, tetapi bukan nilai referensi yang dilewati yang digunakan untuk mengembalikan hasil perbandingan), dan kemudian menghasilkan hash baru dari kata sandi (kosong atau tidak!).
Charles Duffy

... jadi, cukup banyak, ya, Anda benar. :)
Charles Duffy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.